**** BEGIN LOGGING AT Mon Dec 15 02:59:59 2014 Dec 15 03:46:39 build #746 of xburst is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/746 Dec 15 04:05:00 build #822 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/822 Dec 15 04:06:25 any jffs2 issues with 3.18 (ar71xx)? seeing "No jffs2 marker was found" Dec 15 06:25:09 build #232 of omap is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/omap/builds/232 Dec 15 06:43:15 build #8 of ipq806x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ipq806x/builds/8 Dec 15 06:49:17 build #8 of ramips.mt7620 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/8 Dec 15 07:35:40 build #8 of ramips.mt7621 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7621/builds/8 Dec 15 07:43:15 nbd: seems r43564 broke the ramips build somehow Dec 15 07:43:48 Patch platform/0100-mtd-split-remove-padding.patch does not apply Dec 15 07:46:56 http://sprunge.us/WgRi Dec 15 07:49:51 build #8 of ramips.mt7628 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/8 Dec 15 07:50:50 heh, also: http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/8/steps/compile_4/logs/stdio Dec 15 08:08:58 build #157 of brcm63xx.smp is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx.smp/builds/157 Dec 15 08:38:58 ah, probably actually these: r43696 r43700 Dec 15 08:50:44 zajec: i think your r43696 broke ramips Dec 15 08:53:04 rmilecki r43708 trunk/target/linux/brcm47xx/base-files/lib/upgrade/platform.sh * brcm47xx: use separated function in upgrade to detect file type Dec 15 08:53:19 russell--: shit, let me check Dec 15 08:53:49 russell--: https://dev.openwrt.org/changeset/43696/ ? i' Dec 15 08:54:02 russell--: i'm pretty sure I've compared final mtdpart.c and there wasn't any difference Dec 15 08:55:28 russell--: ah, i see now, it's a problem with the https://dev.openwrt.org/changeset/43700/ Dec 15 08:57:07 the conflict was it the mtd splitting stuff, is about as narrow as i could figure out Dec 15 08:57:14 in* Dec 15 09:12:32 rmilecki r43709 trunk/target/linux/ramips/ patches-3.14/0101-mtd-add-rtn56u-support.patch patches-3.14/0100-mtd-split-remove-padding.patch * ramips: update mtd patches to apply after changes from r43700 Dec 15 09:12:36 russell--: done, thanks for report Dec 15 09:13:17 zajec: thanks, i'll give that a whirl Dec 15 09:43:37 cyrus r43710 trunk/package/network/utils/ (6 files in 2 dirs) * nftables: mini-bump and patch cleanup Dec 15 09:43:41 zajec: that fixed it for me Dec 15 09:45:51 blogic r43711 trunk/package/system/procd/Makefile * procd: update to latest git HEAD Dec 15 09:52:20 ok Dec 15 09:53:21 nbd r43712 packages/net/madwifi/Makefile Dec 15 09:53:21 madwifi: mark as broken, it has been found to cause kernel crashes even when not attached to a device Dec 15 09:53:25 nbd r43713 packages/libs/libtorrent * libtorrent: moved to github Dec 15 10:01:33 rmilecki r43714 trunk/target/linux/brcm47xx/base-files/lib/upgrade/platform.sh * brcm47xx: detect (and still reject for now) CyberTAN fw format Dec 15 10:38:50 blogic r43715 trunk/ (17 files in 16 dirs) * add "preinit_regular" diag.sh set_state argument Dec 15 10:38:59 blogic r43716 trunk/package/boot/uboot-envtools/Config.in * uboot-envtools: enable UBI support per default on oxnas Dec 15 10:39:03 blogic r43717 trunk/package/system/fstools/Makefile * fstools: update to latest git HEAD Dec 15 11:11:04 rmilecki r43718 trunk/target/linux/brcm47xx/base-files/lib/upgrade/platform.sh * brcm47xx: extract magics from specific upgrade images (and still reject them) Dec 15 13:12:14 build #659 of ep93xx is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/659 Dec 15 15:02:33 Hauke: hello! i was already a bit worried :) Dec 15 15:03:16 zajec: I was not so well the last week and visited my parents the weekend Dec 15 15:03:45 hope you are ok now? Dec 15 15:04:23 yes it is ok now, the cold just took longer than I expected Dec 15 15:04:33 :( Dec 15 15:18:45 Hauke!! Dec 15 15:19:11 is it too cold in EU right now? Dec 15 15:22:01 Hauke anyway, if you have a few minutes, can I ask some questions to you? Dec 15 15:25:56 the problem is more the combination of rain and wind ;-) Dec 15 15:26:18 Devastator: what is the question? Dec 15 15:27:51 Hauke I've seen a patch commited by you that generates mac addresses for broadcom routers with dumb mac addresses initiating by 00:90:4C, my question is why do you generate mac addresses just for these routers? I have an example for a second use of this patch Dec 15 15:28:30 the 00:90:4C prefix is owned by Broadcom and they use it as a default mac address in their sdk Dec 15 15:28:53 so our assumtion was when we see a mac address starting with 00:90:4C it is probably wrong Dec 15 15:28:54 Hauke I've flashed my netgear WNDR3400 v1 (I think you also have one) with an official 14.07 image, lan mac matches the one on the sticker, but all my macs are the same, the wan mac, the wireless mac Dec 15 15:30:02 and according to your patch, if I understand it correctly, it should be like this: et0macaddr = lan mac, wan mac = lan mac + 1, wifi 1 = lan mac + 2, wifi 2 = lan mac + 3 Dec 15 15:30:34 this is not what I'm seeing with this router Dec 15 15:31:41 Devastator: yes I also have an WNDR3400 V1 Dec 15 15:31:52 I have to check why it does not work Dec 15 15:32:06 my proposal, for consistency sake, is to apply that logic for all routers, no matter if it has a mac 00:90:4C Dec 15 15:32:33 my device has et0macaddr, et1macaddr, sb/1/macaddr, pci/1/1/macaddr and macaddr set to valid addresses Dec 15 15:32:37 but I wanted to check with you first if the patch does what I just said Dec 15 15:32:58 Devastator: are you sure your nvram content is still correct? Dec 15 15:34:03 Hauke my lan mac ends in 8A, so et0macaddr = 8A, sb/1/macaddr = 8A, pci/1/1/macaddr = 89, et1macaddr = 8B Dec 15 15:34:20 and macaddr = 8A as well Dec 15 15:34:41 Devastator: just provide a full real NVRAM dump Dec 15 15:34:47 I asked you for that once or twice Dec 15 15:34:58 so we can see what' really happening Dec 15 15:35:05 now what you think about +1 +2 +3 Dec 15 15:35:29 zajec sure thing, just a pastebin of nvram show? Dec 15 15:35:33 yes Dec 15 15:35:38 or maybe nvram show | sort Dec 15 15:35:42 will be quicker for us Dec 15 15:35:49 yes sir, one second Dec 15 15:36:00 I think the lan and the 2.4 GHz wifi mac is the same also with the original firmware Dec 15 15:36:14 the 5GHz Wifi has an own mac and the wan port Dec 15 15:36:55 err, really? 2GHz wifi sharing MAC with LAN? would be something weird to me Dec 15 15:38:23 zajec http://codepad.org/IN8c3awA Dec 15 15:38:34 if you want I can revert to stock to check Dec 15 15:39:15 my board_data seems intact at least Dec 15 15:40:27 Devastator: well, Hauke is right, LAN and on-SoC WLAN are supposed to have the same MAC: et0macaddr=E0:91:F5:6D:0A:8A sb/1/macaddr=E0:91:F5:6D:0A:8A Dec 15 15:40:44 Devastator: WAN has the same MAC as LAN, because it's OpenWrt specific behavior Dec 15 15:40:55 ok Dec 15 15:41:07 Devastator: does this cause any problems? Dec 15 15:41:07 but your external WiFi (BCM43224) should use this one: pci/1/1/macaddr=E0:91:F5:6D:0A:89 Dec 15 15:42:21 Hauke not really, but as I was reading the patch commit message and checked that my wan port had the same mac as lan, and the commit message said it was not suppose to be that way, I got worried hehe Dec 15 15:42:48 the problem was that all devices shared the same mac address Dec 15 15:43:02 Devastator: as I told you 2-3 times, commit message was about sth different Dec 15 15:43:10 Devastator: NOT about LAN MAC vs. WAN MAC Dec 15 15:43:31 zajec yep, unfortunately I'm not using the external one because proprietary drivers doesn't support the external wifi :( Dec 15 15:43:33 so if someone bought two of the same devices and put them into a network he got a mac address conflict Dec 15 15:43:50 and b43 doesn't doesn't support multiple ssids :( Dec 15 15:45:11 Hauke I see, it's just that in that patch, wan mac is lan mac + 1, but you told me once that in openwrt wan mac and lan mac is the same, zajec confirmed it 2-3 times Dec 15 15:45:37 rmilecki r43719 trunk/target/ linux/bcm53xx/base-files/lib/upgrade linux/bcm53xx/base-files/lib/upgrade/platform.sh * bcm53xx: sysupgrade support for devices with serial flash Dec 15 15:45:41 the patch is this one by the way, if that matters: https://dev.openwrt.org/browser/branches/barrier_breaker/target/linux/brcm47xx/patches-3.10/145-MIPS-BCM47XX-fixup-broken-MAC-addresses-in-nvram.patch Dec 15 15:46:09 is there any plans for b43 to support multiple ssids? is it difficult to support it? Dec 15 15:46:19 Devastator: didn't look at it Dec 15 15:47:14 from what I have seen in brcmsmac you have to do some special/different handling for 2 to 4 vaps and a different for 5 to 16 vaps Dec 15 15:47:34 probably the driver takes over more work from the firmware Dec 15 15:47:47 firmware == ucode in this case Dec 15 15:48:06 but broadcom removed most of the ap parst from brcmsmac Dec 15 15:48:20 s/parst/parts/ Dec 15 15:48:58 yep, they like to make developer's life easier, don't they? Dec 15 15:50:00 probably not so hard when you know what to do Dec 15 15:51:19 I would really dump broadcom-wl if I could, but unfortunately I need multiple ssids for this use-case Dec 15 15:51:45 I'm looking for an atheros replacement meanwhile Dec 15 15:52:56 Hauke actually, I bought this WNDR3400 v1 to help with 5GHz development, mostly testing, but you guys were faster than me, how this router performs? is it any good?! Dec 15 15:52:58 Hauke: could you look at this PCIe problem? we even have a report for that https://dev.openwrt.org/ticket/18577 Dec 15 15:53:17 zajec: yes I will do that Dec 15 15:53:56 zajec: I hoped that this check is only needed because we also do some strange checks for using pcie 2 or 1 Dec 15 15:57:26 and if I may, I want to apologize, especially with zajec, if I brought this mac address subject too often.. I'm usually a nice guy :) Dec 15 15:57:27 blogic r43720 trunk/target/linux/ramips/dts/mt7621.dtsi * ralink: remove partitoon map from mt7621.dtsi Dec 15 15:59:13 Devastator: i just think you were ignoring some facts ;) Dec 15 15:59:34 I probably were Dec 15 19:00:34 build #749 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/749 Dec 15 19:11:06 groz: ping Dec 15 19:12:55 [ 3] 0.0-120.0 sec 7.19 GBytes 515 Mbits/sec Dec 15 19:13:07 with nf_conntrack_rtcache on erlite, 3.18 final kernel Dec 15 19:19:30 build #802 of ppc40x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/802 Dec 15 19:42:11 ping Dec 15 19:42:15 pong Dec 15 19:42:24 wassup stintel ? Dec 15 19:50:16 groz: ah just look at the numbers I posted right below the ping ;) Dec 15 19:50:37 oh Dec 15 19:50:40 hehe, I missed that Dec 15 19:50:43 nice numbers Dec 15 19:51:18 yeah, interesting. and seems I can get over 200Mbps with sqm enabled, but fluctuates a lot Dec 15 19:51:27 is that on traffic passing thru, or, fetching from the device, ie, only going thru one interface ? Dec 15 19:51:56 I haven't fussed at all with the box for a while, been to busy with 'real work' stuff Dec 15 19:52:08 will hopefully get a chance to play a little more again later this week Dec 15 19:52:11 that's passing through Dec 15 19:52:24 ok, that';s very impressive then Dec 15 19:52:28 without NAT, though Dec 15 19:52:48 when I played last week, with nat, was getting about half that Dec 15 19:53:01 I'll try once with NAT Dec 15 19:59:11 [ 4] 0.0-120.1 sec 5.53 GBytes 396 Mbits/sec Dec 15 19:59:39 just out of curiosity: what's the number if you unload the rtcache module? Dec 15 19:59:55 nbd: hold on, btw did you see my issue with the rtcache mod loaded ? Dec 15 20:00:01 yes Dec 15 20:00:20 ok. should I report that on nf-next ML ? Dec 15 20:00:30 yes. did you reproduce it with 3.18 as well Dec 15 20:00:31 ? Dec 15 20:00:34 or just 3.14 Dec 15 20:00:40 didn't try that yet, was thinking of doing that Dec 15 20:00:46 ok, please do Dec 15 20:00:48 but my main router is rspro, no 3.18 yet Dec 15 20:01:01 I did that last week with 3.14 Dec 15 20:01:02 so I'll copy the strongswan config from rspro to erl :) Dec 15 20:01:08 and got right around 250 Dec 15 20:01:20 i want to make sure it's not something caused by my backport Dec 15 20:01:40 ok, that's why I asked you first ;) Dec 15 20:01:46 :) Dec 15 20:05:07 awesome performance improvement really. just to be sure I'm doing 4 tests again Dec 15 20:06:01 iperf -t120 -c on device on eth1 or ERL, iperf -s on device on eth0 of ERL: Dec 15 20:06:13 rtcache enabled, no NAT: [ 4] 0.0-120.0 sec 7.82 GBytes 560 Mbits/sec Dec 15 20:08:41 rtache+NAT enabled: [ 5] 0.0-120.1 sec 6.01 GBytes 430 Mbits/sec Dec 15 20:11:33 no rtache, no NAT: [ 4] 0.0-120.1 sec 4.67 GBytes 334 Mbits/sec Dec 15 20:13:49 no rtcache, NAT enabled: [ 5] 0.0-120.1 sec 3.68 GBytes 263 Mbits/sec Dec 15 20:15:09 wow, that's quite a bit more than i expected Dec 15 20:15:48 I wonder how much more it would achieve with offload modules Dec 15 20:15:51 it's impressive. real-life might be a bit slower, there are only the default firewall rules Dec 15 20:16:18 nbd r43721 trunk/include/host-build.mk Dec 15 20:16:18 build: prevent spurious host-build re-builds by touching .built after the install command before touching .installed Dec 15 20:16:27 Devastator: that's another story. I did some tests with edgeos too Dec 15 20:16:52 numbers with offloading enabled, and just routing (no NAT) were near wirespeed, iirc. Dec 15 20:17:11 also, who develops these modules? ubiquiti or cavium? Dec 15 20:17:15 but disable offloading and then the numbers are nowhere near the numbers above (even with rtcache disabled) Dec 15 20:17:31 Devastator: cavium Dec 15 20:18:18 cavium could then be a good boy and open its source :P Dec 15 20:18:48 openwrt + offload modules.. just wonderful to think of Dec 15 20:18:52 yeah Dec 15 20:19:03 offloading is hard, even with available sources Dec 15 20:19:21 http://pastebin.com/Jv1AkRTC Dec 15 20:19:31 at least doing it properly Dec 15 20:20:34 all the existing implementations i've seen so far are ugly enough to cause eye cancer or scare small childen into hiding under their bed ;) Dec 15 20:22:13 if offload is in use, does that affect the ability to do bandwidth control ? Dec 15 20:22:19 on a per client basis ? Dec 15 20:22:42 thinking the system would never see the traffic, so, various forms of management wouldn't work anymore Dec 15 20:23:13 correct Dec 15 20:23:54 I would be happy with rtcache and offloading just ipsec ;) Dec 15 20:24:34 oh heck, those numbers are with 3.14 kernel Dec 15 20:24:46 since 100mbit is the fastest we can get around here, I'm quite happy to use it just the way it is Dec 15 20:24:50 I though 3.18 but rebuilt image and forgot to edit the makefile ;) Dec 15 20:25:02 capable of saturating links, with all the features enabled Dec 15 20:25:09 and I dont care if the offload hardware sits unused Dec 15 20:25:40 bandiwdth management per client is very important feature for me Dec 15 20:25:55 * groz has wifes ipad dialled down to make youtube videos choppy Dec 15 20:26:01 lol Dec 15 20:27:21 it is a perfectly valid use case Dec 15 20:27:51 groz: usually the system sees the first packet (so it can still decide wether the connection should be allowed/do standard packet filter stuff), then the connection gets handed over to the hardware - often at the same time you can then do some limited QoS (assign to certain queues, then give the queues priorities through other means) Dec 15 20:28:33 but you won't be able to use any elaborate QoS/queueing schemes Dec 15 20:29:26 I have a very simple system here, along this line Dec 15 20:29:43 if(source ip = wife computer / ipad / whatever) send to slow que Dec 15 20:29:52 if (source ip = kids computer ) drop Dec 15 20:30:23 kids are grown up and moved away, so, dont what them to stay to long when they visit Dec 15 20:30:50 youngsters these days that become 'unconnected' have a tendancy to eat and run Dec 15 20:31:32 :D Dec 15 21:13:00 nbd: first tests on 3.18 show the same problem with strongswan Dec 15 21:13:45 I'll look into my firewall rules first thouhg Dec 15 21:16:15 I don't think it will be related though. I currently use these rules to throw my IPsec traffic in the vpn firewall zone: Dec 15 21:16:18 iptables -A input_wan_rule -m policy --dir in --pol ipsec --proto 50 -j zone_vpn_input Dec 15 21:16:21 iptables -A forwarding_wan_rule -m policy --dir in --pol ipsec --proto 50 -j zone_vpn_forward Dec 15 21:16:24 iptables -t nat -A postrouting_wan_rule -m policy --dir out --pol ipsec --proto 50 -j ACCEPT Dec 15 21:17:19 anyway I have to go, double, maybe triple shift coming up Dec 15 21:27:19 stintel: well, if the problem disappears when you unload rtcache, that points to a generic issue in that code Dec 15 21:27:30 stintel: please report it to the netfilter and netdev lists Dec 15 21:27:30 thanks **** ENDING LOGGING AT Tue Dec 16 02:59:58 2014