Trunk updates for uhttpd, luci-ssl, ustream-ssl

[Chadster766]

I think I broke DHCP in my local dev branch when I removed what I though was unneeded packages madwifi and mac80211. I was thinking they could be brought back in once development work started on those packages.

After making these changes. The start image fix wouldn't run at boot causing a read only overlay folder.

So I modified the below file to call the /etc/init.d/boot to call /etc/init.d/done to clean that up.

The package upgrades for uhttpd, luci-ssl and ustream-ssl themselves are actually fairly straight forward.

[Chadster766]

DUID is listed in the below page: http://wiki.openwrt.org/doc/uci/6relaydhttp://wiki.openwrt.org/doc/uci/6relayd

Thanks for the configs that will help me a lot.

What IPv6 address prefix are your clients systems getting? Please post on of your client computer's ipconfig.

[OperatorOverload]

Ok, my understanding is that DUID is auto-generated for DHCPv6 (shouldn't have to be specified, though I believe you can specify if desired), and none of my configs seem to have one set. As to whether my router is sending a DUID to my provider to get it's DHCP address, wouldn't know without doing some sniffing on that interface.

My clients are getting routable public IPv6 addresses in the /64 block that my provider gives me (starts with 26xx:...)

[Chadster766]

Excellent thanks

[OperatorOverload]

@Chadster766 Ok, on Wide-DHCPv6, I believe that's a now-deprecated package, as far as I can see it hasn't had any updates to source since 2008. OpenWRT is now using DNSMasq I believe for core DNS and DHCP services (including IPv6), so compatibility with the wide packages isn't needed.. let me know if you think I've missed something here. Looks like our version of DNSMasq dates back about 18 months, if anything, that might be worth trying to update.

I'm not clear on the distinction between DNSMasq-DHCPv6 functionality and odhcp6c, as it seems they would overlap and be redundant.. need to do some more digging on the distinction and relationship there.

[Chadster766]

@OperatorOverload thanks for clarifying that Wide-DHCPv6 is depreciated.

[mmilburn]

My understanding is that dnsmasq has DHCPv6 support, but Openwrt uses its own packages. It looks like for 12.09.1, Openwrt uses 6relayd (radvd was deprecated in favor of 6relayd, I think). 6relayd was deprecated in favor of odhcpd in June, which apparently did not affect 12.09.1 (I didn't see a backport of odhcpd). So while odhcpd is the future, I got the impression we should be able to do everything we need with 6relayd.

Does that sound right?

[Chadster766]

Yes I believe you are right. Can I just update the odhcpd package and set the init script to not use procd?

[mmilburn]

Good question.
I guess I would remove procd calls entirely and do something like

SERVICE_DAEMONIZE=1
SERVICE_WRITE_PID=1
...
start() {
...
service_start /path/to/ohdcpd
...
}

6relayd just isn't playing nice with DUIDs?

[Chadster766]

I haven't been able to get assign a IPv6 prefix to the router DUID yet. I not sure what the issue is but the Linksys stock firmware send the DUID and I can assign a IPv6 prefix to it which get assigned to the router's client computers.

To disable procd use in packages I think its and easy as setting "USE_PROCD=0" in the init script.

[mmilburn]

Yeah, my concern with just flipping USEPROCD is that there are still calls to procd* helper functions. So I think you'd have to pull in procd anyway just to get the shell helper functions.

[mmilburn]

Which is why I was going down the path of rewriting the init script completely, and avoiding pulling in another package.

[Chadster766]

I just complete a build that I'm going to push to this branch for testing but I'm going to do a little QA first.

[mmilburn]

Here's a quick guess:

#!/bin/sh /etc/rc.common
START=35
STOP=85

SERVICE_DAEMONIZE=1
SERVICE_WRITE_PID=1

start() {
    stop
    service_start /usr/sbin/odhcpd
}

restart() {
    start
}

shutdown() {
    stop
}

stop() {
    service_stop /usr/sbin/odhcpd
}

reload() {
    ubus call dhcp reload
}

[OperatorOverload]

Ok, I think we have a bigger issue currently though which is the fact that our existing image (1.0.4 Prerelease) is known to break when IPv6 and port forwarding is used simultaneously. Thoughts on pushing an image (1.0.4b, or 1.0.5?) that fixes that issue based only on the netifd-backport changes? Then we can work towards further changes.

If we think the issues in the netifd-backport branch are as bad as silent failure of all firewall rules (and thus traffic forwarding/internet access) then that's not a good course of action, but as far as I can tell the only such issue is a potential issue with prefix delegation that I haven't actually seen on my connection where I am using IPv6 live. If that issue does exist, it doesn't seem as bad as losing all internet connectivity. I just think we keep getting into a "one more package", when I'm afraid what we need is frequent releases to keep interest in what's going on here to outside parties.

Thoughts?

[mmilburn]

If we merge netifd-backport, I'd keep the IPv6 ticket open. It sounds like @Chadster766 is the only one able to do exhaustive QA on different IPv6 setups. Until we can either help him out with the QA burden, or he is able to work through it, I wouldn't want to call it finished.

[Chadster766]

I'm going through these IPv6 upgrades with a fine tooth comb :smiley: but it will take time.

Both of you are doing great. Let's not rush this.

The next big development project to tackle is the switch driver. Belkin has done a lot of work on it as @mmilburn has shown.

[mmilburn]

I'm personally OK with merging it, but it's up to @Chadster766. I figured once we got through this release we'd sync up and get an idea of what we should do next. At which point I was planning on pushing drivers heavily since I believe that's our main barrier-to-entry into mainline OpenWRT support.

I've started digging into the switch driver, and my initial impressions are encouraging. I also might have an ace up my sleeve (still gotta test).

https://github.com/mmilburn/linux/commit/1878a702874d640af1e9d7f8c02a6cff47d16365

[Chadster766]

Don't forget we need someone to follow up on jow's suggestion for the wireless driver. https://forum.openwrt.org/viewtopic.php?pid=247986#p247986

[mmilburn]

Ahh, but if we put our changes into mwl8k, I don't think we'll need that. Since mwl8k already uses the standard kernel wireless API, we won't need anything special at that point. I think jow was operating under the assumption that we would never move away from our current wireless driver.

[Chadster766]

It would be great to have another driver option.

[mmilburn]

Just confirming. We definitely won't need that if we put 88W8864 support in the mwl8k driver. Jow was talking about making changes to libiwinfo. According to the page listed below, libiwinfo supports nl80211. nl80211 is part of the kernel's wireless subsystem. mwl8k is a wireless driver in the kernel, any wireless driver in the kernel must use the kernel's wireless subsystem. No more blacklisting interfaces, no more broken LuCI pages. http://wiki.openwrt.org/doc/devel/packages/libiwinfo

[mmilburn]

@OperatorOverload any interest in doing some work on the wifi driver? I think if my mwl8k patch works it will at least get us a/b/g/n. If it won't already do ac, it probably just means reading some more code.

[OperatorOverload]

@mmilburn Happy to help to the extent I can contribute.. I'm no kernel expert, but I'll definitely do testing, smash bugs, and lend my help to rearchitect where I can

[mmilburn]

This got super long, but give it a shot if you want, or just figure out step 7 is going to work:

1. Install quilt
2. Read about creating and applying kernel patches in OpenWRT here: http://wiki.openwrt.org/doc/devel/patches
3. Read this, so you don't do what I did: https://stackoverflow.com/questions/4499130/quilt-patch-with-a-new-file
4. grab my mwl8k changes: https://raw.githubusercontent.com/mmilburn/linux/1878a702874d640af1e9d7f8c02a6cff47d16365/drivers/net/wireless/mwl8k.c
5. Extract the kernel we're using, create a patchset, and then add the driver.
6. Build an image using the new patch, build mwl8k as a module.
7. The mwl8k driver needs external firmware, not a big deal, we just have to figure out how to load it. https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=openwrt+%2Flib%2Ffirmware

[OperatorOverload]

I will work towards this, definitely got some learning to do. So on the external firmware piece, any proposal on where it will come from? I see firmware-libertas for the Marvell Libertas 8xxx wireless cards, are we thinking the 88W8864 is compatible with that?

[mmilburn]

88W8864 should be compatible with the 88W8764 in terms of firmware. Here's my evidence: mrvl_wlan_v7drv/wlan-v7/Makefile:

289 ifeq (W8864, $(SOC))
290 EXTRA_CFLAGS+= -DSOC_W8764 -DSOC_W8864

That's also defined in the mrvl_wlan_v7drv/wlan-v7/build/linux/Makefile. But they're the same file (checked with md5sum). So the preprocessor includes all code that has #ifdef SOC_W8864 as well as #ifdef SOC_W8764 when the driver is built.

mrvl_wlan_v7drv/wlan-v7/driver/linux/ap8xLnxFwdl.c

 35 #elif defined(SOC_W8764)
 36     #ifdef DEFAULT_MFG_MODE
 37         #include "88W8764-mfg.h"
 38     #else
 39             #include "88W8764.h"
 40     #endif

There is a copy of the 8764 firmware here under mwl8k: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git It's a little different from the firmware that came bundled with the mrvl_wlan_v7drv. Firmware from that is here: https://github.com/mmilburn/88W8764-firmware

[Chadster766]

Completed