On Monday 11 February 2013 22:33:31 Rafał Miłecki wrote:
> 2013/2/11 Rafał Miłecki <[email protected]>:
> > I've compiled two extra tools: tcpdump and arp.
> >
> > It seems that OpenWRT can't understand ARP response. See attached
> > tcpdump.and.ping.all.on.router.txt - it's a ping and tcpdump both
> > running on OpenWRT router.
> >
> > Router want to ping 192.168.1.2, so it's sending ARP request:
> > FF FF FF FF FF FF (dest)
> > C8 3A 35 40 C1 A8 (src)
> > 81 00 00 00 (vlan0)
> > 08 06 (arp)
> >
> > My PC replies to the request:
> > C8 3A 35 40 C1 A8 (dest)
> > 00 1D BA 19 9E DB (src)
> > 81 00 00 01 (vlan1)
> > 08 06 (arp)
> >
> > And... nothing! There isn't ICMP request sent by the router. I've
> > decided to check the arp table:
> > # arp
> > IP address HW type Flags HW address Mask
> > Device 192.168.1.2 0x1 0x0 00:00:00:00:00:00 *
> > br-lan
> >
> > Is this the reason? Linux can't parse ARP response from the PC and
> > doesn't know it's MAC?
>
> That theory makes even more sense after re-thinking it.
>
> When I ping router from my PC, there are three packets repeated over and
> over: 1) PC sends ICMP request
> 2) Router sends ARP requres
> 3) PC sends ARP reply
> but nothing more... Router seems to ignore/don't understand ARP reply
> and can't reply for ICMP request.
For your pc to send the ICMP request, it will also have to maintain the hw MAC
address of the router. Meaning it will have to send an arp request from your
pc to the router from time to time, and receive an answer from the router
(depending on the arp cache timeout on your pc), unless you programmed the MAC
address statically. So the router seems to be able to receive, process and
answer an ARP request from your pc, delivering an understandable ARP reply to
your pc? (do you actually see the ICMP request in tcpdump/wireshark)
The other way around seems to be the problem, as the router is not able to
make the ip/MAC association of your pc (which is strange, as request/response
already infers two way communication).
> Do you remember me saying that for a few seconds after doing
> brctl delif br-lan eth0
> brctl addif br-lan eth0.0
> I can still ping the router? It looks it could be thanks to the ARP
> cache. When using eth0 for br-lan router received and parsed ARP
> response. After a switching back to eth0.0 (from eth0) router was
> still using arp cache table until it expired.
> Make sense to me.
This seems to make sense .. br-lan interface is never deleted/flushed
(up/down), so the arp table for that device will remain, until the entries
expire. Default timeout is 60 seconds (check
/proc/sys/net/ipv4/neigh/<dev>/gc_stale_time)
> The only question... WHY router can't understand ARP responses over
> br-lan connected to eth0.0? :(
The question is, where the vlan's are added/removed from the packet. If the
switch driver/hardware remove/change the tag, the (ARP) packet will never
arrive at eth0.0, because there is no more vlan tag/vlan tag is incorrect.
Make sure you see packets (ARP) arrive at br-lan bridge, that's where the ip
address is configured, and is where you should see the start of the reply.
ps. you can tcpdump on trunk eth0, and specify vlan <vlan id> to see packets
for the vlan specified.
Regards,
Tijs
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
