**** BEGIN LOGGING AT Fri Oct 02 02:59:59 2015 Oct 02 04:51:56 build #102 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/102 Oct 02 06:04:37 rmilecki r47079 trunk/package/system/procd/files/nand.sh * procd: make nand_do_platform_check check image only Oct 02 08:25:56 cyrus r47080 trunk/package/base-files/ files/sbin/hotplug-call files/etc/preinit Makefile files/etc/profile * base-files: sanitize and unify $PATH Oct 02 08:26:00 cyrus r47081 trunk/package/network/utils/iproute2/Makefile * iproute2: adapt coexistence layer to new unified path Oct 02 09:36:23 build #94 of ar71xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/94 Oct 02 10:36:34 build #95 of lantiq.xrx200 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/95 Oct 02 10:50:13 blogic r47082 branches/chaos_calmer/package/system/mountd/ patches Makefile files/mountd.init * mountd: move code to a git repo Oct 02 10:50:16 blogic r47083 branches/chaos_calmer/package/system/fstools/Makefile * fstools: update to latest git revision Oct 02 10:50:23 blogic r47084 branches/chaos_calmer/package/system/uci/Makefile * uci: update to the latest version, adds various fixes Oct 02 10:50:34 blogic r47085 branches/chaos_calmer/package/system/rpcd/Makefile * rpcd: update to latest git HEAD Oct 02 10:50:43 blogic r47086 branches/chaos_calmer/target/linux/ramips/patches-3.18/0015-MIPS-ralink-cleanup-early_printk.patch * ramips: make the early_printk code detect which uart is used Oct 02 10:50:57 blogic r47087 branches/chaos_calmer/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch * ramips: make the mt7628 spi driver work for both cs lines Oct 02 10:51:09 blogic r47088 branches/chaos_calmer/target/linux/ramips/patches-3.18/0030-pinctrl-ralink-add-pinctrl-driver.patch * ramips: make pinctrl work on newer socs Oct 02 10:51:17 blogic r47089 branches/chaos_calmer/target/linux/ramips/patches-3.18/0065-mt7628-pww.patch * ramips: add mt7628 pwm driver Oct 02 10:51:32 blogic r47090 branches/chaos_calmer/target/linux/ramips/patches-3.18/0300-mt7628_fixes.patch * ramips: more m7628 pinmux fixes Oct 02 10:52:08 blogic r47091 branches/chaos_calmer/target/linux/ramips/patches-3.18/0048-GPIO-ralink-add-mt7621-gpio-controller.patch * ramips: add get_direction() callback and irq support to gpio-mt7621 Oct 02 10:52:24 blogic r47092 branches/chaos_calmer/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch * ramips: add speed and mode settings to spi-mt7621 Oct 02 10:52:36 blogic r47093 branches/ chaos_calmer/target/linux/ramips/patches-3.18/0301-mt7688-detect.patch chaos_calmer/target/linux/ramips/base-files/lib/preinit/07_set_preinit_iface_ramips * ramips: add proper mt7688 detection Oct 02 10:53:06 blogic r47094 branches/chaos_calmer/target/linux/ramips/patches-3.18/0302-mt762x-vendor-id.patch * ramips: fix reported vendor name Oct 02 10:53:16 blogic r47095 branches/chaos_calmer/target/linux/ramips/patches-3.18/0052-i2c-MIPS-adds-ralink-I2C-driver.patch * ramips: add mt7621/3/8 support to the I2C driver Oct 02 10:53:40 blogic r47096 branches/chaos_calmer/target/linux/ramips/patches-3.18/0037-USB-phy-add-ralink-SoC-driver.patch * ramips: remove debug code from usb phy driver Oct 02 10:53:49 blogic r47097 branches/chaos_calmer/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch * ralink: speed selection was broken in spi-mt7621 Oct 02 10:53:59 blogic r47098 branches/chaos_calmer/target/linux/ramips/patches-3.18/0053-mmc-MIPS-ralink-add-sdhci-for-mt7620a-SoC.patch * ramips: add CD polling to sd driver Oct 02 10:54:17 blogic r47099 branches/chaos_calmer/target/linux/ramips/patches-3.18/0053-mmc-MIPS-ralink-add-sdhci-for-mt7620a-SoC.patch * ralink: the mmc driver can now handle CD lines that are active low Oct 02 10:54:26 blogic r47100 branches/chaos_calmer/target/linux/ramips/dts/mt7628an.dtsi * ralink: add irq to mt7628 gpio node Oct 02 10:54:36 blogic r47101 branches/chaos_calmer/target/linux/ramips/patches-3.18/0026-MIPS-ralink-add-mt7628an-support.patch * ramips: various mt7688 pinmux fixes Oct 02 11:17:43 build #96 of kirkwood is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/96 Oct 02 11:55:58 nbd: where should I send the patch for libubox? Oct 02 11:56:20 I have finally been able to have a proper patch... Oct 02 11:57:03 txomon: openwrt-devel Oct 02 11:57:10 ok Oct 02 11:58:47 is "warn_slowpath_common" trace dumps interesting at all? https://pastee.org/xf7gs or should I just ignore them. everything works, just never seen them before. Oct 02 12:16:53 sent patch... I suppose I did something wrong with the formatting... Oct 02 12:17:06 * txomon always fails at formatting patches Oct 02 12:19:16 git send-email is your friend. Oct 02 12:20:08 karlp: I always use that, but I always fail at writing something xD Oct 02 12:32:11 txomon: are you sure that the setsockopt API guarantees that you can modify multiple options at once? Oct 02 12:34:11 i can't find any docs that say this is allowed Oct 02 12:39:41 sockopts are not bitfields Oct 02 12:40:13 also i don't really see why this needs to go into usock Oct 02 12:40:53 or does it make a difference if you set SO_BROADCAST before binding? Oct 02 12:43:50 also your whole patch does nothing Oct 02 12:44:11 you are setting: int flags = SO_RESUSEADDR and then if (flags & USOCK_BROADCAST) Oct 02 12:44:20 this cannot ever be true Oct 02 12:50:31 cyrusff: I mistakenly checked flags instead of type Oct 02 12:52:14 nbd: it doesn't, that's why I had to do the OR Oct 02 12:52:38 to add bits to flags instead of using setsockopt twice Oct 02 12:53:13 cyrusff: setsockopts AFAIK needs to be done after creation Oct 02 12:53:33 creation of what? Oct 02 12:59:19 the broadcast flag needs to be set before connect() Oct 02 12:59:33 when connecting a socket to a broadcast address Oct 02 13:00:08 txomon: i was questioning the validity of specifying multiple SO_* options within one setsockopt call Oct 02 13:00:17 txomon: my guess is that it doesn't work Oct 02 13:00:38 so you may need to do multiple setsockopt calls Oct 02 13:00:50 nbd: connect is just a default, can be used multiple times Oct 02 13:01:08 setsockopts must only be called once Oct 02 13:01:16 but I can check if you wish Oct 02 13:02:10 what you're saying doesn't make much sense to me Oct 02 13:02:20 of course setsockopt can be called multiple times to set different options Oct 02 13:02:20 sorry I got confused Oct 02 13:02:27 yeah, you are right Oct 02 13:02:38 I was thinking on other api that I use :( Oct 02 13:03:02 either way, i'm fine with adding broadcast support to the API Oct 02 13:03:05 so take your time to finish the patch Oct 02 13:03:09 and test it before you submit v2 Oct 02 13:04:02 ok Oct 02 13:04:46 nbd: what I meant is that connect() on udp connections sets the default, to be able to use send instead of sendto Oct 02 13:05:34 i know Oct 02 13:05:59 when you don't specify USOCK_SERVER, usock will call connect() Oct 02 13:06:35 and so i pointed out that having the broadcast option in usock is okay for that reason Oct 02 13:06:46 oh ok Oct 02 13:07:12 otherwise there would not have been much point to it, since it's easy to just call setsockopt() after setting up the socket Oct 02 13:07:52 nbd: I will test just in case, but I think you can still do it now Oct 02 13:08:16 the thing is that this way you avoid having to set extra headers include that are not absolutely needed Oct 02 13:08:23 and it's not too much burden to add Oct 02 13:09:13 the thing is how can that flag I set up be reused... Oct 02 13:10:30 i just noticed one other thing Oct 02 13:10:38 setting the option just for if (server) is not a good idea Oct 02 13:10:47 especially when it's the connect() call that really needs it Oct 02 13:10:57 and that one is in the !server case Oct 02 13:12:05 nbd: a connect() call in a SOCK_DGRAM resets the previous connect(), just in case Oct 02 13:12:33 i know Oct 02 13:12:44 but usock() without USOCK_SERVER does a connect call right after creating the socket Oct 02 13:12:47 I was thinking this for server mode mainly Oct 02 13:12:59 yeah, but that's not a good reason to limit it to server mode Oct 02 13:13:16 especially because it's mostly unnecessary to have this in usock() for server mode Oct 02 13:13:20 as i've explained above Oct 02 13:13:24 but I haven't limited to server mode, have I Oct 02 13:13:26 ?? Oct 02 13:13:31 yes, you have Oct 02 13:13:39 because you put it in a place that's only reachable for server mode Oct 02 13:14:05 nbd: no, made a mistake and used flags instead of type in the check Oct 02 13:14:13 that's a different mistake Oct 02 13:14:17 look at the context Oct 02 13:14:25 look at where the setsockopt() call is Oct 02 13:14:29 and what's right above it Oct 02 13:15:31 it is just after the socket creation and fcntl Oct 02 13:15:47 before if (server) Oct 02 13:16:07 not in the patch that you sent to the list Oct 02 13:16:25 in the patch you sent to the list, it's inside the 'if (server)' block Oct 02 13:17:31 nbd: ohhhh I understand now Oct 02 13:17:38 yeah, I have corrected that, sorry Oct 02 13:18:29 how may I mark it's v2?? Oct 02 13:18:42 --subject-prefix "PATCH v2" Oct 02 13:18:59 preferably "PATCH libubox v2" Oct 02 13:19:07 to show what repo it applies to Oct 02 13:22:28 this was what I changed now https://github.com/txomon/libubox/blob/master/usock.c#L52-L53 Oct 02 13:28:48 i think you may need to put type & USOCK_BROADCAST in () Oct 02 13:28:55 also, this code clearly does not compile Oct 02 13:29:13 please run a compile test before proposing stuff ;) Oct 02 13:30:53 nbd: I am doing it, yes :) already updated the 'one' problem Oct 02 13:44:07 and it seems to work (I refactored my code to use usock :P Oct 02 13:44:40 btw, any helper such as ustream for udp protocol implementation? Oct 02 13:45:03 because ustream is for SOCK_STREAM AFAIK... Oct 02 13:47:18 i think ustream for datagram does not make sense Oct 02 13:49:04 maybe I am getting confused with uloop... Oct 02 13:49:28 hmmm yeah, seems so Oct 02 13:50:24 ustream is simply stacked on top of uloop to make the annoyances of non-blocking stream processing easier to deal with Oct 02 13:50:38 with stream stuff there's a lot more stuff to consider than with normal datagram send/receive Oct 02 13:50:52 e.g. partial read/write Oct 02 13:52:16 I misunderstood that, I thought ustream was the one providing what I now see as the uloop functionalities Oct 02 14:16:18 can anyone confirm that libubox/blob.h has all the data together and that is up to you how to decode it? or is that data tagged in the blob itself somehow? Oct 02 14:20:18 is it possible my atheros wifi card doesn't support ap mode and sta mode at the same time? How can I check? Oct 02 14:22:21 http://superuser.com/questions/679723/how-to-detect-wi-fi-adapter-capabilities Oct 02 14:23:05 nice, thanks Oct 02 15:10:03 can anyone confirm the blob.h thing please? or if you know a better way to create a blob... I'm all ears Oct 02 15:10:54 I had thought about adding functions like in blob.h but without being tagged... Oct 02 15:12:59 nothing I will do my way just in case Oct 02 15:22:05 txomon: what do you mean by 'has all the data together'? Oct 02 15:23:16 I mean that if I write an uint16 and then a uint8, if they are aligned or not, and if anything apart from the 24bits needed is contained within the blob data. I am trying to write blob data to send by network. Oct 02 15:23:59 blob fields are paddded to 4 bytes, everything is aligned Oct 02 15:24:05 the blob field header is also 4 bytes Oct 02 15:24:35 ok, so it header:type:data:type:data Oct 02 15:24:51 the header contains the type Oct 02 15:24:51 I wanted data:data, so I will just do it my way Oct 02 15:25:10 so it's
... Oct 02 15:25:18 it allows nesting Oct 02 15:25:24 oh ok, I was telling header the cookie Oct 02 15:25:27 so a data part can also contain
... sequences Oct 02 15:25:31 and type the data Oct 02 15:26:03 ok, all clear now, will do it myself, thanks! Oct 02 15:26:34 if you want to pack data together more tightly, you can also embed a struct with blob_put() Oct 02 15:26:39 but then you have to deal with endian stuff yourself Oct 02 15:27:13 nbd: oh that is nice, I have tons of endianess problems, so I am ok handling it myself Oct 02 15:30:57 anyway, as I don't have complex data types, I will just use 10 custom functions to read and write each of the datatypes Oct 02 15:36:49 thought of using protobufs or gzipped json or anything? Oct 02 15:37:23 karlp: is not my protocol :/ Oct 02 15:37:41 but I would have used protobufs probably... Quite standard Oct 02 15:43:19 maybe I should create an writef() or sth like that using varargs to directly write blobs... Oct 02 15:52:48 I used a lua struct library rather than unpacking cruft by hand in C last time I needed to do someone else's protocol Oct 02 15:53:08 local hdr = sock:receive(16) magic, version, len, tv_sec, tv_usec = struct.unpack(">HBxxxHI4I4", hdr) Oct 02 15:54:26 oh that unpack... Oct 02 16:25:45 nbd r47102 trunk/package/libs/libnl/Makefile * libnl: Install include files into libnl3 Oct 02 17:04:23 build #96 of avr32 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/96 Oct 02 17:11:32 nbd: As a followup to the segfaults I was getting yesterday, I ended up trying to narrow down the problem by starting from scratch and building back up to the configuration that I was using previously. Starting with the most default configuration for the x86 build, I first replaced my kernel configuration and then my OpenWRT configuration, and I never got the crashing again. Weird... Oct 02 18:29:08 build #93 of adm8668 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/93 Oct 02 18:33:45 <_trine> Zero_Chaos, did you apply the aircrack-ng patch upstream >? Oct 02 20:06:18 interesting read: http://www.openbsd.org/papers/libtls-fsec-2015/mgp00001.html Oct 03 01:38:11 build #99 of netlogic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/netlogic/builds/99 Oct 03 02:42:21 build #97 of arm64 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/arm64/builds/97 Oct 03 02:45:48 build #90 of mpc52xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/90 **** ENDING LOGGING AT Sat Oct 03 02:59:58 2015