Simultaneous AP and Client Mode Wi-Fi on Raspberry Pi Zero W
github.com
github.com
https://blog.thewalr.us/2017/09/26/raspberry-pi-zero-w-simul...
For everybody interested in details, the article gives useful insights on configuration automated by the script.
> A number of tutorials I found claimed that the address for the virtual AP must be different from the primary MAC address. I found there to be no difference in behavior, but you should be able to change the last byte, for example, to give your client and AP different MACs.
huh ... You'd think this could cause interference, but I guess not if they have different SSIDs and passwords.
I had built [similar repository](https://github.com/computationalprivacy/unveil-pi-data-colle...) as a part of wifi data capture and visualisation experiment ([Project UNVEIL](https://github.com/computationalprivacy/unveil-deployment)) but it used external antenna.
Any links on how does underlying hardware work to enable simultaneous connections?
https://blog.thewalr.us/2017/09/26/raspberry-pi-zero-w-simul...
> At this point, we should be able to connect a device to our Raspberry Pi Zero W’s AP SSID, while we also have our RPi connect to another access point for internet access, and we should be able to access the internet from that device through our RPi.
The "simultaneous" aspect seems to be achieved by having two devices: wlan0 and ap0, the latter created by udev.
It just needs a captive portal of its own when the client side is disconnected.
They usually have an interface so that when you get to a hotel, you can either plug them into the hardline or they will let you connect and then select the hotel's wifi and enter the password.
The great thing is that all your devices will already have your travel router wifi info saved. So when I go to a hotel and fire it up and connect, all our phones, ipads, Roku, even an Amazon echo we sometimes take will will all connect right up.
Sometimes I even luck out and the lan cable going into the TV will be unmetered. One hotel I was getting 100mbps up/down all week for free.
In case anyone wants to know more.
Probably a better use case would be connecting older devices like the Nintendo DS that don't support WPA2 to your network without forcing all of your other devices onto WEP.
Ideally you'd have 802.11ac/ax with 2 separate PHYs each with 4x4 (even if the clients are 1x1 or 2x2 the additional beamforming helps) set to two separate channels.
That's not to say it won't function well enough in a pinch but I wouldn't seek this out as a permanent answer if I were buying new.
I imagine the OP's use case of IoT did not require huge amounts of bandwidth.
Like I said this functions fine, as is evident by it having been posted, but the question was why it wasn't a very good repeater not was it a functional use of an existing pi 0 laying around.
It's also not the best you could do buying new if that is what you had to do as ~$16 will get you a 2x2 802.11n repeater that functions much better, has external antennas, and has an ethernet port too. Not $10 but it's also enclosed and doesn't need a power supply or uSD. ~$30 will get you decent AC repeaters you could use outside of a singular IoT project. Less for either if you're willing to go used. The ideal 4x4 ax double phy wireless repeater is indeed going to be more than a pi 0 but it was an example of what makes a repeater good (to the question) not what should have been purchased for this project.
Again nothing wrong with the solution used here, that's not where my comment was pointed.
[1] https://www.embedded-computing.com/articles/a-lesson-in-wire...
This setup could let me do it without the USB wifi hanging off the USB OTG adaptor.
* This is not secure but it’s fine for my vintage computing hobby
Then connecting a Fire TV Stick or Chromecast to this AP, and tricking it into letting you stream Canadian Netflix or DAZN etc.
Also, we have the same "content can't be offered here by Netflix because the local IP license has been bought out by a different owner" problem that the US and many other places does; but in Canada's case, most of those local IP owners are conservative dinosaur media companies, who either haven't managed, or haven't bothered, to set up their own alternative streaming services yet. They just... hold the licenses, doing nothing with them. Hoarding them, like a dragon. So there are many shows you just can't stream in Canada at all, no matter who you're willing to pay.
If you can use Ethernet (e.g with a dongle on the Fire stick) and turn all the device radios off then there are less inputs available for the device to determine it's location.
Untrusted Wifi > RasPi Client > OpenVPN > AP
How would you go about routing the VPN device between client and AP?
edit: Now that I think about it, what's the difference between using the Pi as an AP and using it as a DNS server?
Is there a ‘fix’ for that ?
edit: This was not meant to be offensive. I was simply hoping somebody could offer how it could be used with systemd and remove the reliance on cron.
It has always been like that since day one with the RPi Zero, which was years ago. The Zero has always been produced in very small quantities and sold at a loss so they could advertise that price, but the actual users who could get it at the advertised price are a small minority of those wanting to buy it. I gave up after 2 full years, and never regretted.
Now I'd rather spend some more quid and get different (and often much more powerful) boards that I can order in 1 or 1000 units and will be available without either being bundled with unnecessary stuff to inflate the price or locked to 1 piece per order.
Here's a big list of boards complete with spreadsheet tables to compare them.
http://linuxgizmos.com/ringing-in-the-new-year-with-136-open...
It's being updated once or twice per year, however this year's pandemic could have delayed the new one.
Still not a crazy price, of course, I just dislike the misleading advertising.
The first AP is connecting to internet gateway through its WAN port. This AP does the networking stuff like DHCP, NAT, etc.
The other wifi APs are configured to be AP-only, i.e. disable DHCP. Use same wifi SSID and auth settings as the first AP. Then connect the APs using their LAN ports.
Client devices should now connect to the AP with the best signal.
But if the client is already connected to an AP and a better-signal AP is available, many clients won't automatically connect to the better AP. This is because the client don't know that the other AP is the same network. So if you move around you may need to trigger the client to disconnect and reconnect.
This can be solved with APs that have a "mesh" feature which can instruct connected clients to reconnect to a better AP in the same network using https://en.wikipedia.org/wiki/IEEE_802.11k-2008 but AFAIK mesh systems from different manufacturers aren't interoperable.
Though I do wonder whether you can add a proper wifi antenna and make the RPI an 'ok' wifi extender. That might be a viable option, provided the performance is ok.
I don't think most chips can do this fwiw, but it's definitely cheap enough now that cameras and IoT devices will probably start doing it everywhere.
Otherwise, ad-hoc is different from AP+Client, as ad-hoc is only between two devices (at least from what I gather) while AP+Client would allow a distributed network where clients are interconnected.
I'm looking for a project that starts with an AP. Once someone connected to it; it opens a web page to configure the client (choose which WIFI from a list, and type the password).
It connects to the chosen WIFI and shuts down the AP.
Anyone here did something similar to that?
Managed to strip down OpenWRT so it would fit in the meager 16MB RAM/8MB flash. In the init script (a bash script) just checked if a wifi network was configured previously (creds stored in a file).
If configured, try to connect to the network for 10 seconds. If it couldn't connect, then switch to AP mode and start a lightHTTPd server listening on 192.168.0.1:80.
The only files it served was a simple index.html with some JS that called a bash script via CGI that used a openwrt bash library to scan and list the available wifi networks.
Then a HTML form to choose an SSID and enter the password, upon submit call another bash file to connect to the network (switch to client mode) with a timeout. If it fails, the bash would switch back to AP mode.
Polling in JS to check if the connection was successful (by checking if AP mode becomes active again)
You can see the chipset name (BCM43430) on dmesg:
$ dmesg | grep brcmfmac
[ 26.488164] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[ 26.512759] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 26.513315] usbcore: registered new interface driver brcmfmac
[ 26.539406] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,model-zero-w.txt