802.1Q vlan frames causing asymmetric neighbor problem

[Justin Lewis]

Hello,

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:

***@vortex:~$ 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.

Cheers,
Justin

[Teco Boot]

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.

Teco

Post by Justin Lewis
Hello,
First of all, thanks for the great software :)
- 192.168.1.95 (Linux box)
- 192.168.1.50 (Android device)
- 192.168.1.51 (Android device)
Received TC from NON SYM neighbor 192.168.1.95
Received TC from NON SYM neighbor 192.168.1.50
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.
*** 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.
Cheers,
Justin
--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users