Shibby 1.28 Captive Portal breaks with default QOS settings - fix (workaround)

Discussion in 'Tomato Firmware' started by toobueller, Jul 29, 2013.

  1. toobueller

    toobueller Reformed Router Member

    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.

    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.
  2. earbuilder

    earbuilder Reformed Router Member

    Still an issue for me. Captive Portal (NoCatSplash) plus QOS enabled breaks internet access, same behaviour as above.

    I am running Tomato Firmware 1.28.0000 MIPSR2-114 K26 USB AIO-64K / tomato-K26USB-1.28.RT-N5x-MIPSR2-114-AIO-64K.trx on an Asus RT-N66u

    I have also configured a wireless guest network per this guide: but the issue was there before, with only the two standard wireless networks. The captive portal is supposed to run on the guest network.
  3. earbuilder

    earbuilder Reformed Router Member

    Upon more experiments it seems the combination NoCatSplash and Bandwidth Limiter also is broken.

    Using both NoCat and BW limiter, with bandwidth limited to download rate 700/download ceil 1000 and upload rate 700/upload ceil 1000, the clients download is capped at 0.94 Mbit/s but upload appears uncapped and maxes out my connection, at ~10 Mbit/s.

    If I turn of NoCatsplash I get a nice 0.94/0.94Mbit/s as expected.

    I would very much appreciate if this could be adressed in an upcoming release! I imagine guest wifi with captive portal and limited bandwidth is a quite common and desireable usage scenario.

    Thanks for all the rest super well functioning stuff! Tell us if and how we can help.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice