Page 2 of 2

Re: qos upload load (kbps)

Posted: Wed May 18, 2011 5:12 pm
by chico
Ok
Thank you Eric.
If possible, take a look on these files too.
It is for show USB DEVICE STATUS.
I'd like you to improve that.
Thank you very much.

Re: qos upload load (kbps)

Posted: Sun May 22, 2011 3:42 pm
by pbix
Chico,

What specific advantage is there to changing from ip_conntrack to nf_conntrack as you propose?

Isn't your change to gargoyle_header_footer enough to resolve the issue you saw?

Re: qos upload load (kbps)

Posted: Sun May 22, 2011 5:16 pm
by chico
Hi pbix,
As I said before, it is required to correctly show l7proto on connection list page.
Check the output of the commands:
cat /proc/net/ip_conntrack
tcp 6 580 ESTABLISHED src=192.168.1.101 *edited* [ASSURED] mark=771 use=2
cat /proc/1/net/nf_conntrack
ipv4 2 tcp 6 94 TIME_WAIT src=192.168.1.101 *edited* [ASSURED] mark=771 l7proto=unknown use=2

Using the first command with 2.6 kernel we don't have "l7proto=".
Therefore it is necessary to edit the file conntrack.js.
Change this command at line 99.
And change the line 115 to:
var protocol= (line.split(/[\t ]+/))[2];

By the way, the change in the gargoyle_header_footer is working perfectly.

Thanks.

Re: qos upload load (kbps)

Posted: Mon May 23, 2011 7:18 am
by pbix
Chico,
I changed the connections page from ip_conntrack to nf_contrack as you suggested and pushed it to the server. The next time Eric makes a build this fix will be in place and the L7proto field should again display correctly.

Eric is looking at your suggested change to gargoyle_header_footer. Identifying the correct interface to use turns out to be tricky. I for example use PPPoE and do not have the issue you report. Not sure why OpenWRT does not do a better job of standardizing these interfaces. We will have to wait on what Eric decides to do.

Thanks for your help on this.

Re: qos upload load (kbps)

Posted: Sat Jan 14, 2012 8:27 pm
by yc3948
The selected attachment does not exist anymore.

The file ./../files/1335_ee26bde82f8fa3eaea3577c39f892688 does not exist.