**** BEGIN LOGGING AT Tue Feb 07 02:59:58 2012 Feb 07 03:28:19 so, what's your problem again? what version are you building? Feb 07 03:28:56 russell--: are you building 3.3? Feb 07 03:56:07 trying to reproduce what you're seeing. Feb 07 04:16:30 build #135 of s3c24xx is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/135 Feb 07 04:26:17 philipp64|laptop: i built r30004, the git update'd to r30310 or whatever it was (see irclogs ^^^), did a make oldconfig ; make Feb 07 04:27:01 * russell-- 's build machine is currently suffering a harddisk failure of half its raid1, working on fixing Feb 07 04:38:23 yay, grub recovery to the rescue. now to scrounge for a new hard disk tomorrow Feb 07 04:39:18 that 32mb CF card finally came in handy for something! Feb 07 06:08:22 build #132 of brcm47xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/132 Feb 07 06:08:23 build #140 of brcm63xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/140 Feb 07 06:20:02 russell--: I'd run r30025 at a minimum. and you're letting it default to 3.2.2.? still having build issues? Feb 07 06:20:09 can you paste them somewhere? Feb 07 06:31:40 philipp64|laptop: it's just the three kernel config questions i already posted Feb 07 06:32:00 and, yes, just the default kernel Feb 07 06:45:24 build #130 of atheros is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/130 Feb 07 11:58:10 nbd * r30345 /trunk/target/linux/generic/ (11 files in 11 dirs): kernel: add a recent upstream commit (post-3.3) to the ssb update patch, required for the next mac80211 update Feb 07 11:58:23 nbd * r30346 /trunk/package/mac80211/ (72 files in 2 dirs): mac80211: update to wireless-testing 2012-02-06 Feb 07 11:58:24 nbd * r30347 /trunk/package/iw/ (8 files in 2 dirs): iw: update to version 3.3, sync with latest nl80211.h changes Feb 07 12:04:39 nbd: if it's post-3.3, then 3.3 needs it, too ;) Feb 07 12:04:51 ah Feb 07 12:04:51 hm Feb 07 12:04:54 it is there Feb 07 12:05:15 ah, missed it because it's separate as "added" Feb 07 12:05:22 nbd: sry ;) Feb 07 12:05:34 fnord. Feb 07 12:06:07 :) Feb 07 12:22:10 mirko * r30348 /packages/libs/libssh2/ (. Makefile): [packages] add package 'libssh2' - thanks to Jiri Slachta Feb 07 13:12:07 jow * r30349 /packages/net/autossh/ (Makefile files/autossh.init): [packages] autossh: fix syntax error in init script (#10920) Feb 07 13:12:56 jow * r30350 /branches/packages_10.03.2/net/autossh/ (Makefile files/autossh.init): [packages_10.03.2] autossh: merge r30349 Feb 07 13:27:42 jow * r30351 /packages/net/yafc/Makefile: [packages] yafc: disable all optional features like socks, socks5, krb4, krb5 or gssapi to prevent configure from picking up host includes Feb 07 13:28:24 jow * r30352 /branches/packages_10.03.2/net/yafc/Makefile: [packages_10.03.2] yafc: merge r30351 Feb 07 13:30:51 acinonyx * r30353 /trunk/target/linux/x86/ (alix2/target.mk geos/target.mk): Feb 07 13:30:51 [x86] alix2, geos: Adjust CFLAGS Feb 07 13:30:51 Clone of CFLAGS change from r30013 into Geos and Alix platforms. Feb 07 13:30:51 Signed-off-by: Philip Prindeville Feb 07 14:32:43 jow * r30354 /branches/packages_10.03.2/libs/protobuf-c/: [packages_10.03.2] protobuf-c: merge r28194 Feb 07 14:42:20 blogic: hi, tried with gigaset fw off fresh svn. think it does not blow up, but not configured for all rqd by pppoa (don't ever see showtime). will make changes to new trunk and try again later. Feb 07 15:19:39 jow * r30355 /packages/utils/tmux/ (Makefile patches/ patches/100-b64_ntop-conflict.patch): Feb 07 15:19:39 [packages] tmux: fix b64_ntop conflict Feb 07 15:19:39 Certain uClibc versions declare b64_ntop but do not actually implement it, this leads to conflicting declarations Feb 07 15:19:39 when the tmux compat replacement function is used. Rename the replacement to local_b64_ntop and define b64_ntop Feb 07 15:19:40 to local_b64_ntop if the libc indeed implements it. Feb 07 15:22:18 jow * r30356 /branches/packages_10.03.2/utils/tmux/ (Makefile patches/): [packages_10.03.2] tmux: merge r30355 Feb 07 15:31:29 build #125 of ps3 is complete: Failure [failed compile_6] Build details are at http://buildbot.openwrt.org:8010/builders/ps3/builds/125 Feb 07 15:46:21 acinonyx * r30357 /packages/libs/libssh2/Makefile: [packages] libssh2: Cleanup package Makefile Feb 07 15:50:07 acinonyx * r30358 /packages/libs/libssh2/Makefile: [packages] libssh2: Add package description Feb 07 15:55:58 nbd * r30359 /trunk/package/mac80211/patches/ (2 files): ath9k: ignore invalid signal strength values in a-mpdu packets, fixes average signal strength display fluctuations Feb 07 16:00:22 jow * r30360 /packages/net/radsecproxy/ (Makefile patches/ patches/100-missing-return.patch): [packages] radsecproxy: add missing return statements to fix compilation on Backfire Feb 07 16:00:52 yes Feb 07 16:01:57 jow * r30361 /branches/packages_10.03.2/net/radsecproxy/ (Makefile patches/): [packages_10.03.2] radsecproxy: merge r30360 Feb 07 16:15:59 nbd * r30362 /trunk/package/broadcom-wl/files/lib/wifi/broadcom.sh: broadcom-wl: turn on wmm by default, disabling it by default makes no sense, and without it 802.11n does not work (fixes #10918) Feb 07 16:30:16 russell_: ping Feb 07 16:30:43 nbd: mooooo! Feb 07 16:33:29 * nbd wonders if google translate supports any bovine languanges Feb 07 16:34:36 with luck Feb 07 16:34:54 there are bits in the game DeathSpank where you talk to a cow Feb 07 18:37:43 jow_laptop: tell me again what I need to do to root-cause the kernel panic in the netdev code? Feb 07 18:38:29 Global build settings Compile the kernel with symbol table information Feb 07 18:38:50 you might also want Feb 07 18:38:57 Compile the kernel with debug information Feb 07 18:39:02 space should be enough Feb 07 18:39:33 while you're at it enable the gdb Feb 07 18:40:05 ok... which symbols are these so I can just through them in defconfig? Feb 07 18:40:07 Advanced configuration options (for developers) Toolchain Options Build gdb Feb 07 18:40:14 proceed with Feb 07 18:40:27 make toolchain/gdb/{compile,install} target/linux/clean world V=99 Feb 07 18:40:45 the gdb make target is only needed once Feb 07 18:41:25 uhm Feb 07 18:41:44 CONFIG_KERNEL_KALLSYMS Feb 07 18:41:52 CONFIG_KERNEL_DEBUG_INFO Feb 07 18:42:08 CONFIG_DEVEL Feb 07 18:42:22 CONFIG_TOOLCHAINOPTS Feb 07 18:42:41 CONFIG_GDB Feb 07 18:42:46 all set to y Feb 07 19:05:52 jow * r30363 /trunk/package/firewall/ (Makefile files/lib/fw.sh): [package] firewall: don't filter IPv4 ICMP types (#10928) Feb 07 19:06:53 jow * r30364 /branches/backfire/package/firewall/ (Makefile files/lib/fw.sh): [backfire] firewall: merge r30363 Feb 07 19:10:48 btw, does CONFIG_KERNEL_DEBUG_KERNEL actually get used anywhere? Feb 07 19:11:20 no idea Feb 07 19:19:43 build #128 of cobalt is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/128 Feb 07 19:25:13 jow_laptop: ok, booted... Feb 07 19:26:03 since the network drivers are crashing, I'm going to assume that we're going to run gdb over the serial port? Feb 07 19:28:42 does the wiki cover any of this? it mentions debugging an app on the router remotely, but not kernel debugging itself... Feb 07 19:42:47 do I need to build with any command line args to the kernel to tell gdb to take the serial line, for instance? Feb 07 19:43:39 build #126 of orion is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/126 Feb 07 19:52:15 looks like I'll need: kgdboc=ttyS0,115200 ... where does that go in my .config file? Feb 07 19:58:42 philipp64|laptop: no you take the stack address and use that to resolve the line of code belonging to it Feb 07 19:59:06 philipp64|laptop: via gdb info line *(0x...) Feb 07 19:59:18 where ... is the topmost address in the oops stacktrace Feb 07 19:59:36 ok. Feb 07 19:59:46 that is done in your buildenv Feb 07 20:00:16 ./staging_dir/toolchain-*/bin/*-gdb ./build_dir/linux-*/linux-*/.../*.ko Feb 07 20:05:16 net/core/dev.c: 3831 BUG_ON(n->gro_list); Feb 07 20:05:30 nbd: pong Feb 07 20:06:29 (if you are asking about the ath5k testing, i haven't quite gotten to it yet ;-) Feb 07 20:06:52 philipp64|laptop: a BUG_ON() is no crash though, but it produces a stacktrace Feb 07 20:09:12 philipp64|laptop: try to resolve the lines leading to that BUG_ON() Feb 07 20:09:56 then I'm not getting a stack trace during the crash... http://fpaste.org/dNNO/ Feb 07 20:11:21 nbd: part of what is slowing me down is i'm not clear on how to apply your patches, are they reverts? or, can i just plop them in ../patches? do i need to apply/revert them by hand? of course, i would figure it out by trying, but i've been distracted by higher priority interrupts. i do want to get the problem solved and understand i need to participate in that process, though ;-) Feb 07 20:12:05 philipp64|laptop: what is 0xe05ce501 ? Feb 07 20:13:04 not sure... it must be in a module, but I don't know which one. Feb 07 20:13:18 also getting: 3935 work = n->poll(n, weight); Feb 07 20:13:28 on the stack, also in net/core.dev.c Feb 07 20:15:12 how do you figure out which modules are at what addresses? Feb 07 20:15:20 /proc/modules afair Feb 07 20:16:36 yup, just saw that. Feb 07 20:18:03 ethernet is via? Feb 07 20:18:55 no, ethernet is 8169cp on geos... Feb 07 20:18:58 ok, so: 8139cp 12164 0 - Live 0xe05cc000 Feb 07 20:19:20 which means that the address is +0x2501 Feb 07 20:19:54 try this in gdb: Feb 07 20:20:14 add-symbol-file .../8139cpo 0xe05cc000 Feb 07 20:20:19 (.o, not .ko!) Feb 07 20:20:39 then info line *(0x2501) Feb 07 20:20:52 or info line *(0xe05ce501) Feb 07 20:21:53 ko would probably work too Feb 07 20:25:46 Line 567 of "drivers/net/ethernet/realtek/8139cp.c" Feb 07 20:27:00 567 __napi_complete(napi); Feb 07 20:27:07 looks right Feb 07 20:27:28 well now I'd go on checking gitweb for recent changes around that place Feb 07 20:29:25 indeed Feb 07 20:29:32 there are three recent changes that look related Feb 07 20:29:36 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=history;f=drivers/net/ethernet/realtek/8139cp.c;h=abc79076f867baa5220361e0d6810d11e7edc8ef;hb=8597559a78e1cde158b999212bc9543682638eb1 Feb 07 20:29:52 and the most recent one from 2012-01-09 most likely fixes your issue Feb 07 20:30:11 as the BUG_ON() earlier involved gro_list I assume that "fix missing napi_gro_flush" solves it Feb 07 20:30:22 without having a deeper understanding of the api Feb 07 20:31:44 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=patch;h=b189e810619a676e6b931a942a3e8387f3d39c21 Feb 07 20:32:34 try putting that as target/linux/x86/patches-3.2/900-fix-missing-napi_gro_flush.patch into your build env and rebuild with make target/linux/{clean,compile} V=99 Feb 07 20:32:50 copy over the resulting *.ko and see if the error persists Feb 07 20:34:42 this is a kmod not built-in... Feb 07 20:35:15 target/linux/ is the right make target anyway Feb 07 20:35:17 don't I need to build the kmod target explicitly? Feb 07 20:35:25 package/kernel/ merely packages the previously compiled *.ko files Feb 07 20:36:14 target/linux/compile builds the modules Feb 07 20:36:22 target/linux/install builds the linux image Feb 07 20:36:45 package/kernel/compile creates the kmod-*.ipk packages Feb 07 20:39:52 ah... that's never been very clear to me. Feb 07 20:52:07 build #128 of lantiq is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/128 Feb 07 20:55:50 jow_laptop: it just blows out elsewhere in the same driver. Feb 07 20:57:00 in some irqflags.h inline I think. Feb 07 20:57:07 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blobdiff;f=drivers/net/ethernet/realtek/8139cp.c;h=886e6bec971a3ecaf6a44ed23813a6a7dd675a6a;hp=87cff10f7be7432c167d3c721a2ba5012cb605b5;hb=7d03f5a48e4d90854275b06433626243b3b3db17;hpb=0e22d0437e6dea36c867b08ceb224c1cc98a45ab Feb 07 20:57:28 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f872b237c1750221932e715da2552225afe4a95c Feb 07 21:04:47 starting to think that I might want to build geos against 3.2.5 stable instead... Feb 07 21:04:58 assuming these fixes made their way in. Feb 07 21:11:50 ok, just did a "make target/linux/prepare LINUX_VERSION=3.2.5" and all the patches applied, so I guess they didn't. :-( Feb 07 21:12:56 and with all 3 patches, I can still panic the $%^&* 8139cp driver. God, I hate that driver. Feb 07 21:13:53 is it still the driver panicing? Feb 07 21:21:03 yup. Feb 07 21:21:19 but a different place? Feb 07 21:26:00 I'll send another stack trace shortly... Feb 07 21:26:31 btw, we don't have anything like modinfo that maps a modules symbolic name back to its source path, do we? Feb 07 21:26:45 don't think so Feb 07 21:27:24 would be handy for generating a .gdbinit script with all of the paths and offset addresses already included. sigh. Feb 07 21:28:12 tried strings /lib/$(uname -r)/foo.ko ? Feb 07 21:28:25 no, I mean back to the source file name... Feb 07 21:28:29 yeah Feb 07 21:28:43 if your kernel was built with debug info I would assume the binaries to contain that Feb 07 21:28:49 modinfo xxx.ko | awk '/filename:/ { print $2; }' Feb 07 21:29:06 if there is a patch in the ko, strings will find it too Feb 07 21:29:08 no need for modinfo Feb 07 21:29:12 *path Feb 07 21:32:27 still need to get from the modules display name to its actual binary file name... (i.e. replace - with _, etc). Feb 07 21:36:03 simply replace all _ and - with [_\-] and let the shell globbing figure out the rest Feb 07 21:36:31 there's not going to be both a foo-bar.ko and a foo_bar.ko Feb 07 21:37:19 yeha I understand that one could just port module-init-tools but where's the fun in that Feb 07 21:37:37 besides that it is not a viable option for various targets Feb 07 21:54:29 jow * r30365 /branches/backfire/package/usbreset/: [backfire] usbreset: merge r29611 Feb 07 22:02:15 I like mit. Feb 07 22:02:17 oh, well. Feb 07 22:03:13 ok, rebooted... now I can't reproduce the problem.. huh... Feb 07 22:10:58 maybe the driver wasn't actually reloaded previously Feb 07 22:14:41 or I mangled rebuilding the image... Feb 07 22:15:20 do those patches apply without fuzz? Feb 07 22:17:08 didn't notice... what's the defuzzing command? Feb 07 22:18:22 make target/linux/refresh Feb 07 22:18:56 http://fpaste.org/57LX/ Feb 07 22:19:18 russell--: you test them by reverting them using patch -p1 -R in the build tree Feb 07 22:22:51 ok, reposting defuzzed... Feb 07 22:26:59 jow * r30366 /trunk/target/linux/x86/patches-3.2/ (6 files): Feb 07 22:26:59 8139cp: backport patches to make driver stable again Feb 07 22:26:59 List of patches that Jo-Philipp groveled out of git. Feb 07 22:26:59 Redux: defuzzed. Feb 07 22:26:59 Signed-off-by: Philip Prindeville Feb 07 22:27:19 thank you, sir! Feb 07 22:35:42 how is the best way to wait in the shell script until interface is not brought up? Feb 07 22:36:21 i could use something like this : while ! ifconfig "$interface" >/dev/null 2>&1; do Feb 07 22:36:36 found it in packages/net/quicktun/files/quicktun.init Feb 07 22:36:46 but i dont know if its the right approach Feb 07 22:37:08 i need it so i can change the mac address of the interface once it's brought up Feb 07 22:37:16 ideas? Feb 07 22:37:30 why change the mac address after it's brought up? Feb 07 22:37:54 its for br2684ctl Feb 07 22:38:12 i want the nas0 interface have specific mac address Feb 07 22:38:27 not the default 00:00:01:00:00:00 Feb 07 22:39:22 it messes up provisioning and i think that will behave badly when there is many users on the network Feb 07 22:41:22 jow * r30367 /packages/admin/syslog-ng/ (Makefile files/syslog-ng.init): Feb 07 22:41:22 [packages] syslog-ng: fix init script (based on patch by Lee Essen ) Feb 07 22:41:23 The syslog-ng start script doesn't stop syslog-ng because it tries to Feb 07 22:41:23 use pid's instead of the executable name. Very simple patch attached. Feb 07 22:41:53 luka12345: you don't need to change anything in the scripts then Feb 07 22:42:00 luka12345: just set the mac address in /etc/config/network Feb 07 22:43:59 in general, anything in the boot path that has to wait for something to happen is usually a mistake Feb 07 22:44:01 I think this is difficult (with the legacy scripts) if nas0 is part of a bridge Feb 07 22:44:14 jow_laptop: in that case you can just set the address for the bridge Feb 07 22:44:24 jow_laptop: which should have pretty much the same effect for provisioning Feb 07 22:45:50 jow * r30368 /branches/packages_10.03.2/admin/syslog-ng/ (Makefile files/syslog-ng.init): [packages_10.03.2] syslog-ng: merge r30367 Feb 07 22:46:23 i dont think setting mac in /etc/config/network will work Feb 07 22:46:33 its this script i'm working on Feb 07 22:46:34 http://pastebin.com/x6hbBAQY Feb 07 22:46:49 I thought the bridge inherited the address of the first device added to it. Feb 07 22:47:02 but why would you want to bridge over DSL? Feb 07 22:47:25 nbd: it's for this part of the network config: http://pastebin.com/qZTUDAP9 Feb 07 22:47:28 or rather, why would you want to bridge your LAN networks with a DSL connection? Feb 07 22:47:53 philipp64|laptop: I mixed it up because another user asked for a bridge mode in the forum today Feb 07 22:48:43 ah. Feb 07 22:48:50 i'm looking if i could batch c code to set the mac there as a argument Feb 07 22:49:16 I thought it handled that already? Feb 07 22:50:00 config 'interface' 'wan' Feb 07 22:50:11 luka12345: the point is that you should have another ordinary config interface covering the nas0 Feb 07 22:50:13 option 'macaddr' x:x:x:x:x:x Feb 07 22:50:23 luka12345: that would hold the macaddr option Feb 07 22:51:30 jow_laptop: could you show me example for that please? Feb 07 22:52:24 config interface whatever; option proto pppoe; option ifname nas0; option username xyz; option password xyz; option mac 11:22:33:44:55:66 Feb 07 22:53:00 i see Feb 07 22:53:03 let me try Feb 07 22:53:16 but I believe you still have a point, I'm unsure whether ppp(oe).sh actually handles macaddr Feb 07 22:53:36 or whether that was generic in prepare_interface Feb 07 22:53:39 just try Feb 07 22:56:09 it's not working Feb 07 22:56:41 i think that the best way is to patch br2684ctl.c to accempt mac as a argument Feb 07 22:56:41 does it work if you set the proto to dhcp (I know, makes no sense, just for testing here) Feb 07 22:56:53 i have tested it with dhcp Feb 07 22:57:08 and i need it with both dhcp and ppp Feb 07 22:57:31 I tend to agree with patching br2684ctl Feb 07 22:57:37 ok Feb 07 22:57:49 i'll start cooking it now Feb 07 22:57:58 but ideally I'd like to see mac handling in a generic way Feb 07 22:58:10 we cannot patch each software package spawning an iface in the long run Feb 07 22:58:43 what would you suggest? a library? Feb 07 22:59:09 netifd has proper mac handling built in Feb 07 22:59:21 no, ideally hotplug would see a network device add event (nas0 appears) and apply the settings from the matching /etc/config/network section to it Feb 07 22:59:26 you can create a config device section for any ethernet device Feb 07 22:59:38 regardless of how it's assigned to one or more config interface sections Feb 07 22:59:46 that was also the original idea of the legacy scripts but it fails for various combinations due to implementaiton weaknesses Feb 07 23:00:07 yeah, in netifd it works already Feb 07 23:00:16 because with its structure it was very easy to support Feb 07 23:00:36 yay, config device Feb 07 23:00:57 nbd: any pointers where should i look inside netifd to put this functionalty? Feb 07 23:01:44 what functionality? Feb 07 23:01:51 setting mac addresses for devices is already supported Feb 07 23:02:18 as for the atm-bridge stuff, let's leave that as a shell implementation until netifd is made default Feb 07 23:02:27 luka12345: config device foo; option ifname nas0; option macaddr ... Feb 07 23:02:39 must config device be named? Feb 07 23:04:20 option name, not option ifname Feb 07 23:04:30 no, wait, ifname Feb 07 23:04:41 too many open windows again ;) Feb 07 23:04:46 I inferred it from device.c Feb 07 23:04:49 yeah Feb 07 23:05:05 it's correct, i just worked on another piece of code that had name/ifname in it ;) Feb 07 23:05:05 is type mandatory? Feb 07 23:05:08 no Feb 07 23:05:34 and the section can be anonymous? Feb 07 23:05:37 yes Feb 07 23:05:41 ok Feb 07 23:06:30 well i tested it with netifd Feb 07 23:06:34 this is my config Feb 07 23:06:35 http://pastebin.com/JYtvgfxv Feb 07 23:06:44 i have rebooted the router just to be safe Feb 07 23:07:17 option macaddr instead of option mac Feb 07 23:07:39 ah :) Feb 07 23:09:50 yes it worked Feb 07 23:09:56 but i think it has a bug Feb 07 23:10:00 1sec Feb 07 23:10:24 http://pastebin.com/ZMjkkCVz Feb 07 23:10:37 you can see that only last nas interface got the correct mac Feb 07 23:11:08 let me double check Feb 07 23:13:57 a mac address starting with BB: makes no sense Feb 07 23:14:22 notice how that has the multicast bit set? ;) Feb 07 23:18:54 yes, that might be the issue Feb 07 23:19:34 let me build a clean image and try again, i have messed with init script on this one Feb 07 23:27:25 nbd: roger, will do. Feb 07 23:31:58 nbd: am i doing something wrong again: http://pastebin.com/mRmvM01g Feb 07 23:33:15 the dsl cable is not connected, i dont know if that makes a difference? Feb 07 23:35:40 you could try setting the mac address in the device section as i suggested earlier Feb 07 23:50:46 nbd: no luck: http://pastebin.com/MShEEDFR Feb 07 23:50:59 is at least the configuration correct? Feb 07 23:51:08 no Feb 07 23:51:17 there's a difference between an 'interface' and a 'device' Feb 07 23:51:31 a 'device' configures low-level settings such as mac address, mtu, etc. Feb 07 23:51:43 an 'interface' configures stuff like dhcp, ppp, ip addresses, etc. Feb 07 23:51:51 the device section should not have a name Feb 07 23:52:04 it should have the 'ifname' option to refer to exactly *one* device Feb 07 23:54:03 if i understand correctly this is how it should be done: http://pastebin.com/XRyxr7rU Feb 07 23:54:43 yes Feb 08 00:02:37 nbd: i'm still not getting any success: http://pastebin.com/6rzw7seK Feb 08 00:03:34 did you try rebooting or restarting netifd? Feb 08 00:03:49 yes i have rebooted the box Feb 08 00:03:54 hm, odd Feb 08 00:07:22 netifd is running, it did not crash... Feb 08 00:22:40 i'll look at it tomorrow Feb 08 00:22:46 ok Feb 08 00:22:56 if i can help let me know **** ENDING LOGGING AT Wed Feb 08 02:59:57 2012