>> First of all, I have tested with 3 units where they are just a few inches
>> away from each other. They ping test is from a particular node to its
>> neighbour nodes in which are a single hop away. The ping duplication is
>> still happening in this case. Out of 50000+ ping, there are 500+
>> duplication. Is the patch you provided applicable for single hop topology as
>> well?
>Yes, the hardware really shouldn't let frames with mismatched RA
>though, but that's the only possibility I see right now.
>> The duplication is worsen when I added a node which is two hop away from the
>> node I run the ping test. The path change in this case is very frequent.
>>
>>
>> The above test was conducted using a SparkLAN WiFi module (ar 9160). I have
>> then change the WiFi module to Winstron (ar9220) and surprisingly the
>> duplication is significantly reduced. From 50000+ ping, there are only 20-30
>> duplication. Will the duplication caused by hardware that we chose?
>Apparently :)Hi Thomas,Below are a few lines of dmesg out of many that I've
>manage to captured:------------[ cut here ]------------
Badness at c998821c [verbose debug info unavailable]
NIP: c998821c LR: c9987ae8 CTR: c9987f8c
REGS: c7ffbd50 TRAP: 0700 Tainted: G W (2.6.35)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22024082 XER: 00000000
TASK = c03f3410[0] 'swapper' THREAD: c0414000
GPR00: 00000000 c7ffbe00 c03f3410 00000000 c6afeb58 00008803 c6cfc040 00002e47
GPR08: 00000002 00000000 c6808000 00000000 22022042 100b1254 c7ad0a80 00000000
GPR16: 0000000a 00000000 00000001 4877cffb c7ffbea8 c7ad4000 c7ad401c c6838300
GPR24: c7ad0a80 00000001 c6afeb58 c6afeb40 00000082 c7ffbe48 c6cfc040 c6afeb40
Call Trace:
[c7ffbe00] [c9987e40] 0xc9987e40 (unreliable)
[c7ffbe40] [c9988bf4] 0xc9988bf4
[c7ffbea0] [c9aaf0f0] 0xc9aaf0f0
[c7ffbf70] [c9aad3c4] 0xc9aad3c4
[c7ffbf90] [c002b6d4] 0xc002b6d4
[c7ffbfb0] [c002b7fc] 0xc002b7fc
[c7ffbff0] [c0010a6c] 0xc0010a6c
[c0415e70] [c0006214] 0xc0006214
[c0415e90] [c002b54c] 0xc002b54c
[c0415ea0] [c00062f4] 0xc00062f4
[c0415ed0] [c001173c] 0xc001173c
--- Exception: 501 at 0xc00091e4
LR = 0xc00091e4
[c0415f90] [c0009194] 0xc0009194 (unreliable)
[c0415fb0] [c0003e28] 0xc0003e28
[c0415fc0] [c03c3884] 0xc03c3884
[c0415ff0] [00003438] 0x003438
Instruction dump:
813e01c0 800900cc 70090100 40a2fddc 38600000 4bfffd78 54a0052a 2f800800
40bef998 8804001e 70090002 40a2f98c <0fe00000> 38800001 4bfffb24 801f0050
------------[ cut here ]------------
Badness at c998821c [verbose debug info unavailable]
NIP: c998821c LR: c9987ae8 CTR: c9987f8c
REGS: c7ffbd50 TRAP: 0700 Tainted: G W (2.6.35)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22024082 XER: 00000000
TASK = c03f3410[0] 'swapper' THREAD: c0414000
GPR00: 00000000 c7ffbe00 c03f3410 00000000 c7b0f618 00008803 c6cbd040 00002e47
GPR08: 00000002 00000000 c6808000 00000000 22022042 100b1254 c7ad0a80 00000000
GPR16: 0000000a 00000000 00000001 489653c2 c7ffbea8 c7ad4000 c7ad401c c6838300
GPR24: c7ad0a80 00000001 c7b0f618 c7b0f600 00000082 c7ffbe48 c6cbd040 c7b0f600
Call Trace:
[c7ffbe00] [c6a9e300] 0xc6a9e300 (unreliable)
[c7ffbe40] [c9988bf4] 0xc9988bf4
[c7ffbea0] [c9aaf0f0] 0xc9aaf0f0
[c7ffbf70] [c9aad3c4] 0xc9aad3c4
[c7ffbf90] [c002b6d4] 0xc002b6d4
[c7ffbfb0] [c002b7fc] 0xc002b7fc
[c7ffbff0] [c0010a6c] 0xc0010a6c
[c0415e70] [c0006214] 0xc0006214
[c0415e90] [c002b54c] 0xc002b54c
[c0415ea0] [c00062f4] 0xc00062f4
[c0415ed0] [c001173c] 0xc001173c
--- Exception: 501 at 0xc00091e4
LR = 0xc00091e4
[c0415f90] [c0009194] 0xc0009194 (unreliable)
[c0415fb0] [c0003e28] 0xc0003e28
[c0415fc0] [c03c3884] 0xc03c3884
[c0415ff0] [00003438] 0x003438
Instruction dump:
813e01c0 800900cc 70090100 40a2fddc 38600000 4bfffd78 54a0052a 2f800800
40bef998 8804001e 70090002 40a2f98c <0fe00000> 38800001 4bfffb24 801f0050
------------[ cut here ]------------
Badness at c998821c [verbose debug info unavailable]
NIP: c998821c LR: c9987ae8 CTR: c9987f8c
REGS: c7ffbd50 TRAP: 0700 Tainted: G W (2.6.35)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22024082 XER: 00000000
TASK = c03f3410[0] 'swapper' THREAD: c0414000
GPR00: 00000000 c7ffbe00 c03f3410 00000000 c7b6d798 00008803 c6fd4040 00002e47
GPR08: 00000002 00000000 c6808000 00000000 22022042 100b1254 c7ad0a80 00000000
GPR16: 0000000a 00000000 00000001 48a3cc1d c7ffbea8 c7ad4000 c7ad401c c6838300
GPR24: c7ad0a80 00000001 c7b6d798 c7b6d780 00000082 c7ffbe48 c6fd4040 c7b6d780
Call Trace:
[c7ffbe00] [c9987e40] 0xc9987e40 (unreliable)
[c7ffbe40] [c9988bf4] 0xc9988bf4
[c7ffbea0] [c9aaf0f0] 0xc9aaf0f0
[c7ffbf70] [c9aad3c4] 0xc9aad3c4
[c7ffbf90] [c002b6d4] 0xc002b6d4
[c7ffbfb0] [c002b7fc] 0xc002b7fc
[c7ffbff0] [c0010a6c] 0xc0010a6c
[c0415e70] [c0006214] 0xc0006214
[c0415e90] [c002b54c] 0xc002b54c
[c0415ea0] [c00062f4] 0xc00062f4
[c0415ed0] [c001173c] 0xc001173c
--- Exception: 501 at 0xc00091e4
LR = 0xc00091e4
[c0415f90] [c0009194] 0xc0009194 (unreliable)
[c0415fb0] [c0003e28] 0xc0003e28
[c0415fc0] [c03c3884] 0xc03c3884
[c0415ff0] [00003438] 0x003438
Instruction dump:
813e01c0 800900cc 70090100 40a2fddc 38600000 4bfffd78 54a0052a 2f800800
40bef998 8804001e 70090002 40a2f98c <0fe00000> 38800001 4bfffb24 801f00
I have discovered some scenario that I could not understand. Below is my test
topology: A / \ B-----CA serial cable is connecting to node A
and I have a terminal window which I've ssh into node B at the same PC. Then, I
have started to ping on the SSH window to node A. In this case, the above
debugging message did not shown often on serial of node A, only a few time in
hundred of ping. I presume those debugging message is shown due to
duplication.After that, I starting to ping to node C on the ssh windows. In
this case, the serial of A shown the debugging message for each ping. But the
ping is not dedicated to node A. Is this mean that, even the packet is not
meant for node A (its a ping from B to C), node A still received the packet?
Thanks,Ming Ann
_______________________________________________
Devel mailing list
[email protected]
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
