On Mittwoch, 26. Oktober 2016 15:19:02 CEST johnzeng wrote: [...]

HostB wlan0 : mac addr : ether 00:1d:43:10:15:44

HostA wlan0 : mac addr: ether c8:3a:35:c9:ce:71

[...]

i run the command at Host A ( Rt2070 ) at ( ping HostA from HostB) iw dev wlan0 station dump: Station 00:1d:43:10:15:44 (on wlan0)

[...]

Here we see that host A noticed that there is a different device and "connected" to it (actually, it just added it as remote station to its internal list).

This is a good sign - at least when both devices have each other in their respective station lists (*spoiler* they don't).

[root@alarmpi ~]# tcpdump -i bat0

07:01:40.635517 ARP, Reply 0.0.0.0 is-at 43:05:43:05:00:00 (oui Unknown), length 28 07:01:50.655521 ARP, Reply 0.0.0.0 is-at 43:05:43:05:00:00 (oui Unknown), length 28

[root@alarmpi ~]# tcpdump -i wlan0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes 07:02:35.815528 c8:3a:35:c9:ce:71 (oui Unknown) > Broadcast, ethertype Unknown (0x4305), length 66:

[...]

Here we see an OGM that is transmitted from this device. So for some reason we don't see the an incoming OGM from host B. Either host B is not really transmitting it, host A is not receiving it or you just didn't capture long enough.

[...]

and i run same command at Host B ( RTL8188CUS ) at ( ping HostB from HostA)

iw dev wlan0 station dump:

" is blank "

This means that RTL8188CUS didn't detect a remote IBSS device. This is odd and at first glance looks to me like a bug in the RTL8188CUS driver. But I would recommend to get a third (known to work) device and check to which of the orignal two devices it can connect and which of the other two devices can connect to it.

You could even use the third device to capture raw wifi frames on a monitor interface and check if both devices submit these OGMs and if both devices are beaconing (and reply to probe requests).

But this is basically the main problem here. The rest of the reply is just to explain some additional things. ---------------------------------------------------------------

[...]

tcpdump -i wlan0

06:57:11.425351 c8:3a:35:c9:ce:71 (oui Unknown) > Broadcast, ethertype

[...]

06:57:11.534759 00:1d:43:10:15:44 (oui Unknown) > Broadcast, ethertype

[...]

This part shows an OGM from host A and host B. So it can receive OGMs from other stations and batman-adv is at least trying to send some data. It is unknown here if the host B is not really sending it or if host A is not really receiving it.

[...]

And i thought Rt2070 support Broadcast and RTL8188CUS don't support Broadcast or send ...

because when i ping ip (RTL8188CUS) from Rt2070 , and i can see ping packet via (tcpdump -i bat0 ) and i can see Rt2070 mac addr via (tcpdump -i wlan0 ) at HOSTB,

but i ping ip (Rt2070) from RTL8188CUS and i can't see any ping packet from RTL8188CUS and i can't see RTL8188CUS mac via (tcpdump -i wlan0 ) at HOSTA

Both should have working broadcast to get the ARP stuff working for the ping. But of course this only a good test when each ping tests are done with clean ARP tables (Linux is sniffing packets to fill its own ARP table without always sending ARP request). There is a test which you could have done even without the `iw dev wlan0 station dump` info from above.

This part now is without batman-adv (because the text from you is quite unclear): --------------------------------------------------------------------------------

But it could be that the ARP table on RTL8188CUS (Host B) was filled by the ARP request from Host A. And this was to only reason why the ping back from host B to host A worked. You can test that by making sure that the ARP table is clean on both hosts and then start pinging from B to A. Also make some captures with tcpdump on both hosts that you later can analyze with wireshark. After your test (when it worked) make sure that the arp table on both hosts contain entries for each other. And than analyze the dumps for ARP packets in wireshark to make sure that host B really submitted and request and host A replied to it.

Kind regards, Sven

On Mittwoch, 26. Oktober 2016 20:52:13 CEST johnzeng wrote: [...]

Thanks , and i will try to purchase suitable wifi hardware ,

Because i use raspberry [...]pi , i have to use wifi card based usb .

whether you can advise a set of usb wifi card based Atheros ( driver ath9k) ?

Sorry, I have zero experience with the USB hardware (ath9k_htc/carl9170). I think Martin was using them some time ago. Or maybe someone else on the ml has more information about them.

But these devices use a firmware running on the device. I know that there were weird problems hunting the carl9170 hardware/firmware [1]. Th ath9k_htc looks a little better but the TODO list for the firmware is also quite large and there also some odd limitations mentioned on the driver page [2].

Kind regards, Sven

[1] https://wireless.wiki.kernel.org/en/users/drivers/carl9170 [2] https://wireless.wiki.kernel.org/en/users/drivers/ath9k_htc

On October 26, 2016 3:05:47 PM GMT+02:00, Sven Eckelmann sven@narfation.org wrote:

On Mittwoch, 26. Oktober 2016 20:52:13 CEST johnzeng wrote: [...]

...

Thanks , and i will try to purchase suitable wifi hardware ,

Because i use raspberry [...]pi , i have to use wifi card based usb

.

...

whether you can advise a set of usb wifi card based Atheros ( driver

ath9k) ?

Sorry, I have zero experience with the USB hardware (ath9k_htc/carl9170). I think Martin was using them some time ago. Or maybe someone else on the ml has more information about them.

Yeah, I used them for some lab tests a few years back. The ath9k_htc works quite well with the exception that the chip/firmware/driver only supports 7 or 8 nodes within range due to limited resources on the chip.

// Martin