I agree that is really odd. I'll make a note to look into why.

I'm using a uuid with btrfs currently so I'd expect it to have worked.

@Alex
Sorry for the delay: my response to your other 2 points was in a text file on my development machine which died.

I had an auto-mount problem and I believe it was addressed by editing /etc/config/fstab.

I noticed the same thing with the wi-fi radios on the current build.  I think it is related to a kernel option I enabled, but I don't know which one exactly.  I was working on why this happened when I suffered some hardware failures.

It's been awhile since I surfaced with an update and I feel I owe those interested in this build an update on the state of things.

In late June I had my primary development environment die on me along with a number of components in my storage server.  My development machine was setup to use the server for storage purposes so this was something of a two for one special of suck.  I have spent the last 2-3 weeks working on getting my build environment back online along with everything else that was affected by my hardware failures.

The new hardware has been stable for a few days now and I am working on getting my first post-failure build done.

Good to hear you are still working on it as I still may end up using it.

Been using Fedora 17 on my box for a while and it seems I still can't get everything to work right.  Its crazy but Samba is refusing to work for me, seriously WTF.

Its also notable that the only distro that allows me to setup an AP on 5Ghz is your build of OpenWRT.  I can only assume there is some patch in there bypassing the annoying issue of the WiFi card being set as the WORLD domain.

At this point though I am still waiting for my ISP to switch me to PPPoE and 100Mbit VDSL, that is the point where I will know if my router can handle it or not.

I'm starting to wish I had just bought a Buffalo WZR-HP-AG300H though, I did not expect to have so many problems getting a distro to work properly.

I managed to get an updated build complete this evening.  I am working on getting it published to my web hosting right now.  I'll post back in the next few hours when the publish is complete.  Build is for svn revision r32878.

New build and image are online at: https://nusku.net/openwrt/r32878/

I was uploading a new build this afternoon and took out my web-hosts storage.  I am in the process of recovering and getting the new image online.  I will report back with my progress in the OP of this thread.

Builds are back online at https://nusku.net/openwrt  Sorry for any problems this may have caused the community.

(Last edited by mcrosson on 17 Aug 2012, 16:44)

Did you ever get the chance to try adding back IMQ support in the kernel?

I found out my router isn't handling my new 70Mbit broadband properly even with QoS off.  So I am currently using Fedora 17 on my Atom which I will trade for your build if you get QoS working.

So no pressure then. :-p

I have not looked closely at the IMQ patches.  It looks like I'll need to create a customized kernel patch and patch the iptables package.  I do have it on my to do list.

I wonder what the reasoning is for NOT including it pre-patches in the source when it IS included in the firmware releases?

That is one thing that threw me about your version, even the web UI is slightly different to the router firmware version.

They changed out the kernel version in the trunk of the repo.  Probably why the IMQ patches haven't made it in yet.

The webui may be different due to the luci sources being updated.

I am working off trunk and the latest from the pre-configured feeds.  Most of the stuff in my build is slightly different than the release due to version bumps and the like.

I did take a little bit of a closer look at bringing in the IMQ patches and it should be do-able but there is a bit of work I will need to do in order to make sure the patches get applied correctly.  I also need to be sure I drop the IMQ patches in the right locations.

Thanks, its much appreciated.

You might even consider using QoS yourself as it really makes WORLDS of difference to usability, I hate not having it enabled now as I have to be so careful when downloading to avoid lagging the whole network. 

I remember back when I was still on 5Mbit it allowed me to download from Usenet while streaming the 1080p Microsoft E3 presentation.  The Usenet download was literally throttled down to a few Kbytes but it did its job perfectly as there was no buffering whatsoever of the video stream and once its was done the download bumped back up to full speed. 

Even when I went to 40Mbit I was using to to watch Netflix while downloading off Usenet, its just darn useful to get the most out of your connection as otherwise you have to guess how much to limit your download which can be completely wrong if other people in the house are using the connection too.

Incidentally the way I had it configured:

Priority: ICMP, DNS
Express: HTTPS, SSH
Normal: HTTP
Bulk/Low: FTP, NNTP

I have no idea if this is optimal but it seemed to work well.  Also, https might need lowering over time as more sites use it as standard but for now it was a good compromise as most downloads still go over standard http so it means important sites like ebay or online banking get a higher priority than downloads, but normal http downloads still get higher than FTP or NNTP.  I suspect that Netflix goes over https so gets a good priority, even if it doesn't it would fall into Normal priority and so higher than NNTP.

I have already setup the basic layer 7 QoS stuff that is present in the build   I've just never used the IMQ / ingress stuff before.

Edit (IMQ): Just found where I needed to drop the kernel patches and the necessary bits are showing in menuconfig.  I also think I found where to apply the iptables patches.  Going to run a test build shortly.

(Last edited by mcrosson on 24 Aug 2012, 19:56)

Ooooh exciting, it better bloody compile now. :-p

I will be honest, I have no idea how the normal QoS stuff works.

All I ever did was install the QoS package which has a dependency on mod-IMQ.  I also tried replicating the iptables rules on a standard Linux distro and it complained of missing functionality in iptables, again implying it was using the IMQ patches.

Initially I was using the QoS on DD-WRT which seems very closely related to the QoS on OpenWRT.

Another interesting thing I have noticed though, routing 70Mbit on the Atom uses almost an entire core when maxed out since my ISP switched to PPPoE.  I really hope that means there is enough headroom for QoS.  Although I am fortunate, my ISP said they can switch me back to a VLAN if I REALLY need it as one of the things that convinced me to join them was the fact they weren't using PPPoE.

Full till 100Mbit should be ok on a dual core atom I'd think, can you post back with success / failure once you get the IMQ stuff turned on?  I'm curiuos how well a dual core atom can really keep up.

On the build front: it's going... will be a few hours before I really know if the compile worked or not.  After it's done with this round I plan to reset and re-build with an updated trunk.  I'll be posting back once everything looks ok from my end.  I've not worked with IMQ before, so I'll need your help testing and validating it works as expected.

Its pretty easy to prove if its working or not, at least it is with Usenet downloads.

Ensure you are maxing out your connection with traffic that is set to Bulk/Low priority.  Then start a download using a protocol with a higher priority, you should see the lower priority download pretty much instantly reduce its speed.  Then do the same with QoS off and you should see the behaviour is far less predictable, more than like the bulk download will retain a higher speed.

If I can ever figure out where I left the USB stick I had put OpenWRT on, I would try out the IMQ enabled build ASAP.

@Alex

You will need to start fresh.  The opkg stuff doesn't have an upgrade mechanism for built-in packages like the kernel.  (I've been meaning to write some kind of upgrade tool, but other things first )

Edit: IMQ enabled build got far enough where I'm confident my changes won't cause a bigger problem.  I'm resetting the environment, updating the sources and kicking off a fresh build now.  I'll post back with status / download link once everything looks good on my end.

(Last edited by mcrosson on 24 Aug 2012, 21:30)

Yeah but without it, I have nothing to copy it onto.

The rest of my sticks are 8GB and 16GB, a huge waste when it works fine on a cheapo 2GB.

Looking forward to trying this out.

It just blew up compiling openssl.  Hopefully it's a quick package fix.  The IMQ stuff looked clean though on the last round so it's just a matter of finishing up the package builds and publishing.  Unfortunately my outgoing connection is a little light so it'll take awhile to publish once complete.

I'll definitely be posting back once it's all online.

@Alex: New build is up and hosted: https://nusku.net/openwrt/r33271/  -- This version includes the IMQ patches.

There was a build issue that required me to turn off OpenSSL's threading support.

Found out why the Buffalo was struggling, it was the traffic monitoring iptables rules that seem to vastly increase the load on the router, far more than the QoS does. 

It handles my connection fine now even with QoS enabled as long as I remove those rules, although it still hits 100% load which makes me suspect there is some performance loss that is just not easily noticeable.  No way a router hitting 100% load can possibly be working "fine" IMO.

So I will still be switching to the Atom as soon as I can as it handled the monitoring in Fedora 17, although even on that it seemed to use up 50% CPU (oddly pppd took up 33% even though it uses next to nothing on the Buffalo). 

Not tested your build yet as I need to physically move my NAS box to do that.

My current build has a bad root password... You'll need to reset it before your first boot.  I'm working on getting an updated build done but it will be awhile before i can get it uploaded.

Just tested your build and it was able to both setup a 5Ghz 802.11n network (which I cannot do on stock Linux distros as they do not let me switch the card into the GB region correctly) and its able to handle 100Mbit over that WiFi network. 

That duplicate WiFi interface bug is darn annoying though, its now showing THREE WiFi interfaces in LuCI when I only have one WiFi card.  Funny as it was only showing four on the old build when I had TWO WiFi cards.

Most importantly though, QoS isn't working.  I can see its marking the traffic correctly in /proc/net/ip_conntrack but its not doing the actual QoS handling as its not throttling the traffic and I see nothing passing over the ifb0 device which I believe is where all marked traffic is sent in order to apply the QoS throttling. 

It seems that its missing the PREROUTING iptables rules that route the traffic to the QoS interface.

Incidentally if you want to check if QoS is working yourself then its easy enough.  Set the downstream and upstream values much lower than your real internet connection then do a speedtest.  It should throttle your connection as if your Internet is the speed of the settings on the QoS page.

Did you fiddle with the mac address in /etc/config/wireless? Thats usually the reason that causes OpenWrt to duplicate the wifi definitions.