I have a (slightly unrelated) questing regarding the performance of the router (WAN->LAN throughput). Is there a way to diagnose what is causing slowdowns? (Cpu/ram/some random firmware thing/kernel?)
My performance on stock is about 2.5-3x as high as on ddwrt/openwrt (including this firmware) and I would like to understand why that is. Perhaps with some understanding it might even be fixable?

Hello hnyman,

I tried trunk and attitude. Both produced the same failure. This log is from the attitude build.
I really like your work but I miss some features and I need different paćkages. Your build is a good starting point :-)

All patches are run by your script:
WNDR3700-trunk-r38896-2013-11-23-1003-luci.patch
WNDR3700-trunk-r38896-2013-11-23-1003-openwrt.patch
WNDR3700-trunk-r38896-2013-11-23-1003-packages.patch

Everything worked fine except the missing files directory...

What are the hard numbers on stock vs third party firmware? Most stock firmware comes with proprietary hardware NAT drivers that by-passes the kernel and iptables to achieve "gigabit" routing speed.

If you try to create attitude, make sure that you download the attitude patches, not those three trunk patches. And also set the patch names in newOpenwrtBuildroot.sh

In your example you have mixed those. You say attitude build, but the patches are for trunk:

To me it sounds that you have wrong patch names inside the script and the new files are not added correctly.

Use the newest attitude build r38865, if you want attitude.

EDIT:
I tested with attitude, and it went ok otherwise, but one chmod line produced error because there is no /etc/rc.button in attitude. I will add a -f parameter to the chmod in the next version, but in the meantime, just comment out the line "chmod 755 files/etc/rc.button/*". (I wan to keep identical script for trunk and attitude, so this one directory existing only in trunk seems to cause a minor mishap in attitude.)

EDIT2:
Example of creating attitude build environment:

2038  cd /Openwrt/
 2039  wget https://www.dropbox.com/sh/t52c02rm20y8x9p/kx9khZN-Zn/attitude-r38865-2013-11-19/WNDR3700-attitude-r38865-2013-11-19-1716-buildscripts.txt
 2040  chmod 755 WNDR3700-attitude-r38865-2013-11-19-1716-buildscripts.txt 
 2041  ./WNDR3700-attitude-r38865-2013-11-19-1716-buildscripts.txt 
 2042  gedit newOpenwrtBuildroot.sh 
 2043  wget https://www.dropbox.com/sh/t52c02rm20y8x9p/8s00UuZrqu/attitude-r38865-2013-11-19/WNDR3700-attitude-r38865-2013-11-19-1716-openwrt.patch
 2044  wget https://www.dropbox.com/sh/t52c02rm20y8x9p/heyuKKtOrx/attitude-r38865-2013-11-19/WNDR3700-attitude-r38865-2013-11-19-1716-packages.patch
 2045  wget https://www.dropbox.com/sh/t52c02rm20y8x9p/0ytrTjtGw_/attitude-r38865-2013-11-19/WNDR3700-attitude-r38865-2013-11-19-1716-luci.patch
 2046  chmod 755 newOpenwrtBuildroot.sh 
 2047  ./newOpenwrtBuildroot.sh 
 2048  ls -la
 2049  cd attitude/
 2050  ls -la
 2051  history

newOpenwrtBuildroot.sh was edited on four lines:
-uncomment two attitude definition lines
-comment out the exit line
-comment out the chmod rc.button line

EDIT3:
I have fixed the chmod command in the script of the attitude 38899 build.

(Last edited by hnyman on 24 Nov 2013, 09:36)

@hnyman: thanks for your help!!!

Your newOpenwrtBuildroot.sh misses an "apt-get install bison", otherwise the build still fails.
Do you the dependencies to remove uhttpd. I want to replace it by lighttpd :-)

WiresharkPortable Internet Control Message Protocol v6

    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0x649d [correct]
    Cur hop limit: 0
    Flags: 0x00
        0... .... = Managed address configuration: Not set
        .0.. .... = Other configuration: Not set
        ..0. .... = Home Agent: Not set
        ...0 0... = Prf (Default Router Preference): Medium (0)
        .... .0.. = Proxy: Not set
        .... ..0. = Reserved: 0
    Router lifetime (s): 0
    Reachable time (ms): 15000
    Retrans timer (ms): 2000
    ICMPv6 Option (Prefix information : 2001:0:9d38:90d7:ff00:0:20:100/64)
        Type: Prefix information (3)
        Length: 4 (32 bytes)
        Prefix Length: 64
        Flag: 0x40
            0... .... = On-link flag(L): Not set
            .1.. .... = Autonomous address-configuration flag(A): Set
            ..0. .... = Router address flag(R): Not set
            ...0 0000 = Reserved: 0
        Valid Lifetime: 4294967295 (Infinity)
        Preferred Lifetime: 4294967295 (Infinity)
        Reserved
        Prefix: 2001:0:9d38:90d7:ff00:0:20:100 (2001:0:9d38:90d7:ff00:0:20:100)

I was waiting for a prefix with 2A01. Were does 2001 come from?
Hnyman, please, can you help me understand,

The needed packages vary a bit by the underlying OS version. So far I have not needed to install bison separately (for my Ubuntu x64). If you need it, add it to your version of the script. Suggested list of pre-requisites can be found here: http://wiki.openwrt.org/doc/howto/build … tallations

I have not played with uhttpd/lighttpd. But info is e.g. here: http://wiki.openwrt.org/doc/howto/luci.on.lighttpd

That's a Teredo address, You wouldn't happen to have a Windows system with internet sharing on your network would you?

Edit: I completely forgot, Teredo sets up the tunnel using normal RS/RA packets, what you're seeing is the PC renewing it's Teredo address.

(Last edited by The_Decryptor on 28 Nov 2013, 10:28)

Hello hnyman,
I still have not solved my problem of IPv6.
Maybe someone could help me. To summarize the ping6 is ok but the navigation is not.

ping -6 www.google.com

Envoi d'une requête 'ping' sur www.google.com [2a00:1450:400c:c03::93] avec 32 octets de données :
Réponse de 2a00:1450:400c:c03::93 : temps=41 ms
Réponse de 2a00:1450:400c:c03::93 : temps=36 ms
Réponse de 2a00:1450:400c:c03::93 : temps=34 ms
Réponse de 2a00:1450:400c:c03::93 : temps=37 ms

Statistiques Ping pour 2a00:1450:400c:c03::93:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 34ms, Maximum = 41ms, Moyenne = 37ms

I do not think it is a DNS problem. I have no result by using this link [2a00:1450:400c:c00::67]

Edit: Awful! This is Avast2014 which is causing the problem under Windows 8.1.

(Last edited by Manani on 2 Dec 2013, 00:37)

Thank you for your reply.
These are the only IPv6 RA I have on my Windows 8.1. PC has a public IPv6 and ping6 is OK. Only the browsing on websites test fails.

That has most likely been fixed in Luci sources a few hours ago by changing the & char to a proper escape sequence: http://nbd.name/gitweb.cgi?p=luci.git;a … e89fc1cbe3
Try the next build in a few days.

It's nice to get the old theme in future updates.
Thanks!

Edit r38996: Everything is ok for the OpenWRT theme.
I will test changing database directory this weekend.

(Last edited by Manani on 5 Dec 2013, 22:00)

So it seems to be. I tested with 39004 and a hidden network is visible when scanned from a PC. My build has the standard wifi components, so we should probably file a ticket for it. There have been several wifi management related changes lately, so it is quite possible that some bug has been introduced.

EDIT:
a ticket has been filed: https://dev.openwrt.org/ticket/14589

EDIT4:
Fixed in 39005

But I also noticed that my wifi button script does not work any more for shutting down wifi. It goes down but restarts immediately. Apparently the commands in the button script need to be modified. Next build will have the fix for the wifi button. (detection of /var/run/hostapd instead of /var/run/hostapd-phy0)   
...  Included in 39025 build

(Last edited by hnyman on 9 Dec 2013, 21:57)

I have no "proper benchmark" numbers, but I get around 60-80 MB/s download speeds from Steam through stock firmware and significantly less with both ddwrt and openwrt (Never gotten anything above 25 if I recall correctly).

After googling a little bit more about it, it seems to most likely be due to the stock firmware using something called fastnat instead of iptables. Both of them are open source, but fastnat lacks a lot of features that iptables has (that the stock firmware doesn't need). Seems like Tomato has experimented with it with some time ago and achieved an increase in routing speed, but they decided it wasn't worth it because of the lost features (It's unclear to me exactly what those features are though).

But I guess using fastnat on openwrt would require me to change some things in the source, not just downloading a package, which I do not have enough knowledge about.

hi all,

just installed the latest, trunk-r39043-2013-12-13
I seem to have problems with the dhcp server in which it doesn't hand out ip's to my guest network

The only range available is the main network range.
Sun Dec 15 01:31:12 2013 daemon.info dnsmasq-dhcp[1414]: DHCP, IP range 192.168.1.200 -- 192.168.1.254, lease time 12h

Before the upgrade, I had this:
Mar 26 20:02:33 OpenWrt daemon.info dnsmasq-dhcp[1841]: DHCP, IP range 192.168.3.100 -- 192.168.3.249, lease time 12h
Mar 26 20:02:33 OpenWrt daemon.info dnsmasq-dhcp[1841]: DHCP, IP range 192.168.1.100 -- 192.168.1.249, lease time 12h

Nothing I've done can make this work???

Any Ideas???
The UCI stuff is unchanged, so I'm not sure how to hack the extra subnet on to the dhcp server.

Are there any warnings, messages from dnsmasq? You could grep the dnsmasq messages from syslog
I am thinking that you might be running into the effects of recent changes in wifi-netifd integration. example here: https://dev.openwrt.org/ticket/14613

My build has the standard wifi and dnsmasq components, so there should be nothing build-specific.

nope no warnings from dnsmasq.

Its more that UCI isn't generating the correct config.

The dnsmasq config file within /var/etc/

On Build r36246 has:
dhcp-range=lan,192.168.1.100,192.168.1.249,255.255.255.0,12h
no-dhcp-interface=pppoe-wan
dhcp-range=guest,192.168.3.100,192.168.3.249,255.255.255.0,12h

On the latest build r39043 only contains:
dhcp-range=lan,192.168.1.100,192.168.1.249,255.255.255.0,12h

and no line for the 192.168.3.x

Might be fixed with r39050  / see bug 14590: https://dev.openwrt.org/ticket/14590
Currently compiling it...

The has not been dnsmasq changes since early November, so it might be either something in netifd or wifi integration.
What is the last revision that worked ok?

If it is not fixed, you might file a bug about it.

(Last edited by hnyman on 14 Dec 2013, 16:13)

@hnyman

After a while I updated again to your latest r38999 build and I don't know if you or anybody else noticed or there's a ticket about it, but all of the ESSIDs are visible, even if it's checked to hide it.

(Last edited by ferob on 7 Dec 2013, 22:16)

I'm not sure what was the last revision that it still worked.

will try when i have time.

but i have just moved to Attitude Adjustment r38899.
And its working fine.

last few builds have a strange behavior  that's driving me insane.

sometimes the "wifi down" command (either issued by cron, wifi button or ssh) fails to delete the wlan0 interface inside the folder /var/run/hostapd/

this means that the next time i press the wifi button the BTN_2 script finds the folder "hostapd" inside /var/run/ (even if the wifi is actually off!!) and it issues a "wifi down" command which obviously fails to bring up the wifi.

this mean i'm unable to toggle the wifi back on with the button but i have to run the command "wifi up" from ssh since luci fails to bring up the wireless too.

manually deleting "/var/run/hostapd" when the wifi is off also makes the wifi button work again, obviously until the next time the bug pops up.

right now i'm on 39043 on my 3700v2

anyone else?

(Last edited by Manp on 15 Dec 2013, 03:14)

I changed the button logic a few builds ago, when I noticed that the previous one did not work. The logic is based on detecting /var/run/hostapd/ , but apparently the behaviour of that directory is not that uniform as I assumed it to be.

Will have to find another logic for it. :-(

EDIT:
I tested the behaviour at two routers. Both 3700v1 and v2 removed the directory 100% right when I toggled wifi either by wifi up/down command or the button. I didn't test cron. However, there was a small lag sometimes. E.g. "wifi down ; ls -l /var/run/hostapd* " would show the directory still there, but after a second the next  ls -l /var/run/hostapd* shows it gone.

Is there anything special regarding your wlan0 ?

(Last edited by hnyman on 15 Dec 2013, 09:34)

in my case it's a pretty weird behavior since i can issue dozens of wifi up and wifi down commands via ssh in the spawn of a couple of minutes and the hostapd directory always get deleted.
it's not even lag in deleting the directory since i have a cron job turning off the wifi at a specific time of the day and sometimes turning on the wifi with the button fails because the hostapd directory is still there, but the cron job ran hours before.

i have not found a way to reliably duplicate this behavior and that's what's driving me insane.

the only special thing about my wlan0 is that i have more than one SSID running on the radio0 so when wifi is on i have:

wlan0
wlan0-1
wlan0-2
wlan1

inside the hostapd directory.
when the "bug" occurs all get deleted but not wlan0.

i've had this setup for more than a year now and it always worked but of course since you only recently changed the way the button script works i have no idea if the hostapd directory not being removed is a new occurrence or if it always happened but i never noticed since the button script worked differently!

i have to say that since yesterday i tried removing wlan0-2 and updating to 39050 and the problem remain.

btw thanks for the answer!

EDIT: tried turning off and on the wifi with the button 3 times, and on my third try:

root@OpenWrt:~# ls -l /var/run/hostapd*
-rw-r--r--    1 root     root           832 Dec 15 15:32 /var/run/hostapd-phy0.conf
-rw-r--r--    1 root     root           644 Dec 15 15:32 /var/run/hostapd-phy1.conf

/var/run/hostapd:
srwxrwx---    1 root     root             0 Dec 15 15:32 wlan0

grrrr

(Last edited by Manp on 15 Dec 2013, 15:33)

The change in the script was minor. The script was changed to check /var/run/hostapd instead of /var/run/hostapd-phy0 and -phy1, as apparently the directory structure has changed a while ago. But that same error should probably have surfaced to you also earlier.

Having multiple SSIDs might explain part of that.
I tried to reproduce your error with r39056 by having 3 SSIDs on radio0, but I couldn't. However, I noticed that taking down radio0 might take 5 seconds after the command was given. So, having multiple SSIDs has a clear impact on the up/down process.

There have laterly been changes in wifi-netifd interaction and I guess this might be related to that.

EDIT:
The changes were made on Dec 2-3:
http://nbd.name/gitweb.cgi?p=openwrt.gi … 845838f986
http://nbd.name/gitweb.cgi?p=openwrt.gi … fce88a0c4e

(Last edited by hnyman on 15 Dec 2013, 16:02)

ok, that's way over my head..

what do you think about a script like this:

#!/bin/sh 
if [ "$BUTTON" = "BTN_2" ] && [ "$ACTION" = "pressed" ]; then
     if (ps | grep -v grep | grep /var/run/wifi-phy > /dev/null) then
        logger "WiFi button used: WiFi down"
        wifi down
    else
        logger "WiFi button used: WiFi up"
        wifi up
    fi
fi

for the wifi button?

i think in my case it could get the job done? it seems to work...

(Last edited by Manp on 15 Dec 2013, 16:30)

You might test this BTN_2 script:

#!/bin/sh
if [ "$BUTTON" = "BTN_2" ] && [ "$ACTION" = "pressed" ]; then
    if [ $(wifi status | grep -c up...true) -gt 0 ]; then
        logger "WiFi button used: WiFi down"
        /sbin/wifi down
    else
        logger "WiFi button used: WiFi up"
        /sbin/wifi up
    fi
fi

I changed the code to check the condition of the radios via 'wifi status'.

change is only on one line:

-    if [ -d /var/run/hostapd ]; then
+    if [ $(wifi status | grep -c up...true) -gt 0 ]; then

(Last edited by hnyman on 15 Dec 2013, 16:30)

thanks man! seems to work fine and it's certainly better than mine.

i'll run it for a bit and see...

even the oldest build on your dropbox has the same bug.
trunk-r38900-2013-11-24

Attitude Adjustment doesn't seem to be affected however I'm getting alot of 'deauthenticated due to inactivity (timer DEAUTH/REMOVE)' on Attitude Adjustment. Every minute or so. which is really strange.

I will raise a ticket soon.

In have uploaded a few even older builds to "old trunk builds" subdir. Direct link: https://db.tt/T2ukSm4g

You might check a build from August & October to see where the error surfaces.

(Last edited by hnyman on 17 Dec 2013, 13:59)

The bug happens if dnsmasq init cannot resolve the "ifname" state variable in /var/state/network. A common cause is using a persistent /var which causes uci state to not get properly cleared on reboots.

Dnsmasq is one of the last users of these variables so broken uci state vars do not affect much else.

I have uploaded r39101 with dnsmasq fixes made by jow.