#20834: qos-scripts applies PPPoA WAN upload rate limit to LAN port eth0 on
boot
-------------------------+--------------------------------
Reporter: saf@… | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone:
Component: packages | Version: Chaos Calmer 15.05
Keywords: qos-scripts |
-------------------------+--------------------------------
On my Netgear DGN3500, with either Barrier Breaker or Chaos Calmer, the
QOS WAN upload bandwidth restriction is incorrectly applied to the eth0
LAN connection on boot. This effectively means that the PC connected to
eth0 has its download speed limited to the QOS upload speed.
My ISP is EE (a UK ISP) and the connection is ADSL using PPPoA.
/etc/config/qos has:
config interface wan
option classgroup "Default"
option enabled 1
option upload 750
option download 12000
/etc/config/network has:
config interface 'wan'
option _orig_ifname 'nas0'
option _orig_bridge 'false'
option proto 'pppoa'
option encaps 'vc'
option atmdev '0'
option vci '38'
option vpi '0'
option username 'xxx'
option password 'xxx'
If I connect to speedtest.net from the PC connected to eth0, it shows a
download speed of about 0.69Mbps.
I have investigated and I believe the problem is caused by qos-scripts
incorrectly invoking tc on the eth0 interface when called before the WAN
connection has been established. I investigated initially under Barrier
Breaker before upgrading to Chaos Calmer to see if it would fix the
problem; the details below are taken from a Chaos Calmer installation, but
I believe the issue is essentially the same for both releases.
If I apply the attached debug.patch patch, which adds some temporary
logging, rebooting and waiting for the ADSL connection to come up
generates the output in log-showing-problem.txt. (It may help to initially
grep out just the lines containing 'user.notice qos'.) This log shows that
during boot, /usr/lib/qos/generate.sh is executed before the pppoa-wan
interface comes up:
Fri Oct 30 20:28:24 2015 user.notice qos: generate.sh executed
Fri Oct 30 20:28:24 2015 user.notice qos: br-lan Link encap:Ethernet
HWaddr xx:xx:xx:xx:xx:xx
Fri Oct 30 20:28:24 2015 user.notice qos: eth0 Link encap:Ethernet
HWaddr xx:xx:xx:xx:xx:xx
Fri Oct 30 20:28:24 2015 user.notice qos: eth0.1 Link encap:Ethernet
HWaddr xx:xx:xx:xx:xx:xx
Fri Oct 30 20:28:24 2015 user.notice qos: ifb0 Link encap:Ethernet
HWaddr xx:xx:xx:xx:xx:xx
Fri Oct 30 20:28:24 2015 user.notice qos: lo Link encap:Local
Loopback
Fri Oct 30 20:28:24 2015 user.notice qos: wlan0 Link encap:Ethernet
HWaddr xx:xx:xx:xx:xx:xx
[note there is no pppoa-wan line]
config_cb retrieves an empty string when it attempts to determine the
device for interface 'wan' - which I think is correct, since the interface
is not up. However, it then decides to use a hard-coded default of eth0 -
which I think is incorrect, at least in this case:
Fri Oct 30 20:28:25 2015 user.notice qos: Defaulting device to eth0 for
wan
start_interface then applies the 'rate 750' specified for uploads over
interface 'wan' in /etc/config/qos to eth0:
Fri Oct 30 20:28:26 2015 user.notice qos: start_interface iface=wan,
num_ifb=1
Fri Oct 30 20:28:26 2015 user.notice qos: tc class add dev eth0 parent 1:
classid 1:1 hfsc sc rate 750kbit ul rate 750kbit
Fri Oct 30 20:28:26 2015 user.notice qos: tc class add dev ifb0 parent 1:
classid 1:1 hfsc sc rate 12000kbit ul rate 12000kbit
Once the WAN interface comes up, generate.sh is invoked again and
correctly applies the upload rate limit to pppoa-wan:
Fri Oct 30 20:29:34 2015 user.notice qos: generate.sh executed
Fri Oct 30 20:29:34 2015 user.notice qos: br-lan Link encap:Ethernet
HWaddr xx:xx:xx:xx:xx:xx
Fri Oct 30 20:29:34 2015 user.notice qos: eth0 Link encap:Ethernet
HWaddr xx:xx:xx:xx:xx:xx
Fri Oct 30 20:29:34 2015 user.notice qos: eth0.1 Link encap:Ethernet
HWaddr xx:xx:xx:xx:xx:xx
Fri Oct 30 20:29:34 2015 user.notice qos: ifb0 Link encap:Ethernet
HWaddr xx:xx:xx:xx:xx:xx
Fri Oct 30 20:29:34 2015 user.notice qos: lo Link encap:Local
Loopback
Fri Oct 30 20:29:34 2015 user.notice qos: pppoa-wan Link encap:Point-to-
Point Protocol
Fri Oct 30 20:29:34 2015 user.notice qos: wlan0 Link encap:Ethernet
HWaddr xx:xx:xx:xx:xx:xx
Fri Oct 30 20:29:35 2015 user.notice qos: start_interface iface=wan,
num_ifb=1
Fri Oct 30 20:29:35 2015 user.notice qos: tc class add dev pppoa-wan
parent 1: classid 1:1 hfsc sc rate 750kbit ul rate 750kbit
Fri Oct 30 20:29:35 2015 user.notice qos: tc class add dev ifb0 parent 1:
classid 1:1 hfsc sc rate 12000kbit ul rate 12000kbit
This is fine, but the rate limit incorrectly applied to eth0 remains in
force.
start_interface already has code to check for an empty device string and
do nothing in this case, but this never comes into play because of the
eth0 default applied in config_cb.
possible-fix.patch patch simply removes the eth0 default; this fixes the
problem for me, but may break whatever case motivated the addition of this
default in the first place.
(I did think initially that a possible workaround would be to connect my
PC to a different physical Ethernet port on the router, but it appears
that if you have only one device connected, that is always eth0,
regardless of which physical socket it is plugged into.)
If you need any more information or would like me to test out an alternate
fix, please let me know.
Cheers.
Steve
--
Ticket URL: <https://dev.openwrt.org/ticket/20834>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
