Wifi repeater and captive portal

Question

Okay, after surfing through the net, I can almost confirm that there is not a single site that tells me whether captive portal hinders the use of a wifi repeater or not. Due to my limited knowledge of how the Wifi protocol works, I can't help but ask several questions that may seem redundant to some. Anyway, here they are:

Assumption: There is a Wifi with a captive portal that requires users to login on a webpage before connecting to the Internet

Q1: If I simply extend that Wifi signal with a portable Wifi repeater, will the new extended Wifi signal work? Why or why not?

Q2: After I pass the captive portal on a desktop, can I set the desktop as an access point to let other devices use the corresponding signal to connect to the Internet? Why or why not? (If yes, will other devices need to login once again?)

Q3: Only if the answer is affirmative to question 2:

If the captive portal allows 10 hours of continuous connection after a successful log in, can I first connect to that Wifi via a computer and a router which then I close the computer but the router is on (using ap mode and connecting to the Wifi) and let other devices connect to the extended signal and connect to the Internet?

Super thanks to your help.

Answer 1

This is pure nonsense. An Ethernet packet has two MAC addresses - source and destination. Routers don't forward MAC addresses, only IP addresses. And a router doing NAT will replace the outgoing IP with it's own. Nobody can know how many hops if any are behind the device they are talking to. So there is no way for a captive portal to know if it is talking to a router doing NAT vs a single wireless client.

It's true that a wireless repeater won't work, because it tries to bridge a single IP network, but it should be entirely possible to build a wireless router that NAT routes between a captive portal and another wireless network, as long as it has some way to authenticate to the captive portal.

Answer 2

The answer to Q1 and Q2 is "no" with almost any captive portal software, which authorizes clients based on their IP and/or MAC address.

Reason is that the repeater/range extender/PC needs two interfaces to extend the range of the wifi cell, one interface in STA mode and the other in AP mode. Therefore routing (or bridging) is needed to carry data from clients on the repeater to the router, on which the captive portal runs.

In case of routing, most often NAT is used by the repeater to avoid having static routes on the wifi hotspot. So the captive portal just sees one IP, namely the one of the repeater.

But even if STA/AP interfaces are internally bridged together on the repeater to form one big IP network, the Ethernet frames from the repeater to the wifi hotspot carry only 3 MAC addresses: the source MAC address, the MAC address of the next hop and the destination MAC address. While the repeater sees the MAC address of the client connected to it as its source, it does not forward this MAC to the captive portal, but replaces it with its own MAC address (because when forwarding the repeater itself is the new source).

So the captive portal has no way to recognize any client behind the repeater and if an user logs in through the repeater, he/she actually logs in with the repeater's address (be it IP or MAC address), not with the address of the user's device. Result is that every device connected to the repeater appears as logged into the captive portal as soon as one user has logged in. Also, if one user logs out, all other users behind the repeater are logged out, too.

To overcome this, some routers can be configured to use WDS (wireless distribution system), but although WDS is contained in the 802.11 standard, the latter does not define any implementation requirements. So, several proprietary implementations are in use, which either use some sort of ARP NAT or a 4 address mode to transmit the origin's MAC address as 4th address in an (wireless) Ethernet frame. Since such WDS implementations require a common set up of the repeater and the captive portal by its admin - and in some cases even the same wifi chipsets on both devices -, I won't elaborate on that any further.