I've been using a similar solution, but I had quite some problems using AP and client mode at the same time. The WiFi chip inside the RPi Zero W (BCM43430) only supports AP and client mode on the same channel. If you setup an AP first, then connect to a client network, hostapd will update the channel of the AP, but clients will notice a disconnect. There are also issues with the firmware blob (see https://github.com/raspberrypi/firmware/issues/1403) in AP mode that haven't been solved yet.
What I did on a similar project using a different board was scan all the APs in the area first, get the band of the AP with the strongest signal, then bring up the device AP using that band. I figured the AP with the strongest signal is the closest AP and the one you most likely want to connect to.
I noticed the script was using the same MAC address for the ap0 adapter. From that blog post...
> 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.
> 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.
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.
Or you can buy an older used router for ~$10 that supports FreshTomato or DDWRT, I know those support simultaneous AP and client mode. I spent a year using one for such needs and worked well on an E2500. Or buy a dedicated like OP said as it's probably less trouble and more reliable, depending on model.
In a pinch you can just spoof the wifi MAC address of the chromecast/firestick/roku with a PC, connect to the wifi, deal with the captive portal, then connect the actual device (change your MAC back unless you want fireworks).
It could be used as a range extender, though not a very good one.
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.
Well 2 things really. Yeah the hardware is a bit garbage as it only goes up to 802.11n only on 2.4 GHz and it's also a 1x1 with a poor antenna. The big thing though is it requires you use the same channel which is disastrous for repeater performance.
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.
"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."
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.
I'd guess the hardware is the problem. Most antennas I've seen on access points are larger than the entire Pi Zero W. While I'm no radio expert, I'd expect APs to use the smaller antennas if they were capable of being as good as bigger antennas.
Ah, that reminds me of an article someone here linked to a few years ago: [1]. That claims the efficiency is -3.5 dB compared to a typical -1.25 dB dipole in dedicated wireless equipment. Not bad; the difference is only a factor of ~2 in power for x8 reduction in size.
I use a pi this way so I can join my pi to hotel wifi (or similar) then join my iPad to the pi’s network - which lets me ssh into the pi to access software there while both devices have internet access.
I use this for configuration on some equipment I sell. The unit has a local web server that lets you configure IP, ID information. It works as a captive portal. Then you just plug your ethernet cable in and its good to go. (I use a Pi 3 in the product).
The use case is in the title. You can use it as a wireless repeater. A more interesting use case would be ethernet over USB and a wireless AP with another interface for client monitoring via airmon.
No, but it's not uncommon to find hotel internet that has a fairly low device count limit. The place I use WiFi repeaters is on airplanes, to avoid the hassle of re-authenticating every time I switch between phone and tablet and laptop.
Maybe it was just an arbitrary example, but really, there's no reason to want Canadian Netflix. We only get about half the stuff the US does.
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.
During the pandemic I can blaze through new additions to the Netflix US catalog with speed, then its time to go find something new to watch for the next few weeks. All of the regional Netflix get movies and shows that the US does not - I was able to watch Star Trek Discovery in its entirety on Netflix Germany for example. Netflix Hong Kong has an amazing catalogue but I could not get that one to work with my VPN. Netflix UK is the most disappointing because it is more or less devoid of UK movies and shows aside from Monty Python and Peppa Pig (both already available in the US anyway).
The software and/or device you are trying to trick would be able to determine it's true location using the MAC address of other WiFi APs in its vicinity - the same way a map app on your smartphone can without GPS and cellular network assistance.
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.
No idea! I spent some time debugging it, but it just does't make sense it works with cron and not with systemd. Let me know if you have any idea where to look!
I think it’s just a shortcut because of lack of experience with systemd (this is not intended to be offensive btw - if cron is already installed and you save time by just using what you know, why not?). I would be very surprised if cron could do something that can’t be done with systemd timers.
Systemd can be very powerful and you can even depend on individual devices being added/removed. I’m pretty sure you can even replace the udev rules with a systemd equivalent if you tried hard enough.
More time to tinker at home? Over the course of a couple weeks, I purchased four a two months back. A project I worked on inspired at least another person in my office to buy one.
> Has anyone noticed a shortage of Pi Zeros recently?
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.
Yes, I entirely agree. I often add one with my orders when I can because they are useful and the equivalent clone versions work out very expensive in the UK. They are in short supply because the margin on them must be tiny and it's not worth wasting much manufacturing capacity on them. I wish they would update the specs but I think that's very unlikely to happen as they'll lose the original $5 computer claim. I don't care if it got a little more expensive (again), I like the form-factor.
I think this is intentional. The Pi Zero is mostly a marketing device. It's advertised at $5 but unless you happen to have a physical store selling them near you, it's not really $5 because the shipping is never free and you can only ever by one. So it's more like $15.
Still not a crazy price, of course, I just dislike the misleading advertising.
Can this be used as a range extender if you use the same SSID and password for the access point as the net you're connecting to? Would other clients silently roam between the two (or more) networks using the same name and password?
No, the identification method of an extended service set is the SSID, aka the network name. Just set up the same SSID and password on both APs, and put them onto the same ip layer network. Your device will roam the networks automatically. Each AP should get its own MAC otherwise they will think packets sent to the other AP was meant for them. WiFi is robust enough to deal with noise like e.g. bluetooth, so it might survive it, but I doubt it'd support two STAs with the same BSSID communicating with each other.
How do you do this with most consumer devices? The only AP I've seen do it successfully is the AsusWRT series - Media Extender mode seems to be transparent. If I try it with anything else I'll end up with two seperate networks, e.g. 192.168.8.0/24 connected to 10.1.1.0/24 (I actually have a GL.inet AR750S in this configuration right now)
If you can wire the 2 AP via a LAN, then this is how I've used cheap consumer wifi APs which are usually combo AP+router devices:
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.
I wonder what's the use case other than a poor wifi extender, or niche cases of sharing one connection between multiple devices where you pay per connection.
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.
Why is that not easy and widely used as nearly all devices we used like camera (dslr to car camera) and remote controller all resolved to stop WiFi and switch to another mode etc to connect.
Not sure exactly what you're referring to, did the author explain in the past they rather want ad-hoc network setup or something?
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.
It's extremely rare that one gets to a working ad-hoc setup... it's a chicken-egg problem. Drivers, firmware, software and UI support are bad, so no one uses it, so development is an afterthought, rinse and repeat.
ad-hoc in general runs a different path inside kernel module, which is normally not supported as well as AP/client mode, so, while many chips can do ah-hoc in theory, in software side it is a difference story
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.
Yep. I didn't do it with a RasPi but with a Chinese chip I found off AliExpress
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)
I’ve seen Raspberry Pi images from Ubiquity Robotics(not Ubiquiti Networks) having similar daemon called “pifi” for command line operation, but this one looks nicer
Just curious, but I was trying to help someone with a Raspberry Pi Zero W wifi issue the other day and had trouble finding sny info about the wireless chipset used. I couldn't find it listen anywhere on the site, or several tech review sites, only extremely useless information on the 802.11 versions support. If it recall correctly, it didn't even show up in the schematica. Luckily wikipedia had the name of the chipset used, but I don't get it. Why does their official documentation seem to be so secretive?
How to get faster internet at a hotel:
Have 4-5 of these connected and talking with the hotels WiFi, and one who share Internet with you. All the traffic goes to a server you have at home that “join+proxy” the traffic. Based on the idea that every user have a limited bandwidth, combining multiple will give you higher speed.
You can also plug multiple wifi dongles into a usb 3.0 hub and use magic to load balance traffic across all the interfaces connected to different wifi internet APs.
