**** BEGIN LOGGING AT Mon Dec 17 02:59:58 2012
Dec 17 05:28:18 <builder__> build #102 of kirkwood is complete: Exception [exception MasterShellCommand]  Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/102
Dec 17 05:54:03 <builder__> build #106 of xburst is complete: Exception [exception MasterShellCommand]  Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/106
Dec 17 06:17:30 <russell--> is it safe to build for mikrotik and wndr3800 in the same tree?
Dec 17 08:04:36 <builder__> build #124 of brcm47xx is complete: Exception [exception MasterShellCommand]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/124
Dec 17 08:09:03 <russell--> it appears i have a surewest munged wndr3800
Dec 17 08:09:43 <isuldor> surewest munged?
Dec 17 08:11:07 <russell--> some company called surewest has a custom openwrt derived firmware on it, but won't flash standard openwrt images
Dec 17 08:11:27 <isuldor> ouch
Dec 17 08:11:53 <russell--> there is a forum thread about working around, but i'm interested to know what it's doing under the covers, whether it's a custom uboot or what
Dec 17 08:12:16 <isuldor> ah
Dec 17 08:12:41 <isuldor> netgear discontinued the wndr3800 afaik
Dec 17 08:12:49 <russell--> supersecret credentials: username: SWAdmin ; password: $WN3Tw0rk!
Dec 17 08:13:47 <russell--> if anyone has an image of the stock netgear uboot, i'd be interested in comparing
Dec 17 08:14:07 <russell--> (for wndr3800, obviously)
Dec 17 08:14:26 <isuldor> I've got the router. How could I get the image for you?
Dec 17 08:15:08 <russell--> dd if=/dev/mtdblockN of=/tmp/mtdblockN # where N is the uboot partition
Dec 17 08:16:18 <isuldor> I'll get you mtd0 in a sec
Dec 17 08:16:27 <russell--> probably N=0 and N=1
Dec 17 08:16:40 <russell--> mtdblock1 is env or something
Dec 17 08:18:35 <isuldor> pm me your email address and I'll send them as attachments
Dec 17 08:23:35 <isuldor> sent
Dec 17 08:23:41 <russell--> thanks
Dec 17 08:29:05 <russell--> looks like mtdblock0 is the same in both
Dec 17 08:29:15 <russell--> also mtdblock1
Dec 17 08:29:24 <russell--> (all 0xff)
Dec 17 08:29:39 <russell--> (all 0xff in mtdblock1, that is)
Dec 17 08:31:36 <russell--> isuldor: how about mtdblock3?
Dec 17 08:31:45 <russell--> appears to be the config partition
Dec 17 08:32:40 <russell--> at least in mine
Dec 17 08:43:54 <builder__> build #119 of cobalt is complete: Exception [exception MasterShellCommand]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/119
Dec 17 08:45:55 <builder__> build #124 of atheros is complete: Exception [exception MasterShellCommand]  Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/124
Dec 17 08:53:36 * russell-- searches for what the firmware uses to reflash itself
Dec 17 08:58:56 <builder__> build #102 of ixp4xx is complete: Exception [exception MasterShellCommand]  Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/102
Dec 17 09:14:14 <isuldor> ok, I'll send you mtdblock3 in a second
Dec 17 09:16:01 <russell--> thanks!
Dec 17 10:11:40 <_trine> this might be worth having in openwrt http://en.wikipedia.org/wiki/ATA_over_Ethernet
Dec 17 10:15:19 <isuldor> _trine: it already is.
Dec 17 10:17:38 <jow_laptop> dwmw2_gone: regarding xtables-addons, personally I'd like to wait until all targets are 3.7+ and the switch xtables-addons
Dec 17 10:17:43 <jow_laptop> to version 2.0
Dec 17 10:18:03 <_trine> isuldor, oh thanks i didnt know
Dec 17 10:18:36 <jow_laptop> dwmw2_gone: and the author made a new version of rtsp_conntrack for 3.6+, http://mike.it-loops.com/rtsp/rtsp-module-3.6.tar.gz
Dec 17 10:24:22 <cyrusff> jow_laptop: when did the ABI-change happen? 3.6 or 3.7?
Dec 17 10:24:34 <jow_laptop> cyrusff: 3.6 afaik
Dec 17 10:24:38 <cyrusff> ok
Dec 17 10:24:40 <jow_laptop> cyrusff: or 3.4 even already
Dec 17 10:24:57 <cyrusff> so we could think about a new iptables once all targets are on 3.6?
Dec 17 10:25:03 <jow_laptop> yes
Dec 17 10:25:06 <cyrusff> ok
Dec 17 10:25:11 <jow_laptop> new iptables, new ipset, new xtables
Dec 17 10:25:28 <jow_laptop> just think its not worth dragging around two versions
Dec 17 10:25:37 <cyrusff> yes and finally the new unified iptables then
Dec 17 10:27:55 <jow_laptop> right, seems we have to abandon the package-based separation of ipv6 support
Dec 17 10:28:31 <cyrusff> well finally i think
Dec 17 10:28:34 <jow_laptop> at least I see no way how to provide an iptables & ip6tables with the new version
Dec 17 10:28:45 <jow_laptop> without ip6tables being just a bunch of symlinks
Dec 17 10:29:04 <cyrusff> i'd really like to see natuve ipv6 in the standard builds
Dec 17 10:29:07 <jow_laptop> maybe we can consider build variants but those are always messy from a distribution perspective
Dec 17 10:50:36 <dwmw2_gone> jow_laptop: this would be a good time for IPv6 to be enabled by default and only turned off for *very* constrained platforms
Dec 17 10:51:33 <dwmw2_gone> I wasn't sure about waiting for all targets to be 3.7. That means that xtables-addons is broken for some targets, until that happens. I figured it was easy enough to keep the old version around for now and then delete it when all the targets catch up
Dec 17 10:54:30 <nbd> i'm ok with enabling v6 at some point
Dec 17 10:54:38 <nbd> but we really do need to figure out a way to make our kernel images smaller
Dec 17 10:55:57 * russell-- loves ipv6, but his relatives don't ... facebook's words-with-friends doesn't seem to like ipv6 on
Dec 17 10:57:25 <blogic> caog: hi
Dec 17 10:57:36 <caog> blogic:  yo
Dec 17 10:59:14 <caog> blogic: devicetree was very handy, custom board running in about 1 hour, no C code!!
Dec 17 11:00:02 <blogic> :-D
Dec 17 11:07:07 <dwmw2_gone> disable Legacy IP? How much would that save? :)
Dec 17 11:07:17 <cyrusff> haha
Dec 17 11:08:24 <dwmw2_gone> hm, I bet i can shrink the ppc kernel
Dec 17 11:08:32 <dwmw2_gone> what's a good target to play with?
Dec 17 11:09:15 <cyrusff> i think we also should talk about which features we will support by default, i guess stuff like ipv6-nat is not that important
Dec 17 11:09:31 <dwmw2_gone> I would be happy never supporting ipv6 nat
Dec 17 11:09:39 <dwmw2_gone> that's an abomination which should never have been dreamed of
Dec 17 11:10:24 <cyrusff> the problem is that for some scenarios its the lesser abomination compared to the alternatives
Dec 17 11:10:38 <dwmw2_gone> really?
Dec 17 11:11:05 <cyrusff> most users won't need it but if you run into multi-uplink scenarios
Dec 17 11:11:06 <dwmw2_gone> most such scenarios I've encountered so far as better solved by a psychologist. Or just some education.
Dec 17 11:11:14 <dwmw2_gone> Or a better ISP :)
Dec 17 11:11:17 <cyrusff> haha
Dec 17 11:11:50 <dwmw2_gone> I have multi-uplink and don't need NAT; not for IPv6 and not for Legacy IP either.
Dec 17 11:12:42 <cyrusff> i haven't encountered problems either, but I've heard from users (also in the openwrt-forum) reporting about borken device that don't select the correct source adress etc. etc.
Dec 17 11:15:36 <cyrusff> some even haven üproblems when you just announce an ULA-prefix and a public prefix at the same time
Dec 17 11:16:26 <dwmw2_gone> admittedly, I use the same range of IP addresses on both uplinks...
Dec 17 11:17:36 <dwmw2_gone> so the primary use case for NAT is endpoints that can't manage basic RFC3484 address selection?
Dec 17 11:17:46 <dwmw2_gone> that sounds like a use case for a hammer
Dec 17 11:18:14 <jow_laptop> I don't find the stateless ipv6 nat that bad
Dec 17 11:18:16 <dwmw2_gone> http://david.woodhou.se/bswap-3.6.patch should make the ppc kernel a little smaller
Dec 17 11:18:28 <cyrusff> yes well stateless nat is used for broken clients and stateful nat is used for broken sysadmins, mainly
Dec 17 11:18:30 <jow_laptop> its just a mapping from one prefix to another prefix of the same size
Dec 17 11:18:35 <jow_laptop> no port mapping etc.
Dec 17 11:18:45 <dwmw2_gone> that's a lot saner, I suppose
Dec 17 11:19:23 <cyrusff> yeah at least it doesn't involve the whole conntracking and lookup stuff
Dec 17 11:19:25 <jow_laptop> it also allows you to keep a secondary ula prefix around which still can reach the net
Dec 17 11:19:28 <dwmw2_gone> but still needs to find embedded IP addresses in all protocols to fix them up
Dec 17 11:41:30 <dwmw2_gone> what platforms support load-and-byteswap and store-and-byteswap instructions, other than ppc and x86(atom)
Dec 17 11:56:18 <nbd> mips32r2 has an instruction that can be used for that
Dec 17 11:56:32 <nbd> 32 bit swap is 2 instructions, 16 bit just one
Dec 17 11:56:56 <nbd> not including the load/store instruction
Dec 17 11:56:59 <dwmw2_gone> to combine with load/store? Or just to swap in a register?
Dec 17 11:57:16 <nbd> just swap in a register
Dec 17 11:57:21 <dwmw2_gone> that's no fun then
Dec 17 11:57:31 <dwmw2_gone> looking for equivalents of lwbrx or movbe
Dec 17 11:57:32 <nbd> gcc doesn't use that
Dec 17 11:57:38 <nbd> it generates code that's even worse
Dec 17 11:57:56 <dwmw2_gone> hm, really? Got a PR# for that?
Dec 17 11:58:27 <nbd> 46453
Dec 17 11:59:03 <dwmw2_gone> I'm looking at using __builtin_bswap32() et al for all byteswapping instead of the inline asm we have at the moment
Dec 17 11:59:11 <dwmw2_gone> http://git.infradead.org/users/dwmw2/byteswap.git/commitdiff/cf66bb93e0f75e0a4ba1ec070692618fa028e994
Dec 17 11:59:20 <dwmw2_gone> bugs like that would hurt
Dec 17 12:28:50 <OpenWrt-Commits> juhosg r34727 trunk/target/linux/ (6 files in 2 dirs) * ar71xx: add kernel support for the UniFi AP Pro
Dec 17 12:28:58 <OpenWrt-Commits> juhosg r34728 trunk/target/linux/ ar71xx/base-files/etc/diag.sh ar71xx/base-files/lib/ar71xx.sh ar71xx/base-files/lib/upgrade/platform.sh ar71xx/base-files/etc/uci-defaults/network * ar71xx: add user-space support for UniFi AP Pro
Dec 17 12:29:02 <OpenWrt-Commits> juhosg r34729 trunk/tools/firmware-utils/src/mkfwimage2.c * firmware-utils/mkfwimage2: allow to use numbers in partition names
Dec 17 12:29:08 <OpenWrt-Commits> juhosg r34730 trunk/target/linux/ ar71xx/generic/profiles/ubnt.mk ar71xx/image/Makefile * ar71xx: add profile and build image for UniFi AP Pro
Dec 17 12:38:02 <dwmw2_gone> - 558605	./fs/btrfs/btrfs.ko
Dec 17 12:38:02 <dwmw2_gone> + 537469	./fs/btrfs/btrfs.ko
Dec 17 12:38:10 <dwmw2_gone> -  16784	./drivers/net/ethernet/realtek/8139cp.ko
Dec 17 12:38:10 <dwmw2_gone> +  16168	./drivers/net/ethernet/realtek/8139cp.ko
Dec 17 12:38:13 <dwmw2_gone> modest shrinkage
Dec 17 12:38:23 <dwmw2_gone> -3575032	vmlinux
Dec 17 12:38:23 <dwmw2_gone> +3565088	vmlinux
Dec 17 13:03:05 <OpenWrt-Commits> juhosg r34731 trunk/target/linux/ generic/files/drivers/net/phy/rtl8366rb.c generic/files/drivers/net/phy/rtl8367b.c generic/files/drivers/net/phy/rtl8367.c generic/files/drivers/net/phy/rtl8366s.c * generic: rtl836x: fix compiler warnings
Dec 17 13:08:26 <OpenWrt-Commits> jow r34732 trunk/package/libs/libubox/Makefile * libubox: update to latest git head, introduces jshn json_is_a() helper
Dec 17 13:08:30 <OpenWrt-Commits> jow r34733 trunk/package/base-files/ Makefile files/lib/functions/network.sh * base-files: use json_is_a() in network.sh
Dec 17 14:37:40 <russell--> hmm. wan interface not coming up during boot
Dec 17 14:38:14 <russell--> on wndr3800 + my custom config translated from another target
Dec 17 14:38:46 <russell--> eth1 is wan, manually running udhcpc -i eth1 works (logging in over wifi)
Dec 17 14:39:07 <russell--> although /tmp/resolv.conf.auto isn't filled in
Dec 17 14:39:42 <russell--> eth1 got an ipv6 address without intervention
Dec 17 14:39:50 <russell--> (from my upstream router)
Dec 17 14:40:20 <russell--> (via radvd router advertisements or something)
Dec 17 14:42:44 <russell--> hmm /me sees recent commits relating to this?
Dec 17 14:43:38 <rundfreifunk> why eth1? on my wndr3600 all ethernets are eth0..
Dec 17 14:44:16 <jow_laptop> rundfreifunk: on wndr3800 it is eth1
Dec 17 14:44:44 <rundfreifunk> ok
Dec 17 14:45:30 <russell--> [   18.750000] ar71xx: pll_reg 0xb8050014: 0x11110000
Dec 17 14:45:30 <russell--> [   18.750000] eth1: link up (1000Mbps/Full duplex)
Dec 17 14:45:30 <russell--> [   18.750000] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Dec 17 14:45:58 <russell--> yeah, eth1 is right because udhcpc -i eth1 works ;-)
Dec 17 14:47:05 <russell--> the default config on r34240 worked okay
Dec 17 14:47:21 <russell--> (which is ancient now!)
Dec 17 14:48:06 <russell--> have tried rebooting, same problem, so it wasn't a fluke
Dec 17 14:50:49 <jow_laptop> well, pastebin your network config?
Dec 17 14:52:31 <russell--> http://sprunge.us/jeGN
Dec 17 14:53:03 <jow_laptop> trunk?
Dec 17 14:53:42 <russell--> yeah
Dec 17 14:53:54 <jow_laptop> rev?
Dec 17 14:54:07 <jow_laptop> could be that it is broken right now
Dec 17 14:54:17 <jow_laptop> fix might appear in a couple of minutes
Dec 17 14:54:33 <russell--> that vlan/led stuff was snagged directly from r34240, but this is r34730
Dec 17 14:55:04 <jow_laptop> the issue is betwwen netifd and libubox
Dec 17 14:55:09 <jow_laptop> not related to your config
Dec 17 14:55:13 <russell--> okay
Dec 17 14:55:25 * russell-- vaguely recalls hearing inklings about that
Dec 17 14:56:04 * russell-- just got this device cracked open in the last few hours
Dec 17 14:58:04 <OpenWrt-Commits> nbd r34734 trunk/package/network/config/netifd/Makefile
Dec 17 14:58:04 <OpenWrt-Commits> netifd: update to latest version, no longer needs the removed jshn_append() shell function
Dec 17 14:58:57 <jow_laptop> russell--: ^
Dec 17 14:59:01 <russell--> cool
Dec 17 14:59:11 * russell-- is going to sleep now, but will test when i wake up ;-)
Dec 17 14:59:34 <OpenWrt-Commits> nbd r34735 branches/attitude_adjustment/package/netifd/Makefile
Dec 17 14:59:34 <OpenWrt-Commits> netifd: update to latest version, no longer needs the removed jshn_append() shell function
Dec 17 15:12:21 <OpenWrt-Commits> nbd r34736 trunk/tools/Makefile * tools: add a symlink for gnu awk to fix kernel build errors on some platforms
Dec 17 15:12:27 <OpenWrt-Commits> nbd r34737 trunk/target/linux/ (8 files in 3 dirs)
Dec 17 15:12:27 <OpenWrt-Commits> kernel: add some debloat patches, strip down procfs and make O_DIRECT support optional, saves ~15K after lzma on MIPS
Dec 17 15:12:30 <OpenWrt-Commits> nbd r34738 trunk/package/system/sierra-directip * sierra-directip: delete, replaced by upstream drivers
Dec 17 15:12:34 <OpenWrt-Commits> nbd r34739 trunk/package/libs/ncurses/patches/200-fix_missing_include.patch * ncurses: fix build error in libncursesw
Dec 17 15:33:58 <russell--> i lied, not asleep yet, r34734 seems to have fixed it for me, just flashed r34739 with the same config and it came up for me, danke!
Dec 17 18:45:31 <Weedy_lappy> nbd: Priority_down is slightly less important but packets larger then Priority right?
Dec 17 18:46:13 <Weedy_lappy> or what happens if packets are larger then 400 when i've reclassified them priority?
Dec 17 20:32:04 <builder__> build #127 of brcm63xx is complete: Exception [exception MasterShellCommand]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/127
Dec 17 20:56:37 <OpenWrt-Commits> nbd r34740 trunk/target/linux/ generic/patches-3.6/903-debloat_direct_io.patch generic/patches-3.7/903-debloat_direct_io.patch * kernel: fix a warning in the O_DIRECT debloat patch
Dec 17 21:19:43 <builder__> build #130 of at91 is complete: Exception [exception MasterShellCommand]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/130
Dec 17 21:55:15 <dwmw2_gone> gr. Why is netifd refusing to bring l2tp up *this* time
Dec 17 21:55:49 <dwmw2_gone> another connection to the same server seems to work, so it's not just refusing to do it because it doesn't tihnk it has a route (it should know about the route now anyway)
Dec 17 21:58:16 <nbd> i think there's a bug in the /lib/functions/network.sh scripts
Dec 17 21:58:26 <nbd> 6in4 also doesn't work because it can't find the wan ip address
Dec 17 21:58:41 <nbd> i'm waiting for jow to look into it
Dec 17 21:59:12 <dwmw2_gone> odd that a different l2tp connection to the *same* server was working
Dec 17 21:59:31 <nbd> interesting
Dec 17 22:00:00 <dwmw2_gone> is there a way to ensure an interface is up *without* taking it down first?
Dec 17 22:00:20 <dwmw2_gone> when my ADSL ppp lines go down I want to bring up the L2TP
Dec 17 22:00:34 <dwmw2_gone> but not take it *down* if it's already up
Dec 17 22:00:36 <dwmw2_gone> which 'ifup' does
Dec 17 22:01:37 <nbd> i guess we need to add an option to the ifup script for that
Dec 17 22:01:59 <nbd> or you just call 'ubus call network.interface.l2tp up'
Dec 17 22:02:02 <nbd> instead of ifup
Dec 17 22:02:09 <nbd> that avoids the down->up cycle
Dec 17 22:02:35 <dwmw2_gone> that works; thanks
Dec 17 22:04:59 <dwmw2_gone> after a reboot, that is. No idea why l2tp wasn't coming up before
Dec 17 22:05:04 <dwmw2_gone> no bloody error output from netifd :(
Dec 17 22:10:28 <nbd> what does ifstatus <interface> tell you?
Dec 17 22:12:32 <nbd> if it's not up, it should show an error code or something
Dec 17 22:14:15 <dwmw2_gone> if it happens again, I'll try that
Dec 17 22:24:51 <nbd> oh, found a minor error reporting issue in netifd ;)
Dec 17 22:25:14 <nbd> rare, and only shows stale data for some proto-shell error messages, but still
Dec 17 22:25:18 <OpenWrt-Commits> nbd r34741 trunk/package/network/config/netifd/Makefile
Dec 17 22:25:18 <OpenWrt-Commits> netifd: update to latest version, fixes interface error reporting for shell proto handlers
Dec 17 22:27:01 <OpenWrt-Commits> nbd r34742 branches/attitude_adjustment/package/netifd/Makefile
Dec 17 22:27:01 <OpenWrt-Commits> netifd: update to latest version, fixes interface error reporting for shell proto handlers
Dec 17 22:28:57 <OpenWrt-Commits> juhosg r34743 trunk/target/linux/ ar71xx/config-3.3 ar71xx/patches-3.3 * ar71xx: nuke 3.3 support
Dec 17 22:28:59 <OpenWrt-Commits> juhosg r34744 trunk/target/linux/ ramips/rt288x/config-3.3 ramips/patches-3.3 ramips/rt3883/config-3.3 ramips/rt305x/config-3.3 * ramips: nuke 3.3 support
Dec 17 22:50:59 <dwmw2_gone> nbd: feel like merging the work I did last night to fix the 3.7 build?
**** ENDING LOGGING AT Tue Dec 18 02:59:58 2012