[WLANware] Bug with S05nvram and WL-HDD

[Dan Flett]

Hi all,

I've been having problems with using the Freifunk-Kit with the WL-HDD.  If I 
create a TRX image with the kit and load it into a WL-HDD all the network 
interfaces become unreachable.  I can tell that everything is working 
internally because the wlan SSID is what I set it to with the kit, and if I 
use the firmware recovery tool and load WhiteRussian RC5, I can see that the 
Kit set it's nvram variables correctly.

It took a while, but I've narrowed the problem down to the S05nvram init.d 
script that runs at firstboot only.

The version of S05nvram that FF uses seems to be based on an old 
WhiteRussian version.  It uses the nvram var "productid" to distinguish 
between various Asus models.  The problem is, "productid" does not survive 
an "mtd erase nvram" - so if you erase your nvram and use the bootloader 
defaults, S05nvram does not correctly set the "lan_ifnames" variable.  This 
isn't usually a big problem with most firmwares WL-HDD, including a 
plain-vanilla Freifunk Firmware.

But when you use the FF-Kit, you set "wifi_ifname" and I believe the routine 
in S14ffnvram for some reason does not correct this.  I don't know why - it 
should remove the wlan interface from "lan_ifnames" but it seems that it 
does not.  Another theory is that "lan_ifnames" is conflicting with 
"wan_ifname".

I've copied the latest S05nvram script from the WhiteRussian SVN:
https://dev.openwrt.org/browser/branches/whiterussian/openwrt/package/base-files/default/etc/init.d/S05nvram
Putting this script into root.tgz in the appropriate place seems to fix the 
problem on the WL-HDD.  The new version uses the nvram variable "et1phyaddr" 
to identify the WL-HDD and this variable is re-created after an erased nvram 
by the bootloader.

I haven't tested on other routers yet, but I don't see why the new S05nvram 
should cause problems.

Cheers,

Dan