FAQ

• What is NoDogSplash (NDS)? NDS shows a special site (called splash page) when a client tries to access the Internet.
  Usually the client needs to use the splash page to authenticate in some way before being granted access to the Internet.

• Where can I find the documentation? The full documentation can be found at: https://nodogsplashdocs.readthedocs.io

• Why does Nodogsplash not have built in traffic shaping?
  It used to, but recent Linux kernels no longer support IMQ (Intermediate queueing device).
  The original pre version 1 feature has been broken since OpenWrt 12.09 (Attitude Adjustment).
  Pull Requests are welcome!
  However the OpenWrt package, SQM Scripts (Smart Queue Management), is fully compatible with Nodogsplash and if configured to operate on the Nodogsplash interface (br-lan by default) will provide efficient IP connection based traffic control to ensure fair usage of available bandwidth. A useful link: https://wiki.openwrt.org/doc/howto/sqm

• Why does NDS not work when there is no Internet? (..and how to fix it)
  Your Browser first needs to resolve to some IP address (via DNS) to make the actual HTTP request that can be intercepted by NDS. A solution is to run a DNS server along with NDS that returns a fake IP address when no Internet is present. For dnsmasq (e.g. on OpenWrt), you can use the address=/#/1.2.3.4/ setting in /etc/dnsmasq.conf, or use a dedicated solution.

• Does NDS support IPv6
  Not yet. Some basic support has been added but is not yet functional.

• My devices show the splash page when they first connect, but when the authorization expires, they just announce there is no internet connection. I have to make them "forget" the wireless network to see the splash page again. Is this how is it supposed to work?

  Captive Portal Detection has been implemented on just about every platform, including most browsers.

  It is important to remember that it is designed primarily for mobile devices to automatically detect the presence of a portal and to trigger the login page, without having to resort to breaking SSL/TLS security by requiring the portal to redirect port 443 for example.

  Just about all current CPD implementations work very well but some compromises are necessary depending on the application.

  The vast majority of devices attaching to a typical Captive Portal are mobile devices. As you have seen, CPD works well giving you the initial login page.

  For a typical guest wifi, eg a coffee shop, bar, club, hotel etc., a device connects, the Internet is accessed for a while, then the user takes the device out of range.

  When taken out of range, a typical mobile device begins periodically polling the wireless spectrum for SSIDs that it knows about to try to obtain a connection again, subject to timeouts to preserve battery life.

  Most Captive Portals have a session duration limit (NDS included).

  If a previously logged in device returns to within the coverage of the portal, the previously used SSID is recognised and CPD is triggered and tests for an Internet connection in the normal way. Within the session duration limit of the portal, the Internet connection will be established, if the session has expired, the splash page will be displayed again.

  Early mobile device implementations of CPD used to poll their detection URL at regular intervals, typically around 30 to 300 seconds. This will trigger the Portal splash page quite quickly if the device stays in range and the session limit is reached, preventing the problem you are seeing.

  However it was very quickly realised that this polling kept the wifi on the device enabled continuously having a very negative effect on battery life, so this polling whilst connected was either increased to a very long interval or removed all together, depending on vendor, to preserve battery charge. As most mobile devices come and go into and out of range, this is not an issue.

  However if the device stays within range, without CPD polling, until the session expires, the issue you are seeing appears.

  The workaround you have found, or even just manually disconnecting or turning wifi off or on will simulate a "going out of range", initialising an immediate trigger of the CPD. One or any combination of these workarounds should work, again depending on the particular vendor's implementation of CPD.

  In contrast, most laptop/desktop operating systems, and browser versions for these still implement CPD polling whilst online as battery considerations are not so important.

  For example, Gnome desktop has its own built in CPD browser with a default interval of 300 seconds. Firefox also defaults to something like 300 seconds. Windows 10 is similar.

  So in answer to your question, this IS how it is supposed to work, but does involve some compromises.

  The best solution is to set the session timeout to a value greater than the expected length of time a client device is likely to be present. My own experience shows a limit of 24 hours covers most situations eg bars, clubs, coffee shops, motels etc. If for example an hotel has guests regularly staying for a few days, then increase the session timeout as required.

  Staff at the venue could have their devices added to the Trusted List if appropriate, but, again in my experience, it is better not to do this as they very soon learn what to do and can help guests who encounter the issue. (Anything that reduces support calls is good!)

• Why do I get a long delay on some clients before the splash page is served?
  Most devices these days are dual stack ipv4/ipv6, and OpenWrt by default has DHCPv6-Service enabled. Devices will therefore prefer ipv6, getting a dhcp address from the router. However they then get no response from the connection. After some seconds, depending on the device OS version, the device will fall back to ipv4 and retry its captive portal detection and eventually receive the splash page. Until NodogSplash supports IPv6 the solution is to disable the OpenWrt DHCPv6-Service. Luci/network/interfaces. Edit LAN. Scroll down to DHCP server. Select IPv6 settings. Change both Router Advertisement-Service and DHCPv6-Service to disabled. Click Save and Apply.

• What is FAS?
  FAS is Forward Authentication Service. FAS allows custom dynamic web pages to be served for authentication.
  FAS configuration consists of "hooks" to these dynamic web pages, somewhere on a separate web server. This server can be on the same device as NDS, on another device on the local network, or on an Internet web hosting service. The custom FAS code is usually written in PHP, but can be any scripting language that the web server supports.

• What is PreAuth?
  PreAuth is a special implementation of FAS. PreAuth uses Nodogsplash's own Web server to serve custom dynamic web pages.
  PreAuth code can be written in any scripting language supported on the device, such as BASH, PHP-cli, Python etc. It could also be a compiled application program.
  In addition, PreAuth also has the advantage of not requiring the resources of a separate Web server, very useful on devices with limited RAM and Flash memory.

• What is BinAuth?
  BinAuth is a means of executing a script for post Nodogsplash authentication processing. It can be used with all types of FAS configurations or with the basic NDS splash page.
  It is able to set individual client session timeout intervals and can be passed client credentials for validation.
  BinAuth code can be written in any scripting language supported on the device, such as BASH, PHP-cli, Python etc. It could also be a compiled application program.

• What is the difference between Nodogsplash authentication and FAS authentication?
  NDS authentication is the process that NDS uses to allow a client device to access the Internet through the Firewall.
  In contrast, FAS provides a process of "Credential Verification", after which FAS, if the verification process is successful, passes the client token to NDS for access to the Internet to be granted.