**** BEGIN LOGGING AT Thu Nov 14 02:59:59 2013 Nov 14 04:11:38 build #364 of kirkwood is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/364 Nov 14 10:14:20 build #441 of orion is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/441 Nov 14 11:24:33 hi Nov 14 11:24:59 nbd: hi, is the last fix okay or is any other change needed? Nov 14 11:59:07 tripolar: the description of the -s flag is a bit weird Nov 14 11:59:51 also, i'm not really sure about the implementation yet Nov 14 11:59:52 need to check Nov 14 12:00:24 nbd: tell me how you like it and i will do it to get it upstream :) Nov 14 12:01:33 i think in your code there's some confusion about what the jffs2count variable means Nov 14 12:01:38 you're writing something about partitions Nov 14 12:01:51 but the loop is not iterating over partitions Nov 14 12:01:55 it's iterating over erase blocks Nov 14 12:02:16 its more like finding the "deadc0de" marker Nov 14 12:02:48 so how should i call it? Nov 14 12:03:20 depending on the padding being done, it might find two markers in the same partition Nov 14 12:03:30 if eraseblocksize is 64k, but it's padded to 128k Nov 14 12:04:00 my original suggestion was to make it ignore the first n number of bytes or eraseblocks Nov 14 12:04:20 bytes is probably more convenient, since the eraseblock size depends on the flash chip Nov 14 12:06:08 okay so i call ignore the first bytes when appending the jff2 data, defaults to 1 Nov 14 12:06:42 okay so i call ignore the first n bytes when appending the jff2 data, defaults to 1 Nov 14 12:07:43 nbd one other question - i have a ap pro with some people connecting and i never stopped the wifi manually but i the logs i have this Nov 14 12:07:46 http://paste.debian.net/65804/ Nov 14 12:08:10 why is the wifi leaving promiscous mode after ~10h Nov 14 12:08:11 device wlan0-1 left promiscuous mode Nov 14 12:08:28 or is this normal Nov 14 12:09:31 when it's 'ignore the first n bytes' default should be 0 Nov 14 12:11:37 nbd "ignore the first n bytes when appending the jff2 data, defaults to 1" - wouldn't it be better to call it "ignore the first n JFFS2_EOF markers, defaults to 0" Nov 14 12:11:55 i don't want "ignore the first n JFFS2_EOF markers" Nov 14 12:11:58 because that's fragile Nov 14 12:12:18 as i said, different paddings vs. eraseblock sizes can mess it up Nov 14 12:12:48 nbd: but n bytes somehow sounds like - we are just using an offset - at least for me Nov 14 12:12:49 i'd like to pass -s Nov 14 12:12:51 not -s 2 Nov 14 12:13:02 okay Nov 14 12:13:07 now i understand Nov 14 12:13:54 i tried to do this in the beginning and use lseek (fd,0,SET_CUR) to get the current position Nov 14 12:14:08 but somehow something was wrong Nov 14 12:14:09 you don't need to call lseek at all Nov 14 12:14:21 how do i get the current position? Nov 14 12:14:23 the loop iterates over erase blocks Nov 14 12:14:29 it knows the size of an erase block Nov 14 12:14:35 you move the check outside of the memcmp() Nov 14 12:14:43 because it needs to cover the line after that memcmp() block as well Nov 14 12:14:48 the one that parses jffs2 data Nov 14 12:14:54 not just the EOF detection Nov 14 12:15:12 mtd must *completely* ignore any jffs2 data in the skip area Nov 14 12:15:21 at least for the sake of config append Nov 14 12:16:16 i had it at in if (jffs2file) { ... if (jffs2file && lseek ...) { Nov 14 12:18:21 nbd: but i ment how do i determine how much data got allready written/read - without lseek? Nov 14 12:19:53 looking into it at the moment Nov 14 12:22:43 tripolar: something like this: if (jffs2file && w > jffs2_skip_bytes) Nov 14 12:23:08 nbd r38801 trunk/package/kernel/mac80211/patches/ 502-ath9k_ahb_init.patch 530-ath9k_extra_leds.patch 300-pending_work.patch 550-ath9k_entropy_from_adc.patch * mac80211: merge a patch that enables DFS for ad-hoc mode Nov 14 12:23:12 nbd r38802 trunk/package/kernel/mac80211/patches/ 300-pending_work.patch 550-ath9k_entropy_from_adc.patch * ath9k: add a fix to improve reliability of high bitrates on AR93xx/AR95xx Nov 14 12:23:29 nbd: okay thanks Nov 14 12:24:09 nbd: but the question before is the output from dmesg - normal or is there someting wrong? Nov 14 12:24:12 http://paste.debian.net/65804/ Nov 14 12:30:10 what version is that? Nov 14 12:30:15 and what device? Nov 14 12:30:20 build #442 of orion is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/442 Nov 14 12:32:39 nbd AP Pro 38797 - trunk Nov 14 12:32:52 build #406 of rb532 is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/406 Nov 14 12:33:41 nbd: the users experience sometimes hangs (or get disconnected) as it seems it only happens when using 5gh Nov 14 12:34:02 i'd like to see the output of cat /sys/kernel/debug/ieee80211/phy1/ath9k/reset Nov 14 12:35:43 build #406 of ppc44x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/406 Nov 14 12:36:50 nbd: all 0 Nov 14 12:37:16 and this is after a few of those messages appeared? Nov 14 12:37:32 nbd: yes i think so Nov 14 12:37:48 i have to same problem sometimes here with the wndr3700 Nov 14 12:38:05 3800 Nov 14 12:38:14 but only with n Nov 14 12:39:07 ok Nov 14 12:41:39 nbd: anything i could try to capture? or look at when it happens? Nov 14 12:41:59 not at the moment Nov 14 12:42:47 nbd did you know about this problem? Nov 14 12:44:33 there are many different issues that look like this Nov 14 12:44:37 most of which i've fixed already Nov 14 12:45:07 i will try the lastest version - maybe it works better Nov 14 12:56:55 nbd I just want to say sorry for disturbing you when you were working on important things, on Sunday I think Nov 14 12:58:05 no problem, i had already forgotten that Nov 14 12:59:03 as a rule of thumb, i'd recommend only bugging individual people if you're reasonably certain that what you're asking concerns them directly in some way Nov 14 12:59:25 if that's not the case, it's better to ask questions on a list or in a channel indirectly Nov 14 13:01:01 got it, I was curious because, for me, you give lots of attention to atheros devices/chips, but specifically in this case you seemed not working on atheros at all Nov 14 13:01:29 I was like "is there something better, a new tendency perhaps, that is better than atheros?" Nov 14 13:01:41 i did work on the legacy atheros target many years ago Nov 14 13:01:52 but abandonened it for ar71xx Nov 14 13:03:15 is it correct to say that your target is ar71xx/9xxx? Nov 14 13:03:49 I don't know much, but I understood those as being atheros as well Nov 14 13:04:04 anyway, offtopic, better to talk about it some other time Nov 14 13:04:18 'atheros' is for ar231x/ar531x Nov 14 13:04:24 the old SoC before 802.11n came along Nov 14 13:04:33 80211a/g stuff Nov 14 13:04:49 * MartijnVdS has a few of those out "in the field" still :| Nov 14 13:05:17 ("We're not investing in new hardware during a big recession") Nov 14 13:06:14 oh, ok Nov 14 13:06:44 but who makes ar71xx/9xxx? isn't atheros as well? Nov 14 13:07:01 ? Nov 14 13:07:54 Devastator: the "atheros" target targets ar231x/ar531x, the "ar71xx" target is for newer devices, also made by atheros Nov 14 13:08:33 makes sense Nov 14 13:08:51 MartijnVdS thanks Nov 14 13:09:25 so, if I'm speaking about newer devices, I better call it ar71xx Nov 14 13:12:32 nbd: the patch i sent before worded nice, but now the device is just dead after sysupgrade - the image works okay when not using sysupgrade - http://paste.debian.net/65815/ Nov 14 13:13:15 jffs2_skip_bytes == 1572864d Nov 14 13:35:58 tripolar: what does 'device is just dead' mean? Nov 14 13:39:30 okay i added debug code Nov 14 13:39:45 it seems it doesnt find the endmarker with this offset Nov 14 13:40:41 nbd: i added this Nov 14 13:40:41 /* no EOF marker, make sure we figure out the last inode number Nov 14 13:40:44 * before appending some data */ Nov 14 13:40:47 + fprintf(stderr, "no EOF marker\n"); Nov 14 13:41:19 are you flashing squashfs or jffs2 images? Nov 14 13:41:25 squashfs Nov 14 13:41:46 openwrt-ar71xx-generic-ubnt-uap-pro-squashfs-sysupgrade.bin with sysupgrade Nov 14 13:41:47 it's normal for it to not find the EOF marker during the squashfs writes Nov 14 13:41:59 it should find the marker after the squashfs Nov 14 13:42:27 mtd_parse_jffs2data only finds valid data when flashing a jffs2 image Nov 14 13:42:34 it is unused for squashfs Nov 14 13:43:10 nbd: with the skip it found the marker Nov 14 13:43:25 so again: what does 'device is just dead' mean? Nov 14 13:43:34 it doesnt come up Nov 14 13:43:42 the light stays off all the time Nov 14 13:43:48 so you don't have a serial console? Nov 14 13:43:51 i have no serial console connected Nov 14 13:43:53 k Nov 14 13:44:00 i need a voltmeter to test the pins Nov 14 13:44:08 last time i kill a serial device ... Nov 14 13:44:51 i have one here, i will open the device and see what i will get Nov 14 13:47:14 nbd: what's the best way to find which pin is connected to tx,rx,gnd,vd? Nov 14 13:47:42 http://wiki.openwrt.org/doc/hardware/port.serial#digital.multimeter.method Nov 14 13:48:17 thanks Nov 14 14:00:38 jow_laptop: but i don't connect vcc or do i have to connect it? Nov 14 14:01:01 no Nov 14 14:01:13 only gnd rx tx Nov 14 14:12:41 nbd: the serial output Nov 14 14:12:42 http://paste.debian.net/65833/ Nov 14 14:14:20 seems the jffs is damaged Nov 14 14:20:31 the kernel is added as kernel0 Nov 14 14:20:36 but in the boot loader it's now looking for kernel1 Nov 14 14:21:00 please interrupt the boot loader and show me the output of printenv Nov 14 14:25:40 nbd: http://paste.debian.net/65837/ Nov 14 14:26:50 before loading the kernel Nov 14 14:26:50 http://paste.debian.net/65838/ Nov 14 14:26:55 @nbd Nov 14 14:27:07 or trying to load it ;) Nov 14 14:38:49 i think i found the error Nov 14 14:50:34 cyrusff: with BB r38631, my he.net tunnel seems to get the default route wrong. any known issues there ? Nov 14 14:51:08 ifstatus @ http://pastebin.com/WMv0ZJJf Nov 14 14:52:12 hmm, according to docs: option 'ip6prefix' '2001:DB8:1234:ABCD::/64' # Your routed prefix (required!) Nov 14 14:52:23 why is that required ? Nov 14 14:53:21 stintel: its usually required because if you sent traffic with an unknown source address it might simply get filtered out Nov 14 14:54:12 right, it's working now Nov 14 14:54:20 I had an IP on lan in the prefix Nov 14 14:54:28 guess it used that as default IP - and filtered out Nov 14 14:54:54 weird though, I'd expect it to use the IP on the tunnel iface Nov 14 15:16:43 nbd: it works only like this Nov 14 15:16:44 if (jffs2file) { Nov 14 15:16:44 - if (memcmp(buf, JFFS2_EOF, sizeof(JFFS2_EOF) - 1) == 0) { Nov 14 15:16:44 + if (w >= jffs2_skip_bytes && Nov 14 15:16:45 + memcmp(buf, JFFS2_EOF, sizeof(JFFS2_EOF) - 1) == 0) { Nov 14 15:17:08 i sent a new version of the patch to the ml Nov 14 15:40:04 is that pach really working? Nov 14 15:40:35 in default_do_upgrade() you quote $MTD_CONFIG_ARGS in the mtd command line Nov 14 15:41:12 yes Nov 14 15:41:15 which would cause "-s 0x180000" to be passed as one single parameter to mtd's argv[] Nov 14 15:41:27 optarg handles this fine Nov 14 15:41:41 it also allows -s0x180000 Nov 14 15:41:45 it might work yet because getopt is permissive but I guess it would fails once there is more than one flag in it Nov 14 15:42:08 i hear V4 calling ;) Nov 14 15:42:13 e.g. "-s 0x180000 -X foo" would get interpeted as "-s", "0x180000 -X foo" Nov 14 15:43:02 well, shell quoating rules can be a pita Nov 14 15:43:06 jow_laptop so i shouldn't quote $MTD_CONFIG_ARGS Nov 14 15:43:12 right Nov 14 15:43:24 jow_laptop yeah like the ${@:2} desaster :D Nov 14 15:51:27 nbd: do you plan on updating aa-mac80211.git with your latest changes ? Nov 14 15:52:30 yes, but i want to wait first for some more feedback from trunk users Nov 14 15:52:42 ok Nov 14 15:52:53 I'll try at home Nov 14 15:52:58 probably not tonight though Nov 14 15:53:57 tripolar: i think your change to move that w >= jffs2_skip_bytes into the inner if block is wrong Nov 14 15:55:18 nbd when i put it outside Nov 14 15:58:55 build #431 of ramips is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/431 Nov 14 16:00:39 the kernel doesnt come up Nov 14 16:00:43 if (jffs2file) { Nov 14 16:04:38 nbd i tried it outside and then i end up with the error from before i posted before Nov 14 16:40:21 tripolar: have you tested if that's reproducible? Nov 14 16:53:04 yes Nov 14 16:53:10 nbd yes Nov 14 16:53:21 i reflashed now with the latest mod without any problem Nov 14 16:53:31 lets say 10-15 times Nov 14 16:58:06 tripolar: the change is still wrong though Nov 14 16:58:15 why? Nov 14 16:58:32 because with your change, mtd still parses the jffs2 data from the kernel partition Nov 14 17:00:13 build #377 of sibyte is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/377 Nov 14 17:03:08 nbd so nbd it seems to be realted to last_ino and target_ino Nov 14 17:03:34 in jffs2 Nov 14 17:08:47 nbd any idea how i could avoid the parsing? without parsing uboot can't load the kernel Nov 14 17:14:53 the main problem is that the boot loader assumes that there's one big jffs2 covering the whole firmware area Nov 14 17:15:06 we need to find a way to trick the boot loader Nov 14 17:16:56 hm Nov 14 17:18:35 actually, there might be a way to trick u-boot Nov 14 17:27:51 i've taken a look at the jffs2 parsing functionality used in the u-boot version that this boot loader is based on Nov 14 17:28:17 the main issue is getting it to stop parsing the jffs2 at a certain point Nov 14 17:28:25 even though it wants to read the whole flash firmware area Nov 14 17:29:15 a way to do this would be to emit a fake jffs2 padding node Nov 14 17:29:37 with a bogus length that is longer than the firmware space Nov 14 17:29:47 the boot loader code has no sanity checking that would detect this ;) Nov 14 17:36:25 sounds really dirty Nov 14 17:36:31 is there no eof marker of some sort Nov 14 17:38:25 no Nov 14 17:38:47 the only exit condition for the jffs2 parser function is when offset >= max Nov 14 17:38:56 so we need to manipulate the offset Nov 14 17:40:10 i'm currently hacking up some code that generates this padding for me Nov 14 17:40:32 so we can add it as an option to padjffs2 Nov 14 17:45:23 but why is it working when i parde the jffs2 part from beggining? Nov 14 17:45:27 @nbd Nov 14 17:45:35 i mean within mtd Nov 14 17:46:31 juhosg r38803 trunk/package/base-files/ Makefile files/lib/functions.sh * base-files: add macaddr_canonicalize helper function Nov 14 17:48:07 parde/parse Nov 14 17:48:23 because of the inode cache in the boot loader Nov 14 17:48:43 if it doesn't parse the kernel, the inode number of the sysupgrade config tarball collides with the kernel image from the kernel partition Nov 14 17:48:48 at least from the boot loader's point of view Nov 14 17:48:55 ahh okay Nov 14 17:49:19 and we can't just ignore that issue, because it can show up again with just normal filesystem use Nov 14 17:49:30 as long as the boot loader still tries to scan that area Nov 14 17:49:40 okay Nov 14 17:49:42 the good thing about the hack that i'm building (if it works) is that it will also speed up boot time Nov 14 17:49:57 because the boot loader will not have to do any flash reads after the kernel part Nov 14 17:49:59 tripolar is the code you are messing openwrt specific? Nov 14 17:50:26 Devastator: i added some code to mtd and sysupgrade Nov 14 17:50:55 nbd why did ubiquity choose to use jffs2 for the kernel? Nov 14 17:51:00 somehow makes no sense to me Nov 14 17:51:42 nbd: when i code is ready to test ping me - i can test it Nov 14 17:52:03 it's a long shot but guys from mtd mailing list are really helpful Nov 14 17:52:55 Devastator the stuff i changed is openwrt specific and only effects one device by now Nov 14 17:53:21 I see.. Nov 14 18:04:09 Would be valid this example in AA for a Danube board with RTL8306 switch? Nov 14 18:04:11 https://forum.openwrt.org/viewtopic.php?pid=115181#p115181 Nov 14 18:04:44 build #432 of lantiq is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/432 Nov 14 18:05:34 tripolar: http://nbd.name/padjffs2-test.patch Nov 14 18:08:01 nbd: i rebuilding the whole image takes ~20min Nov 14 18:08:20 make tools/padjffs2/install target/install Nov 14 18:08:23 that should be faster Nov 14 18:08:24 ;) Nov 14 18:08:35 allready deleted staging_dir build_dir ;) Nov 14 18:09:06 why? ;) Nov 14 18:09:58 nbd becasue you type too slow ;) , i also moved the w >= part to the outer loop Nov 14 18:10:33 loop=if statement Nov 14 18:11:56 you don't need to delete stuff every time you change the code Nov 14 18:12:25 nbd when i changed base-files and mtd i allways did Nov 14 18:12:26 make package/{base-files,mtd}/clean Nov 14 18:12:28 before Nov 14 18:16:57 I do exactly like you, I'm afraid of false alarms (bugs) Nov 14 18:40:17 build #419 of uml is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/419 Nov 14 18:53:34 nbd: it works but i used it with my path together - should i try it without my patch? Nov 14 18:53:43 path=patch Nov 14 18:53:55 use it with the patch variant on the outer if() Nov 14 18:54:03 the one that was failing before Nov 14 18:54:06 yeah i did this Nov 14 18:54:10 ah, cool Nov 14 18:54:23 please show me what the boot loader prints when it loads the kernel Nov 14 18:54:25 should i send the whole patch again? Nov 14 18:54:36 no, i need to finish my padjffs2 changes first Nov 14 18:54:37 okay i have to open the device again Nov 14 18:55:23 it also boots a bit faster Nov 14 19:04:04 nbd: http://paste.debian.net/65889/ Nov 14 19:04:39 ah, great. no warnings introduced by my code Nov 14 19:05:25 nbd, that doesn't mean code is good, means compiler is confused :) Nov 14 19:05:54 groz: i meant runtime warning by the boot loade Nov 14 19:05:55 r Nov 14 19:06:03 ;) Nov 14 19:06:09 because of the evil hack that i made Nov 14 19:06:13 and even better it works :) Nov 14 19:06:15 hehe, and I'm being facetious after a week off, visiting with family Nov 14 19:06:32 nbd r38804 trunk/tools/padjffs2/src/padjffs2.c Nov 14 19:06:32 padjffs2: add a different kind of padding (using standard jffs2 elements) to work around broken boot loaders for kernel partitions Nov 14 19:06:33 had dad here at the new place for a week, so, I avoided my office most of the week Nov 14 19:06:36 nbd r38805 trunk/target/linux/ar71xx/image/Makefile Nov 14 19:06:36 ar71xx: use the new padjffs2 padding on Ubiquiti UAP-PRO to make the boot loader stop searching after the kernel partition Nov 14 19:06:57 groz: :) Nov 14 19:07:41 prepping for a 'fun' afternoon, new video card for the linux box is 'on the truck for delivery' according to canada post Nov 14 19:07:42 tripolar: now you can send a new patch Nov 14 19:08:04 okay Nov 14 19:08:14 so, plugging in a card with 4 displayport ports later today Nov 14 19:08:28 nice Nov 14 19:08:36 will see how well that can be made to work Nov 14 19:08:51 get a couple more big monitors, put both macs in 'target display' mode Nov 14 19:08:54 have you tried mac os 10.9 yet? Nov 14 19:09:06 no, I've been kinda busy, so avoided the upgrade button Nov 14 19:09:15 but, I did buy a new mac yesterday Nov 14 19:09:23 27 inch imac with i7 processor Nov 14 19:09:29 i'm really happy with the changes they made to 10.9 Nov 14 19:09:36 but it's christmas present for my nephw, I don't get to play with it Nov 14 19:09:39 they finally made multi-monitor work well ;) Nov 14 19:09:59 hmm, I've not had issues here with multi monitor, got a 19 inch plugged into the mac as second Nov 14 19:10:10 actually, it routes thru the kvm switch, plugs into 4 computers Nov 14 19:10:11 well, now you can have separate desktop switching for different monitors Nov 14 19:10:22 oh, really, that's interesting Nov 14 19:10:29 lol, multimonitor worked well on the mac as far back as 1987 Nov 14 19:11:00 DonkeyHotei: i'm talking about actual use, not just basic functionality Nov 14 19:11:17 for one of my projects, decided I really want 'big monitors' native on the linux box, so, ordered a video card for it, with cables to use the mac in target display mode Nov 14 19:11:38 if that works out well, gonna add more monitors, and end up with the ability to switch em all to mac, or all to the linux box Nov 14 19:11:50 by flipping macs into target display mode Nov 14 19:12:33 * groz wondering how well the linux drivers will deal with monitors that come and go Nov 14 19:12:35 time will tell Nov 14 19:13:13 whoooohooo, just did a fresh checkout, and see a cubieboard target in there Nov 14 19:13:21 been meaning to work on that for a while, but, never had time Nov 14 19:13:30 I haven't noticed that one before Nov 14 19:17:52 nbd r38806 trunk/target/linux/ramips/image/Makefile * ramips: use dd bs=4096k instead of bs=4M to make it more portable Nov 14 19:18:06 nbd: sent Nov 14 19:19:56 your patch includes an old version of my changes Nov 14 19:19:59 those need to be removed Nov 14 19:20:04 (since i've committed them already) Nov 14 19:21:53 ahh okay Nov 14 19:22:16 also, the patch syntax is this: Nov 14 19:22:29 [PATCH v4] ar71xx: fix Unifi AP Pro sysupgrade Nov 14 19:22:35 for the subject Nov 14 19:22:36 okay Nov 14 19:22:44 and in the body you start with the commit description Nov 14 19:22:54 and if you want to add a changelog, put a line with "---" before it Nov 14 19:23:04 okay Nov 14 19:23:08 that way i can use git am to apply the patch and it'll import it in a way that's suitable for committing Nov 14 19:23:10 nbd, got a dumb question on some of the support for ubiquity devices Nov 14 19:23:26 will current open source stuff work on the 900mhz radios ? Nov 14 19:23:29 yes Nov 14 19:23:38 it will pretend it's 2.4 ghz Nov 14 19:24:12 hmmm, ok, that's very interesting, I've been contemplating using 900mhz for the observatory link, after realizing we have to cross a creek to run fiber Nov 14 19:24:38 since the creek is designated 'fish bearing', need to have an environmental a$$essment done to get a permit Nov 14 19:24:59 something I just learned this last week Nov 14 19:25:24 apparently it's not cool to just dig a trench thru the creek, then backfill it Nov 14 19:25:38 stupid creek is just a small stream Nov 14 19:25:53 dries up in late summer Nov 14 19:27:25 nbd: sent Nov 14 19:29:10 nbd: and could you also apply the openssl patch i sent some time ago to the ml it adds ripemd/160 support and just add 5 kb to the openssl size Nov 14 19:29:26 i need it for the erlang update and id like to enable it in openssh Nov 14 19:30:46 k Nov 14 19:37:21 tripolar: is RIPEMD160 considered secure? Nov 14 19:38:31 the security of RIPEMD160 is comparable to sha1 Nov 14 19:38:46 which is slowly being retired Nov 14 19:39:14 Hauke: as it seems not Nov 14 19:39:39 at least erlangd needs it and removing it doesn't seem to be that trivial Nov 14 19:39:48 i only had a short look Nov 14 19:40:42 nbd r38807 trunk/ package/base-files/files/sbin/sysupgrade package/base-files/files/lib/upgrade/common.sh package/system/mtd/src/mtd.c target/linux/ar71xx/base-files/lib/upgrade/platform.sh * ar71xx: Unifi AP Pro sysupgrade patch Nov 14 19:40:56 tripolar: http://crypto.stackexchange.com/questions/957/ripemd-versus-sha-x-what-are-the-main-pros-and-cons contains a nice writeup Nov 14 19:41:14 tripolar: (re: enabling it for anything other than erlangd) Nov 14 19:42:22 I have a philosophy on that type of security stuff Nov 14 19:42:36 if you are really concerned about security over a connection, then the solution is simple Nov 14 19:42:44 don't plug the unit into a network connection Nov 14 19:42:50 :) Nov 14 19:43:00 and if you plug it into a network connection, just realize, at some point it WILL be penetrated Nov 14 19:43:05 no even better cut the power cord ;) Nov 14 19:43:06 only question is, when Nov 14 19:43:22 groz: sure, but there's a difference between offering people a false sense of security vs offering the "best currently known" set, at least as a default Nov 14 19:44:20 the amount of effort put into securing, should be relative to the value of the data being secured Nov 14 19:44:37 ie, if it's really important stuff, take it seriously Nov 14 19:44:50 groz: what do you think? exclude it and don't update erlang? Nov 14 19:45:04 i'm also not motivated to invest hours for this app i don't need Nov 14 19:45:12 tripolar, if you want erlang, decision is made for you Nov 14 19:45:21 groz: sure, but if it's something as simple as "only enable this potentially insecure bit for erlang" vs "enable it for ALL the things", I'd go with the "one thing" option Nov 14 19:45:21 if you don't want it , then, decision is easy Nov 14 19:45:32 i would upgrade it as it's completly outdated Nov 14 19:45:45 and enble an unsecure algo in openssl Nov 14 19:46:15 tripolar: *potentially Nov 14 19:46:25 MartijnVdS: when you want security you would have to disable any encryption below aes256 Nov 14 19:46:26 tripolar: OpenSSL also still has MD5 enabled, which is a lot scarier imho :) Nov 14 19:46:32 I kinda look at it this way, even the insecure ssh will befuddle the VAST majority of folks Nov 14 19:46:45 and, for the truly determined, and capable penetrator Nov 14 19:46:45 MartijnVdS: it's only scarry when the user enables it Nov 14 19:46:49 groz: until it hits the news Nov 14 19:46:53 doesn't matter what's there, they will get thru Nov 14 19:47:15 and maybe its fine when the traffic is just happening in the local lan - better encryption normally needs more cpu time Nov 14 19:47:54 MartijnVdS: like last time when the news stated that openwrt is unsecure allthough it was about bad user passwords :D Nov 14 19:48:06 tripolar: I'm nog saying you should (not) enable it, I'm just trying to make sure you know the implications of the choice :) Nov 14 19:48:17 news folks always get the facts wrong Nov 14 19:48:37 and usually have an 'expert' available to confirm those facts Nov 14 19:48:45 usually a 'self proclaimed' expert too Nov 14 19:48:50 groz: because they don't understand what they write about ;) - and have to pump the headline up to get some attention Nov 14 19:49:19 yes, and, they often need to juice articles a bit, to make them 'buzzword compliant' Nov 14 19:49:20 like little barging dogs ;) Nov 14 19:49:28 ie, the more buzzwords, the better it looks Nov 14 19:49:51 no different than sales folks want / need various buzzwords on the box, to sell product Nov 14 19:49:59 most of the time, they have no clue what the buzzword means Nov 14 19:50:28 in the router world, the biggest effort, most useless buzzword (my opinion) is SNMP Nov 14 19:50:37 gotta have it on the box, to sell to corps Nov 14 19:50:48 because purchasing department looks for that buzzword Nov 14 19:50:56 but, it department has no clue what it is, or how to use it Nov 14 19:51:09 they just want a pretty web interface Nov 14 19:51:36 groz: who doesn't though Nov 14 19:52:54 I had one client, delivering a high end process control system Nov 14 19:53:06 end customer was ADAMANT, needed snmp support Nov 14 19:53:15 client added snmp checkbox to web interface Nov 14 19:53:25 said 'supports it', put NO backing code behind it Nov 14 19:53:33 it's been deployed now for nigh on 6 years Nov 14 19:53:35 :) Nov 14 19:53:42 end customer still has not realized, that check box does nothing Nov 14 19:53:51 win Nov 14 19:53:53 :) Nov 14 19:54:36 Some day I may get a panic phone call, asking me to put simple snmpd on the box, overnight Nov 14 19:54:38 tripolar: what about reverting the commit that added ripemd160 to erlang ? Nov 14 19:54:46 but, some day has not arrived yet, not likely to ever arrive Nov 14 19:55:09 plntyk: i'f you are motivated to remove the support i will apply it :) Nov 14 20:01:10 build #387 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/387 Nov 14 20:34:24 nbd r38808 trunk/package/kernel/mac80211/patches/ 608-add_platform_data_mac_addr.patch 300-pending_work.patch 603-rt2x00-introduce-rt2x00eeprom.patch 607-rt2x00-allow_disabling_bands_through_platform_data.patch * rt2x00: fix a crash in the recent update (#14467) Nov 14 20:44:03