Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[vitaly75]

I've just came across the following problem with my DSR-500N. It does not respond to ARP packets where source and destination IPs are from different subnetworks.
In my case ARP packets to WAN1 with real IP come from 192.168.x.x address in provider's network. This seems a bit strange from first look, but https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt (variable arp_announce) says that by default linux kernel is allowed to put any local address in ARP request. and this is what my provider does. I've check other devices on the same port: desktop linux, windows, etc, and they DO RESPOND to these packets.
Exactly following variable in the same document mentions that by default linux is supposed to answer these requests, if not configured in non standard way. I was really surprised to see non standard value of 2 there for all interfaces on my dlink, meaning that my device will never work among others configured by default.
I have not found any description of this modification in router docs, same as no webui checkbox to disable this and return to default behavior.
I have no arguments to convince my provider to put 2 at his side as well. His response is that his HW has behavior recommended by default and all other clients are happy. Does anyone want to buy my DSR-500N   for cheap?
Vitaly

[FurryNutz]

Link>Welcome!

• What Hardware version is your router? Look at sticker under router.
• Link>What Firmware version is currently loaded? Found on the routers web page under status.
• What region are you located?

"It does not respond to APR packets where source and destination IPs are from different subnetworks.
In my case ARP packets to WAN1 with real IP come from 192.1"
APR? or ARP packets?

[vitaly75]

HW - A1
SW - 1.08b51_WW
Region - Ukraine

ARP, fixed

[FurryNutz]

I recommend that you phone contact your regional D-Link support office and ask for help and information regarding this. We find that phone contact has better immediate results over using email.
Let us know how it goes please.

[vitaly75]

Hi,

Yes, I contacted local representatives. They are bit away from understanding how ARP works, first saying that packets from other subnetwork are prohibited by different RFCs, not saying which.

What seems to be an argument for them, is the fact that 2 DSRs with described behavior, having switched main and alias subnets will never communicate one to other, since from one DSR ARP will come from main IP regarding IP in alias network (to communicate to main IP on the second DSR), and this second DSR will not respond since it is specially configured not to answer these packers. They promised to create a request for devs and let me know results.

Did anyone tried this scenario with same or similar HW?

I've fixed my box by just commenting last line in the following fragment of /pfrm2.0/etc/userInit script

#Setting arp_ignore to 2 so that we can drop the arp requests (whois) with
#target IP not matching with the IP of the interface on which it was received or
#if the source IP of the arp request is not in the same subnet as that of the
#IP of the interface (SPR#35932).
echo "2" > /proc/sys/net/ipv4/conf/all/arp_ignore

Thanks good people who provided root shell access to the box. I will not upgrade to modern fw, it will break everything again.

Vitaly

[FurryNutz]

Glad you got it working and thank you for sharing the information. Hope it helps others.

Enjoy.