WiFi Access Point

[sebastienNEC]

Hello Rene, What would be required in the wlan driver to have the rpi be an Access Point instead of a Station. Even an open AP (no WPA2) would be useful for my purposes. Thank you !

[rsta2]

Actually I don't know this exactly. I think, the driver for the WLAN hardware, which was ported from Plan 9, is specific for station mode. It provides functions to enable scan, to set the ESSID to connect and crypt keys, and to join a network, but not more. Also the hostap project has been ported for WPA supplicant mode only. These are the functions, which are supported by a hostap driver, which seems to be suitable for AP mode:

https://github.com/rsta2/hostap/tree/hostap_0_7_0-circle/src/drivers/driver_atheros.c#L1323

And these are supported by the Circle driver:

https://github.com/rsta2/hostap/tree/hostap_0_7_0-circle/src/drivers/driver_circle.cpp#L574

[sebastienNEC]

Thank you for the pointers. I hacked together a CBcm4343Device::CreateOpenNet(const char *pSSID) function by modifying the Plan 9 driver, cross-referencing it with the linux driver. I guess my next step is to write a lightweight DHCP server.

Would you be interested in the code to include it into circle ? Not sure how useful or complete it might be in this state, because a WiFi AP opens up a whole can of worms: should it bridge the ethernet connection to the internet?

[rsta2]

I would have a look on your code, but not sure, what parts of Circle your code will touch in the end. I don't see Circle as a general basis for AP mode applications. I'm afraid, this will not fit well into the Circle TCP/IP networking model, where a Circle application acts as a client, connected to a router (or maybe to a direct peer). Also Circle does not support multiple network interfaces. If you are using your own DHCP server, you have to implement NAT (Network Address Translation) too, if you want to route WLAN traffic to the Internet. That's a lot of work and more work to get it stable.

[sebastienNEC]

Yes indeed, this is what I thought, much work. My use case is a lot simplier though and fits more within the IoT realm. Imagine a bunch of IoT WiFi clients streaming data to a central raspi AP, that does the aggregating+processing+logging. If the AP logs on the SD card as opposed to on the internet somewhere, it doesn't need to bridge the WiFi traffic to a second network interface.

[rsta2]

Sounds like an interesting project!

[rsta2]

@sebastienNEC After a long while I tested your WiFi AP mode patch now, because there is a potential application for it. Based on addon/wlan/sample and sample/20-tcpsimple I implemented a TCP echo server, which is available via an open WiFi AP with a static IP address. For the client side I used addon/wlan/sample and a simple program which sends some ASCII string each 5 seconds via TCP and displays received data on the screen. That is all working now. So thank you for the patch.

Unfortunately there is a problem with the BSSID of the created WiFi AP. It is always the same 60:14:B3:AC:DE:6F here and does not change when using different Raspberry Pi devices (tried with RPi Zero W, Zero 2 W, 3 A+, 3 B). I don't know, if you have an idea, how this can be fixed? Different APs should have different BSSIDs.

[sebastienNEC]

Aha interesting, I had not noticed this... Looking at the linux sources (https://github.com/torvalds/linux/blob/master/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h), there's this structure (brcmf_assoc_params_le) that contains the BSSID aka MAC as the first 6 bytes. So I would guess that instead of the following line in my patch, you could set the MAC ?

    memset(p, 0, 14/*sizeof brcmf_assoc_params_le*/);

I would test this myself, but I am currently on paternal leave with 2 kids/infants and this is a full time job ;-) Thank you !

[rsta2]

I have to apologize. After trying this again, I noticed that I was looking at the wrong place for the peer BSSID. The address I found was for a different device. It's working! The BSSID is the MAC address of the respective Raspberry Pi computer, without changing your patch. Setting an alternative BSSID in the brcmf_assoc_params_le struct did not work, but is not necessary any more. Thank you for responding. Have fun with your kids!

[sebastienNEC]

Ah ok no probs, it's great that it works! I have a question as for your TCP echo server: what sort of latency are you getting ? I had a similar app with a raw 802.11 echo server of audio frames (where latency is of course essential) and was getting quite some jitter. On average, the latency was great (1ms or so) but some frames were delayed as much as 20 ms, even without 802.11 retries (i.e. with a broadcast MAC) This seems a bit high, so I am interested in your experience... My kernel.cpp doesn't do much more than

while (true) {
    m_Scheduler.Yield();
    m_Net.Process();
}

[rsta2]

I did a test with a TCP echo server. The client was sending 115 messages with 64 bytes payload each, one per second. The roundtrip time was minimum 1558µs, average 1887µs and maximum 3211µs. In another test I had seen one message with 12ms roundtrip time. I think this depends on the traffic, which is taking place on other WLANs around on the same channel. There is at least one of it here.

BTW. Normally you do not need to explicitly call m_Net.Process(), because the CNetTask is doing it already in the background.

[rsta2]

The open WLAN AP support is on the wlan-ap branch now. There is an echo server and client sample in addon/wlan/sample/hello_ap/. The echo server also creates the open access point.

Thank you again @sebastienNEC for providing the patch. I stripped the comments very much, because they were very long and un-formatted and the comment style in the ether4330.c driver is relatively quiet.

[sebastienNEC]

Thank you for your latency measurements and the code advice ! Indeed, the comments in the code where mostly for my future self, and not of production quality, so to say :)

[rsta2]

You are welcome. The open WLAN AP support is on the develop branch now and will be part of the next release. It's still experimental as the whole WLAN support. The wlan-ap branch has been removed.

[rsta2]

The WLAN AP support has been released with Circle 44.3, so this topic can be closed. Thanks again for contributing this.