-
-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARP response and VLANS with INL issue #21
Comments
Part of the issue was fixed by Wagner in a recent pull request. @Konamiman, could you please incorporate his pull request? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using INL with a network device connected to a vlan/bridged router (most of the modern WAN/LAN routers) arp responses are not being forwarded correctly as they are perceived by the router as vlan tagged frames.
The issue can be reproduced with a networked MSX to any Linux based AP connected to an internet provider router (example ASUS RT-AC5300, ASUS RT-AC66U, etc) and using INL to ping the gateway address defined on the bridged vlan. You can ping any device on the vlan, except for the gateway IP as all ARP responses sent to the router in unicast are dropped.
Here is what happens with a PC on the network trying to ping the router.
The ARP response is 46 bytes in size. Everything works ok.
Here is what happens with an MSX with INL pinging the router.
The ARP response is 50 bytes in size when it should be 46 like the PC. Because it is 50 bytes in size, the router thinks it is a tagged frame and, as the vlan id is undefined, it drops the frame.
From the ARP documentation:
If the ARP message is to be sent in an untagged frame then the frame overhead itself is 18 bytes. That would result in a frame of 28+18=46 bytes without padding. Additional 18 bytes of padding are necessary in this case to bloat the frame to the 64 byte length.
If the ARP message is to be sent in an 802.1Q-tagged frame then the frame overhead is 22 bytes, resulting in the total frame size of 28+22=50 bytes. In this case, the padding needs to be 14 bytes long.
Apparently INL.COM that creates ARP responses needs a fix to generate a 46 bytes ARP response instead of 50 bytes. Where 22 is added should be 18 according to the documentation.
The text was updated successfully, but these errors were encountered: