Version 1 (modified by benoitg, 16 years ago)

New explanation and design document

Last revision:

Error: Failed to load processor Timestamp
No macro or processor named 'Timestamp' found

Supporting devices with no web browser

Supporting devices with no web browser is a complicated issue that has surfaced on the mailing list from time to time. The most comprehensive thread about it is can be found at the top of this page:

Why is this so complicated

A lot of people wrongly assume that since the MAC adress is currently transmitted to the auth server as part of the authentication process it's technically simple to do MAC based authentication. Unfortunately it's a LOT more complicated than that. Since these devices do not have a web browser at all, there is no way to use the current mechanism to transmit the MAC adress of such a device, or even notify wifidog of it's presence.

There are also a policy/philosophy issues that come up, as most of the solutions imply treating users diffrently based on trying to find out the devices they own or the type of service they use.

Both of these have been extensively discussed in the thread linked to above.

Technical options

For solving the technical issues, you only have the following general options:

1-Tie MAC adress(es) to a single user account who vouches for it

This is ticket #19


  • Works for all devices.
  • Works with port 80 (with some coding pitfall)
  • Only slightly more insecure than normal captive portal operation, so it can even replace the login page even for laptops (go straight to portal) in some circumstances.


  • Require the user to sign-up his device.

2-Whitelist specific servers


  • User transparent (for users of the selected services).
  • Works with port 80
  • "perfectly" secure.
  • No ambiguity on what your are allowing/blocking.
  • Allows the group to ask money from their operators for the priviledge (since they run a business on your network).
  • Works for all devices that need to communicate with a finite set of servers.


  • Works for the Nintendo DS or VOIP operators, as well as specific projects (sensors, webcams and the like) but doesn't work for allowing anyone to connect to their own asterisk server for example.

3-Whitelist specific ports

This is trying to identify the service (such as SIP) through the port.


  • User transparent.


  • Once you do that, anyone can tunnel any kind of traffic trough these ports.
  • Doesn't works with port 80. Lots of devices use http on port 80 to communicate with web services, so it can't work for them.
  • Service may not be the only one using those ports, and dynamic ports may be used by the service.

3.5-Don't run any authentication at all

This is the same as 3, but a default-allow policy.


  • All services are equal (except http)


  • Only applicable groups who only run a portal only to display a splash page and terms of service.

4-Whitelist a range of MAC adresses by manufacturer.

This is trying to identify the type of device (such as a Voip Phone) through the manufacturer's . Pros:

  • Works with port 80


  • Only works when the manufacturer and the service to be whitelisted are tied (it would work for the Nintendo DS, but not for a 3com wifi phone.
  • Once the users knows which type of devices are whitelisted, they no longuer have to guess of find a MAC adress to spoof.

Implementing the solutions

Solutions 2, 3 and 3.5 work now, but require custom configuration of the gateway for every change. Solutions 1, 4 (and moving 2 and 3 server side) require the following

Http-independent device detection

Since these devices have no web browser, there has to be some other way to make wifidog aware of their presence. I can think of two implementations (both using DHCP)

Auth trigger hook plugin

This would allow an existing DHCP server to call an executable that would sent a message to wifidog that a device has been granted a lease.

Implement a DHCP server plugin within wifidog

Hopefully this would leverage an existing codebase as a plugin. The main reason to do this is to allow the gateway to send it's lease list to tha auth server, allowing a user more to pick the device to whitelist from a list of MAC and manufacturers instead of typing it if he is at a hotspot.

New wifidog protocol

Version 2 of the WiFiDog protocol? will allow several improvement in server-gateway communication. Among those relevent to the current issues is

Server based firewall rules
Allows to mitigate some of the problems above, by setting different policies (ports, etc.) for the devices authenticated by MAC adress.
Allows a gateway to ask an auth server if it should modify it's firewall rules for a device that it detected, before there is a www authentication request. This would free the gateway from having to download and update full list of MAC adress to be potentially whitelisted in scenario 1, and calculating the masks in scenario 4.