OpenWrt Forum Archive

Topic: Custom x86 Image (NO LONGER MAINTAINED)

The content of this topic has been archived between 6 Sep 2015 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

Alex Atkin UK wrote:

Is this perhaps due to you using trunk so the QoS scripts have already been adapted for IFB so aren't setting up IMQ?

That begs the question as to why QoS didn't work BEFORE you started fiddling with IMQ?

Hmm, I also notice wondershaper is on there (at least its showing in LuCI).  The FAQ for QoS explicitly notes NOT to have the normal QoS scripts and Wondershaper installed at the same time (which is why they are both optional packages on backfire), that might not help matters.

An updated, non-test build just finished uploading to box (https://nuskunetworks.box.com/s/9a4248d4f94a59ee1201).  Can you try r33288 with the libxt_IMQ.so file and report back?  My non-test builds should not include wshaper.

Same problem, so I tried overwriting /usr/lib/qos with the backfire version.  That fixed the iptables rules and now imq0 shows under ifconfig instead of ifb0.

However its STILL not throttling according to the QoS up/downstream limits like its supposed to.  I'm quite at a loss now.

I did notice there are some compile time config options for IMQ, did you compare your options to backfire?

Well, it seems that its known that the IFB QoS is not working properly yet:
https://dev.openwrt.org/ticket/9620

I'm still interested in getting IMQ working though if we can, seems we are very close but missing something.

I compared the iptables package files to backfire, can you post the compile time config stuff?

Alex Atkin UK wrote:

It was this I was wondering about:
http://linuximq.net/foswiki/bin/view/IM … 1NAT_63_41

Do we know which way backfire had it set?

The kernel in trunk is 3.3 and I used the appropriate IMQ patches.  If I remember correctly backfire is using the 2.6 kernel so things will be a little different.


I believe the behavior described in the link appears as a kernel option now.  In the kernel configuration I have an option "IMQ behavior (PRE/POSTROUTING)" which is set to AB...  I did not make any changes to this option.  This might need to change, but I am not sure, if I read the help right it seems to spell out the default is BA...  I have details below on this option.

Do you agree that the default is option #3 (BA)?  Let me know what you think and I will kick off another build for you to test.  It doesn't take too long to put together a small test build with just openssh / kernel / iptables / luci.  Once everything is situated and working I'll put together a fuller build.


This setting defines how IMQ behaves in respect to its
  ? hooking in PREROUTING and POSTROUTING.         
  ?                                                                         
  ? IMQ can work in any of the following ways:           
  ?                                                                         
  ?     PREROUTING   |      POSTROUTING                 
  ? -----------------|-------------------                         
  ? #1  After NAT    |      After NAT                           
  ? #2  After NAT    |      Before NAT                       
  ? #3  Before NAT   |      After NAT                         
  ? #4  Before NAT   |      Before NAT                     
  ?                                                                       
  ? The default behavior is to hook before NAT on PREROUTING         
  ? and after NAT on POSTROUTING (#3).                                 
  ?                                                                       
  ? This settings are specially usefull when trying to use IMQ
  ? to shape NATed clients.                                                 
  ?                                                                         
  ? More information can be found at: www.linuximq.net 
  ?                                                             
  ? If not sure leave the default settings alone.


Edit: Fixed typo

(Last edited by mcrosson on 31 Aug 2012, 03:03)

@Alex: Good news

I need to learn to hit '?' on more stuff in the kernel configuration tool.  Turns out the list of options to select details what "B" and "A" mean and what the order means.

Turns out the IMQ option was changed from the default somehow in my kernel configuration.  I am updating it to use the default behavior now.  I will also run a test build like before for your review.  It will be another small build with luci / openssh / imq. 

If everything goes good in your tests I'll bring the changes across into my full build and publish an updated full build.

I think I know what is stopping QoS working, the sheduling modules are missing:
sch_red                 3504  4
sch_sfq                 4416  4
sch_hfsc               14320  2

I wonder if this is why IFB QoS doesn't work either?

Alex Atkin UK wrote:

I think I know what is stopping QoS working, the sheduling modules are missing:
sch_red                 3504  4
sch_sfq                 4416  4
sch_hfsc               14320  2

I wonder if this is why IFB QoS doesn't work either?

Does IMQ just expose a device to work with or does it include an algorithm for shaping?  The modules you have listed look like the in/out QoS algorithms mentioned in the various guides I've seen in the past.


I checked the kernel config and it looks like some of the QoS stuff is not selected.  Running a new test build now.  Shouldn't be too long before its posted for you.

@Alex: New test build is online (same URL as before), this time with the QoS stuff enabled in the kernel.  Let me know how this round goes.

Also, thanks for being patient with me and helping me do the iterations to get IMQ 100%

(Last edited by mcrosson on 31 Aug 2012, 19:57)

Well, both IMQ and IFB use the standard Linux tc command to handle the actual shaping.  So my guess is its how you describe, that IMQ handles capturing the traffic and standard Linux QoS stuff does the actual shaping.

Its still not working on the latest version though, for some reason the modules are not being loaded.  I'm guessing I missed something with the QoS scripts.

For reference, the ones I have pulled over from backfire so far are:

/usr/lib/qos/*
/usr/bin/qos-start
/usr/bin/qos-stat
/usr/bin/qos-stop

For now I just need to keep digging.

I'll get a new build going with the QoS scripts package integrated.  I also setup the QoS kernel stuff as modules, they likely aren't set to auto-load.  I'll look into that as well.  I'll post back when the next build is online.

Edit: It looks like the QoS scripts were selected for inclusion in my test build.

(Last edited by mcrosson on 31 Aug 2012, 22:13)

Fun discovery: http://wiki.openwrt.org/doc/uci/qos

There is a note that the qos-scripts have dropped IMQ support in favor of IFB.  I will be be looking closer at my kernel to ensure IFB support is also included.

Edit: IFB was not included in my kernel.  I have enabled it for the next test build.

(Last edited by mcrosson on 31 Aug 2012, 22:11)

I was well aware of that, hence why I was copying over the IMQ QoS scripts from backfire and why I suggested fixing IFB support first before resorting to patching IMQ back in. 

Sorry if I did not make that clear.

Oh, well then.  As it stands I have IMQ support going and IFB.  From what I saw on the IMQ site, IFB may not be enough for some users.  Figure I have the kernel patches going for IMQ, might as well leave it enabled.

I also re-set my primary build working tree so hopefully it fixes up the iptables-imq packaging problem I've been having.

@Alex: New test build just finished uploading.  Includes qos-scripts, IFB, IMQ, other QoS stuff built into the kernel.  Let me know how it looks.

Don't forget, the default QoS scripts will ONLY work with IFB.

If anyone wants to use IMQ they will need to replace those scripts, like I was doing.

I will try it with the default scripts first though.

If you get the default scripts working as well as a set working with IMQ, I can create a package from your IMQ scripts for inclusion as an option for people.

Latest build segfaults on boot while inserting one of the modules, couldn't tell which one as it wouldn't let me login either to try and dump the bootup log.  Network didn't come up either, so that was the end of that.

I'll take a closer look and see what I can come up with.

Edit: Tracked it down to the way OpenWRT's config system handles kernel modules.

(Last edited by mcrosson on 1 Sep 2012, 04:12)

@Alex: New test build with IFB and IMQ is up.  Same URL as before.

Still something wrong as now the boot screen shows a lot of sysinit plugin errors, no network access and still cannot login on tty0 as it says "password incorrect".

There is also mention of modules-boot.d being missing, if that is anything.  Never looked at the working boot screen so not sure what its supposed to say further up, I just knew the latter end of the reports weren't sysinit errors.

The errors you received are benign, or at least should be.  The password should be "openwrt" and root as the user.  I logged into the image using those credentials before I posted it....


What network card(s) are you using on your box?

(Last edited by mcrosson on 1 Sep 2012, 05:07)

Okay you were right, it IS working.  For some reason it doesn't work via copying the configuration files over like other versions did so I am having to configure from scratch.

So things on the whole are looking positive for the base?  Still working on IFB / IMQ I assume?

Sorry, posts 101 to 100 are missing from our archive.