Shibby 1.28 Captive Portal breaks when QOS is enabled with the default QOS settings. This fix is actually more of a work around until it is fixed in a future release. I'm not sure if it is a victek or toastman or shibby or even original nocat author issue, so other builds may also have a similar issue with getting captive portal to work correctly, and therefore others having a similar problems with captive portal may find this info useful. I've had issues getting my captive portal to work correctly with QOS enabled. Without QOS, the captive portal will give users the banner and redirect after the click. My fix uses my super advanced skills level of "fumbling amateur" to solve the problem, so please don't be too harsh on my fix. Symptoms: With QOS enabled, the click goes nowhere. resetting the captive portal by clicking save will allow access without having to click another banner, but additional connect attempts from other devices meet with the same symptoms. clicking "I agree" goes no where. With QOS disabled, Captive portal appears to work as intended. I checked the logs when QOS and captive portal were both active, and I noticed this line: ... user.notice.root: filter::NoCat: Allowing traffic tagged with class x from network ... with 'class x' being a number from 1 to 3 with 4 and higher being dropped. Noting that there were 10 predefined classes in the QOS settings, I redefined port 80 WWW traffic to be class 3, and afterward captive portal started redirecting back to a web page correctly, but since this only fixes http traffic, I had to do a little more work. My work around was to redefine all 10 QOS class names so that 1 was high, 2 was medium, 3 was low and 4-10 was 4x,5x,etc..10x. Then I redefined the classifications so everything in the default set was 1 through 3, instead of a 1 through 10. (divided class by 3 to approximate a level 1-3 reclassification). I also had to modify the rates and limits to better suit the crowded classes. Since I don't know enough about how this works to fix it correctly, I thought I would report it here in hopes that the right people could fix it for everyone in a future release, or in the very least save someone else from hours of frustration. If my guess is correct, a possibly simple change of a "4" to an "11" or even "99" or maybe "0" to an iptable rule created by the captive portal will fix this. the related log line is ... user.notice.root: mangle::NoCat: Deny packets from interface br0 by default (i.e. give them class: 4) Having both QOS and the captive portal were important in my choice for this build, so disabling one was not an option for me. If someone knows the correct file and line to change, I'd like to know so I can get the default QOS settings back to 10 levels.