[Olsr-users] 802.1Q vlan frames causing asymmetric neighbor problem
Mon Nov 4 19:09:02 CET 2013
Can you provide a clue why .51 is using .1Q tags? Would have to to with CoS (priority bits) configuration.
Please provide at least uname -a and ip link / ifconfig info.
Couple of years ago, default IP QoS bits are changed. Maybe one of your Android devices copies these L3 DiffServ bits in 802.1 CoS bits. You can try with different olsrd configs and see when .1Q tags are used and when not.
Op 4 nov. 2013, om 18:44 heeft Justin Lewis <(spam-protected)> het volgende geschreven:
> First of all, thanks for the great software :)
> I'm having a problem with olsrd on Android, which I am hoping I can get some help with. The problem is causing one of my devices to become and remain an asymmetric neighbor. I have 3 devices in my network:
> - 192.168.1.95 (Linux box)
> - 192.168.1.50 (Android device)
> - 192.168.1.51 (Android device)
> Now, .95 and .50 have no problems seeing each other, but neither of them can see .51, the problematic device. He sees .50 and .95 as asymmetric (from olsrd):
> Received TC from NON SYM neighbor 192.168.1.95
> Received TC from NON SYM neighbor 192.168.1.50
> I can ping .51 from .50 and vice versa. I took a tcpdump and noticed the following on .50:
> (spam-protected):~$ adb -s SH139PY05892 shell su -c "tcpdump -n -e"
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 17:31:53.176326 90:21:55:56:77:fb > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 90: 192.168.1.50.698 > 192.168.1.255.698: OLSR, seq 0xd320, length 48
> 17:31:54.401973 8c:77:12:a7:43:93 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 78: vlan 0, p 6, ethertype IPv4, 192.168.1.51.698 > 192.168.1.255.698: OLSR, seq 0x423e, length 32
> 17:31:55.143062 90:21:55:56:77:fb > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 74: 192.168.1.50.698 > 192.168.1.255.698: OLSR, seq 0xd321, length 32
> 17:31:56.012782 8c:77:12:a7:43:93 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 78: vlan 0, p 6, ethertype IPv4, 192.168.1.51.698 > 192.168.1.255.698: OLSR, seq 0x423f, length 32
> As you can see, .51 seems to be wrapping the HELLO packets with these 802.1Q vlan frames. I have no idea what these are, or what to do about them.
> I tested and have found the same behaviour on olsrd 0.6.6, 0.6.5, 0.6.4 and 0.6.3, all compiled locally on an Ubuntu 10.04 x64_64 box and using the exact same config.
> Interestingly, I have a pre-built binary of olsrd-0.6.3 (using exact same config) which does not exhibit this problem (the frames are not wrapped with the vlan tags). Here is the version output:
> *** olsr.org - pre-0.6.3-git_98cbd3d-hash_ ***
> Build date: 2012-06-27 17:21:39 on ubuntu
> I looked for this hash in the git repo, but couldn't find it.
> Does anyone have any idea about this? Is this a bug? I'd be really grateful if an expert could give me some pointers on this.
> Olsr-users mailing list
More information about the Olsr-users