Dear all,
I captured 802.11 frames of BATMAN-adv V.
Here is the script to do this.
===============================================
iw phy phy1 interface add mon0 type monitor
ifconfig mon0 up
ifconfig mon0
tcpdump -c 2000 -i mon0 -y IEEE802_11_RADIO -w mon0.pcap
===============================================
I checked the .pcap file in wireshark and found 4 type of packets:
1. many unicast packets, with length of 200 bytes. I guess it's ELP unicast.
2. some batman-adv broadcast packets of 56 bytes length. I guess it's OGM2?
3. several batman-adv broadcast packets of 16 bytes length. It's ???
3. many rts/cts/ack packets.
4. some beacon frames.
Here is a ELP unicast packet sample.
16:43:43.438367 26700598255us tsft 2462 MHz 11n antenna 0 7.2 Mb/s MCS 0 20 MHz
short GI RX-STBC0 00:00:0d:18:08:02 (oui Unknown) > 00:00:0d:18:08:06 (oui
Unknown) SNAP, ethertype Unknown (0x4305), length 200:
0x0000: aaaa 0300 0000 4305 030f 0000 0d18 0802 ......C.........
0x0010: 0000 0000 0000 0000 87f3 6000 800e 0488 ..........`.....
0x0020: 0000 0000 0000 0001 8785 e550 0000 0001 ...........P....
0x0030: 0000 0001 0000 0000 0800 0000 ffff ffff ................
0x0040: ffff 0000 0d18 0802 0011 2233 4458 0039 .........."3DX.9
0x0050: aaaa 0300 0000 4305 030f 0000 0d18 0802 ......C.........
0x0060: 204b 4075 0000 01f4 ffff ffff 0401 0014 .K@u............
0x0070: 0101 0002 56cb 6224 8000 0000 632c bf3d ....V.b$....c,.=
0x0080: 0000 005f 0602 0004 0700 0000 0201 0000 ..._............
0x0090: 8333 aaff 0000 aaff 0000 c005 0000 00fc .3..............
0x00a0: ffdd 1800 50f2 0201 0180 0003 a400 0027 ....P..........'
0x00b0: a400 0042 435e 0062 322f 00dd 0900 037f ...BC^.b2/......
0x00c0: 0101 0000 ff7f dd18 8cbe be01 0101 0202 ................
Here is a 56 bytes (OGM2?) packet.
17:08:42.241883 28209488314us tsft 18.0 Mb/s 2462 MHz 11g -73dBm signal -75dBm
signal antenna 0 -77dBm signal antenna 1 00:00:0d:18:08:05 (oui Unknown) >
Broadcast SNAP, ethertype Unknown (0x4305), length 56:
0x0000: aaaa 0300 0000 4305 040f 3000 1b34 cd42 ......C...0..4.B
0x0010: 0000 0d18 0802 0024 0000 004d 0401 0014 .......$...M....
0x0020: 0101 0002 56cb 6224 8000 0000 632c bf3d ....V.b$....c,.=
0x0030: 0000 005f 0602 0004 0700 0000 0201 0000 ..._............
Here is a 16 bytes batman-adv packet.
17:08:42.258522 28209504921us tsft 18.0 Mb/s 2462 MHz 11g -78dBm signal -84dBm
signal antenna 0 -80dBm signal antenna 1 00:00:0d:18:08:01 (oui Unknown) >
Broadcast SNAP, ethertype Unknown (0x4305), length 16:
0x0000: aaaa 0300 0000 4305 030f 0000 0d18 0801 ......C.........
0x0010: a333 a781 0000 01f4 .3......
I will try to increase the ELP interval and check the performance again.
I noticed 2 macro definitons.
#define BATADV_ELP_PROBES_PER_NODE 2
#define BATADV_ELP_MIN_PROBE_SIZE 200 /* bytes */
I wonder why it sends 2 prob ELP packets to each neighbour.
Can I change the value of BATADV_ELP_PROBES_PER_NODE from 2 to 1?
And can I decrease ELP prob packet size from 200 to 100, in order to decrase
the ELP airtime?
Yours Sincerely
Ligang
At 2018-08-30 17:06:30, "Sven Eckelmann" <[email protected]> wrote:
>On Donnerstag, 30. August 2018 16:55:38 CEST Ligang LIU wrote:
>> >[...]
>> >> One strange thing. Can I ignore this waring, even if I think the wifi
>> >> driver is ok?
>> >> [ 30.628792] batman_adv: bat0: WiFi driver or ethtool info does not
>> >> provide information about link speeds on interface wlan1, therefore
>> >> defaulting to hardcoded throughput values of 1.0 Mbps. Consider
>> >> overriding the throughput manually or checking your driver.
>> >[...]
>> >
>> >I would say that you cannot ignore it because it means that the wifi driver
>> >didn't provide the expected throughput for a station.
>> >
>> >But it is most likely better to let Marek and/or Antonio answer this
>> >question.
>>
>> I said it's strange because it seems the throughput value is acttually
>> updated when batman is running, even there is a warning.
>
>Maybe it was just not available when batman-adv asked the first time.
>
>> >Btw. please structure you mails better. I will not read through this 400KB+
>> >text mail just to find your annotations and questions. One which I saw but
>> >which should be answered by a different person is "6-node case".
>> >
>> I described the main results.
>> And the attahed log is just for whom interested in finding the reason. It
>> could be ignored for the others.
>>
>> I have to emphasize that, the tests show that the output route of V is ok
>> but the delay and throughput are bad. We should try to find where's gone the
>> bandwidth. Do you have any suggestion about it?
>
>Since there is still the problem that the ELP messages are potentially sent
>too often for low quality links (which also need the automatic retries by the
>wifi driver/hw). Did you try to increase the interval [1]? Just to make sure
>that they don't use the complete airtime.
>
>
>There was also this odd wifi problem which somehow was (maybe)
>triggered or caused by B.A.T.M.A.N. V: https://www.open-mesh.org/issues/341
>Unfortunately, the discussion with the reporter was rather frustrating and at
>the end stopped completely.
>
>When I remember it correctly, the wifi performance of all nodes (even when not
>sending data over the batman-adv interface) was rather bad when some
>B.A.T.M.A.N. V nodes were around (and one of the nodes disappeared?).
>
>Kind regards,
> Sven
>
>[1] https://www.open-mesh.org/projects/batman-adv/wiki/Tweaking#ELP-interval
