Closed Chadster766 closed 10 years ago
@Chadster766 Ok, so what was your actual goal when you started here? It seems there are at least a couple pieces wrapped up, namely:
Might not be a bad idea to break these two apart and diagnose any issues with them separately
I made a mistake attempting point (1) and that idea should be discarded at this point IMO.
I found the missing clue. All it is dnsmasq not starting at boot. When started from the command prompt it solves the DHCP issue.
Now I just have to hunt down the one liner that's not running in the init scripts.
awesome!
Just to let you know: I avoided messing with procd and such by reading through the new scripts in the trunk version of the package, and only pulling them in if I was reasonably certain using the old scripts wouldn't somehow affect the functionality of the underlying daemon. So for netifd, I used the old init script but pulled the dhcp scripts.
Thanks for the FYI.
Can you tell me how to do a pull requests for this branch? I have been pushing to the master branch and merging between my local branches but have never done a pull request so others can review my code changes and additions.
That's a good question. I've only done pull requests within the context of merging changes from a forked repo back into a "main" repo. So I don't know. I think for our purposes, if you just want to push to the branch that'd be fine. "git push origin release-candidate" should do it.
I made the commit to this branch.
Two issue with the commit:
Its as though /etc/init.d/rcS isn't running the /etc/init.d/rc.d links. I'm wondering if we have a combination of the old boot process and the procd boot running at the same time :confounded:
It would be nice to get a fresh outlook on these two issues.
I'll flash it tomorrow. I'll probably append set -eufvx to the top of all the scripts, reboot and see if I can catch the failure on serial.
see "Argument List Processing" for a description of those parameters: http://linux.die.net/man/1/dash
Saved me some time when I was refactoring wan_monitor: https://sipb.mit.edu/doc/safe-shell/
and this too, even though OpenWRT shell scripts don't adhere to these guidelines: http://google-styleguide.googlecode.com/svn/trunk/shell.xml
building the image now. Will start testing when I get home.
starting a sysupgrade with your image
Looks like I need to do a full flash. Everything came up without a problem via sysupgrade.
This is the content of my sysupgrade file.
root@cerenkov:~# cat /etc/sysupgrade.conf
## This file contains files and directories that should
## be preserved during an upgrade.
# /etc/example.conf
# /etc/openvpn/
/etc/config
/etc/shadow
/etc/unbound
edit: that wasn't entirely true. any symlink between /etc/init.d scripts and /etc/rc.d got blown away since I didn't have those directories listed in my sysupgrade.conf.
Also please load via TFTP with command "run update_both_images" to be absolutely sure you are testing the new firmware.
Did you find any clues? I will be doing IPv6 testing with the backports branch this morning.
On my first boot I thought I saw some kind of backtrace. I wasn't fast enough to record it. I couldn't get it to appear on subsequent boots. dnsmasq is running on boot for me, no DHCP issues.
Weird 6relayd doesn't seem to want to start for me.
6relayd was a configuration error on my part. It looks like the shell scripts won't say much when you are missing configuration parameters.
Thanks for the update.
I'm still doing the netifd-backport IPv6 connection QA. I am having some issues with it. Just to be sure I'm double checking my IPv6 testing setup.
I'm going to rebuild an image from the release-candidate branch and re-flash. I'm not certain I didn't accidently use the wrong .config.
Stepping out for a bit. Should be back and working on this in about 2 hours.
Have fun :smile:
I'm having a hard time reproducing issues 1 & 2 mentioned earlier. Also, I was unable to reproduce the backtrace I thought I saw. It may have never occurred.
What should I be looking for in terms of LuCI functionality? Do I need to confirm anything?
Also, madwifi should not be a required package. I don't know about mac80211 though, that sounds a lot like a kernel wireless API. I normally remove wifidog, freeradius, and postgres. IIRC removing freeradius drops the need for mysql, cyrus-sasl, and openldap libs. The default .config has some very strange defaults.
edit: I originally said I remove madwifi, instead of wifidog. They are very different things, removing madwifi may break your build!
When I was testing IPv6 DHCP-PD on the netifd-backport branch I installed the WIDE-DHCPv6 packages. This creates what looks like duplicate services.
root@OpenWrt:/# ps | grep dhcp
1331 root 632 S odhcp6c -s /lib/netifd/dhcpv6.script -Ntry -P0 eth1
5509 root 1316 S {dhcp6c} /bin/sh /etc/rc.common /etc/init.d/dhcp6c s
5640 root 896 S /usr/sbin/dhcp6c -c /var/etc/dhcp6c.conf eth1
Interesting. I should see the same on the release-candidate branch, no?
Yes it should be the same.
And that's only after installing WIDE-DHCPv6?
I can turn off 6relayd, and install WIDE-DHCPv6 if you want.
This is running 6relayd, no odhcpd, no WIDE:
root@OpenWrt:~# ps | grep dh | grep -v grep
root@OpenWrt:~#
I'm sorry, I remove wifidog, not madwifi! That's another kernel API.
Please hold off on this branch for a while.
We need to verify that the netifd-backport branch plays nice with the native IPv6 WIDE-DHCPv6 packages. The Linksys stock code tests out fine in my IPv6 test lab and our OpenWRT needs to do the same.
Documentation on DHCP-PD implementation for OpenWRT is pretty sketch.
Do you have some way of testing native IPv6 DHCP-PD as I do? I use HE but I've also used Mikrotik RouterOS for the job.
The wrt is my only hardware between me and my centurylink ADSL modem. I should get more hardware. I imagine setting up an HE tunnel would not do the trick?
I don't think 6relayd can do DHCP-PD. It would be great if it does but I haven't see it work.
Also the router has to use a DUID in the IPv6 DHCP prefix request.
For 12.09.1 the documentation for lan side IPv6 is misleading, at best.
You can run Mikrotik RouterOS on any old computer for IPv6 testing.
Ok. I should be able to nuke my build machine and set things up to do so. It will take some time to do so. Is there any network hardware you can recommend to expedite future testing (e.g. what I assume is a cisco 1811)? Really hoping Mikrotik has a live distro...
If you do try RouterOS be careful because if you load it through the netinstall it wipes the hard drive it goes onto.
Thanks for the heads up!
That sounds like a lot of work. By the time you are finished I will probably have it figured out :smiley: I have a old Cisco 1811 Enterprise router that has just enough memory to run the Cisco firmware for IPv6 which makes it much easier for me. RouterOS was a pain because it was on my dev machine and I had to clone back and forth to do some IPv6 testing. That sucked!
I recommend you leave it with me for a little while.
Ok then. Good luck!
Let me know if there's something I can do to help you out. I'm going to take some time today to look at https://github.com/Chadster766/McWRT/issues/20.
That would be great! I recommend looking at it using a branch off the master.
Will do.
@Chadster766 re: DHCP-PD support, I can confirm that the build from the netifd-backport branch which now matches release-candidate does have working DHCP-PD support as I'm getting a /64 delegated from my provider and it's working internally with those delegated addresses.
I don't know about the wide-dhcpv6 package, can you clarify the difference between that and what we've got today?
EDIT: Ok, after reviewing I now see that release-candidate and netifd-backport are not in sync... note here too, It would be good if all Commits could have a meaningful description, as it would help immensely in figuring out what exactly has changed.
Also, sorry I've been out of pocket all weekend, should be back in the saddle somewhat now, still working on getting the rest of my environment set back up
@OperatorOverload that would be great. What is your DHCP-PD configuration? Are you sending a DUID to the ISP?
The more detail you can supply on the /etc/config's would really help me and others out with IPv6 setup :smile:
Working on getting the stuff together, but the key configuration items to change out of the box under your public (provider) side interface -> DHCP Server -> IPv6 Tab:
Router Advertisement Service: Server mode DHCPv6 Service: Server mode DHCPv6 Mode: Stateless + Stateful
/etc/config/dhcp:
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '30m'
option ra 'server'
option dhcpv6 'server'
option ra_management '1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
/etc/config/network:
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config interface 'lan'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option _orig_ifname 'eth0 wdev0ap0 wdev1ap0'
option _orig_bridge 'true'
option ipaddr '192.168.1.1'
option ifname 'eth0 wdev0ap0 wdev1ap0'
config interface 'wan'
option proto 'dhcp'
option ifname 'eth1'
option ipv6 '1'
config globals 'globals'
option ula_prefix 'fdfb:7c18:1155::/48'
config interface 'wan6'
option proto 'dhcpv6'
option ifname '@wan'
/etc/config/6relayd
config server default
option master wan6
list network lan
option rd server
option dhcpv6 server
option fallback_relay 'rd dhcpv6 ndp'
option management_level 1
option compat_ula 1
And not sure on the DUID point.. is there a way for me to figure that out without TCPDump-ing that interface?
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.