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.
PC
17:06:25.047007 04:92:26:69:71:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.201 tell 192.168.0.1, length 28
0x0000: 0001 0800 0604 0001 0492 2669 7160 c0a8 ..........&iq`..
0x0010: 0001 0000 0000 0000 c0a8 00c9 ............
17:06:25.049611 00:91:9e:e6:e5:38 > 04:92:26:69:71:60, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.201 is-at 00:91:9e:e6:e5:38, **length 46**
0x0000: 0001 0800 0604 0002 0091 9ee6 e538 c0a8 .............8..
0x0010: 00c9 0492 2669 7160 c0a8 0001 0000 0000 ....&iq`........
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
The ARP response is 46 bytes in size. Everything works ok.
Here is what happens with an MSX with INL pinging the router.
MSX
15:51:11.997014 04:92:26:69:71:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.243 tell 192.168.0.1, length 28
0x0000: 0001 0800 0604 0001 0492 2669 7160 c0a8 ..........&iq`..
0x0010: 0001 0000 0000 0000 c0a8 00f3 ............
15:51:12.007186 35:65:e4:24:08:40 > 04:92:26:69:71:60, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.243 is-at 35:65:e4:24:08:40, **length 50**
0x0000: 0001 0800 0604 0002 3565 e424 0840 c0a8 ........5e.$.@..
0x0010: 00f3 0492 2669 7160 c0a8 0001 0101 0600 ....&iq`........
0x0020: 7542 6be7 013b 8000 0000 0000 0000 0000 uBk..;..........
0x0030: 0000
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.
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.