**** BEGIN LOGGING AT Thu Mar 12 02:59:58 2015 **** BEGIN LOGGING AT Thu Mar 12 05:03:11 2015 Mar 12 06:22:08 build #230 of ar71xx.mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/230 **** BEGIN LOGGING AT Thu Mar 12 07:25:15 2015 Mar 12 07:58:50 build #871 of uml is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/871 Mar 12 08:47:25 build #909 of at91 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/909 Mar 12 10:01:18 hmm, some kind of ath5k problem? Mar 12 10:02:16 i'm getting "[ 13.393144] cfg80211: Unknown symbol get_net_ns_by_fd (err 0)" during boot on r44685. r44597 was okay. Mar 12 10:03:03 (and no wlan iface's with the same .config with kmod-ath5k selected) Mar 12 10:04:51 * russell-- rebuilds kernel Mar 12 10:05:32 anychance we could change the topic to refer to 14.07 now? Mar 12 10:06:12 blogic r44686 trunk/target/linux/cobalt/modules.mk * cobalt: framebuffer device has moved Mar 12 10:06:17 blogic r44687 trunk/package/kernel/acx-mac80211/Makefile * acx-mac80211: fails to build on cobalt Mar 12 10:06:25 blogic r44688 trunk/package/kernel/linux/modules/usb.mk * modules: set dwc2 gadget dependency for at91 Mar 12 10:06:32 blogic r44689 trunk/package/network/services/lldpd/files/lldpd.init * lldpd: add support for 'readonly_mode' Mar 12 10:06:42 blogic r44690 trunk/target/linux/ ramips/patches-3.14/0111-i2c-MIPS-add-mt7621-I2C-driver.patch ramips/modules.mk * ralink: MT7621 add i2c controller driver Mar 12 10:06:57 blogic r44691 trunk/target/linux/ramips/dts/FIREWRT.dts * ralink: resize the flash partition for FireWRT Mar 12 10:07:06 blogic r44692 trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-hornet-ub.c * ar71xx: Hornet UB GPIO WPS/Reset Mar 12 10:07:18 blogic r44693 trunk/target/linux/ar71xx/files/arch/mips/ath79/ mach-hornet-ub.c mach-tube2h.c * ar71xx: Ext LNA patch for TUBE2H and HORNET-UB targets Mar 12 10:07:25 blogic r44694 trunk/toolchain/uClibc/patches-0.9.33.2/470-powerpc_syscall6.patch * uClibc: fix syscall() for syscalls with 6 arguments on PowerPC Mar 12 10:10:04 ah, that seems to have helped Mar 12 13:58:22 nbd: ping Mar 12 13:58:32 bforbes: pong Mar 12 13:58:54 nbd: I saw you landed most of the patches... thanks! Mar 12 13:59:29 for iwinfo the nl80211 header sync is irrelevant Mar 12 13:59:38 oh, really? Mar 12 13:59:39 because it doesn't use the antenna gain attribute Mar 12 13:59:43 and the rest is ABI-stable Mar 12 13:59:51 same for hostapd Mar 12 14:00:03 ah, ok, that makes sense Mar 12 14:00:27 IIRC (this was about a month ago), I was running into issues because of the cryptoapi ports Mar 12 14:00:49 so I was trying everything and I refreshed the nl80211.h header everywhere that used it Mar 12 14:01:04 what you're saying makes sense, though Mar 12 14:02:07 nbd: is there anything else you need me to do? Mar 12 14:02:20 nope, everything seems to be fine at this point Mar 12 14:02:32 i will update hostapd to current git soon Mar 12 14:02:52 sweet Mar 12 14:03:33 nbd: this was a fun project :) Mar 12 14:04:10 :) Mar 12 14:04:24 thanks for your work on this, it saved me quite a bit of time Mar 12 14:04:36 it probably would have been easier had I known your tricks and how that script worked ;) Mar 12 14:04:55 nbd: no problem... it's nice to have a stable 5ghz radio! Mar 12 14:05:16 now, about those cryptoapi patches I reverted... Mar 12 14:05:43 i had the following idea in mind: Mar 12 14:06:26 in all the source files that use aead_* cryptoapi functions, return -EOPNOTSUPP before any of those calls (protected by an #ifdef) Mar 12 14:06:34 except for aes-ccmp Mar 12 14:06:53 is there a way we can make that optional? Mar 12 14:06:57 in that one, replace the cryptoapi calls with equivalent code ported from the old stuff Mar 12 14:07:11 not sure if there's a simple way that will be acceptable upstream Mar 12 14:07:22 well, right Mar 12 14:07:34 for the aes-ccmp stuff there's probably no way to solve this in an upstream compatible way Mar 12 14:07:35 the #ifdef thing seems to be the easiest way Mar 12 14:07:47 right, I doubt we'll be able to solve this upstream Mar 12 14:07:54 and the other parts are simple if the code remains the same and only return statements are surrounded by an #ifdef Mar 12 14:08:06 so the compiler still compiles the cryptoapi calls, but the optimizer throws them out Mar 12 14:08:10 thus eliminating the dependency Mar 12 14:08:13 and making the patch small Mar 12 14:08:15 my concern is that using the kernel ccm module, the mac80211 stack didn't even work Mar 12 14:08:27 that's odd Mar 12 14:08:31 you're telling me Mar 12 14:08:42 I can make a patch of what I did Mar 12 14:08:42 maybe it's a backport related issue Mar 12 14:08:44 i don't know Mar 12 14:08:50 because i'm pretty sure there are people using that stuff Mar 12 14:09:06 e.g. ben greear's tests tend to use a lot of sw crypto Mar 12 14:09:22 since he makes excessive use of multi-sta-vif Mar 12 14:09:32 hmm, could be Mar 12 14:09:42 could it be a problem with the version of hostapd we have? Mar 12 14:10:21 i don't think so Mar 12 14:10:27 since there's no interaction between hostapd and cryptoapi Mar 12 14:10:31 now that we have a working stack with the latest wireless-testing, I should go back and try it with the kernel cryptoapi modules Mar 12 14:10:33 hostapd just uses normal nl80211 Mar 12 14:10:42 and that would affect cryptoapi and non-cryptoapi equally Mar 12 14:10:54 right, but if hostapd is sending something in a format that the cryptoapi isn't expecting? Mar 12 14:11:07 I'm just throwing out ideas Mar 12 14:11:09 keys are binary data Mar 12 14:11:21 there's no specific format that cryptoapi could be expecting Mar 12 14:11:22 yeah, that's a good point Mar 12 14:11:39 I'll make a build using the cryptoapi modules and get some logs Mar 12 14:11:41 and it's fixed-length stuff as well Mar 12 14:11:49 either way, for openwrt i don't care about cryptoapi Mar 12 14:11:53 i just want it out of the way Mar 12 14:11:56 I know you do Mar 12 14:12:09 but if we can make it optional, even just for openwrt, that'd be nice Mar 12 14:12:24 i don't see the point in allowing the use of it Mar 12 14:12:29 at least at this point Mar 12 14:12:40 because there's no real advantage to it Mar 12 14:12:46 aren't some of those ciphers better than others? Mar 12 14:13:03 those new ciphers aren't in real use yet Mar 12 14:13:10 (I'm showing my lack of complete understanding of wireless crypto) Mar 12 14:13:19 and even if you want to use them... there's no hw crypto for them Mar 12 14:13:27 so performance will suck Mar 12 14:14:17 that makes sense Mar 12 14:15:39 should we be preparing for the future, though? Mar 12 14:16:06 i expect it will take years until the new ciphers catch on Mar 12 14:16:24 ok Mar 12 14:16:25 they'll continue to be useless as long as hw doesn't support them Mar 12 14:16:32 understood Mar 12 14:16:53 and current hw is not flexible enough for stuff like that to be added via firmware or similar means Mar 12 14:16:55 well, I'm still curious as to why cryptoapi was failing Mar 12 14:17:30 it just doesn't make sense Mar 12 14:17:52 maybe just missing kernel modules Mar 12 14:18:03 e.g. aead loaded, but stuff missing for ccm Mar 12 14:18:16 perhaps... I thought I got it all Mar 12 14:18:21 something like that would show up as a runtime failure when connecting, and not as a module dependency Mar 12 14:19:08 yeah, I was getting a -2 file not found error Mar 12 14:19:31 I wonder if it was trying to load a module and couldn't find it Mar 12 14:20:27 do you have a list of modules that you had loaded? Mar 12 14:20:37 from back when you played with cryptoapi Mar 12 14:20:46 no, I don't think I do Mar 12 14:21:10 nope, I don't Mar 12 14:21:26 it would definitely need ccm.ko to be loaded Mar 12 14:21:29 I'll play with it and see what I can reproduce it Mar 12 14:21:33 yeah, I know that one was loaded Mar 12 14:21:42 for sure Mar 12 14:22:09 I'll recreated it and test it again tonight Mar 12 14:23:05 this is the output from hostapd -dd: https://gist.github.com/bryanforbes/1fd72b4b945653d5468f Mar 12 14:23:14 line 143 shows the error I was getting Mar 12 14:27:31 nbd: I'll investigate and see what I can come up with... mostly for my curiosity and not for anything that OpenWRT will use Mar 12 14:29:06 nbd: but it's really cool that you and jow_laptop and others helped me to get an update to mac80211 Mar 12 14:29:13 hopefully I can help in the future, too Mar 12 14:52:40 nbd: this might be a dumb question: is there a way to make the cryptoapi less bloated? :) Mar 12 14:59:03 i don't think so Mar 12 14:59:35 nbd: ok Mar 12 15:00:02 what is it about the cryptoapi ccm implementation that makes it more bloated than the one we revert to in mac80211? Mar 12 15:00:29 (I haven't looked at the differences between the two) Mar 12 15:01:36 its dependencies Mar 12 15:01:49 it requires aead (which pulls in more crap) Mar 12 15:02:14 does the one we revert to not do aead? (again, I'm not familiar with crypto ciphers) Mar 12 15:02:46 right Mar 12 15:02:51 it uses plain aes Mar 12 15:02:57 which has much fewer dependencies Mar 12 15:03:14 got it Mar 12 15:03:14 since it's a simple block cipher Mar 12 15:03:24 and is there hardware that will do AES + AEAD? Mar 12 15:05:22 you mean AES + CCM Mar 12 15:05:26 AEAD is just API foo Mar 12 15:05:28 yes Mar 12 15:05:57 there is one driver that does it Mar 12 15:06:31 wait, so what does aead give to the aes crypto module? just API? Mar 12 15:06:53 yes Mar 12 15:07:07 that seems... silly Mar 12 15:07:31 actually, aead isn't even the big part Mar 12 15:07:36 i just looked it up again Mar 12 15:07:39 ccm selects ctr Mar 12 15:07:53 and ctr selects seqiv + manager Mar 12 15:08:17 and manager selects aead, hash, pcomp Mar 12 15:08:27 a whole clusterfsck of bloat Mar 12 15:10:35 dang, you're right Mar 12 15:11:02 and right now (with the patch to revert), we're only bringing in aes, arc4, and core Mar 12 15:11:09 right Mar 12 15:11:35 why the heck is all of that required? Mar 12 15:11:51 well, cryptoapi looks like overengineered crap to me Mar 12 15:12:09 LOL Mar 12 15:12:42 it seems like it brings in a lot of stuff that not all ciphers would need Mar 12 15:12:44 people in the desktop/server linux world simply don't give a damn about code bloat as long as it stays out of the hot path Mar 12 15:13:35 and i don't see any way for us to make them care Mar 12 15:16:06 nbd: hmmm, it looks like some of the bloat of crypto-manager could be alleviated by setting CONFIG_CRYPTO_MANAGER_DISABLE_TESTS Mar 12 15:17:04 there are 4 things in the crypto Kconfig like this: select CRYPTO_AEAD2 if !CRYPTO_MANAGER_DISABLE_TESTS Mar 12 15:18:21 aead is required either way Mar 12 15:19:11 and aead only requires CRYPTO_AEAD2 and CRYPTO_ALGAPI, which are both selected by kmod-crypto-core Mar 12 15:19:35 yes, i agree, the bloat can be mitigated a bit Mar 12 15:20:01 (sorry, not trying to be contrary... I'm just trying to work this through in my mind) Mar 12 15:20:42 the dependencies could be reduced to aead, ccm, ctr, seqiv Mar 12 15:21:32 aead isn't a problem, since its dependencies are small and already included in what we include in kmod-crypto-core Mar 12 15:21:53 all 4 modules are somewhat small Mar 12 15:22:17 but combined, it probably still eats up a few kilobytes after lzma Mar 12 15:23:21 the ctr dependency of ccm is what brings in a bunch of stuff Mar 12 15:23:33 yes Mar 12 15:23:41 seqiv and manager Mar 12 15:23:46 but we can mitigate the size of manager Mar 12 15:24:00 hm, seqiv pulls in rng as well Mar 12 15:24:07 yup Mar 12 15:24:12 the manager dependency can probably simply be removed Mar 12 15:24:18 i don't see any direct code dependencies Mar 12 15:24:23 me eithr Mar 12 15:28:10 nbd r44695 trunk/target/linux/generic/patches-3.18/ (25 files) * kernel: backport fib_trie improvements/fixes from 4.0-rc Mar 12 15:34:12 nbd: what the heck... ctr depends on manager in Kconfig, but I'm not seeing any (from a cursory look) places where manager is used... Mar 12 15:43:39 nbd: the only symbol exported from the manager module is alg_test Mar 12 15:44:56 nbd: and the only modules that use that function are tcrypt and drbg Mar 12 15:45:26 nbd: I'm quite baffled Mar 12 15:56:58 nbd: and I'm not sure where to direct my questions about it ;) Mar 12 16:17:26 exit Mar 12 16:17:27 quit Mar 12 16:17:29 quit Mar 12 16:17:31 q Mar 12 16:17:32 exit Mar 12 16:17:43 /quit Mar 12 16:22:17 nbd r44696 trunk/package/kernel/mac80211/patches/307-ath9k-fix-tracking-of-enabled-AP-beacons.patch * ath9k: fix a beacon enable handling bug Mar 12 16:32:31 nbd r44697 branches/barrier_breaker/package/kernel/mac80211/patches/300-pending_work.patch * ath9k: fix a beacon enable handling bug Mar 12 16:45:25 nbd: still around? Mar 12 16:46:14 yes Mar 12 16:47:23 what's the best way to select a default set of packages for build into a firmware image on top of the defaults for a certain platform? Mar 12 16:48:09 aside from manually going into menuconfig and selecting them Mar 12 16:48:19 you mean when creating a fresh config? Mar 12 16:49:11 yeah Mar 12 16:50:18 you could try putting the overrides into ~/.openwrt/defconfig Mar 12 16:50:44 i.e. the output of ./scripts/diffconfig.sh after selecting your packages (leaving out the platform part) Mar 12 16:51:04 wow, never new ~/.openwrt was used. Mar 12 16:51:08 the things you learn.... Mar 12 16:51:50 nbd: why would I leave out the platform part? Mar 12 16:54:22 i guess you can leave it in Mar 12 16:54:27 depends on if you want the platform to be preselected as well Mar 12 16:54:30 instead of just the packages Mar 12 16:54:46 ah, gotcha Mar 12 16:56:52 nbd: thank you! that works great! Mar 12 17:00:09 nbd: is there any advantage to switching which gcc is used to compile things? Mar 12 17:03:23 yes, you get to experience more interesting kinds of breakage ;) Mar 12 17:03:44 hah, ok then Mar 12 17:07:41 is there a way for a script to block until an interface is up? Mar 12 17:16:26 build #799 of kirkwood is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/799 Mar 12 19:28:47 build #832 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/832 Mar 12 19:50:30 blogic r44698 trunk/package/system/procd/Makefile * procd: bump to latest git HEAD Mar 12 19:50:38 blogic r44699 trunk/package/system/fstools/Makefile * fstools: bump to latest git HEAD Mar 12 19:51:08 blogic r44700 trunk/package/utils/busybox/patches/250-date-k-flag.patch * busybox: Minor fix for glibc 2.21 compatibility Mar 12 19:51:21 blogic r44701 trunk/ (49 files in 17 dirs) * toolchain: The glorious return of glibc, ver 2.21 Mar 12 19:52:16 blogic r44702 packages/ (5 files in 5 dirs) * global: change all instances of USE_EGLIBC to USE_GLIBC Mar 12 20:30:14 blogic r44703 trunk/toolchain/patches * glibc: remove accidentally commited folder Mar 12 20:30:22 blogic r44704 trunk/toolchain/Config.in * glibc: make it more obvious that eglibc is a version of glibc Mar 12 23:01:11 bforbes: no compile bustage w/ gcc 4.9-2015.02 on ar71xx, octeon, x86_64 w/ my limited packages, binutils 2.25.0-2015.01-2 otoh... Mar 12 23:01:45 swalker: what compile flags on ar71xx? Mar 12 23:03:56 bforbes: default w/ a mix of http://blog.oldcomputerjunk.net/tag/openwrt/'s and the committed hardening options Mar 12 23:04:49 close to head uClibc after fixing its patches Mar 12 23:06:06 swalker: interesting Mar 12 23:06:12 I'll have to read more of this later Mar 12 23:09:31 haven't tried to boot ar71xx on 4.0-rc3 on ar71xx iirc, the octeon revert (77f3ee59ee7cfe19e0ee48d9a990c7967fbfcbed) should be in the 4.0 release Mar 13 02:25:46 build #92 of arm64 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/arm64/builds/92 Mar 13 02:58:05 nbd r44705 trunk/target/linux/ (15 files in 2 dirs) * atheros: add v3.18 support Mar 13 02:58:15 nbd r44706 trunk/target/linux/ (12 files in 6 dirs) * atheros: v3.18: rename ATHEROS_AR231X symbol to ATH25 Mar 13 02:58:27 nbd r44707 trunk/target/linux/ (6 files) * atheros: v3.18: rename kernel platform to ath25 Mar 13 02:58:42 nbd r44708 trunk/target/linux/ atheros/patches-3.18/100-board.patch atheros/patches-3.18/210-reset_button.patch atheros/patches-3.18/110-ar2313_ethernet.patch atheros/patches-3.18/105-ar2315_pci.patch * atheros: v3.18: rename platform header Mar 13 02:58:49 nbd r44709 trunk/target/linux/atheros/patches-3.18/100-board.patch * atheros: v3.18: remove odd header reset.h Mar 13 02:59:03 nbd r44710 trunk/target/linux/ atheros/patches-3.18/103-ar2315_gpio.patch atheros/patches-3.18/100-board.patch atheros/patches-3.18/102-ar5312_gpio.patch atheros/patches-3.18/105-ar2315_pci.patch * atheros: v3.18: remove eth platform device unused field Mar 13 02:59:14 nbd r44711 trunk/target/linux/atheros/patches-3.18/100-board.patch * atheros: v3.18: cleanup cpu-feature-overrides.h Mar 13 02:59:22 nbd r44712 trunk/target/linux/ (6 files) * atheros: v3.18: update names and declarations Mar 13 02:59:34 nbd r44713 trunk/target/linux/ atheros/patches-3.18/103-ar2315_gpio.patch atheros/patches-3.18/100-board.patch atheros/patches-3.18/102-ar5312_gpio.patch atheros/patches-3.18/105-ar2315_pci.patch * atheros: v3.18: change calls logic Mar 13 02:59:43 nbd r44714 trunk/target/linux/ atheros/patches-3.18/100-board.patch atheros/patches-3.18/105-ar2315_pci.patch * atheros: v3.18: rearrange interrupt handling functions Mar 13 02:59:51 nbd r44715 trunk/target/linux/ atheros/patches-3.18/100-board.patch atheros/patches-3.18/105-ar2315_pci.patch * atheros: v3.18: rework early initialization **** ENDING LOGGING AT Fri Mar 13 02:59:59 2015