Another interesting fact is that I am using v24pre-SP2 1099 which is circa Nov 2008. Can someone clue me into the location of the QOS script with the incorrect IPTABLES command? I can check this version and see if it has the same script error.
That's all that has to be done for HTB but for HFSC the entire tc structure has to be redone. _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
Oops! I stuck this at the end of my firewall script and rebooted my router but the spurious rule is still present. (The command definitely works if I issue it manually in telnet.)
Looks like there's a timing issue involved here. Any suggestions for wrapper code to run this command when DD-WRT is actually ready for it?
A frequent cron job. _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
I thought you were just Jokin' but you must be serious...
I tried running sleep before running the command to delete the rule, but that just seems to delay imq initialization by the number of seconds that it sleeps.
Also tried forcing sleep into the background and wait-ing for the job to complete, but that didn't work any better.
After testing this with different delays I determined that one second wasn't enough but two seemed to be sufficient. Here's why I upped it all the way to five seconds:
Quote:
root@DD-WRT:~# cat /proc/kmsg
[...]
<6>etherip: Ethernet over IPv4 tunneling driver
<0>ip_conntrack_pptp version 1.9 loaded
<0>ip_nat_pptp version 1.5 loaded
<6>IPP2P v0.8.2 loading
<6>imq driver loaded.
<6>HTB init, kernel part version 3.17
<6>HTB init, kernel part version 3.17
<6>IPP2P v0.8.2 unloaded
<0>ip_nat_pptp version 1.5 unloaded
<0>ip_conntrack_pptp version 1.9 unloaded
<0>ip_conntrack_pptp version 1.9 loaded
<0>ip_nat_pptp version 1.5 loaded
<6>IPP2P v0.8.2 loading
<6>IPP2P v0.8.2 unloaded
<0>ip_nat_pptp version 1.5 unloaded
<0>ip_conntrack_pptp version 1.9 unloaded
<0>ip_conntrack_pptp version 1.9 loaded
<0>ip_nat_pptp version 1.5 loaded
<6>IPP2P v0.8.2 loading
<6>HTB init, kernel part version 3.17
<6>HTB init, kernel part version 3.17
Those messages are from interface state changes. A common culprit is the firewall blocking dhcp renewal replies that it doesn't like which causes the interface to go down temporarily while it sends out a request for any ip.
http://svn.dd-wrt.com:8000/dd-wrt/ticket/973 _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
I actually use that command from your Trac ticket to allow DHCP requests from clients on my second AP. I wasn't aware that this may need to be added to the default config as well. I will take a look at it after I get some sleep. Thanks...
Here's another interesting test tool that might help diagnose some problems. I ran it but was a bit mystified how to correct some of the problems it found.