1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

br1 (wl0) skip QoS

Discussion in 'Tomato Firmware' started by _wb_, Dec 24, 2013.

  1. _wb_

    _wb_ Networkin' Nut Member

    I have setup a tomato router with QoS. I have 2 networks. LAN (br0) for home and LAN1 (eth1/wl0) for guests wi-fi network.

    I created eth1(wl0) to bridge to LAN1 (br1). LAN1 can't reach LAN.

    I get a DHCP address on LAN (subnet1) and LAN1 (subnet2), respectively.

    I can see LAN traffic in the QoS details and everything is fine.

    Once a guest in LAN1 gets an IP from subnet2 then subnet2 does not to go through QoS rules. That subnet2 is labelled as Unclassified.

    I just want LAN1 to use the same QoS rules as LAN. Any advice?

    Any input @Porter @Toastman ?
     
    Last edited: Dec 24, 2013
  2. Porter

    Porter LI Guru Member

    The problem is that I don't know how all you network interfaces interact when there is a separate subnet. What seems to be the case here is that the normal iptables ruleset doesn't see the traffic generated by your subnet2 and therefore can't mark it. You probably need to research how those packets traverse thought the iptables-system and then you might be able to add the missing rules.
     
  3. mw333

    mw333 Serious Server Member

    How are you assessing the traffic not going through QOS rules? If you are looking at the Details page you will not see the local IP address in the source column - looks like a bug. For some reason Details works for that binned as Unclassified. You could look at the Connections Distributions page while surfing to see it the WWW bin count follows.
     
  4. _wb_

    _wb_ Networkin' Nut Member

    @Porter @mw333 If I go to the "Details" page I only see src gateway 172.16.0.1 (subnet2) talking to the client 172.16.0.2 and to WAN port (since it goes to the internet) but the QoS rules are not applied since all ports 80, 25, etc shows as Unclassifed. Same applies to "Connections Distributions" page. It only shows Unclassified traffic from that subnet2.
     
  5. mw333

    mw333 Serious Server Member

    I see. Recommend that you take a look at the mangle table (iptables -t mangle -L) and see what you have in
    Chain QOSO and its references (FORWARD and OUTPUT). Hopefully you will see source and destination
    anywhere / anywhere (unless you specified a specific source/destination). You could also look at the other tables and follow Porter's recommendation.

    What does your routing table say?
     
  6. _wb_

    _wb_ Networkin' Nut Member

    QOSO table only shows anywhere/anywhere as you mentioned. Although, /etc/qos specify
    Code:
    WAN_DEV=vlan2
    IMQ_DEV=imq0
    but tun11 is the VPN traffic. Would it be possible to copy /etc/qos to /tmp and somehow run those rules with WAN_DEV=tun11 ?!? and IMQ_DEV=imq1 ?!?
     
  7. mw333

    mw333 Serious Server Member

    Something might have gotten scrogged. I'd be more inclined to "start over." At a minimum, recommend tear down wl0, rebuild, try again; tear down the vlan/br you created and try again. The best solution may be to Restore Default Configuration/clear nvram and create the br, vlan, and wl0 following Mr. Teaman's examples.

    Go slow, one step at a time - troubleshooting one change is easier than after many. The order of the nvram variables creation may play role. There is also discussion to make sure each br has a physical LAN port assigned for successful startup port assignments.

    What router do you have? Do you know physical port vs switchport? For example, labeled LAN1 is not always GUI Port 1 and WAN is not always GUI WAN.
     
  8. Porter

    Porter LI Guru Member

    @_wb_:

    As I've already told you, you need to understand how the packets traverse through all theses chains (PREROUTING, INPUT, QOSO etc.). Personally I can't help you there because I just don't have the time right now. From my superficial perspective it just looks like the packets from your subnet2 are not traversing through QOSO and that's why the QoS-system displays them as unclassified.

    The solution might be as easy as to do a "iptables -A FORWARD -o other_interface -j QOSO".

    I'm a bit puzzled right now: where do tun11 and imq1 come from? You didn't mention VPN in your first post.

    If you want to use your own QoS script, then I would recommend using the JFFS partition. /tmp doesn't stick through a reboot.
     
  9. Porter

    Porter LI Guru Member

    @_wb_

    Now I know where all those devices come from which you didn't mention in your first post: http://linksysinfo.org/index.php?threads/dev-requested-add-qos-for-openvpn-tunnels.69001/

    The topic of this thread is quite different so please disregard it.

    The two additional commands you probably just need are those:

    Code:
    iptables -t mangle -A FORWARD -o br1 -j QOSO
    iptables -t mangle -A OUTPUT -o br1 -j QOSO
    Add those lines to Administration/Scripts/WAN Up.

    I don't think you will need an extra QoS-Script. Just try those two lines first. I hope br1 is the right interface.
     
  10. mw333

    mw333 Serious Server Member

    For what it is worth my /etc/qos variables are the same (were the vlanN is br0). QOS is working for me (for br0, br1, br2, and br3) without any additional rules. What is your VLAN setup? Are you utilizing the GUI?
     
  11. _wb_

    _wb_ Networkin' Nut Member

    @mw333 I setup a VLAN 3 (using the GUI) without any physical ports assigned to it. I set it up as bridge LAN1(br1).
    I then went to "Basic-Network" and created a new subnet to lease addresses to this "guest" only network.
    Do I need to assign a physical port to VLAN3 in order to work properly even though I am using the wifi from this router to be a guest network only?

    Update: This is how it is setup http://www.mcbsys.com/techblog/2011/11/set-up-guest-wireless-with-tomato/
     
    Last edited: Jan 4, 2014
  12. _wb_

    _wb_ Networkin' Nut Member

    Thanks @Porter but if you do an ifconfig you see the extra imq1 and other interfaces. Also, /etc/qos has the qos script as far as I can see but I am not keen what each entry mean.

    Nevertheless, I tried just adding those two iptables but that doesn't work either.
     
  13. mw333

    mw333 Serious Server Member

    In reference to "Do I need to assign a physical port to VLAN3" it is advised. There are discussions regarding router start-up and interface assignment on the fly with sometimes unpredictable behavior. Best to give each vlan an interface. FYI the order in which you set up your vlan3 is different than the order the brain trust has recommended. The order in which variables are assigned is important. As recommended before, I'd be inclined to start over.

    Here's a good start: https://code.google.com/p/tomato-sdhc-vlan/wiki/MultiSSIDHOWTOForWRT54GL
     
  14. _wb_

    _wb_ Networkin' Nut Member

  15. Porter

    Porter LI Guru Member

    @_wb_

    Actually I don't see an extra imq1 device and I wouldn't even know why there should be an additional one. Could you look into /etc/iptables and tell me which device it attaches to? I don't have a tun* interface either because I'm not using VPN.

    And I did mention that br1 might be the wrong interface. Also there is mw333 who seems to have a similar setup without any problems so my suggestions might be unneccessary.
     
  16. mw333

    mw333 Serious Server Member

    @Porter

    On reflection it appears Tomato is working the way it is supposed to (based on the information provided).

    QOS applies to WAN connectivity. The VPN will appear as a single connection - the VPN listener port. This port, and all the stuff in the tunnel, will follow the QOS rules (for this port). If the QOS rules say Unclassified it will be Unclassified.

    QOS cannot take stuff out of the tunnel and place it into another classification for us to see in the charts. Does this make sense?
     
  17. Porter

    Porter LI Guru Member

    @mw333

    Where did _wb_ tell us in his first post that he tried doing VPN? He just suddenly mentioned a VPN-interface in one of his posts and this probably came from another unrelated thread to his problem. So let's be careful and stick to the problem at hand.

    I agree with the VPN part, though, and I don't recall saying anything to the contrary. But again: this thread isn't about VPN.

    The part that makes me curious is how those packets/connections from subnet2 circumvent the marking mechanism in QOSO so that there is unclassified traffic when everything clearly has to exit through ppp0.
     
  18. mw333

    mw333 Serious Server Member

    @Porter

    Thank you. I was grasping for straws and it was early in the morning. :)

    The packets should not circumvent. Regrettably we do no know what _wb_'s configuration is - only the pieces that have been shared. We are trying to help viewing the world through our own personal lens, how we would do things. For example, I wonder if the routing table is like mine. It's possible the VLAN configuration is not complete / variables have been assigned incorrectly. Might be best to start out from a known state.
     
  19. _wb_

    _wb_ Networkin' Nut Member

    I really appreciate your help. Thanks in particular to @Porter and @mw333
    Procedure:

    1. Re-flashed RT-N16 with Shibby patch 115.
    2. Followed the steps from this site.
    - Created DHCP for br0 10.0.1.1/27 and br1 172.16.0.1/29
    - WAN is assigned to VLAN VID 1
    - LAN (br0) is assigned to VLAN VID 2
    - LAN1 (br1) is assigned to VLAN VID 3 (guest wifi)
    - eth1 bridge to LAN1 (br1)​

    At this point I am able to get IP from my LAN and also if I connect to my guest wi-fi I get IP from LAN1 as expected.

    QoS:
    Case 1: Any IP on LAN will show up in source (QoS - View Details).
    Example: When I ssh to ip 68.17x.xx.xx as shown in screen1.jpg, you see that the source is my machine's IP on LAN 10.0.1.17 to IP 68.17x.xx.xx and matched class Remote as expected.​

    Case 2: Any IP on LAN1 will NOT show up in source (QoS - View Details). The internal IP assigned (172.16.0.4) to the machine is not shown when I try to ssh to ip 68.17x.xx.xx. QoS - View Details only shows source as 68.17x.xx.xx and destination wan-ip (xx.xx.184.122) BUT it is assigned the correct class Remote.

    I expected Case 2 to behave as Case 1. Also, LAN1 shows tons of Unclassified. Maybe this is how it works but I am not sure. Any thoughts?
     

    Attached Files:

    Last edited: Jan 5, 2014
  20. mw333

    mw333 Serious Server Member

    The best way to assess the QOS function is to monitor the Connections Distribution page in real time. For example, WWW traffic will tic up and down for both br0 and br1 as you surf WWW on these VLANs. If you focus on the Details page it may be confusing. On the Details page, the traffic on br1 seems to be displayed from br0's perspective, e.g. outside of br1 so you get the external IP.

    Have you tried assessing QOS from the Connections Distribution page?
     
  21. _wb_

    _wb_ Networkin' Nut Member

    I did and it shows LAN1 in "Connection Distributions (TCP/UDP)" and the other two graphs on that page. Although there is no details on this page except that traffic goes up and down on both VLANs.

    Again, this is fine but QoS-Details page shows useful information not displayed in Connections Distribution. I would like to see the details page correctly reporting each LANx traffic and not the general view of connections distributions.
     
  22. mw333

    mw333 Serious Server Member

    If you are really ambitious you could do some reading on netfilter connmark. Then look at the /proc/net/ip_conntrack file. There's a field called mark. Then Look at your firewall mangle table and correlate the CONNMARK values.

    cat /proc/net/ip_conntrack
    iptables -t mangle -nvL
     
  23. _wb_

    _wb_ Networkin' Nut Member

    The mangle tables all show * in to * out. The interesting one is PREROUTING that has:
    Code:
    Chain PREROUTING (policy ACCEPT 93891 packets, 45M bytes)
    pkts bytes target     prot opt in     out     source               destination      
    36900   32M CONNMARK   all  --  vlan1  *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore mask 0xff
    36900   32M IMQ        all  --  vlan1  *       0.0.0.0/0            0.0.0.0/0           IMQ: todev 0
    
    VLAN1 here is the WAN. All the other tables there is no mention of any other VLANs. I am clueless at this time. I tried to read and get familiar but something else must be triggering it to show or not the details of LAN1 ups in QoS-Details page.

    Do you know what makes QoS-Details page show the correct IP for LAN?
     
    Last edited: Jan 5, 2014
  24. mw333

    mw333 Serious Server Member

    I have the same rules. If you look at the QOSO chain you will see something like:
    udp dpt:53 connbytes 0:10239 bytes direction both CONNMARK set-return 0x101001/0xff
    that applies to everything. Does port 53 sound familiar? (Hint: check Classification Rules match rule and class)

    I believe the details page pulls most of it's information from the ip_conntrack file. But I could be wrong. To answer your question, "Do you know what makes QoS-Details page show the correct IP for LAN?" the short answer is yes. A solution is to stick with br0. Another solution is a little harder. Someone with a burning desire needs to take the time to figure it out and share with the community. Do you have the burning desire?
     
  25. _wb_

    _wb_ Networkin' Nut Member

    @mw333 port 53 is for DNS. Still can't make sense of it. I don't know about "burning desire" but I do want it to work because I don't think it is correct now. I went back to this qos development link and it seems that if I replicate what is in /etc/qos it might work with these FORWARD and OUTPUT rules I might go somewhere.

    Code:
    iptables -t mangle -A FORWARD -o SOME_INTERFACE -j QOSO
    
    iptables -t mangle -A OUTPUT -o SOME_INTERFACE -j QOSO
    I also noticed that from another user here that referred to an IMQ document where it states each interface should belong to a different imq. Anyway, I will have to keep reading and testing unless someone that understands the inner works of the QoS chime in with some concrete solutions.
     
  26. mw333

    mw333 Serious Server Member

    Keep on reading. Have fun.
     

    Attached Files:

  27. _wb_

    _wb_ Networkin' Nut Member

    See my post above. The originating address is not shown in QoS-Detail when I try to ssh for example. Instead, I see the ssh destination IP and port shown in QoS-Detail as the source. Not sure where to go from here.
     
  28. Porter

    Porter LI Guru Member

    @_wb_:

    I'd suggest you ignore /etc/qos and IMQ-devices for now, because all your traffic has to go through ppp0 and imq0. Now you only have to find out why the iptables-system doesn't know about it.

    In your second example here http://www.linksysinfo.org/index.php?threads/br1-wl0-skip-qos.69445/#post-239610 it looks like the traffic gets recognized, but too late (the answer of the server is being marked, from you router's point of view it looks like an incoming connection). As I said I don't know why it doesn't, but one explanation why your ssh traffic does get recognized later might be that the filter you added on the Classification page accepts src and dst packets and not only dst packets. Most of the other filters in the list do in fact only act on dst packets. So a very imperfect solution (unknown side effects, such as bad detection of traffic and poor QoS-performance) would be to switch all you filters from "dst" to "dst and src". But I really don't recommend this.
     
  29. _wb_

    _wb_ Networkin' Nut Member

    Indeed It does indeed look like an incoming connection for LAN1. I don't think it is my Classifications because LAN subnet is shown properly but not connections from LAN1 subnet. I think LAN1 is somehow not being market by iptables but I can't find any specific iptable that makes it show in QOS-Detail. Appreciate your help.
     

Share This Page