doc/developer/SupportingDevicesWithNoWebBrowser

Main contributors: Benoit Grégoire, last modified: 2008-01-16

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:  http://listes.ilesansfil.org/pipermail/wifidog/2006-February/thread.html

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

Pros:

  • 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.

Cons:

  • Require the user to sign-up his device.

2-Whitelist specific servers

Pros:

  • 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.

Cons:

  • 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.
NINTENDO DS SERVERS

nintendowifi.net
nintendowifi.com
wii.com
american-sk8land.com

3-Whitelist specific ports

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

Pros:

  • User transparent.

Cons:

  • 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.

Pros:

  • All services are equal (except http)

Cons:

  • 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

Cons:

  • 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.

5-WISPr Appendix D: The smart Client to Access Gateway Interface Protocol

This is basically a standard way for a device to send a username and password to a captive portal, allowing portable devices to script the login process for portable devices (WiFi?? SIP Phones, WiFi?? Digital Cameras, Nintendo DSs, standalone instant messengers, etc). Should this get widespread industry support, it's one way to solve the problem of supporting devices with no web browser. It's actually quite demanding for manufacturer to implement (hence probably not an universal solution), but easy for WiFiDog to support (work is in progress).

WISPr support for wifidog has it's own page: http://dev.wifidog.org/wiki/doc/developer/WiFiDogRadiusWISPr#WhataboutWISPr

Pros:

  • Works with any port
  • Allow devices without web browser to be treated the same as any other device

Cons:

  • Only works for devices with WISPr support
  • Require the user to configure his device properly

Implementing the solutions

Solutions 2, 3 and 3.5 work now, but require custom configuration of the gateway for every change. Work on solution 5 is in progress. 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.

A good programming reference is  http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.progcomm/doc/progcomc/dhcp_api.htm

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.
Pre-Authentication
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.