**** BEGIN LOGGING AT Fri May 04 02:59:59 2012
May 04 03:16:28 <philipp64|laptop> hmmm... one of my init.d scripts is failing to complete... how do I figure out which one?
May 04 03:19:04 <philipp64|laptop> ps shows http://fpaste.org/1EB2/ and console shows http://fpaste.org/T3E4/
May 04 03:27:33 <m4t> what does logread show
May 04 03:43:22 <philipp64|laptop> rebooting... wait 1.
May 04 03:46:06 <philipp64|laptop> ok... http://fpaste.org/FNit/
May 04 03:47:34 <philipp64|laptop> m4t: anything stand out?
May 04 03:50:21 <philipp64|laptop> also, I noticed that natpmp's /etc/config/ file needs to be edited in place during the install...
May 04 08:52:52 <builder_> build #6 of rdc is complete: Failure [failed compile_3]  Build details are at http://buildbot.openwrt.org:8010/builders/rdc/builds/6
May 04 09:01:44 <builder_> build #8 of iop32x is complete: Failure [failed compile_10]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/8
May 04 09:59:10 <dwmw2_go`> whee. juhosg merged my patches to openwrt + packages.
May 04 09:59:13 <dwmw2_go`> now just the luci ones to go
May 04 09:59:21 <dwmw2_go`> then it must be time for me to do something new
May 04 10:02:23 <dwmw2_go`> +Copyright 2011 Jo-Philipp Wich <xm@subsignal.org>
May 04 10:02:39 <dwmw2_go`> hm, that's probably more true than if it pretend it's © me :)
May 04 10:02:47 <dwmw2_go`> since it's mostly a copy of existing stuff, with a few bits changed.
May 04 10:02:53 <dwmw2_go`> jow_laptop: what do you think?
May 04 10:08:38 <dwmw2_go`> oops, can't send from @intel address; that's not subcribed
May 04 10:22:49 <karlp> dwmw2_go`: yeah, I've had that thought a few times too :)
May 04 10:23:11 <karlp> I think on the new files I put "Copyright year OpenWrt.org"
May 04 11:05:13 <CIA-19> nbd * r31581 /packages/net/samba36/Makefile: samba36: update to 3.6.5 to fix CVE-2012-2111 (fixes #11388)
May 04 11:05:14 <CIA-19> nbd * r31582 /packages/net/samba36/Makefile: samba36: add a package for nmblookup/smbclient
May 04 11:05:16 <CIA-19> nbd * r31583 /packages/net/samba/: remove samba 2.0, it does not work with recent clients and probably has many unfixed security issues
May 04 11:05:22 <CIA-19> nbd * r31584 /packages/ (net/cifs-utils/ net/cifs-utils/Makefile utils/cifsmount/): add cifs-utils, replacing the old cifsmount package
May 04 11:05:23 <CIA-19> nbd * r31585 /packages/net/samba3/: remove samba3, all of its features should now be supported by samba36+cifs-utils
May 04 13:11:56 <jow_laptop> dwmw2_go`: please add your own copyright
May 04 13:12:34 * nbd is now almost done with netifd host route dependency handling for pptp and stuff
May 04 13:13:54 <jow_laptop> yay
May 04 13:14:34 <nbd> hm, somebody will have to port odd stuff like tagya
May 04 13:15:03 <jow_laptop> ignore it for now, it probably has one or two users at most
May 04 13:15:16 <jow_laptop> besides, tayga is mostly firewall related, less network wise
May 04 13:15:17 <nbd> ok
May 04 13:15:24 <nbd> i'll mark it as broken then
May 04 13:16:20 <nbd> and openconnect also needs to be ported
May 04 13:16:54 <nbd> and a few others, e.g. ahcpd, xl2tpd
May 04 13:17:18 <nbd> oh, and wing
May 04 13:17:30 <nbd> i think those are all that are left in /packages
May 04 13:17:52 <nbd> oh, and l2tpv3tun as well
May 04 13:19:07 <jow_laptop> yeah
May 04 13:19:16 <jow_laptop> l2tpv3 is hairy
May 04 13:19:23 <jow_laptop> it behaves bridge-like
May 04 13:19:37 <jow_laptop> hm actually with netifd there is no need for that anymore
May 04 13:21:32 <nbd> the l2tpv3 proto handler should probably be replaced with an init script that sets up the tunnel device
May 04 13:21:48 <jow_laptop> it needs reconnect logic
May 04 13:22:05 <nbd> what kind of reconnect logic?
May 04 13:22:14 <jow_laptop> I gave up on the concept of init scripts for any kind of netwokr setup
May 04 13:22:24 <jow_laptop> its a failed approach
May 04 13:23:03 <jow_laptop> well it does not detect link changes, it needs some agent (hotplug handler) which recreates the tunnel if the route to the target or the local ip changed
May 04 13:23:12 <nbd> ah, that
May 04 13:23:25 <nbd> how does a network proto handler make that part any easier?
May 04 13:23:32 <nbd> compared to an init script
May 04 13:23:54 <jow_laptop> I didn't say a proto handler makes it easier
May 04 13:23:59 <nbd> ah, ok
May 04 13:24:05 <jow_laptop> but a classical init script is racy
May 04 13:24:30 <nbd> the l2tp proto handler script has locking
May 04 13:24:34 <nbd> so we can convert it to an init script
May 04 13:24:46 <jow_laptop> but why l2tp as init script and pptp as proto?
May 04 13:25:00 <nbd> because pptp is ppp
May 04 13:25:04 <nbd> and ppp is not layer2 stuff
May 04 13:25:10 <jow_laptop> then why l2tp as init script and 6in4 as proto?
May 04 13:25:23 <nbd> same
May 04 13:25:29 <jow_laptop> they're both iproute2 initiated tunnels
May 04 13:25:30 <nbd> 6in4 is also not a layer 2 device
May 04 13:25:44 <jow_laptop> don't see why the layer2 plays a role here
May 04 13:25:46 <nbd> with l2tp you can set up any kind of proto on top
May 04 13:25:53 <nbd> similar to openvpn
May 04 13:26:23 <nbd> at least i think so
May 04 13:26:56 <jow_laptop> I don't see why it should be an init script, but okay
May 04 13:27:15 <jow_laptop> its a stateless tunnel, without associated userspace daemons
May 04 13:27:27 <nbd> i'll read some l2tp code/docs to see if my assumptions are correct
May 04 13:27:57 <jow_laptop> note that l2tpv3 is completely different to l2tp
May 04 13:29:17 <nbd> yeah, i'm talking about v3 at the moment
May 04 13:29:24 <dwmw2_go`> l2tpv2 should be a proto, just like pptp
May 04 13:29:33 <nbd> yes
May 04 13:29:34 <jow_laptop> its setup requires an already working network, so it cannot be launched on init as it would race with the network setup, so you end up with a messy init script that does nothing on boot but defers itself to get started through hotplug
May 04 13:29:36 <dwmw2_go`> I can give you a test account for openconnect and l2tpv2
May 04 13:29:43 <nbd> l2tpv3 seems to support ethernet-like encapsulation
May 04 13:29:48 <jow_laptop> and in the end you end up with the same crappy mess that is there right now
May 04 13:29:50 <nbd> which makes it more of a candidate for an init script
May 04 13:30:00 <dwmw2_go`> l2tpv3 allows you to encapsulate fairly much anything.
May 04 13:30:22 <jow_laptop> it must not be a protocol either
May 04 13:30:23 <dwmw2_go`> it's just a more versatile tunnel. But I still don't see why it would be an init script. Surely it should still be a proto
May 04 13:30:24 <nbd> jow_laptop: the idea is, as an init script it's easy to hook it up to the service restart infrastructure
May 04 13:30:28 <jow_laptop> I would be fine with a hotplug handler
May 04 13:30:34 <nbd> jow_laptop: which i will work on, once the netifd transition is complete
May 04 13:30:57 <nbd> the hotplug handler will then tell the init script to reload/restart and stuff
May 04 13:31:09 <nbd> i want the hotplug scripts to only contain a minimum amount of logic
May 04 13:31:12 <dwmw2_go`> if you're offering *services* over openvpn/l2tp(v2 or v3)/etc then those should probably be started by init scripts
May 04 13:31:23 <dwmw2_go`> but if you're making outbound connections as a client, those are protos
May 04 13:31:44 <dwmw2_go`> so you'll have a different init script for each configured connection?
May 04 13:32:02 <jow_laptop> probably one with multiple isntances
May 04 13:32:07 <nbd> the idea is that init scripts will become smart enough to have a reload command that checks if anything on the system affecting the service has changed
May 04 13:32:11 <jow_laptop> but controlling it gets annyoing
May 04 13:32:26 <jow_laptop> at least if its not connected to the ifup / ifdown mechanism
May 04 13:32:34 <nbd> so that in the end, an interface up/down event will trigger a global init script reload call, going out to any init scripts that request it
May 04 13:33:18 <jow_laptop> but by that logic you can turn 6in4 into an init script as well
May 04 13:33:25 <dwmw2_go`> so *all* ifup/ifdown for all interfaces ends up being done by init scripts?
May 04 13:33:25 <jow_laptop> its also just ip tunnel add + wget
May 04 13:33:32 <nbd> no
May 04 13:33:36 <nbd> 6in4 is not generic enough
May 04 13:33:40 <nbd> it doesn't support arbitrary encaps
May 04 13:33:58 <dwmw2_go`> I don't really see why that makes a difference.
May 04 13:34:23 <dwmw2_go`> Xin4 *does* support arbitrary encaps. You can route anything over IPv4... :)
May 04 13:34:26 <nbd> with l2tpv3, you can attach an arbitrary number of interface configurations to the tunnel device in /etc/config/network
May 04 13:34:34 <dwmw2_go`> we just happen to support IPv6 over IPv4 and not a lot else.
May 04 13:34:46 <nbd> and netifd will manage the state of those
May 04 13:35:18 <jow_laptop> so you do not want to manage layer 2 stuff?
May 04 13:35:28 <nbd> at least not right now
May 04 13:35:32 <nbd> it doesn't fit well enough yet
May 04 13:35:40 <dwmw2_go`> nbd: With the existing l2tp and openconnect stuff, you can attach an arbitrary number of interface configurations and the proto scripts will handle them.
May 04 13:35:46 <nbd> at some point i might migrate that to 'config device' sections in /etc/config/network
May 04 13:36:02 <dwmw2_go`> you mean that for l2tpv3 you have multiple tunnels under *one* configuration?
May 04 13:36:13 <nbd> i mean one tunnel with multiple configurations
May 04 13:36:13 <jow_laptop> ok. but I still think it shouldn't be an *init* script, it should be something outside of /etc/init.d/ with similar semantics but solely triggered by events
May 04 13:36:20 <nbd> running on it simultaneoushly
May 04 13:36:20 <dwmw2_go`> that sounds wrong. For l2tpv2 I did indeed do it with separate devices
May 04 13:36:32 <dwmw2_go`> ah, ok.
May 04 13:36:45 <nbd> the idea is that a l2tpv3 device is generic enough to be treated the same way as an ethernet device
May 04 13:37:05 <nbd> sure, you can have multiple l2tpv3 devices, the init script should handle that just fine
May 04 13:37:05 <jow_laptop> it more or less is (pmtu issues aside)
May 04 13:37:24 <nbd> and that's where i draw the line
May 04 13:37:28 <dwmw2_go`> this is also true for RFC2684 Ether-over-ATM
May 04 13:37:35 <nbd> yes
May 04 13:37:41 <nbd> it also has an init script
May 04 13:37:57 <dwmw2_go`> so when the atm device is hotplugged, what happens?
May 04 13:38:12 <jow_laptop> we have a crappy hotplug handler that starts the init script
May 04 13:38:12 <nbd> there's an atm hotplug handler that fires up br2684ctl
May 04 13:38:24 <nbd> the scripts to handle such stuff right now are pretty messy
May 04 13:38:31 <nbd> but this will be cleaned up after the netifd transition
May 04 13:39:23 <jow_laptop> to reiterate, I do not have a problem with init scripts, I just dislike the fact that their boot() action will often not work
May 04 13:39:26 <nbd> the main reason why i don't want generic ethernet-like tunnel devices to be hooked up to the interface logic is that this creates limitations which will be annoying to deal with later
May 04 13:39:32 <jow_laptop> so they'rem ore service control scripts, no startup scripts
May 04 13:39:43 <jow_laptop> and therfore shouldn't be in /etc/init.d/
May 04 13:39:57 <dwmw2_go`> nbd: which limitations? And aren't we going to need to handle them anyway?
May 04 13:40:08 <jow_laptop> because then other stuff like enable/disable/disabled for init script looses its meaning
May 04 13:40:29 <nbd> dwmw2_go`: 'interfaces' in netifd are layer3 configurations and are treated as such. i.e. you can have multiple of them referring to the same device
May 04 13:41:10 <nbd> dwmw2_go`: if we mix those up with providers of layer 2 devices, it makes it hard to have multiple configurations on the same device
May 04 13:41:23 <nbd> since the down/up logic will then create nasty corner cases
May 04 13:41:50 <dwmw2_go`> it doesn't *have* to.
May 04 13:42:01 <dwmw2_go`> you can take the l2 down only when all the logical interfaces on it are also down.
May 04 13:42:11 <nbd> it's still a layering violation
May 04 13:42:17 <nbd> and i don't like that
May 04 13:42:19 <jow_laptop> I agree
May 04 13:42:22 <dwmw2_go`> ont really. It's just a layer.
May 04 13:42:45 <dwmw2_go`> the l3 configurations require the existence of the l2 device. Go figure
May 04 13:43:01 <dwmw2_go`> you already have to cope with devices appearing and going away, surely? With hotplug.
May 04 13:43:10 <dwmw2_go`> "hey, eth0 arrived. Let's set it up..."
May 04 13:43:20 <nbd> it already does that
May 04 13:43:54 <dwmw2_go`> but you don't want it to handle 'Oh, the user wants to bring nas0 up; let's create it' ?
May 04 13:44:03 <nbd> but if you have multiple l3 configurations on a single tunnel, then you'd have to make one of them the primary one
May 04 13:44:08 <nbd> and that choice would be somewhat arbitrary
May 04 13:44:15 <nbd> and bringing that one down will then tear down the other ones as well
May 04 13:44:21 <dwmw2_go`> why would you do that
May 04 13:44:36 <nbd> i suppose you could also treat it as a 'proto none' type of thing
May 04 13:44:46 <dwmw2_go`> -EPARSE.
May 04 13:45:05 <nbd> so suppose you create a 'config interface' section for a l2tpv3 tunnel
May 04 13:45:17 <dwmw2_go`> I'm stuck on why you'd take down a 'physical' device just because you took down *one* of the multiple configs that use it
May 04 13:45:18 <nbd> it'll have 'option proto l2tpv3'
May 04 13:45:24 <jow_laptop> hm, in the case of l2tpv3, a hypothetical "ifdown l3user" would still let the l2 iface remain up? Or would it get torn down if no more ip is configured?
May 04 13:45:26 <nbd> what kind of l3 related options would you put in there?
May 04 13:45:41 <nbd> jow_laptop: it would get torn down once there are no more active users
May 04 13:45:51 <dwmw2_go`> which is fine.
May 04 13:45:52 <jow_laptop> through the init script?
May 04 13:46:03 <dwmw2_go`> you wouldn't tear it down while there are *active* users; that would just be a bug.
May 04 13:46:17 <nbd> dwmw2_go`: let's talk about the ip configuration part in /etc/config
May 04 13:46:23 <dwmw2_go`> so you've have one l2tpv3 configuration for the tunnel itself.
May 04 13:46:28 <nbd> dwmw2_go`: what kind of options would you put in there for the proto=l2tpv3 interface section?
May 04 13:46:32 <dwmw2_go`> and multiple interface configurations which reference that.
May 04 13:46:34 <nbd> dwmw2_go`: any ip settings or just nothing?
May 04 13:46:52 <jow_laptop> encapsulation mode, remote endpoint, remote port (if applicable)
May 04 13:47:19 <dwmw2_go`> I'm not entirely familiar with l2tpv3; I've mostly looked at l2tpv2
May 04 13:47:35 <nbd> for l2tpv2, an interface configuration actually makes sense
May 04 13:47:40 <nbd> since it's more limited
May 04 13:47:53 <jow_laptop> but I agree, config interface is the wrong context to describe/spawn an l2 l2tpv3 tunnel
May 04 13:48:08 <dwmw2_go`> The way it works with l2tpv2 in the current setup is that even if you have multiple sessions to the same host, xl2tpd handles that behind the scenes. You specify the LNS and the login details, and you don't *care* if it's actually over the same tunnel as another configuration
May 04 13:48:16 <jow_laptop> a config device would
May 04 13:48:24 <jow_laptop> but then it needs a concept of "device handlers"
May 04 13:48:28 <jow_laptop> not only "proto handlers"
May 04 13:48:36 <dwmw2_go`> that makes some sense.
May 04 13:48:37 <nbd> i will implement device handlers eventually
May 04 13:48:44 <nbd> but i don't want to do that right now
May 04 13:48:50 <nbd> since it'd require more rework in the core
May 04 13:49:00 <nbd> at the moment it assumes that it can bring up devices immediately
May 04 13:49:29 <nbd> (after the hotplug stuff has told it that the device is there and usable)
May 04 13:50:20 <jow_laptop> so where would you store the l2tpv3 config?
May 04 13:50:28 <jow_laptop> outside of /e/c/network ?
May 04 13:50:35 <jow_laptop> or make an exception like for atm bridges?
May 04 13:50:50 <nbd> maybe we should start nailing down the format and go for a config device section immediately
May 04 13:51:07 <dwmw2_go`> nbd: bringing the device up would still be conditional on its config, right? So I can set it to onboot=no and bring it up manually later?
May 04 13:51:19 <jow_laptop> yes, that would make sense. From a user pov it doesn't matter who or what implements this device section format, just that it is somewhat generic
May 04 13:51:26 <nbd> dwmw2_go`: bringup-on-boot is configured per interface configuration
May 04 13:51:32 <dwmw2_go`> I'll probably put a wireless card in, and make it come up *only* when the ADSL is down. And then authenticate with WISPr and then bring up an L2TP tunnel to the ISP...
May 04 13:52:18 <dwmw2_go`> I'd go for /etc/config/l2tpv3 , and sections in /etc/config/network which reference the tunnels defined therein.
May 04 13:52:20 <nbd> so initially you'd manage l2tp tunnel up/down for v3 through the init script
May 04 13:52:23 <nbd> e.g. with enable/disable
May 04 13:52:46 <nbd> and the hotplug script would check for '/etc/init.d/l2tpv3 enabled' before doing anything automatically
May 04 13:53:19 <dwmw2_go`> assume you have more than one l2tpv3 tunnel, to different hosts.
May 04 13:53:23 <nbd> once the core is reworked and l2tpv3 is promoted to a full device handler, you can do everything through bringing the interface configurations that use it up/down
May 04 13:53:30 <nbd> that's fine
May 04 13:53:46 <nbd> each tunnel has its own 'config device' section
May 04 13:53:56 <nbd> and you could have an option for disabling one or more of them
May 04 13:54:10 <dwmw2_go`> how do you enable/disable them individually when invoking the init script ?
May 04 13:54:20 <nbd> and have /etc/init.d/l2tpv3 enable/disable take an optional argument which specific tunnel you refer to
May 04 13:54:27 <nbd> same for start/stop
May 04 13:54:48 <nbd> when you don't provide the optional argument, it means 'do them all'
May 04 13:54:58 <nbd> the rc.common wrapper supports that
May 04 13:55:13 <dwmw2_go`> when would 'do them all' be the right thing to do?
May 04 13:55:29 <nbd> it's convenient if you only have one tunnel
May 04 13:55:34 <dwmw2_go`> surely you only want to bring a tunnel up when you have an interface trying to *use* it?
May 04 13:55:50 <nbd> and we'll get to that point later
May 04 13:56:06 <nbd> right now i'm interested in an easy migration to netifd so that i can finally nuke the old scripts
May 04 13:56:16 <dwmw2_go`> hm, ok.
May 04 13:56:37 <jow_laptop> I would propose an anonymous section "config device"
May 04 13:56:50 <jow_laptop> with two generic options, "protocol" and "devname"
May 04 13:56:50 <nbd> yep
May 04 13:56:58 <nbd> well, we already have 'type'
May 04 13:57:07 <nbd> and 'name'
May 04 13:57:16 <jow_laptop> type and name would work too
May 04 13:57:22 <nbd> netifd already uses those
May 04 13:57:42 <jow_laptop> we could reserve the type "ethernet" to attach stuff like mtu, txqueuelen to devices
May 04 13:57:46 <nbd> and you can already use them to create bridges with arbitrary names
May 04 13:58:04 <jow_laptop> all other types would be unhandled
May 04 13:58:05 <nbd> the create-bridge-through-interface section is handled entirely in config.c as legacy format support
May 04 13:58:29 <jow_laptop> so that various hotplug scripts / init scripts or deamons could pick those up
May 04 13:58:35 <nbd> right now it falls back to ethernet if the type is unset
May 04 13:58:46 <nbd> we can make it fall back to that if the type is unknown as well
May 04 13:58:56 <dwmw2_go`> makes more sense
May 04 13:58:56 <jow_laptop> yes
May 04 13:59:07 <dwmw2_go`> using 'ethernet' for basic netif stuff that isn't Ethernet-specific would be wrong.
May 04 14:16:37 <dwmw2_go`> nbd: if you want l2tp(v2) or openconnect testing accounts, let me know
May 04 14:16:50 <jow_laptop> I'
May 04 14:17:01 <jow_laptop> I'd love to get access to some line offering 6rd
May 04 14:19:22 <dwmw2_go`> just configure your DHCP server to advertise a 6rd prefix of 2002::/16 and a border router of 192.88.99.1?
May 04 14:20:30 <jow_laptop> I'm not interested in testcases built according to the fine RFCs, I'd rather want to see whats actually done in the wild :)
May 04 14:20:45 <jow_laptop> like comcast using an eintirely different dhcp option number than specified in the fine RFC
May 04 14:20:48 <dwmw2_go`> well yes, but test cases are a good start :)
May 04 14:20:52 <dwmw2_go`> hah, realy?
May 04 14:20:55 <jow_laptop> yes
May 04 14:21:01 <dwmw2_go`> joy
May 04 14:21:46 <karlp> rfc's aren't specs, they're requests for comment :)
May 04 14:22:07 <jow_laptop> fine with me, problem is that others build their interop assumptions around them
May 04 14:26:22 <dwmw2_go`> well, having a basic implementation based on the spec, and a way to divide the subnet up into separate /64s for your internal subnets, and making that co-operate with DHCPv6 PD which also wants to do the same thing, should keep you out of trouble while you're waiting for a Comcast user to say "hey, let me test what you've implemented" :)
May 04 14:26:36 <dwmw2_go`> my ISP doesn't bother with 6rd; they just do native IPv6.
May 04 14:26:48 <dwmw2_go`> for the last 10 years.
May 04 14:29:34 <dwmw2_go`> I think there's a ppp option for prefix delegation too
May 04 14:30:25 <jow_laptop> oh there's more than enough standards
May 04 14:31:39 <dwmw2_go`> I can certainly provide you with an l2tp account that does dhcpv6 PD
May 04 14:32:42 <dwmw2_go`> the bit which allocates /64s to the internal networks and prods radvd probably wants ripping out of the existing dhcp6c code, and making generic enough so that you can use it from 6rd too.
May 04 14:34:13 <dwmw2_go`> we probably want an 'allocate-a-slash-64' config flag on our internal interfaces, and those will be satisfied by any prefixes which magically get discovered through PD/6rd/ppp/aiccu/etc.
May 04 14:49:04 <karlp> dwmw2_go`: what's the usual sort of a size prefix a home user would get assigned ona  pure ipv6?
May 04 14:49:39 <karlp> I see a lot of mention of /64s? but in some cases shorter?
May 04 14:49:52 <karlp> what sort of situations isn't a /64 enough?
May 04 16:37:36 <jow_laptop> karlp: it isn't enough for example if you want to redistribute ipv6 with radvd
May 04 16:38:28 <jow_laptop> karlp: unless you resort to proxy ndp, which is equivalent with proxy arp for ipv4
May 04 16:39:11 <karlp> I can't go all the way down to a /120 or something like in ipv4?
May 04 16:39:21 <karlp> I know there's a lot of extra predetermined network and link addresses,
May 04 16:39:45 <jow_laptop> no. the 2nd half (the upper 64bit) are derived from the mac
May 04 16:39:58 <karlp> oh, that's right, I'd forgotten about that.
May 04 16:39:59 <jow_laptop> at least when using stateless autocon
May 04 19:16:24 <philipp64|laptop> got a question: I built natpmp but it was installed with the natpmp.config file as is... the wan and lan interfaces didn't get customized for the platform I built for. is that a bug?
May 04 19:16:56 <philipp64|laptop> it referenced br-lan eth1 for the inbound interface, and vlan0 (????) for the outbound interface.
May 04 19:34:10 <swalker> philipp64|laptop: I'd say it's a white russian remnant
May 04 19:34:54 <philipp64|laptop> do I need to file a bug?
May 04 19:35:19 <philipp64|laptop> it showed nico as doing most of the commits to it (and some from abd) but I've not seen either in a while.
May 04 19:36:46 <swalker> philipp64|laptop: yes or post to the ml
May 04 21:28:10 <builder_> build #8 of rb532 is complete: Failure [failed compile_3]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/8
**** ENDING LOGGING AT Sat May 05 03:00:01 2012