**** BEGIN LOGGING AT Sun Apr 22 03:00:00 2012
Apr 22 07:51:49 <CIA-54> juhosg * r31433 /trunk/target/linux/amazon/ (config-2.6.30 config-2.6.32 patches-2.6.30/ patches-2.6.32/): amazon: remove 2.6.3{0,2} support
Apr 22 07:51:49 <CIA-54> juhosg * r31434 /trunk/target/linux/ep93xx/ (config-2.6.39 patches-2.6.39/): ep93xx: remove 2.6.39 support
Apr 22 08:39:04 <dwmw2_gone> jow_laptop, nbd, etc: If someone could look at my openconnect post to the mailing list, and give me a clue why the Legacy IP address gets *removed* from the interface after vpnc-script sets it up correctly, that would be much appreciated...
Apr 22 08:41:09 <blogic> dwmw2_gone: scripts or netifd ?
Apr 22 08:41:12 <dwmw2_gone> scripts
Apr 22 08:41:17 <blogic> hmmm
Apr 22 08:41:32 <blogic> first idea is the uci state being applied in hotplug somewhere
Apr 22 08:41:38 <dwmw2_gone> I can set up test accounts if you want to try it
Apr 22 08:41:51 <blogic> need to wrap up these pincrtl dts bindings today
Apr 22 08:42:06 <blogic> i can look tomorrow if it is not resolved by then
Apr 22 08:42:07 <dwmw2_gone> should I be setting uci state myself, rather than just configuring the interface?
Apr 22 08:42:10 <dwmw2_gone> ok, thanks.
Apr 22 08:42:13 <blogic> well
Apr 22 08:42:22 <blogic> ok, let me drink coffee and then have a look ;)
Apr 22 08:42:48 <dwmw2_gone> fine plan
Apr 22 08:42:58 <blogic> openconnect as in BT ?
Apr 22 08:43:03 * dwmw2_gone is on his first cup of tea of the morning, and the lines are only just becoming unblurred
Apr 22 08:43:10 <dwmw2_gone> no, Cisco AnyConnect VPN client.
Apr 22 08:43:13 <blogic> ahhh
Apr 22 08:43:24 <dwmw2_gone> ifup foo ; ifconfig vpn-foo
Apr 22 08:43:26 <dwmw2_gone> looks fine
Apr 22 08:43:29 <dwmw2_gone> wait a second, ifconfig vpn-foo
Apr 22 08:43:40 <dwmw2_gone> and the IPV6 still works but *something* removed the LEgacy IP address
Apr 22 08:44:15 <blogic> just read your mail
Apr 22 08:44:28 <dwmw2_gone> openconnect uses *exactly* the same vpnc-script that vpnc normally uses.
Apr 22 08:44:28 <blogic> the "almost immediatley afterwards" smells like hotplug
Apr 22 08:44:33 * blogic reads code brb
Apr 22 08:44:50 <dwmw2_gone> don't look too hard — there are many things to fix, but I wanted to fix this first :)
Apr 22 08:45:07 <dwmw2_gone> oh, while I tihnk of it: There's a bug in the ppp code I copied to use as a template
Apr 22 08:45:17 <blogic> dwmw2_gone: off topic ... do you know of a way to spell check code ?
Apr 22 08:45:48 <dwmw2_gone> it resolves the IP of the gateway, and then sets an explicit route to the gateway, through the same router as the existing default route.
Apr 22 08:45:50 <blogic> i reworked my patch release script last night and i want to add a step that checks source code comments ...
Apr 22 08:45:56 <blogic> ?
Apr 22 08:46:01 <blogic> that sounds wrong
Apr 22 08:46:13 <dwmw2_gone> but that's wrong. the VPN gateway (I think it's for pptp in this case) is not necessarily on the default route. Some users have it on the local network.
Apr 22 08:46:27 <dwmw2_gone> vpnc-script gets it right if /sbin/ip is installed, by using 'ip route get $VPNGATEWAY'
Apr 22 08:46:56 <dwmw2_gone> vpnc-script has the same bug as openwrt's ppp script, if it's using 'ifconfig'.
Apr 22 08:47:16 <dwmw2_gone> but hopefully netifd will get this right.
Apr 22 08:51:07 <dwmw2_gone> blogic: hm, what bits do you want to spell-check? Comments, variable names, function names?
Apr 22 08:51:19 <dwmw2_gone> comments should be relatively simple to identify and spell-check.
Apr 22 08:51:43 <dwmw2_gone> if you want to do more, you'd probably need to be able to *parse* the code.
Apr 22 08:52:43 <blogic> just comments
Apr 22 08:52:53 <blogic> i know i can just look for comments etc and hack a script
Apr 22 08:53:01 <blogic> just wanted to know if you knew of a working solution
Apr 22 08:53:17 <dwmw2_gone> I haven't ever heard of one
Apr 22 08:53:31 <blogic> oki
Apr 22 08:54:01 <blogic> so, you could try to install ip and use that
Apr 22 08:54:16 <blogic> see if it fixes the problem
Apr 22 08:56:55 <dwmw2_gone> blogic: the default route thing? I'll deal with that later. I know there are openwrt users who care (some university in .de makes people use VPN over the wireless, because they haven't heard of wpa)
Apr 22 08:57:17 <dwmw2_gone> so the vpn server is on the local (wireless) network, *not* accessible via the default route.
Apr 22 08:57:26 <dwmw2_gone> but my real problem at the moment is the fact  taht the IP address gets removed.
Apr 22 08:57:46 <dwmw2_gone> I'll add 'ifconfig | logger' to all the 'iface' hotplug scripts :)
Apr 22 08:57:52 <dwmw2_gone> narrow down the culprit a bit
Apr 22 08:58:53 <blogic> dwmw2_gone: yes
Apr 22 08:59:06 <blogic> imho some hotplug script foobars
Apr 22 08:59:13 <blogic> i would start to look there
Apr 22 09:13:02 <dwmw2_gone> hm, I don't think the hotplug scripts run
Apr 22 09:13:19 <dwmw2_gone> they don't on ppp interfaces either; /etc/ppp/ifup runs them manually
Apr 22 09:13:55 <dwmw2_gone> and running them manually *doesn't* remove the LEgacy IP address, if I reinstate it and then run them again
Apr 22 09:15:04 <dwmw2_gone> root@geos:/etc/hotplug.d/iface# ifup foo ; env -i ACTION="ifup" INTERFACE="foo"
Apr 22 09:15:04 <dwmw2_gone> DEVICE="vpn-foo" PROTO=openconnect /sbin/hotplug-call "iface"
Apr 22 09:15:19 <dwmw2_gone> by the time 00-netstate script runs, the Legacy IP address is already gone.
Apr 22 09:15:53 <dwmw2_gone> hm, maybe it's "addif"
Apr 22 09:40:43 <CIA-54> claudio * r31435 /trunk/target/linux/at91/files/arch/arm/mach-at91/board-netus-foxboard.c: [at91] Remove old netus board definition
Apr 22 09:40:46 <CIA-54> claudio * r31436 /trunk/target/linux/at91/ (3 files in 3 dirs): [at91] tqma9263: update board definition for 3.x series and fix config choose
Apr 22 11:23:27 <jow_laptop> dwmw2_gone: creating an interface triggers a net subsystem event, which runs the network hotplug handletr which attempts to look up the configuration for the given device and apply it
Apr 22 11:23:42 <jow_laptop> dwmw2_gone: so as soon as your tun device is spawned it wil lget the settings applied from uci
Apr 22 11:24:25 <jow_laptop> dwmw2_gone: 6in4 etc. use a hack to prevent this: https://dev.openwrt.org/browser/trunk/package/6in4/files.old/6in4.sh#L62
Apr 22 11:34:40 <dwmw2_gone> ta
Apr 22 11:37:04 <dwmw2_gone> yay, that works. Thanks
Apr 22 12:03:50 <jow_laptop> one of the ugly details of the current script environment
Apr 22 12:07:31 <CIA-54> hauke * r31437 /trunk/package/mac80211/patches/060-compat_add_module_pci_driver.patch:
Apr 22 12:07:31 <CIA-54> mac80211: add module_pci_driver to compat
Apr 22 12:07:31 <CIA-54> Without module_pci_driver being defined the pci drivers do not get registered.
Apr 22 12:07:31 <CIA-54> Should fix #11332
Apr 22 12:08:14 <CIA-54> juhosg * r31438 /trunk/package/mac80211/patches/301-add-module_pci_driver-to-compat-3.4.patch:
Apr 22 12:08:14 <CIA-54> mac80211: add backport of the module_pci_driver macro
Apr 22 12:08:14 <CIA-54> That is required by various PCI drivers.
Apr 22 12:08:24 <jow_laptop> haha
Apr 22 12:10:41 <CIA-54> juhosg * r31439 /trunk/package/mac80211/patches/301-add-module_pci_driver-to-compat-3.4.patch:
Apr 22 12:10:41 <CIA-54> Revert "mac80211: add backport of the module_pci_driver macro"
Apr 22 12:10:41 <CIA-54> Erm, Hauke was faster.
Apr 22 12:11:08 <Hauke> ;-)
Apr 22 13:21:01 <dwmw2_gone> hm, mrtg really doesn't work well with openwrt's pppoa interfaces
Apr 22 13:21:10 <dwmw2_gone> when they go down/up the ifno changes and can't be found any more
Apr 22 13:21:21 <dwmw2_gone> even when mrtg is configured to do it by interface name. I think it caches the name
Apr 22 13:58:48 <builder_> build #0 of at91 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/0
Apr 22 13:59:22 <builder_> build #0 of brcm63xx is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/0
Apr 22 13:59:25 <builder_> build #0 of brcm47xx is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/0
Apr 22 13:59:31 <builder_> build #0 of s3c24xx is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/0
Apr 22 14:00:03 <builder_> build #0 of lantiq is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/0
Apr 22 14:03:04 <builder_> build #0 of rb532 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/0
Apr 22 14:03:04 <builder_> build #0 of avr32 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/0
Apr 22 14:03:10 <builder_> build #0 of ppc44x is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/0
Apr 22 14:03:11 <builder_> build #0 of uml is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/0
Apr 22 14:03:16 <builder_> build #0 of ppc40x is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/0
Apr 22 14:03:20 <builder_> build #0 of pxcab is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/pxcab/builds/0
Apr 22 14:03:29 <builder_> build #0 of sibyte is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/0
Apr 22 14:04:27 <builder_> build #0 of ramips is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/0
Apr 22 14:05:34 <builder_> build #0 of ixp4xx is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/0
Apr 22 14:05:38 <builder_> build #0 of ar71xx is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/0
Apr 22 14:06:44 <builder_> build #0 of iop32x is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/0
Apr 22 14:07:52 <builder_> build #0 of kirkwood is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/0
Apr 22 14:08:29 <builder_> build #0 of etrax is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/etrax/builds/0
Apr 22 14:09:09 <builder_> build #0 of gemini is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/0
Apr 22 14:09:09 <builder_> build #0 of x86 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/0
Apr 22 14:09:14 <builder_> build #0 of rdc is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/rdc/builds/0
Apr 22 14:09:32 <builder_> build #0 of xburst is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/0
Apr 22 14:09:56 <builder_> build #0 of au1000 is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/0
Apr 22 14:10:08 <builder_> build #0 of ep93xx is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/0
Apr 22 14:25:15 <builder_> build #0 of cobalt is complete: Failure [failed]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/0
Apr 22 15:20:42 <builder_> build #1 of s3c24xx is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/1
Apr 22 15:52:43 <builder_> build #1 of x86 is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/1
Apr 22 16:31:27 <swalker> updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/index.html
Apr 22 17:27:03 <CIA-54> claudio * r31440 /trunk/target/linux/at91/9260/config-default: [at91] flexibity: Cleanup the subtarget config
Apr 22 18:14:35 <dape> meh, openwrt wiki loads SO hard..
Apr 22 19:04:13 <dwmw2_gone> what does the pptp support do, if the server disconnects?
Apr 22 19:04:34 <dwmw2_gone> does it automatically reconnect all the time that the interface is configured to be up? I don't see how.
Apr 22 19:04:44 * dwmw2_gone is working out what openconnect support should do
Apr 22 19:12:47 <jow_laptop> dwmw2_gone: it relies on pppd to do the reconnect
Apr 22 19:13:01 <dwmw2_gone> ah, I was looking for the 'persist' option but didn't see it.
Apr 22 19:13:36 <jow_laptop> that should be the implicit default
Apr 22 19:13:40 <dwmw2_gone> ok
Apr 22 19:36:31 <dwmw2_gone> hmmm
Apr 22 19:37:00 <dwmw2_gone> root@geos:/lib/functions# cat /var/run/openconnect-foo.pid
Apr 22 19:37:00 <dwmw2_gone> 30563
Apr 22 19:37:00 <dwmw2_gone> root@geos:/lib/functions# ps axf | grep run-openconnect
Apr 22 19:37:00 <dwmw2_gone> 30563 root      1384 S    {run-openconnect} /bin/sh /usr/bin/run-openconnect f
Apr 22 19:37:00 <dwmw2_gone> 30750 root      1256 S    grep run-openconnect
Apr 22 19:37:01 <dwmw2_gone> root@geos:/lib/functions# start-stop-daemon -K -s TERM -p /var/run/openconnect-f
Apr 22 19:37:03 <dwmw2_gone> oo.pid -x /usr/bin/run-openconnect
Apr 22 19:37:05 <dwmw2_gone> no /usr/bin/run-openconnect found; none killed
Apr 22 19:37:07 <dwmw2_gone> wtf?
Apr 22 19:42:06 * stappers would try oo.pid -x {run-openconnect}
Apr 22 19:42:41 <dwmw2_gone> no {run-openconnect} found; none killed
Apr 22 19:43:08 <dwmw2_gone> root@geos:/lib/functions# ls -l /proc/30563/exe
Apr 22 19:43:08 <dwmw2_gone> lrwxrwxrwx    1 root     root             0 Apr 22 20:42 /proc/30563/exe -> /bin/busybox
Apr 22 19:43:08 <dwmw2_gone> root@geos:/lib/functions# start-stop-daemon -K -s TERM -p /var/run/openconnect-f
Apr 22 19:43:08 <dwmw2_gone> oo.pid -x /bin/busybox
Apr 22 19:43:08 <dwmw2_gone> no /bin/busybox found; none killed
Apr 22 19:43:22 <dwmw2_gone> root@geos:/lib/functions# start-stop-daemon -K -s TERM -p /var/run/openconnect-f
Apr 22 19:43:23 <dwmw2_gone> oo.pid -x /bin/sh
Apr 22 19:43:23 <dwmw2_gone> stopped /bin/sh (pid 30563)
Apr 22 19:43:29 <dwmw2_gone> aha, at last. I thought I'd tried that earlier.
Apr 22 19:46:46 <stappers> scary,     to kill /bin/sh
Apr 22 19:46:51 <dwmw2_gone> yeah
Apr 22 19:47:10 <dwmw2_gone> I also then need to kill the /usr/sbin/openconnect that the run-openconnect script *may* have spawned.
Apr 22 19:47:32 <dwmw2_gone> the idea of run-openconnect is that it runs in a loop, spawning openconnect repeatedly each time it disconnects
Apr 22 19:50:42 <CIA-54> nbd * r31441 /trunk/target/linux/generic/files/drivers/net/phy/ar8216.c: ar8216: enable forwarding of multicast frames to the cpu port on ar8327 (thx, SeG)
Apr 22 20:21:23 <dwmw2_gone> oh I hate shell programming
Apr 22 21:03:54 <phaidros> wiki is back.
Apr 22 21:03:55 <phaidros> we had a harddrive failure
Apr 22 21:41:49 <dwmw2_gone> should /etc/resolv.conf be a symlink to /tmp/resolv.conf ?
Apr 22 21:42:01 <jow_laptop> yes
Apr 22 21:42:12 <jow_laptop> and you should not mess with it
Apr 22 21:42:24 <jow_laptop> if you want to register ns servers, put them in /tmp/resolv.conf.auto
Apr 22 21:42:24 <dwmw2_gone> yeah, I'm beating vpnc-script into shape for openwrt
Apr 22 21:42:36 <dwmw2_gone> the basics of starting and stopping the connection seem to be working fine now
Apr 22 21:42:49 <dwmw2_gone> put them in /etc/resolv.conf.auto... or use add_dns() ?
Apr 22 21:43:41 <jow_laptop> add_dns()
Apr 22 21:44:13 <dwmw2_gone> add_dns() works.
Apr 22 21:44:25 <dwmw2_gone> now, if this was really a VPN we might want to remove the old ones and use *only* the new one.
Apr 22 21:46:58 * danmackay make distcleans and starts again with my wanted packages list
Apr 22 21:47:57 <jow_laptop> dwmw2_gone: yes, probably. But that would go contrary to the expectations
Apr 22 21:48:26 <jow_laptop> we probably need more options for dns control
Apr 22 21:48:43 <jow_laptop> we already have "peerdns" which became universal with netifd
Apr 22 21:48:55 <jow_laptop> so we can probably introduce a "replacedns" bool as well
Apr 22 21:48:56 <danmackay> is there a command I can run that will set all kmods except for the ones I specificly set to include to just build the rest as packages
Apr 22 21:49:07 <danmackay> without doing it 1 by 1
Apr 22 21:49:30 <dwmw2_gone> jow_laptop: I'll leave it like this for now, and a theoretical future generic 'replacedns' will then do the right thing, hopefully.
Apr 22 21:49:55 <jow_laptop> danmackay: sed -i -e 's,# CONFIG_PACKAGE_kmod-\(.*\) is not set,CONFIG_PACKAGE_kmod-\1=m,' .config
Apr 22 21:50:03 <dwmw2_gone> next, addresses. I note that *something* puts the current addresses in to uci network state for ppp
Apr 22 21:50:25 <jow_laptop> dwmw2_gone: /etc/ppp/ip-up does it afair
Apr 22 21:50:41 <danmackay> hmm, thanks
Apr 22 21:50:46 <dwmw2_gone> ah, so it does.
Apr 22 21:50:54 <dwmw2_gone> I grepped for that and failed to find it, in /etc/ppp
Apr 22 21:51:00 * dwmw2_gone wonders what he *actually* grepped for
Apr 22 21:51:06 <dwmw2_gone> only does it for Legacy IP and not IPv6.
Apr 22 21:51:10 <dwmw2_gone> is there any reason to do it?
Apr 22 21:51:20 <dwmw2_gone> you still have to set the addresses manually with ifconfig/ip anyway, right?
Apr 22 21:51:23 <jow_laptop> uci_set_state network "$PPP_IPPARAM" ipaddr "$PPP_LOCAL"
Apr 22 21:52:08 <dwmw2_gone> but not in ipv6-up
Apr 22 21:52:13 <jow_laptop> the reason is that this stuff was implemented before there was any v6 support
Apr 22 21:52:24 <jow_laptop> when v6 was added it always has been an afterthought
Apr 22 21:53:27 <jow_laptop> the interaction of ip-up and ipv6-up is not well defined either
Apr 22 21:53:35 <jow_laptop> afair they both execute concurrently
Apr 22 21:53:45 <jow_laptop> and v6 only ppp links are completely broken atm
Apr 22 21:54:07 <dwmw2_gone> heh, because ip-up never gets called?
Apr 22 21:54:12 <jow_laptop> yes
Apr 22 21:54:29 <jow_laptop> if you do the common stuff from both you'll need locking and state tracking
Apr 22 21:54:35 <jow_laptop> and then it is a pita already again
Apr 22 21:54:40 <dwmw2_gone> broken in what way? Because the hotplug script doesn't get called?
Apr 22 21:54:45 <jow_laptop> yeah
Apr 22 21:54:55 <jow_laptop> firewall stuff isn't triggered for example
Apr 22 21:55:04 <jow_laptop> anything that relies on interface events isn't triggered
Apr 22 21:55:08 <jow_laptop> state vars aren't set
Apr 22 21:55:42 <dwmw2_gone> I could probably disable the Legacy IP addresses on one of my ADSL lines and see what actually happens when it's IPv6-only.
Apr 22 21:56:57 <dwmw2_gone> what is the 'proto1' bit in setup_interface() (in /lib/network/config.sh) for? I can't see anything else which uses it.
Apr 22 21:57:03 <jow_laptop> it will probably already work fine with netifd
Apr 22 21:57:28 <dwmw2_gone> is that just remains of something that used to work?
Apr 22 21:57:43 <jow_laptop> the proto1 is either a workaround for a namespace clash or a remainder of the old pptp implementation which used to configure the lower protocol in the same network declaration
Apr 22 21:57:53 <jow_laptop> in contrast to the current approach of defining it separately
Apr 22 21:57:54 <dwmw2_gone> yeah, the latter.
Apr 22 21:58:16 <dwmw2_gone> ok, I'll ignore it then.
Apr 22 22:07:40 <dwmw2_gone> is there any way I can put a status string into uci network state, then have it displayed in luci?
Apr 22 22:09:08 <jow_laptop> not without making the gui print it
Apr 22 22:09:14 <danmackay> goodbye kmod-ppp
Apr 22 22:09:29 <jow_laptop> but in principle I don't see why not
Apr 22 22:11:36 <dwmw2_gone> would be useful to have some half-decent error handling if the connection doesn't work, that's all.
Apr 22 22:11:47 <danmackay> hmm i bet my fstab i included along with a /files/mnt/usb wont auto mount
Apr 22 22:11:52 <dwmw2_gone> how do we handle ppp/pptp errors like login failure?
Apr 22 22:12:28 <jow_laptop> not at all. the gui will say its not connected and its left to the user to check his syslog
Apr 22 22:12:40 <jow_laptop> netifd has better error reporting
Apr 22 22:12:42 <dwmw2_gone> I'll match that for now, but it makes me sad :)
Apr 22 22:12:52 <dwmw2_gone> what's supposed to set connect_time ?
Apr 22 22:16:55 <dwmw2_gone> ah, I'm supposed to run the hotplug script :)
Apr 22 22:18:09 <dwmw2_gone> that's better
**** ENDING LOGGING AT Mon Apr 23 02:59:58 2012