3

Why do tutorials about turning a Raspberry Pi into a Wi-Fi repeater say that the Pi needs to authenticate with the original Wi-Fi network first? As in this diagram from balena Blog:

enter image description here

Or the top "raspberry pi wifi repeater" Google result from PiMyLifeUp:

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

... replace the ssid with the name of the network you want to connect to and replace the psk value with the password for that network.

network={
        ssid="networkname"
        psk="networkpassword"
}

Doesn't a repeater only have to hear frames and then retransmit them? Why does it need the original Wi-Fi's connection details for itself? Can't it be a genuinely invisible middle man between the device and the original Wi-Fi network if all it does is rebroadcast RF information?

1 Answer 1

4

Doesn't a repeater only have to hear frames and then retransmit them? Why does it need the original Wi-Fi's connection details for itself? Can't it be a genuinely invisible middle man between the device and the original Wi-Fi network if all it does is rebroadcast RF information?

That's not all it does.

Originally repeaters did work this way (back in the era of WEP and 802.11b), but from what I've heard, they had various downsides – e.g. if I remember correctly, clients would see duplicate frames (reducing the channel's capacity), the repeater would indiscriminately repeat all networks on the same frequency, WPA couldn't be made to work (I can't remember why though), and I assume that if the same approach was applied to modern standards such as 802.11ac it would prevent new features such as beamforming or wider channels from working too as the AP would have no knowledge about where the clients are physically.

So modern "repeaters" are not layer-1 RF repeaters at all, they're layer-2 bridges that keep track of their own clients and overall act like additional access points in the network (except they have a wireless uplink connection to another AP, rather than wired Ethernet). It's just that the terminology has stuck – though it's not entirely inaccurate, as the device still repeats stuff, it's just happening at layer2 now instead of layer1.

(Wi-Fi natively supports roaming between multiple APs within a single SSID, so if your "repeater" is a fully functioning AP, clients will be able to handle it the same way as they handle multiple wired APs in range, and of course the repeater can handle clients on a different channel, it can do beamforming and stuff, etc.)

That being said, this method has its own downsides – e.g. a special "4-address" connection mode needs to be negotiated between the uplink AP and the "repeater" bridge in order to preserve real MAC addresses of bridged clients, which is something that mesh products do correctly but a RPi connected to a typical standalone AP will not be able to, leading to ugly hacks like L2NAT, but usually you won't notice those.

4
  • why can't a raspberry pi access point preserve the clients' MAC addresses? Sep 25 at 12:40
  • That's a whole separate post but, The access point side can, it's the uplink side that cannot, as the link-layer header doesn't have a field for that. (It's asymmetric and assumes the transmitting client is the original sender – so when the Pi is connected as a client, even though it knows your original MAC, it can't use that when forwarding the frame up to the original access point.) There's a "WDS bridge" mode that would make the Pi-to-uplink connection symmetric but many home routers don't support it.
    – user1686
    Sep 25 at 13:31
  • Back in the olden days, what would two repeaters side-by-side do to stop infinitely repeating cumulatively more and more frames? Sep 25 at 17:43
  • 1
    No idea, didn't have any to actually test with.
    – user1686
    Sep 25 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.