**** BEGIN LOGGING AT Mon Apr 30 02:59:58 2012 Apr 30 04:49:33 oh finally figured it out after debugging udev Apr 30 04:49:50 the updated driver switched classes from firmware to compat_firmware Apr 30 04:49:59 so i added the rule and script from the compat-wireless source Apr 30 04:50:00 :-] Apr 30 05:06:40 I want to rearrange a ar71xx board's lan and wan ports.Don't know how. Apr 30 05:07:24 https://lists.openwrt.org/pipermail/openwrt-devel/2012-April/015162.html Apr 30 05:08:39 http://postimage.org/image/fhynzvipd/ Apr 30 07:57:12 nbd * r31539 /trunk/package/mac80211/patches/300-pending_work.patch: mac80211: fix station lookup issues Apr 30 08:20:38 nbd * r31540 /trunk/package/mac80211/patches/300-pending_work.patch: ath9k: merge a ar93xx ht40 performance fix Apr 30 08:38:13 juhosg * r31541 /trunk/ (24 files in 18 dirs): kernel: update linux 3.3 to 3.3.4 Apr 30 09:22:36 build #4 of adm5120 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/4 Apr 30 09:23:26 <||> I merged your branches into my openwrt, packages and luci repos and gave it a Apr 30 09:23:26 <||> try over the past 24 hours running on a ath9k-based router. Apr 30 09:23:26 <||> Results: very nice. This should go uptream. Apr 30 09:23:41 * dwmw2 looks at jow_laptop :) Apr 30 09:27:34 dwmw2: about your kernel header change - does it really have to run the header install stuff every time the kernel tree gets built? Apr 30 09:31:07 whats the deal with ppp and ppp-multilink? Apr 30 09:31:18 is the multilink so big that it requires a dedicated package? Apr 30 09:32:14 seems like ~13K Apr 30 09:32:28 13k compressed Apr 30 09:32:32 yes Apr 30 09:33:07 i think it's enough to justify having a separate package, especially because multilink is rarely used and ppp is in the default image Apr 30 09:33:45 nbd: theoretically no, because the kernel<->user ABI shouldn't really change that often anyway. Apr 30 09:33:53 but we carry that netfilter layer7 patch... Apr 30 09:34:12 otherwise I'd have used the copy that we already export for the toolchain Apr 30 09:34:18 I thought we nuked l67 Apr 30 09:34:20 *l7 Apr 30 09:34:36 well, it was still there when I did the headers_install thing last week Apr 30 09:35:00 iptables failed to build after I switched to properly-exported headers, until I fixed the l7 patch to add its new header to the Kbuild file to be exported Apr 30 09:35:26 if it's still there, we should just nuke it Apr 30 09:35:33 it's practically unusable for anything serious anyway Apr 30 09:35:36 because of horrible memleaks Apr 30 09:35:48 in that case, we could probably use the kernel headers that the toolchain gets. Apr 30 09:35:59 ok Apr 30 09:36:03 hm Apr 30 09:36:05 those should be recent-ish, right? Apr 30 09:36:19 they're built from the same kernel version as the target that the toolchain was built with Apr 30 09:36:21 we don't redo the toolchain if a new kernel is built Apr 30 09:36:24 including generic patches Apr 30 09:36:35 if I were to update my kernel and iptables, and a new netfilter module is added upstream (something sane, not layer7) Apr 30 09:36:46 then using the toolchain's headers wouldn't pick that up, right? Apr 30 09:37:03 exporting headers is *quick*, so there's not really any harm in doing it each time the kernel is built. Apr 30 09:37:21 i think exporting headers should be done after unpacking/patching the kernel Apr 30 09:37:24 not each time it is built Apr 30 09:37:35 that makes sense. Apr 30 09:37:53 I don't know my way around the makefiles very well; I was surprised enough that I made it work at all :) Apr 30 09:37:57 :) Apr 30 09:37:59 feel free to move it to somewhere more appropriate Apr 30 09:38:32 re ppp-multilink: we *can't* use that on adsl lines sanely. It expects the lines to be in sync. Apr 30 09:38:57 which is why I'm doing bonding using teql ;) Apr 30 09:39:24 as for pptp, i'll try to get all the missing pieces for netifd in this week Apr 30 09:39:29 and then the old scripts will go away Apr 30 09:39:43 ok. So making that work for l2tp too should be fairly simple Apr 30 09:39:45 just need to find a clean way to integrate the route-to-pptp-server stuff Apr 30 09:39:57 you saw that's broken at the moment, right? Apr 30 09:39:58 nbd: regarding route-to-gw Apr 30 09:39:59 and my fix? Apr 30 09:40:07 ... which requires /sbin/ip Apr 30 09:40:21 nbd: for dhcp we should first install host routes to the gw, then install the default route Apr 30 09:40:23 after i'm done it won't require /sbin/ip anymore Apr 30 09:40:38 but you saw the brokenness and the fix? Apr 30 09:40:41 yes Apr 30 09:40:46 ok, just checking. Apr 30 09:41:08 jow_laptop: why the host route to the gw? Apr 30 09:41:25 nbd: because there are isps out there who advertise gateways outside of the assigned prefix Apr 30 09:41:34 and the host route fixes that? Apr 30 09:41:39 adding a default route to them will fail unless a host route is installed first Apr 30 09:42:12 wow, does that actually work with *any* client? Apr 30 09:42:36 dwmw2: apparently yes Apr 30 09:42:44 shouldn't it be enough to specify the device for the default route? Apr 30 09:42:48 see the discussions here: https://forum.openwrt.org/viewtopic.php?id=29973 Apr 30 09:42:54 netifd already does that, iirc Apr 30 09:43:09 hm Apr 30 09:43:12 odd Apr 30 09:48:13 I didn't implement the fix mentioned in the forum yet because state tracking gets hairy with the scripts (specirfically the garbage collection of stale host routes) Apr 30 09:48:31 leave it out for the legacy scripts Apr 30 09:48:34 in netifd it's easy to add Apr 30 09:48:40 thats what I figured Apr 30 09:48:50 something entirely different Apr 30 09:49:06 is there a way to enumerate available procedure calls via ubus cli? Apr 30 09:49:23 ubus -v list Apr 30 09:49:27 I found "ubus call network.interface.foo status" by accident Apr 30 09:49:33 ah -v Apr 30 09:49:56 great Apr 30 09:50:13 for luci we should probably add a lua binding soon Apr 30 09:50:18 so you don't have to parse cli outout Apr 30 09:50:22 yeah, I started looking into it Apr 30 09:50:27 ah, cool Apr 30 09:50:30 will do a libubus-lua Apr 30 09:50:39 or something like that Apr 30 09:50:55 jow_laptop: pptp uses 'serv_addrs' for that... Apr 30 09:51:02 (for remembering the host routes it's set up) Apr 30 09:51:14 theoretically lua table structures should be suitable for easy conversion to/from blobmsg data Apr 30 09:51:42 nbd: yep, theoretically the json output could be used as-is when substituting colons with equal signs Apr 30 09:51:55 so its possible to map it to lua Apr 30 09:51:55 are the escaping rules the same? Apr 30 09:51:59 mostly Apr 30 09:52:17 but I don't want to "eval" from an external source, I'd rather parse and filter it in C Apr 30 09:52:17 the direct approach would probably be less hackish though Apr 30 09:52:31 then pass it to Lua Apr 30 09:52:46 i think parsing/filtering strings that way is a bit messy Apr 30 09:52:53 tables are still somewhat expensive so it makes sense to filter at the source to avoid creating garbage Apr 30 09:53:19 "filter" in the sense of not e.g. dumping a whole subtree just because I want a rx counter Apr 30 09:54:26 anyway, once I start adding netifd bindings I want to remove old stuff at the same time, so openwrt needs to make this default first Apr 30 09:54:32 you could keep blobmsg data as userdata with a metatable Apr 30 09:54:37 and implement a get_single op Apr 30 09:54:50 that way you can avoid the table overhead Apr 30 09:54:58 yes, good idea Apr 30 09:57:50 i think i know how i'll handle vpn server routes Apr 30 09:58:04 i'll make the proto script call a notifier telling netifd to 'claim' a route to a host Apr 30 09:58:13 internally that'll create a static route in a separate list Apr 30 09:58:24 bind it to the interface that provided the route Apr 30 09:58:31 so it works as a trigger at the same time Apr 30 09:58:46 when the interface that provided the route goes down, it can trigger a reconnect on the vpn interface Apr 30 09:59:01 (optionally) Apr 30 10:37:53 net/ipv4/tcp.c: In function 'tcp_gro_receive': Apr 30 10:37:53 net/ipv4/tcp.c:2837:82: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses] Apr 30 10:37:59 * dwmw2 bets that came from the alignment patch Apr 30 10:42:29 - tcp_flag_word(th2) |= flags & (TCP_FLAG_FIN | TCP_FLAG_PSH); Apr 30 10:42:29 + tcp_flag_word2(th2) = tcp_flag_word(th2) | flags & (TCP_FLAG_FIN | TCP_FLAG_PSH); Apr 30 10:42:29 Apr 30 10:42:31 eww :) Apr 30 12:35:46 writing uci-defaults scripts, is it fair to assume that the ucitrack file will always exist? even if the section for any given app might not? Apr 30 12:41:43 ucitrack only exists if luci-lib-core is installed Apr 30 12:52:57 opkg upgrade `opkg list-upgradable | grep -v kmod | grep -v Multiple | cut -f1 -d\ ` Apr 30 12:53:02 there has to be a better way of doing that, surely? Apr 30 12:53:07 what am I missing? Apr 30 12:53:21 (please don't tell me to use awk :) Apr 30 12:53:42 * check_data_file_clashes: Package blkid wants to install file /sbin/blkid Apr 30 12:53:42 But that file is already provided by package * busybox Apr 30 12:55:16 yes, a better way of doing that is patching opkg do not list held back packages in list-upgradable Apr 30 12:55:25 I do not like the "hold" behaviour anyway Apr 30 12:55:33 it still allows downgrades Apr 30 12:55:40 that was going to be my next question :) Apr 30 12:55:57 I'm guessing that sed s/hold// -i /var/lib/opkg/status Apr 30 12:56:03 in order to let me update all the kmod packages Apr 30 12:56:09 is not the approved way of doing things :) Apr 30 12:56:21 no it isn't Apr 30 12:56:38 we do not support inplace upgrades Apr 30 12:56:51 your platform is special so the hackery works Apr 30 13:04:45 hm, blkid upgrade is moving it from /usr/sbin to /sbin where busybox already has a symlink for it. Apr 30 13:04:59 we don't enable blkid by default afaik Apr 30 13:06:53 hm, BUSYBOX_CONFIG_BLKID is still on in my config. Apr 30 13:06:55 * dwmw2 turns it off Apr 30 13:07:29 though it is quite unuusual for a non-busybox package to put stuff outside of /usr Apr 30 13:07:53 it used to be in /usr/sbin, but a recent upgrade moved it. Apr 30 13:08:59 I know Apr 30 13:12:58 hm, is there a way to reinstall something like busybox that I *don't* want to remove and then reinstall? Should I artificially bump its release number and rebuild? Apr 30 13:13:45 I've done that once. Apr 30 13:13:47 opkg install --force-reinstall --force-removal-of-essential-packages busybox Apr 30 13:13:51 is that likely to actually work? Apr 30 13:14:00 * dwmw2 wonders where his USB CF card reader is :) Apr 30 13:14:03 dwmw2: yes, but do it with the file already in /tmp Apr 30 13:14:11 the new package? Apr 30 13:14:22 because wget is gone briefly Apr 30 13:14:28 yes with the new ipk Apr 30 13:14:44 opkg install --force-reinstall --force-removal-of-essential-packages /tmp/busybox_foo.ipk Apr 30 13:15:10 * check_data_file_clashes: Package busybox wants to install file /sbin/ifconfig Apr 30 13:15:10 But that file is already provided by package * h_{ _{ _{ ! Apr 30 13:15:10 * check_data_file_clashes: Package busybox wants to install file /sbin/mkswap Apr 30 13:15:10 But that file is already provided by package * swap-utils Apr 30 13:15:10 * opkg_install_cmd: Cannot install package busybox. Apr 30 13:15:12 that went well Apr 30 13:15:19 --force-overwrite Apr 30 13:15:39 should I be scared about the package name that allegedly provides those? :) Apr 30 13:15:48 *shrug* Apr 30 13:15:58 as I said we do not support inplace upgrades, now you see why :) Apr 30 13:16:04 heh Apr 30 13:16:20 hey, if you pull my git trees then I can easily do a complete reinstall and just restore my configuration :) Apr 30 13:16:23 opkg is no apt and it often faisl hard at upgrade tasks Apr 30 13:16:54 sysupgrade -n! don't even try and upgrade :) Apr 30 13:17:04 sysupgrade doesn't work on block storage. Apr 30 13:17:16 I'll probably have no time to do anything on openwrt in the next two or three days Apr 30 13:17:23 that's being worked on though isn't it? Apr 30 13:17:31 jow_laptop: http://david.woodhou.se/authorized_keys :) Apr 30 13:17:42 karlp: it's being talked about. Not sure it's the same thing :) Apr 30 13:17:48 I do not decide commit access Apr 30 13:18:21 dwmw2: are you actually swedish, or was that just a convenient domain? Apr 30 13:19:12 karlp: the latter Apr 30 14:28:39 build #8 of s3c24xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/8 Apr 30 15:39:55 * dwmw2 now running 3.3.4 on his router Apr 30 18:23:54 nbd * r31542 /trunk/package/relayd/ (Makefile files/relay.hotplug files/relay.init files/relay.sh): relayd: use an init script instead of a legacy network proto handler (fixes #11276) Apr 30 18:23:58 nbd * r31543 /trunk/package/base-files-network/files/lib/network/config.sh: base-files-network: add a fixup_interface function like with the netifd compatibility scripts - allows selective fixup of individual interface sections instead of having to do the full scan_interfaces Apr 30 18:24:01 nbd * r31544 /trunk/package/relayd/files/relay.init: relayd: use config_load+fixup_interface instead of scan_interfaces to speed up startup time Apr 30 18:27:13 nbd * r31545 /trunk/package/relayd/files/relay.init: relayd: move the interface fixup to the right place Apr 30 18:31:15 build #6 of ppc40x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/6 Apr 30 19:21:40 dwmw2: I thought we'd already agreed that the ipv4/v6 code wasn't acceptable for devices were it wasn't needed? Apr 30 19:22:37 karlp: que? Apr 30 19:23:39 btw. i expect the performance hit for the unaligned load/store stuff to be fairly minor Apr 30 19:23:59 on most devices, bus traffic is the big bottleneck anyway Apr 30 19:24:01 nbd: if we do the headers_install after unpacking/patching the kernel, we end up patching it into various different Kernel/Prepare/Default macros depending on where the kernel comes from Apr 30 19:24:10 but there's only one Kernel/Configure/Default, afaict. Apr 30 19:24:45 nbd: bus traffic delays might be exacerbated by byte-by-byte loads. Apr 30 19:25:17 typically the cache takes care of the extra loads Apr 30 19:25:22 just look at the silly hoops we're trying jump through to do 64-bit loads from the solos card on geos, for example. Because PCI transaction setup and completion, for a single 32-bit read, are a lot of overhead. Apr 30 19:25:25 now do it for each byte :) Apr 30 19:25:34 as long as it's cached, that's OK Apr 30 19:25:42 anything network stack related operates on cached memory Apr 30 19:25:48 yeah Apr 30 19:25:54 this is all far above the level of the driver itself. Apr 30 19:40:36 build #6 of ppc44x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/6 May 01 00:41:25 * m4t is trying to cross compile crda May 01 00:41:32 and i got it to build... May 01 00:41:36 but it just segfaults :( May 01 00:48:20 humm May 01 00:48:26 objdump shows a different architecture May 01 00:48:34 :o May 01 00:49:57 0x00000150 is my crda, 0x00000112 is the rest of binaries on rootfs May 01 00:57:17 duh --shared was a bad idea May 01 00:57:38 even though i specified the exact library path with -L, it wasnt seeing the so's there May 01 00:58:18 ld suggests --rpath and --rpath-link, but it doesnt seem to have an effect May 01 01:01:32 nvm, figured it out, because i overrode pkg-config it wasnt adding -lnl and -lgpg-error automatically **** ENDING LOGGING AT Tue May 01 03:00:01 2012