**** BEGIN LOGGING AT Sat May 05 03:00:01 2012
May 05 07:20:17 <CIA-19> juhosg * r31586 /trunk/target/linux/generic/patches-2.6.32/100-netfilter_layer7_2.21.patch: linux/2.6.32: fix layer7 patch
May 05 11:26:25 <builder_> build #8 of uml is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/8
May 05 11:43:12 <CIA-19> juhosg * r31587 /trunk/target/linux/mpc83xx/patches-3.3/200-powerpc-add-rbppc-support.patch: mpc83xx: fix build warnings in RB333/600 dtb wrappers
May 05 11:43:14 <CIA-19> juhosg * r31588 /trunk/target/linux/mpc83xx/patches-3.3/200-powerpc-add-rbppc-support.patch: mpc83xx: fix MAC addresses on the RB333
May 05 11:43:17 <CIA-19> juhosg * r31589 /trunk/target/linux/mpc83xx/patches-3.3/200-powerpc-add-rbppc-support.patch: mpc83xx: cleanup rb333.dts
May 05 11:43:21 <CIA-19> juhosg * r31590 /trunk/target/linux/mpc83xx/ (7 files in 4 dirs): mpc83xx: populate network config from an uci-default script
May 05 11:43:22 <CIA-19> juhosg * r31591 /trunk/target/linux/mpc83xx/Makefile: mpc83xx: remove broken flag
May 05 11:43:24 <CIA-19> juhosg * r31592 /trunk/target/linux/rb532/ (4 files in 2 dirs): rb532: add 3.3 support
May 05 11:43:27 <CIA-19> juhosg * r31593 /trunk/target/linux/rb532/Makefile: rb532: switch to 3.3 and mark the target broken
May 05 11:43:30 <CIA-19> juhosg * r31594 /trunk/target/linux/rb532/ (config-2.6.32 patches-2.6.32/): rb532: remove 2.6.32 support
May 05 11:43:31 <CIA-19> juhosg * r31595 /trunk/target/linux/rdc/Makefile: rdc: switch to 3.3 and mark the target as broken
May 05 11:43:33 <CIA-19> juhosg * r31596 /trunk/target/linux/rdc/ (config-2.6.32 patches-2.6.32/): rdc: remove 2.6.32 support
May 05 11:43:37 <CIA-19> juhosg * r31597 /trunk/target/linux/generic/ (config-2.6.32 patches-2.6.32/): linux/2.6.32: R.I.P.
May 05 11:53:47 <stintel> targeting 3.3 kernel for a new stable branch ? :)
May 05 11:56:57 <jow_laptop> yes
May 05 12:04:31 <stintel> cool
May 05 12:06:08 <KanjiMonster> hrm, that means we just got two new brcm47xx builders ;p
May 05 12:08:46 <stintel> ah right, this means this patch could go in (it needs 3.3 kernel): http://stewie.be.tintel.eu/0001-Add-openvswitch.patch
May 05 12:08:52 <stintel> but I need to work on it some more
May 05 12:13:05 <stintel> let's see if I can get it to work now with netifd
May 05 12:48:36 <CIA-19> juhosg * r31598 /trunk/include/kernel-defaults.mk: (log message trimmed)
May 05 12:48:36 <CIA-19> include/kernel-defaults: set V='' if c is not set in OPENWRT_VERBOSE
May 05 12:48:36 <CIA-19> This fixes the following errors:
May 05 12:48:36 <CIA-19> CALL arch/powerpc/kernel/prom_init_check.sh
May 05 12:48:36 <CIA-19> arch/powerpc/kernel/prom_init_check.sh: line 39: [: ss: integer expression expected
May 05 12:48:37 <CIA-19> arch/powerpc/kernel/prom_init_check.sh: line 39: [: ss: integer expression expected
May 05 12:48:38 <CIA-19> arch/powerpc/kernel/prom_init_check.sh: line 39: [: ss: integer axpression expected
May 05 12:53:38 <CIA-19> hauke * r31599 /trunk/target/linux/brcm47xx/Makefile: brcm47xx: update target to kernel 3.3
May 05 13:06:34 <CIA-19> nbd * r31600 /trunk/package/pptp/Makefile: pptp: compile with the openwrt cflags instead of -O0
May 05 13:56:31 <CIA-19> juhosg * r31601 /trunk/target/linux/ar71xx/patches-3.3/605-MIPS-ath79-db120-fixes.patch:
May 05 13:56:31 <CIA-19> ar71xx: fix a typo in the db120 mach file
May 05 13:56:31 <CIA-19> Reported-by: Sven Eckelmann <sven@narfation.org>
May 05 13:56:39 <CIA-19> juhosg * r31602 /trunk/target/linux/ar71xx/patches-3.3/ (100 files): ar71xx: update 3.3 patches
May 05 16:47:23 <builder> build #12 of s3c24xx is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/12
May 05 16:56:22 <CIA-19> nbd * r31603 /trunk/package/netifd/Makefile: netifd: update to latest version, adds support for host route dependencies
May 05 16:56:25 <CIA-19> nbd * r31604 /trunk/package/pptp/files/options.pptp: pptp: remove the defaultroute option from options.pptp, this is managed by generic ppp code
May 05 16:56:30 <CIA-19> nbd * r31605 /trunk/package/pptp/ (Makefile files/pptp.sh files.old/ files.old/pptp.sh): pptp: add netifd support
May 05 16:56:43 <CIA-19> nbd * r31606 /trunk/package/pptp/patches/ (. 100-signal_cleanup.patch): pptp: kill the call manager process on shutdown
May 05 17:02:15 <CIA-19> swalker * r31607 /packages/libs/postgresql/Makefile: [packages] postgresql: add missing libpthread depends
May 05 17:02:36 <CIA-19> juhosg * r31608 /trunk/target/linux/ar71xx/ (8 files in 7 dirs):
May 05 17:02:37 <CIA-19> ar71xx: add support for the TP-Link TL-WR1041N v2 board
May 05 17:02:37 <CIA-19> Patch-by: Vince Huang <axishero@foxmail.com>
May 05 17:02:39 <CIA-19> juhosg * r31609 /trunk/tools/firmware-utils/src/mktplinkfw.c:
May 05 17:02:39 <CIA-19> firmware-utils/mktplinkfw: add support for the TL-WR1041N v2
May 05 17:02:39 <CIA-19> Patch-by: Vince Huang <axishero@foxmail.com>
May 05 17:02:42 <CIA-19> juhosg * r31610 /trunk/target/linux/ar71xx/ (generic/profiles/tp-link.mk image/Makefile):
May 05 17:02:42 <CIA-19> ar71xx: add profile and build image for the TL-WR1041N v2 board
May 05 17:02:42 <CIA-19> Patch-by: Vince Huang <axishero@foxmail.com>
May 05 17:04:57 <CIA-19> swalker * r31611 /packages/admin/pmacct/ (Makefile patches/): [packages] pmacct: update to 0.14.0 (#11364, thanks deus), remove leading whitespace causing missing conffiles, use PKG_INSTALL
May 05 17:22:51 <swalker> nbd: did you look at the scons/chrpath patches needed for updating gpsd?
May 05 17:23:02 <nbd> no
May 05 17:27:51 <swalker> would be good if they were added, http://huchra.bufferbloat.net/~cero1/for_openwrt/
May 05 17:32:31 <CIA-19> juhosg * r31612 /trunk/package/ar7-atm/ (15 files in 2 dirs): package/ar7-atm: refresh patches
May 05 17:32:34 <CIA-19> juhosg * r31613 /trunk/package/ar7-atm/ (2 files in 2 dirs): package/ar7-atm: allow to build on 3.3
May 05 17:32:37 <CIA-19> juhosg * r31614 /trunk/target/linux/ar7/image/Makefile: ar7: fix kernel_entry extraction
May 05 17:32:40 <CIA-19> juhosg * r31615 /trunk/target/linux/ar7/ (10 files in 2 dirs): ar7: add 3.3 support
May 05 17:32:42 <CIA-19> juhosg * r31616 /trunk/target/linux/ar7/Makefile: ar7: switch to 3.3 and mark the target as broken
May 05 17:32:45 <CIA-19> juhosg * r31617 /trunk/target/linux/ar7/ (config-2.6.37 patches-2.6.37/): ar7: remove 2.6.37 support
May 05 17:33:02 <nbd> swalker: i'll take care of it
May 05 17:33:29 <nbd> hm, chrpath is broken
May 05 17:33:32 <nbd> doesn't compile here
May 05 17:37:20 <stintel> nbd: I just tested openvswitch with netifd, it almost works fine when you configure it like a normal ethernet device in /etc/config/network
May 05 17:37:26 <nbd> ok, great
May 05 17:37:28 <stintel> only thing I need to do is ifconfig ethX up
May 05 17:37:35 <CIA-19> nbd * r31618 /trunk/ (4 files in 3 dirs):
May 05 17:37:35 <CIA-19> tools: add scons (patch by Dave Taht)
May 05 17:37:35 <CIA-19> This makes it more possible to build scons based applications
May 05 17:37:35 <CIA-19> for openwrt.
May 05 17:37:43 <nbd> why do you need to do that?
May 05 17:38:01 <stintel> because openvswitch doesn't bring up member interface, as it seems
May 05 17:38:21 <nbd> ah, ok
May 05 17:38:24 <stintel> the vswitch is there, and eth0 is in it, but not up
May 05 17:38:35 <nbd> swalker: is chrpath really necessary for gpsd?
May 05 17:39:11 <nbd> having to use a program to reset the runtime path in elf binaries seems rather hackish to me
May 05 17:40:27 <swalker> nbd: it could be patched out I suppose, http://git.savannah.gnu.org/cgit/gpsd.git/tree/SConstruct#n393
May 05 17:41:28 <nbd> ok, should be patched out then
May 05 17:43:26 <nbd> that piece of code is a pretty nasty hack and we're better off without it ;)
May 05 17:44:56 <nbd> i wonder if linux distros patch this out as well
May 05 17:45:28 <nbd> because leaking the source build dir as an additional library search path into the final binaries could be a security risk too
May 05 18:04:45 <stintel> nbd: if I use option type ovs in /etc/config/network, will netifd automatically look for ovs.sh ? or does it need more
May 05 18:05:23 <nbd> i don't see a good way to integrate ovs with netifd right now
May 05 18:05:36 <nbd> right now plugins only act as interface configuration plugins
May 05 18:05:43 <nbd> so layer 3 stuff
May 05 18:05:52 <nbd> or combined stuff (e.g. in the case of ppp)
May 05 18:05:58 <nbd> there's no device provider plugin support yet
May 05 18:06:36 <stintel> ic
May 05 18:48:11 <philipp64|laptop> something is blocking the init scripts on startup, but it happens late enough that dropbear is already running. how do I go about isolating the hung script?
May 05 18:48:33 <nbd> look at the process list?
May 05 19:00:47 <nbd> dwmw2_go`: ping
May 05 19:15:04 <nbd> wow, scons is such a crappy build system
May 05 19:18:42 <philipp64|laptop> http://fpaste.org/kgAD/
May 05 19:19:14 <philipp64|laptop> any way to have init print out the name of each script it's about to run?
May 05 19:19:56 <nbd> you could edit /etc/init.d/rcS
May 05 20:12:45 <dwmw2_go`> nbd: hi
May 05 20:13:16 <nbd> i'm currently looking into porting openconnect to netifd
May 05 20:13:24 <dwmw2_go`> want account?
May 05 20:13:29 <nbd> not yet
May 05 20:13:37 <nbd> seems that i will drop vpnc-scripts for it
May 05 20:13:48 <dwmw2_go`> makes sense; netifd should be able to do all that.
May 05 20:13:54 <nbd> yep
May 05 20:14:01 <dwmw2_go`> likewise for vpnc, although I don't think we have a vpnc proto suport
May 05 20:14:04 <nbd> i'll
May 05 20:14:08 <nbd> let you know when i have something for testing
May 05 20:18:59 <dwmw2_go`>         option proto 'openconnect'
May 05 20:18:59 <dwmw2_go`>         option server 'casper.infradead.org'
May 05 20:18:59 <dwmw2_go`>         option cookie '62e282ac-1b90-48b9-b0e9-10f498b4e6d2'
May 05 20:18:59 <dwmw2_go`>         option port '4443'
May 05 20:19:30 <nbd> thanks
May 05 20:19:58 <dwmw2_go`> it'll give you public IPv6 address 2001:770:15f::108
May 05 20:20:16 <dwmw2_go`> and an RFC1918 Legacy IP address which can't route any further than the other end of the VPN link.
May 05 20:20:54 <dwmw2_go`> nbd: want me to make it tell you an HTTP server to use, while we're at it? Or is that something for another day?
May 05 20:20:55 <dwmw2_go`> :)
May 05 20:21:08 <dwmw2_go`> HTTP proxy I mean.
May 05 20:21:25 <nbd> maybe for another day, i don't know if i'm going to port it today
May 05 20:22:01 <philipp64|laptop> any way to have init print out the name of each script it's about to run?
May 05 20:22:06 <nbd> btw. the host route dependency stuff is working nicely in netifd now
May 05 20:22:10 <philipp64|laptop> grrrr...
May 05 20:22:17 <philipp64|laptop> not what I was expecting. http://fpaste.org/LzYr/
May 05 20:22:18 <nbd> it even restarts the vpn service if the route changes to a different interface (with pptp)
May 05 20:22:41 <philipp64|laptop> dwmw2_go: btw, I was suggesting using "ip -o" to avoid having to delete newlines with sed...
May 05 20:22:52 <philipp64|laptop> I hate parsing ifconfig output for this very reason.
May 05 20:23:43 <dwmw2_go`> philipp64|laptop: yeah, makes sense. Using awk makes a certain amount of sense too.
May 05 20:23:46 <nbd> in the new version it's just one line:
May 05 20:23:47 <nbd> proto_add_host_dependency "$config" "$server"
May 05 20:23:48 <nbd> ;)
May 05 20:24:02 <dwmw2_go`> although this is only used on Linux boxes so sed isn't likely to be absent or fucked-in-the-head-Sun-sed :)
May 05 20:24:19 <dwmw2_go`> (thinking of the vpnc-script version, since the OpenWrt one will die imminently anyway)
May 05 20:24:40 <nbd> at some point i'm going to bring up netifd on a desktop linux as well
May 05 20:24:43 <nbd> maybe after adding wifi support
May 05 20:24:48 <nbd> ;)
May 05 20:25:05 <dwmw2_go`> Android seems to do it differently. It uses SO_BINDTODEVICE on the connection to the VPN server, to force it to go the right way. And doesn't screw with the routing at all.
May 05 20:25:14 <dwmw2_go`> not entirely sure that does the right thing; I need to test.
May 05 20:25:50 <nbd> my code simply assumes that the vpn client is stupid
May 05 20:25:56 <nbd> which for many clients is a good assumption
May 05 20:25:58 <dwmw2_go`> :)
May 05 20:25:59 <nbd> having looked at the pptp source
May 05 20:26:19 <dwmw2_go`> do make sure it copes with the case where the VPN server is on the same subnet as the client, and *not* reached through the default gateway.
May 05 20:26:35 <dwmw2_go`> I have heard from openwrt users in that situation, using openconnect.
May 05 20:26:37 <philipp64|laptop> nbd: why would /etc/rc.d/S99sysctl hang?
May 05 20:26:45 <nbd> philipp64|laptop: no idea
May 05 20:26:51 <nbd> philipp64|laptop: throw in a set -x
May 05 20:27:20 <philipp64|laptop> David, what do you know about IPsec?
May 05 20:27:31 <dwmw2_go`> not a huge amount, but some
May 05 20:27:37 <dwmw2_go`> sec, baby is being murdered...
May 05 20:27:50 <philipp64|laptop> I used to have kame/racoon working in Astlinux pretty well, but there was one thing I never got it to do.
May 05 20:28:32 <philipp64|laptop> and this is functionality I'd really like to see: hand out to some clients /32 addresses on the *local* subnet that the concentrator is running on, and then proxy arp for them.
May 05 20:28:45 <philipp64|laptop> just as if they were local and DHCP assigned.
May 05 20:29:46 <dwmw2_go`> hard on Ethernet, since you can't easily tell clients to do PtP
May 05 20:29:51 <philipp64|laptop> if I could get my iPhone to do that, for instance, then a bunch of devices in my home (sat. box, TV set, home theatre, security system, MPEG4 cameras, etc.) could all talk to it a lot more easily.
May 05 20:29:55 <dwmw2_go`> I suppose you could pretend to bridge.
May 05 20:30:08 <dwmw2_go`> just use IPv6. Welcome to the 21st century.
May 05 20:30:23 <philipp64|laptop> you lost me. why is it hard to do? the policy just needs to know to match the entire subnet that the /32 came out of.
May 05 20:30:44 <dwmw2_go`> tell me what the *client* sees
May 05 20:30:57 <philipp64|laptop> these are embedded devices. 10 years from now they still won't have IPv6.
May 05 20:31:09 <philipp64|laptop> what do you mean what the client sees?
May 05 20:31:18 <dwmw2_go`> I've been using IPv6 for 10 years. You mean we have to wait *another* ten?
May 05 20:32:15 <dwmw2_go`> I am a client plugged into your network. I've sent a DHCPDISCOVER. What do I see?
May 05 20:32:24 <dwmw2_go`> (when you have this working, of course)
May 05 20:34:22 <philipp64|laptop> um, sorry, we're talking crossed purposes.
May 05 20:34:59 <philipp64|laptop> no, I'm saying I'm my iPhone or laptop, and I try to connect to an address which triggers an IPsec policy.
May 05 20:35:41 <philipp64|laptop> nbd: that script is effectively a 1-liner with no loops.
May 05 20:36:00 <philipp64|laptop> so we hold the packet, and instantiate an IPsec tunnel.
May 05 20:36:04 <dwmw2_go`> ok
May 05 20:36:21 <dwmw2_go`> between the iphone/laptop and the far end.
May 05 20:36:39 <philipp64|laptop> tunnel comes up, hands me an /32 address on 192.168.1.x/24, for instance, and sends me a policy telling me the route to 192.168.1.0/24 is through the tunnel.
May 05 20:37:43 <philipp64|laptop> as for local devices, whenever they try to send a packet to any address in my IPsec pool (say 192.168.1.32-63), that address gets proxy-ARPed by my IPsec concentrator.
May 05 20:38:29 <dwmw2_go`> Hm, so the ipsec isn't using the *existing* IP addresses? It's a tunnel?
May 05 20:38:36 <dwmw2_go`> you can do both with IPSec, right?
May 05 20:38:40 <philipp64|laptop> the kernel on the IPsec concentrator will have a locally installed route (will, in the case of linux it's not really a route, it's an iproute xfrm instead) that points to the tunnel.
May 05 20:39:57 <philipp64|laptop> it would be like DHCP in that you'd carve out a subnet from your /24 block... maybe 32..63 for IPsec clients, and 64...192 for DHCP.
May 05 20:40:22 <philipp64|laptop> and 1..31 for devices with reserved addresses or static addresses.
May 05 20:41:53 <philipp64|laptop> make sense?
May 05 20:43:25 <philipp64|laptop> kame tends to be oriented to island IPsec (i.e. tying 2 LANs together). but it completely misses LAN-to-point connections.
May 05 20:43:51 <philipp64|laptop> I'd heard from a colleague that Openswan was better at this, but hadn't looked into what scripting would be necessary.
May 05 20:44:10 <philipp64|laptop> anyway, it would be nice if OpenWRT supported rich IPsec connectivity out-of-the-box.
May 05 20:44:44 <philipp64|laptop> nbd: sorry, it wasn't S99sysctl that was hanging, it's whatever comes after it.
May 05 20:44:46 <philipp64|laptop> my bad.
May 05 20:47:43 <CIA-19> jow * r31619 /trunk/package/ubus/Makefile: [package] ubus: update to current git, package up libubus-lua
May 05 20:49:52 <philipp64|laptop> so it gets through all the scripts in the run_scripts section, the last one exits... but the "for" loop never completes. very strange.
May 05 20:49:52 * dwmw2_go` returns
May 05 20:51:59 <dwmw2_go`> philipp64|laptop: So you just connect to the VPN and get a /24 from it instead of a single address, and you route some of your extra addresses for your clients?
May 05 20:52:18 <dwmw2_go`> But don't those clients already *have* IP addresses? Real public ones from the local network? Or horrid NAT ones if you have a shitty ISP.
May 05 20:52:32 <dwmw2_go`> I ask again: What exactly does the *client* see.
May 05 20:52:46 <dwmw2_go`> and say again: just bloody use IPv6. Site-local (deprecated though it may be) does this perfectly.
May 05 20:52:47 <philipp64|laptop> can't. there are a lot of embedded devices that don't know how to talk to a non-adjacent device.
May 05 20:52:51 <philipp64|laptop> or don't want to.
May 05 20:53:05 <philipp64|laptop> my DVR will stream to an iPad on the local subnet, for instance.
May 05 20:53:12 <dwmw2_go`> I'll buy you an axe.
May 05 20:53:15 <philipp64|laptop> but not to one on a separate subnet.
May 05 20:53:17 <dwmw2_go`> that'll deal with *that* problem.
May 05 20:53:41 <philipp64|laptop> there are a lot of braindead manufacturers out there that assume that no household will ever have more than 1 subnet.
May 05 20:53:57 <dwmw2_go`> ok, so you want to do promiscuous proxy ARP. That's kind of separate to the games you're playing with addressing and routing, surely?
May 05 20:54:16 <dwmw2_go`> philipp64|laptop: if it was sold to you as supporting IP, take it back. It's broken
May 05 20:54:26 <philipp64|laptop> that's what you get when you build an IP CCTV camera and don't want to pay licensing fees for a non-braindead protocol stack.
May 05 20:54:33 <philipp64|laptop> "routing will cost you extra". sigh.
May 05 20:54:50 <philipp64|laptop> it's a losing battle.
May 05 20:55:08 <dwmw2_go`> not really; more and more people are moving to Linux. Thankfully.
May 05 20:55:20 <philipp64|laptop> but why would my iPad (connected to my home via IPsec) ever need more than a /32 stub anyway?
May 05 20:55:54 <dwmw2_go`> so your iPad is away from home, connected to home via a VPN?
May 05 20:56:01 <dwmw2_go`> right, so it would only need single /128
May 05 20:56:12 <dwmw2_go`> oh sorry, must remember we're talking 20th century. A /32
May 05 20:56:31 <dwmw2_go`> and yes, you could do proxy arp for it.
May 05 20:56:41 <philipp64|laptop> yes, that's the scenario.
May 05 20:57:03 <dwmw2_go`> so your feature request is just that you could give out addresses from the local subnet (but outside the dynamic DHCP range) to VPN clients, and do proxy ARP for them?
May 05 20:57:14 <dwmw2_go`> that seems simple enough
May 05 20:57:30 <dwmw2_go`> if it was a pptp/l2tp vpn you could probably add the trigger in /etc/ppp/ip-up.d
May 05 20:57:34 <philipp64|laptop> nbd: something must be holding stdin open for the $LOGGER in run_scripts() if the "for" loop is not exiting... maybe a process is backgrounding and forgetting to close stdout and stderr?
May 05 20:57:48 <dwmw2_go`> I'm sure there's somewhere you could script it when the VPN service is IPsec
May 05 20:58:44 <philipp64|laptop> not in Kame. there's a pre-phase 2 script but not a post-phase 2 script which would be needed to install the ARP table entry (publish,public,static)
May 05 20:59:38 <philipp64|laptop> anyway, since you're a VPN connoisseur I thought you might know something about setting up Openswan...
May 05 21:00:01 <dwmw2_go`> not really.
May 05 21:00:15 <dwmw2_go`> I wrote openconnect so I could connect to the Intel VPN but other than that I hate VPNs.
May 05 21:01:04 <dwmw2_go`> I use L2TP so that I can get real IPv6 and Legacy IP addresses when I'm stuck on shitty NATted networks.
May 05 21:01:56 <dwmw2_go`> and so that my home router can hop onto the neighbours' wireless when my ADSL lines are down, connect to the ISP and still route my home ranges of Legacy IP and IPv6 addresses.
May 05 21:02:07 <dwmw2_go`> which I suppose is just a special case of the first reason for using L2TP.
May 05 21:02:40 <CIA-19> nbd * r31620 /trunk/ (3 files in 2 dirs): scons: override the platform instead of using the host one - fixes build issues on non-linux systems
May 05 21:03:01 <CIA-19> nbd * r31621 /packages/net/gpsd/ (7 files in 3 dirs): gpsd: update to version 3.5 from cerowrt + chrpath removal patch
May 05 21:04:03 <dwmw2_go`> nbd: that openconnect account is yours for as long as you need it, it's otherwise unused addresses from a /64 that's routed to one of my hosted boxes.
May 05 21:04:14 <dwmw2_go`> nbd: I can do you an l2tp account too, but on a more limited basis. Let me know when you want it.
May 05 21:04:40 <dwmw2_go`> nbd: it'll have Legacy IP and IPv6 and DHCPv6+PD.
May 05 21:07:39 <dwmw2_go`> blogic: Ralf tells me he doesn't have lantiq box. How is this?
May 05 21:07:59 <blogic> he does
May 05 21:08:07 <dwmw2_go`> I'd be interested in setting one up to work properly with aa.net.uk (with DHCPv6 PD and all).
May 05 21:08:07 <blogic> dwmw2_go`: i mailed him 2 or 3
May 05 21:08:14 <dwmw2_go`> hm, where was he at the time?
May 05 21:08:21 <dwmw2_go`> Ralf isn't always at "home" in Cambridge :)
May 05 21:08:23 <blogic> i maile dhim uk and de units
May 05 21:08:40 <dwmw2_go`> OK, I'll steal one and set it up for aa.net.uk, and give it back to him :)
May 05 21:08:47 <blogic> ok
May 05 21:08:59 <blogic> you might want to get a bthh3
May 05 21:09:21 <blogic> its not fully supported yet due to lack of time
May 05 21:09:32 <blogic> but its a very nice annex-a unit
May 05 21:10:02 <dwmw2_go`> my ISP is playing with Technicolor routers, because they support IPv6 out of the box with PD
May 05 21:10:23 <dwmw2_go`> but other than that feature they're apparently a PITA. So I'd like to set up an openwrt box and say "hey, why don't you just use this?"
May 05 21:11:06 <dwmw2_go`> lantiq seems like the best bet.
May 05 21:12:05 <philipp64|laptop> and it looks like natpmp is the culprit... http://fpaste.org/bSBT/
May 05 21:14:58 <blogic> dwmw2_go`: it is
May 05 21:18:19 <jow_laptop> philipp64|laptop: you mean natpmp inhereits descriptors?
May 05 21:18:23 <philipp64|laptop> natpmp is holding stdout and stderr open to the logger...
May 05 21:18:27 <jow_laptop> yeah
May 05 21:18:43 <jow_laptop> its just forking, but no chroot(/) and no closing of stdin, err and out
May 05 21:19:00 <jow_laptop> might help to start it through service wrappers instead of its own
May 05 21:19:01 <philipp64|laptop> I just looked at natpmp.c:fork_to_background() -- it fails to fclose(stdout), etc. in the child.
May 05 21:19:18 <philipp64|laptop> ok... point me at an example?
May 05 21:19:36 <philipp64|laptop> (though I'll probably upstream a fix to initialize the daemon properly as well....)
May 05 21:21:08 <philipp64|laptop> jow_laptop: http://fpaste.org/RkI6/ ... am I missing anything?
May 05 21:23:14 <jow_laptop> http://luci.subsignal.org/~jow/natpmp-use-service-wrappers.patch
May 05 21:23:56 <builder> build #11 of brcm47xx is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/11
May 05 21:24:55 <jow_laptop> whitespace is also borked in the init script
May 05 21:26:02 <philipp64|laptop> argh... your webserver isn't handing out the correct MIME content/type for .patch files...
May 05 21:26:08 <philipp64|laptop> should be text/plain...
May 05 21:26:45 * jow_laptop only uses "GET" to view patches
May 05 21:26:56 <jow_laptop> but I can look
May 05 21:28:39 <jow_laptop> should be better now
May 05 21:33:25 <philipp64|laptop> that fixed the natpmp startup issue... now, about the config file...
May 05 21:33:34 <philipp64|laptop> how do I customize it during the install?
May 05 21:34:11 <jow_laptop> you could ship a post install script
May 05 21:34:38 <jow_laptop> for luci I usually ship a uci-defaults file which takes care of compile time installation
May 05 21:34:54 <jow_laptop> and an opkg postinstall which executes the uci-defautls script on target opkg install
May 05 21:35:07 <jow_laptop> to spare the need for an additional reboot
May 05 21:35:07 <philipp64|laptop> what other packages do this?
May 05 21:35:15 <jow_laptop> none
May 05 21:35:21 <jow_laptop> you'd be the first
May 05 21:35:24 <philipp64|laptop> ah... so no existing examples.
May 05 21:36:50 <jow_laptop> usually its easier to rework the init script to resolve openwrt ifnames to devices on startup
May 05 21:37:11 <jow_laptop> so you have just "wan" and "lan" in the config
May 05 21:37:30 <jow_laptop> and it will work regardless of what they actually are on a given target device
May 05 21:39:35 <nbd> dwmw2_go`: are exported variables from outside of openconnect passed to the vpnc-script?
May 05 21:40:52 <philipp64|laptop> jow_laptop: trying to picture how to do that.
May 05 21:45:48 <philipp64|laptop> ummm... V=99 no longer works...
May 05 21:46:30 <philipp64|laptop> no, take it back. my build host is just incredibly loaded.
May 05 21:47:01 <jow_laptop> I updated the previous patch
May 05 21:48:21 <jow_laptop> the idiom  config_get foo "$foo" ifname "$foo"  makes it fall back to the original value if the entry is no uci reference
May 05 21:48:47 <jow_laptop> e.g.  foo=lan: config get foo "lan" ifname "lan" will return "br-lan"
May 05 21:49:07 <jow_laptop> and  foo=eth0: config_get foo "eth0" ifname "eth0" will return "eth0" because there is no config interface eth0
May 05 21:52:59 <jow_laptop> updated the patch again to outline the config file changes
May 05 21:53:32 <jow_laptop> also the default config was broken, having an unquoted space separated value for an uci option is a syntax error
May 05 22:08:00 <philipp64|laptop> looks good. ship it!
May 05 22:08:02 <philipp64|laptop> :-)
May 06 00:00:37 <philipp64|laptop> jow_laptop: still around?
May 06 00:01:48 <jow_laptop> yes
May 06 00:15:52 <builder> build #8 of pxcab is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/pxcab/builds/8
May 06 00:16:18 <philipp64|laptop> had any more thoughts about supporting tag: and set: in dnsmasq?
May 06 00:18:12 <jow_laptop> not yet
May 06 00:24:49 <philipp64|laptop> ok. well, I'd like to bang it out soon because it's holding back a couple of deployments I've been wanting to do... replacing a few Astlinux boxes and Linksys routers with OpenWRT...
May 06 00:25:20 <philipp64|laptop> I proposed a syntax but didn't hear back if it was acceptable or not.
May 06 02:48:02 <builder> build #7 of etrax is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/etrax/builds/7
**** ENDING LOGGING AT Sun May 06 03:00:01 2012