First of all, sorry for posting this here, this is the first time I want to ask something about code available on GitHub. If I should post this somewhere else or contact someone personally please tell me.
The problem I have is that I wanted to use the Binvoucher and Preauthentication options available in the release version (0.9_beta9.9.8-1). However, this version seems to be slower with redirecting people to the splash page and only port 80 is blocked for preauthenticated users (even port 443 seems to be open so people can just use https). All this I am doing on OpenWrt (on a TP-Link WDR3600). I also tried the "standard" version for OpenWrt of nodogsplash (0.9_beta9.9.6-3). This seemed to work better with respect to redirection speed and blocking of all ports.
So for me there are two options now. The first is to use the released version of nodogsplash, fix the redirection speed issue and find a way to block all ports instead of only port 80. I have been looking into the iptables but I could not find the issue, I am not very familiar with those unfortunately...
The second options, which looks best to me, is to take version 0.9_beta9.9.6-3 which seems to be more stable on OpenWrt, already blocks all ports automatically and the redirection speed seems better. Then I still need a way to do pre-authentication. That is because I want to use multiple nodes/routes and I don't want clients to be shown the splash page every time they switch nodes because they move from place to place. So I would need to take some pieces of code from the release version, specifically in the file nodogsplash/src/http.c. Now I don't really know how to develop for/modify nodogsplash. So in this case my question would be what the easiest/best way would be to make a small modification to the source code of nodogsplash, compile and test it. It only has to work on OpenWrt, maybe that makes things easier? Currently I install nodogsplash using opkg so I would have to create an ipk file containing the modified nodogsplash code, but I am open to easier solutions to my problem.
Hm, everything should blocked for preauthenticated users (except for port 80 that is redirected).
Regarding the speed issues - I wonder if this is related to the multithreading that was removed.
But this does not seem to be very likely.
Instructions for modifying and testing the NDS code for OpenWrt can be found here: https://github.com/nodogsplash/nodogsplash/tree/master/openwrt
issue confirmed 0.9_beta9.9.8. pre-authenticated user can access any ports other than 80. I think this is a big problem. because most mobile app works fine without using 80 port. 0.9_beta9.9.6 works fine but it doesn't have the binvoucher feature, which is very useful for customizing authentication strategy.
@kinhunt What's the behavior exhibited by this "seems to be slower with redirecting people to the splash page"?
We're using NDS on an OM2P and, on the same smartphone, we get the splash page when joining the wifi AP only half the time. The rest of the time we have to open a browser and request any URL to get it.
hi @contentfree. mpbuijs described this issue in the original post. The loading time of splash page can be very slow(3-5 seconds) with 0.9_beta9.9.8 while it's instant in beta9.9.6. I confirm this on openWRT.
I am the guy who remove multi-threading: #9
On the first thought, I guess it might related to multi-threading, too.
However, I had already do some stress tests, and it seems the non-threading version is slightly faster than multi-threading version.
I ran the nodogsplash, based-on the latest release and remove the commit 73e5b8d, on hundreds of APs for months.
Up to now, there are all work great and I didn't experience any speed issue.
I am also trying to reproduce this issue using the latest release (only revert 2 lines that mwarning mentioned) and default config, but everything looks fine to me.
Is the speed issue always exist? What happen if you restart nodogsplash?
Is there other users in your network? Some stupid app might create a large number of HTTP requests if they cannot connect to their own services.
Are top, netstat -tlan commands output any unusual? high cpu, large amount of connections?
您好@sayuan 。我做了一些测试, 在一个干净的 openwrt + nodogsplash 环境, 低 cpu 和很少连接。每次加载初始页面花了5-10 秒 (chrome/safari osx, iphone 上似乎很好)。但是, 如果我使用 ip 地址 (任何) 而不是域名, 立即加载初始页。我想这可能与 dns 和防火墙规则有关。
hi @sayuan . I did some test on a clean openwrt+nodogsplash environment, low cpu and few connections. It took 5-10 seconds to load the splash page every time (chrome/safari on osx, it seems to be fine on iphone). However, if I use ip address (any) instead of domain name, splash page loaded instantly. I am thinking maybe it's related to dns and firewall rules.
Which version are you using in your production environment? Don't you have the issue which pre-authenticated clients can access any ports but 80?
@mwarning , thank you for pointing out where to look for information on how to build code for OpenWrt (https://github.com/nodogsplash/nodogsplash/tree/master/openwrt). And thank you all for trying to solve the reported issues. I followed the instructions to build and modify nodogsplash for OpenWrt and the first part works perfectly for me now: building the current version of nodogsplash in an .ipk file. Notice that I also had to select nodogsplash during "make menuconfig" in the Network->Captive Portal section, else it wouldn't build the nodogsplash .ipk file at all. Now I wanted to make changes to the code of nodogsplash, but that didn't seem to work. I downloaded http://dev.cloudtrax.com/downloads/patches/nodogsplash-0.9_beta9.9.6.tar.gz, made a minor change, put it under git control, added all files and created the symbolic link using two absolute paths. Still, the newest version of nodogsplash is built. Notice that I also selected the development option "Advanced configuration options" => "Enable package source tree override".
I would also like to address another issue with respect to the 0.9_beta9.9.8-1 (again using OpenWrt on a WDR3600). Maybe it would be good to start a new Issue for that. Namely the fact that the BinVoucher support output script does not receive complete mac addresses. On lines 216-218 and 393-395 in http.c a script is called for remote authentication based on the value of BinVoucher in nodogsplash.conf. In both cases the last part of the MAC addresses passed to the script is missing. With the last part I mean the last 4 hexadecimals from the MAC address of the client including the middle semicolon. So the output I receive in the script that I call is of the form "04:0c:ce:dd" and "04:0c:ce:dd:". I named the script "/bin/myauthentication" and this is also set in the BinVoucher variable. My best guess is that the problem lies in the sprintf function called in both cases to create the string that is going to be used to execute. The problem with sprintf I am referring to here is documented here: http://linux.die.net/man/3/snprintf "Because sprintf() and vsprintf() assume an arbitrarily long string, callers must be careful not to overflow the actual space; this is often impossible to assure". Bottom line: I don't think it was the intention to authenticate 16^4=65536 MAC addresses instead of only one. I didn't do any calculations but it seems to me that on large networks chances will increase significantly that people will have the same 8 hexadecimals in their MAC addresses.
Last, I will do some more testing on the problem regarding long loading times of the splash page on different versions with different browsers.
the bug is there as well, so it may not be our fault (TM); I wait for the authors confirmation.
the binary expects two chains to be created beforehand; use "iptables -t filter -N NDS_FW_NG" and "iptables -t nat -N NDS_FW_NG" to create them
@mpbuijs: Try rm -r build_dir/target*/nodogsplash* and build the package again. If this works we need to update the howto. Please create a new issue/ticket for the MAC issue. I haven't looked into
it yet. Lines 216-218 and 393-395 in http.c look ok to me. Maybe your BinVoucher value is too long (>230 characters)?
Alright, after some help we got it figured out - sort of.
The package mentioned above has -I (prepend) changed to -A (append) because otherwise NDS would ignore all following firewall rules once it has handled traffic.
With -A, OpenWrts default firewall rules apply first. But those have "ACCEPT all". As a consequence - NDS does not even get any traffic to reject/accept. The package above was used in an environment that does not use the OpenWrt firewall - so this problem was non-existent there.
So, what do we do? Using -I as before seem to be the logical choice. It would be good to let the OpenWrt firewall do its stuff when we can disable the "ACCEPT all" behavior without effort.
But the previous behavior is what was expected. Therefore we should use -I (as before) until there is a better solution.