**** BEGIN LOGGING AT Tue Jan 21 02:59:59 2014
Jan 21 04:37:42 <builder_> build #500 of atheros is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/500
Jan 21 04:47:01 <builder_> build #508 of brcm47xx is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/508
Jan 21 04:49:55 <builder_> build #434 of sibyte is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/434
Jan 21 06:56:52 <builder_> build #476 of uml is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/476
Jan 21 07:25:45 <builder_> build #444 of avr32 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/444
Jan 21 07:56:02 <OpenWrt-Commits> wigyori r39355 trunk/target/linux/generic/config-3.13 * [3.13]: add missing symbols
Jan 21 08:13:08 <builder_> build #502 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/502
Jan 21 09:11:53 <champtar> Hi, can anyone ACK or NACK this patch http://patchwork.openwrt.org/patch/4738/ (add busybox hostname) ( nbd ?)
Jan 21 09:21:01 <russell--> champtar: an alternative might be to patch the package (zabbix?) to read /proc/sys/kernel/hostname instead?
Jan 21 09:24:16 <champtar> russell—: i know, but if this patch is accepted it's useless (and i'm a bit lazy). if i have a clear NACK i'll patch zabbix, but i don't want to start until i've it
Jan 21 09:25:53 * russell-- can't do either ack nor nack, just peanut gallery comments ;-)
Jan 21 09:54:04 <OpenWrt-Commits> blogic r39356 trunk/package/kernel/lantiq/ltq-vdsl-fw/src/w921v_fw_cutter.c * lantiq: fix unaligned access in vdsl firmware extractor
Jan 21 09:55:24 <wigyori> nbd: poke
Jan 21 11:31:22 <builder_> build #465 of x86 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/465
Jan 21 11:51:47 <dtaht_nuc> cyrus: hi
Jan 21 11:52:04 <cyrusff> dtaht_nuc: hi
Jan 21 11:52:19 <cyrusff> how is it going?
Jan 21 11:52:23 <blogic> dtaht_nuc: hey
Jan 21 11:52:37 <dtaht_nuc> hi. Didn't realize you guys hid here.
Jan 21 11:53:18 <dtaht_nuc> I am still fighting a losing battle with ipv6, but I'm about to reboot into head
Jan 21 11:53:42 <blogic> how so ?
Jan 21 11:53:43 <cyrusff> yeah i couldn't really reproduce most of what you wrote on the list
Jan 21 11:54:02 <cyrusff> so i guess there was must be some subtle differences between cero and owrt that are causing trouble
Jan 21 11:54:04 <dtaht_nuc> cyrusff: I appreciate you trying, very much.
Jan 21 11:54:29 <dtaht_nuc> only major difference between your test and mine was the sheer number of interfaces involved... and that I was calling network restart as I tested...
Jan 21 11:54:52 <dtaht_nuc> so a fresh boot on a fresh os, and removing some interfaces seems to be in order.
Jan 21 11:55:04 <cyrusff> well in the end the number of downstream interfaces doesn't really matter for the routing of the upstream interfaces
Jan 21 11:55:22 <dtaht_nuc> blogic: users got bit by the comcast problem. After that is theoretically fixed, hurricane electric broke with a weird routing issue
Jan 21 11:55:44 <blogic> oh \dear
Jan 21 11:55:55 <blogic> well, i am actually installing ipv6 in my home today
Jan 21 11:56:03 <blogic> i figured its about time to move to ipv6
Jan 21 11:56:05 <blogic> :)
Jan 21 11:56:17 <dtaht_nuc> http://www.bufferbloat.net/issues/439
Jan 21 11:56:26 <dtaht_nuc> cool. Welcome to the 90s!
Jan 21 11:57:01 <blogic> dtaht_nuc: looking at that link you posted ... i think your router is broken
Jan 21 11:57:04 <dtaht_nuc> the core issue I'd hit was that not all routes were getting inserted at boot with hurricane and I have no idea why.
Jan 21 11:57:04 <blogic> try installing openwrt
Jan 21 11:57:05 <dtaht_nuc> hahahaha
Jan 21 11:57:06 <blogic> :)
Jan 21 11:57:28 <dtaht_nuc> if I coulda done the work on bloat I did with bridged interfaces I would have.
Jan 21 11:57:38 <blogic> the scary thing about the 90s ... they already sucked while they were real
Jan 21 11:57:45 <blogic> now, 15 years later they still suck
Jan 21 11:57:51 <blogic> bad musci, bad hair ....
Jan 21 11:57:51 * dtaht_nuc does NOT remember trumpet winsock fondly
Jan 21 11:58:04 <blogic> oh dear, i forgot winsock
Jan 21 11:58:09 <dtaht_nuc> you are lucky
Jan 21 11:58:17 * dtaht_nuc ran an isp 1993-1996
Jan 21 11:58:22 <blogic> well, i will have nightmares again tonight
Jan 21 11:58:30 <blogic> perv
Jan 21 11:58:31 <cyrusff> ping of death ;)
Jan 21 11:58:35 <blogic> cyrusff: lol
Jan 21 11:58:41 <blogic> cyrusff: windows 95
Jan 21 11:58:51 <cyrusff> yeah but they reintroduced that buf with ipv6 in recent windows
Jan 21 11:59:01 <cyrusff> probably ms nostalgia
Jan 21 11:59:03 <dtaht_nuc> I lost christmas 94? 95? to the ping of death.
Jan 21 11:59:06 <blogic> yeah
Jan 21 11:59:13 <dtaht_nuc> some bastard was rebooting all my boxes at 3AM
Jan 21 11:59:15 <dtaht_nuc> for a week
Jan 21 11:59:38 <dtaht_nuc> anyway, while I've been poking about, I've realized that procd was nice. (yea, welcome to 2013)
Jan 21 11:59:51 <blogic> thanks
Jan 21 11:59:58 <dtaht_nuc> and it looks like things like babel could get started from it, and thus restarted sanely?
Jan 21 12:00:06 <blogic> yes
Jan 21 12:00:19 <dtaht_nuc>         procd_open_instance
Jan 21 12:00:19 <dtaht_nuc>         procd_set_param command "$PROG" -I $PID_F $args $interfaces
Jan 21 12:00:19 <dtaht_nuc>         procd_close_instance
Jan 21 12:00:39 <dtaht_nuc> as I recall there was some horrid multi-word syntax in babel that needed sane quoting
Jan 21 12:00:43 <blogic> dtaht_nuc: ok, so now for the details
Jan 21 12:00:49 <blogic> automatic config reload
Jan 21 12:01:01 <blogic> have you seen it ?
Jan 21 12:01:08 <blogic> 1) edit a uci file
Jan 21 12:01:12 <blogic> 2) execute /sbin/reload_config
Jan 21 12:01:21 <blogic> 3) nothing else you need to do
Jan 21 12:01:24 <dtaht_nuc> oh, goody.
Jan 21 12:01:30 <blogic> all config has already been applied
Jan 21 12:01:35 * dtaht_nuc needs a uci file for xinetd then
Jan 21 12:01:38 <blogic> also, there is implict uci data vaidation
Jan 21 12:02:09 <blogic> inside a init.d file you can add validation info for a uci section and have procd validate it prior to starting the service
Jan 21 12:02:12 <blogic> :)
Jan 21 12:02:33 <blogic> dropbear is a simple example of how to do it
Jan 21 12:03:31 <dtaht_nuc> yea, well, I liked the extra protections (sensors, ip address restrictions) that xinetd had, so I went with that X years ago....
Jan 21 12:03:58 <dtaht_nuc> but I will look at the dropbear thing and start adopting procd wherever I can
Jan 21 12:04:43 * dtaht_nuc imagines procd can't listen on ports
Jan 21 12:05:24 <blogic> dtaht_nuc: not yet
Jan 21 12:05:31 <blogic> but i plan to eventually add a inetd
Jan 21 12:06:11 <dtaht_nuc> one of the things I'm big on is more actively protecting router from bad guys.
Jan 21 12:06:29 * dtaht_nuc read the code to procd this morning. Clean. Why didn't we invent json in the 80s?
Jan 21 12:06:39 * dtaht_nuc thinks of nfs rpc and shudders
Jan 21 12:06:43 <blogic> yes
Jan 21 12:06:54 <blogic> well he assumption is that json-c is safe
Jan 21 12:07:09 <blogic> if that holds true then the rpcd is pretty safe aswell aslong as the acl is in place
Jan 21 12:07:27 <dtaht_nuc> yep
Jan 21 12:07:36 <dtaht_nuc> I am going to go reboot now, see you in a bit
Jan 21 12:08:44 <blogic> good luck
Jan 21 12:09:02 <blogic> if we dont see you in an hour we will send an owrt technician
Jan 21 12:09:14 <dtaht_nuc> jhahahahahahaa
Jan 21 12:09:40 <dtaht_nuc> well, my simple attempt at adding babeld to procd just failed. was going to reboot anyway
Jan 21 12:09:45 <dtaht_nuc> bye
Jan 21 12:14:06 <OpenWrt-Commits> jogo r39357 trunk/target/linux/generic/files/crypto/ocf/Kconfig * kernel: ocf: add missing dependency for hifn driver
Jan 21 12:15:37 <dtaht_nuc> well, the good news is a build from openwrt head worked...
Jan 21 12:18:57 <blogic> dtaht_nuc: ok, ipv6 works
Jan 21 12:20:12 <Devastatr> ipv6 is so confusing :(
Jan 21 12:21:25 <dtaht_nuc> the bad news is doing a network reload with he enabled, there are a zillion processes created,  routes get created and decreated, I lose connectivity, even ipv4, and the universe spins out of control.
Jan 21 12:22:54 <blogic> yay
Jan 21 12:23:03 <blogic> dtaht_nuc: i just flashed HEAD onto a lantiq dsl router
Jan 21 12:23:19 <blogic> installed 6in4, set the he.net config and tyoed reload_config and i am online
Jan 21 12:24:11 <dtaht_nuc> yea. Did they ever fix the firmware on that puppy?
Jan 21 12:24:29 * dtaht_nuc will try reload_config
Jan 21 12:24:38 * dtaht_nuc nukes a ton of extra interfaces
Jan 21 12:24:46 * dtaht_nuc may not be back alive
Jan 21 12:31:35 <dtaht_nuc> well, watching all that activity go by with ip monitor was interesting. Didn't log it, but the end result for extra processes was
Jan 21 12:31:36 <dtaht_nuc> http://pastebin.com/AApymMR9
Jan 21 12:32:09 <dtaht_nuc> that hurt a lot. lets do that again!
Jan 21 12:32:46 <cyrusff> something looks wrong ;)
Jan 21 12:33:02 <cyrusff> i wonder whats happening
Jan 21 12:33:31 <cyrusff> can you paste a (censored) /etc/config/network?
Jan 21 12:36:32 <dtaht_nuc> my @!#!@#!@#! network file is here
Jan 21 12:36:34 <dtaht_nuc> http://pastebin.com/t1JX0Qfv
Jan 21 12:37:06 <dtaht_nuc> I disabled all but 2 interfaces in wifi.
Jan 21 12:37:35 <dtaht_nuc> I have now learned that once the system is this toasty, a reboot is required.
Jan 21 12:38:22 <dtaht_nuc> brb
Jan 21 12:38:53 <cyrusff> i'll try to put this config on my router later and see what happens
Jan 21 12:43:28 <dtaht_nuc> one other difference I have is that interfaces get renamed early in the boot process...
Jan 21 12:45:05 <dtaht_nuc> #!/bin/sh /etc/rc.common
Jan 21 12:45:06 <dtaht_nuc> START=05start() {
Jan 21 12:45:06 <dtaht_nuc>         /sbin/nameif
Jan 21 12:45:06 <dtaht_nuc> }
Jan 21 12:45:59 <dtaht_nuc> so that might be an issue.  I can stop doing that... but let me re-run this with ip monitor going
Jan 21 12:51:23 <blogic> renaming interfaces while netifd starts sound scary
Jan 21 12:51:39 <blogic> without knowing the internals i would out money on it that it will break
Jan 21 12:51:53 <blogic> that could also expalin your trizillion rouge processes
Jan 21 12:52:05 <dtaht_nuc> been working for a couple years
Jan 21 12:52:19 <blogic> i doubt that
Jan 21 12:52:20 <dtaht_nuc> http://pastebin.com/42hnKKxa is what happens to the route table while all the magic happens
Jan 21 12:52:27 <blogic> netfid is not a coupe of years old
Jan 21 12:52:52 <dtaht_nuc> ? nameif has been around way long
Jan 21 12:52:57 <blogic> yes
Jan 21 12:52:59 <blogic> netifd has not
Jan 21 12:53:14 <blogic> you claimed the netifd + nameif combo has worked for several years
Jan 21 12:53:21 <blogic> i beg to differ as netifd is not that old
Jan 21 12:53:35 <blogic> so it cannot have worked a couple of years ago
Jan 21 12:53:46 <blogic> half of the involved softare did not exist back then
Jan 21 12:53:52 <dtaht_nuc> ah. the netifd +  nameif combo has been working until last week. so far as I knew. better?
Jan 21 12:54:05 <stintel> blogic: did you read my message here about 39333 breaking logread?
Jan 21 12:54:15 <blogic> stintel: no
Jan 21 12:54:35 <stintel> ok, I had this in /e/c/system: option 'log_size' '256'
Jan 21 12:54:40 <stintel> commenting that fixed the problem
Jan 21 12:54:46 <blogic> ?
Jan 21 12:54:52 <blogic> commiting what ?
Jan 21 12:55:00 <blogic> you eepect me to invest time to fix it
Jan 21 12:55:02 <stintel> commenting
Jan 21 12:55:04 <stintel> option 'log_size' '256'
Jan 21 12:55:10 <blogic> i expect yu to speak understandable sentences
Jan 21 12:55:16 <KanjiMonster> commenting *out* likely ;p
Jan 21 12:55:21 <blogic> single words do not count as sentences
Jan 21 12:55:33 <blogic> KanjiMonster: that is not an english sentence either
Jan 21 12:55:38 <stintel> geez
Jan 21 12:55:56 <blogic> stintel: you want me to understand what you say ? then dont be scarce on the language usage
Jan 21 12:56:00 <KanjiMonster> I assume using "256" will cause it to use 256k log size thus hitting the 32k maximum ubus message limit problem
Jan 21 12:56:07 <jow_laptop> exactly
Jan 21 12:56:36 <jow_laptop> hitting the same ubus size constraint frequently while developing the luci2 stuff
Jan 21 12:56:42 <blogic> KanjiMonster: see, the proper use of the english language does make it easy
Jan 21 12:56:43 <dtaht_nuc> that was one of the other possible issue I thought I might be hitting myself
Jan 21 12:56:51 <jow_laptop> we need a clean mechanism for that
Jan 21 12:57:01 <stintel> 21|13:54:35 < stintel> ok, I had this in /e/c/system: option 'log_size' '256'
Jan 21 12:57:04 <jow_laptop> multipart messages or something
Jan 21 12:57:04 <stintel> 21|13:54:40 < stintel> commenting that fixed the problem
Jan 21 12:57:07 <stintel> people were able to understand it
Jan 21 12:57:29 <blogic> stintel: well blow me
Jan 21 12:57:30 * dtaht_nuc is not allergic to bufferbloat where it would be useful. is the ubus messages size a short or something?
Jan 21 12:57:30 <blogic> :)
Jan 21 12:57:34 <builder_> build #378 of iop32x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/378
Jan 21 12:57:46 <blogic> stintel: other can fix it then ... how abut that :)
Jan 21 12:58:00 <stintel> whatever
Jan 21 12:58:04 <jow_laptop> dtaht_nuc: its an arbritary size limit for now
Jan 21 12:58:04 <KanjiMonster> stintel: but only because some were willing to fill in the gaps with assumptions what you meant ;)
Jan 21 12:58:15 <dtaht_nuc> compiled in?
Jan 21 12:58:19 <jow_laptop> yes
Jan 21 12:58:29 <jow_laptop> libubus hardcodes it afair
Jan 21 12:58:35 <blogic> hmmmmm
Jan 21 12:58:37 * dtaht_nuc is not allergic to tweaking that right now...
Jan 21 12:58:46 <stintel> well excuse me for not mastering the English language 100%
Jan 21 12:58:53 <blogic> you did not try
Jan 21 12:58:56 <stintel> fuck sake
Jan 21 12:59:17 <blogic> that is what i thought
Jan 21 12:59:24 <KanjiMonster> blogic: maybe limit the actual buffer size in prod to whatever works until we fixed that (and omit a scary warning if one uses a larger value)?
Jan 21 12:59:45 <blogic> KanjiMonster: yes, i will make 2 options, one for log file size and one for internal buffer
Jan 21 12:59:48 <jow_laptop> imho ubus is in its current state simply not suitable for transporting large amounts of data
Jan 21 12:59:51 <blogic> then limit the internal buffer to 32k
Jan 21 12:59:58 <blogic> jow_laptop: ack
Jan 21 13:00:11 <jow_laptop> so we cannot really use it for logging
Jan 21 13:00:19 <blogic> jow_laptop: agreed
Jan 21 13:00:32 <blogic> or have a bulk stream interface or similar
Jan 21 13:00:36 <jow_laptop> or we need to adopt the netlink approach of fragmented messages
Jan 21 13:00:46 <blogic> that would also be an option
Jan 21 13:01:54 <KanjiMonster> I guess that would be the cleaner option, as this would allow some sort of implicit atomicity for fragmented messages?
Jan 21 13:02:03 <KanjiMonster> (no idea if this is true for netlink)
Jan 21 13:02:05 <jow_laptop> anyhow that limit will sooner or later hit other use cases
Jan 21 13:02:19 <jow_laptop> e.g. having a lot of netif managed prefixes or routes on an iface
Jan 21 13:02:35 <jow_laptop> will inflate the iface dump output enough to hit the ubus message limit
Jan 21 13:04:48 * dtaht_nuc clones ubus.git
Jan 21 13:06:27 <dtaht_nuc> #define UBUS_MAX_MSGLEN 65536
Jan 21 13:06:27 <dtaht_nuc> #define UBUS_SYSTEM_OBJECT_EVENT        1
Jan 21 13:06:27 <dtaht_nuc> #define UBUS_SYSTEM_OBJECT_MAX          1024
Jan 21 13:08:34 <dtaht_nuc> so this bit is 64k, not 32....
Jan 21 13:08:59 <jow_laptop> still 256 >> 64k
Jan 21 13:16:48 <builder_> build #457 of ar7 is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/457
Jan 21 13:21:00 <dtaht_nuc> well, there is a 16 bit seqno, but I don't see how #define UBUS_MAX_MSGLEN (512*1024)
Jan 21 13:21:23 <dtaht_nuc> wouldn't solve everything, these are unix sockets, don't think there's a datagram limit....
Jan 21 13:23:08 <blogic> jow_laptop: http://pastebin.com/qn8dqTLF
Jan 21 13:23:22 <blogic> how about that as a fix for stintel's bug report ?
Jan 21 13:23:34 <blogic> i am not sure if 512 is a safe value to use
Jan 21 13:25:44 * dtaht_nuc reboots again
Jan 21 13:48:08 * dtaht_nuc tries coming up on comcast
Jan 21 13:55:50 <jow_laptop> blogic: that would work
Jan 21 13:56:00 <blogic> kk
Jan 21 13:56:03 <blogic> will push it then
Jan 21 14:00:39 <builder_> build #408 of ar71xx is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/408
Jan 21 14:10:11 <builder_> build #60 of mvebu is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/60
Jan 21 14:25:48 <OpenWrt-Commits> wigyori r39358 trunk/target/linux/generic/config-3.13 * [3.13]: add missing symbols
Jan 21 14:27:33 <OpenWrt-Commits> wigyori r39359 trunk/target/linux/generic/files/drivers/net/phy/swconfig.c * modules: update swconfig.c to compile on 3.13 (compile-tested)
Jan 21 14:30:21 <KanjiMonster> wigyori: the error path for 3.13 looks wrong; I would assume if genl_register_family_with_ops() fails there is nothing to unregister and you can directly return the error
Jan 21 14:31:26 <wigyori> just spotted that
Jan 21 14:31:39 <wigyori> also the return 0 should be moved outside the if
Jan 21 14:33:04 <KanjiMonster> you can probably just do return genl_register_family_with_ops(&switch_fam, swconfig_ops); in the 3.13 path, but then it will complain about unused err or so ;)
Jan 21 14:33:17 <Devastatr> found a possible typo on this patch: [PATCH] lantiq: do an endianness swap to the RT2860 eeprom for ARV752DPW(22). He uses swap on the commit message, but his var is swab?!
Jan 21 14:33:19 <wigyori> the unregister: will be unused on 3.13, but i guess it won't hurt if i don't move it under an if linux_ver
Jan 21 14:33:27 <wigyori> hehe, yes :)
Jan 21 14:34:35 <Devastatr> nevermind, I guess swab means swap bytes
Jan 21 14:46:38 <OpenWrt-Commits> wigyori r39360 trunk/target/linux/generic/files/drivers/net/phy/swconfig.c
Jan 21 14:46:38 <OpenWrt-Commits> modules: swconfig.c: update the error path on 3.13, and behave nicely with return
Jan 21 15:22:39 <dtaht_nuc1> returning now to my task at hand, getting ipv6 to work.
Jan 21 15:24:33 <dtaht_nuc1> I did boot up and run on comcast ipv6 for the last hour. The only thing I had to do to make it work was enable some stuff in dnsmasq.conf, AND add a second ipv6 address to each internal interface. No RAs were sent internally until I did that. I'm going to reboot soon and see if there is merely a very long timeout until dnsmasq sees those, but perhaps my conf is merely wrong somewhere. pasting...
Jan 21 15:26:30 <dtaht_nuc1> http://pastebin.com/bTeP4FqZ
Jan 21 15:32:44 <dtaht_nuc1> cyrusff: did you also test to see if ras were being sent on the delegated interfaces?
Jan 21 15:35:07 <cyrusff> dtaht_nuc1: yes both RAs and DHCPv6 are working (with odhcpd)
Jan 21 15:44:00 * dtaht_nuc1 is stumped. dnsmasq should pick up the new addrs as assigned and start doing ras...
Jan 21 15:44:19 <dtaht_nuc1>     inet6 2601:3:8180:9a0::1/64 scope global dynamic
Jan 21 15:44:19 <dtaht_nuc1>        valid_lft 182420sec preferred_lft 182420sec
Jan 21 15:44:23 <dtaht_nuc1> didn't start doing ras
Jan 21 15:44:33 <dtaht_nuc1> did
Jan 21 15:44:34 <dtaht_nuc1>     inet6 2601:3:8180:9a0::2/64 scope global
Jan 21 15:44:34 <dtaht_nuc1>        valid_lft forever preferred_lft forever
Jan 21 15:45:08 <dtaht_nuc1> cyrusff: see my paste? http://pastebin.com/bTeP4FqZ
Jan 21 15:46:34 <KanjiMonster> dtaht_nuc1: are you using dnsmasq 2.68? 2.68 only does RA/dhcpv6 with constructor for "permanent" addresses (i.e. unlimited lifetime) (2.66 did not have this limitation, no idea about 2.67)
Jan 21 15:48:32 <KanjiMonster> this is supposedly to prevent dhcpv6/ras on autoassigned interfaces (e.g. from dhcpv6 or slaac)
Jan 21 15:48:54 <KanjiMonster> s/autoassigned/autoconfigured/
Jan 21 15:51:46 <dtaht_nuc1> Kanjimonster: 2.68
Jan 21 15:51:57 <KanjiMonster> there's your problem ;)
Jan 21 15:52:25 <dtaht_nuc1> this probably explains why it works for  cyrusff as he's probably on 2.67 or prior
Jan 21 15:52:57 <KanjiMonster> openwrt is still at 2.66
Jan 21 15:53:37 <dtaht_nuc1> ok, so, what's a good answer?
Jan 21 15:53:44 * dtaht_nuc1 goes looking for syntax
Jan 21 15:55:16 <KanjiMonster> dtaht_nuc1: remove the check that it is a permanent address (a flag that is set by the kernel for addresses with unlimited lifetime)
Jan 21 15:55:28 <KanjiMonster> e4cdbbf5218f6fa6d7b2b172091ddb0aa9ad3bfe is the commit that introduced the check
Jan 21 15:58:55 <dtaht_nuc1> meh. How about inserting the dhcp-pd derived addr with some other proto than static?
Jan 21 16:00:30 * dtaht_nuc1 goes to bug simon too
Jan 21 16:00:47 <KanjiMonster> dtaht_nuc1: http://88.73.137.4/~jonas/0001-allow-dhcp-range-construction-with-non-permanent-add.patch is what we use at T-Labs
Jan 21 16:02:04 <dtaht_nuc1> u rock, has this been discussed on dnsmasq-discuss?
Jan 21 16:02:10 <KanjiMonster> no, not yet
Jan 21 16:02:19 <KanjiMonster> didn't have the time yet for it
Jan 21 16:03:05 <builder_> build #432 of xburst is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/432
Jan 21 16:03:07 <dtaht_nuc1> Can I open that dicussion? I imagine you don't want that url in an email.
Jan 21 16:15:55 <cyrusff> dtaht_nuc1: it works for me because i don't use dnsmasq
Jan 21 16:16:04 <cyrusff> as in only for dns
Jan 21 16:17:09 <cyrusff> so default openwrt doesn't care about that as it doesn't use dnsmasq's RA or dhcpv6 features
Jan 21 16:20:17 <dtaht_nuc1> right, which is why I asked what the config should look like in that paste. if you turn dnsmasq dhcpv6 off?
Jan 21 16:21:13 <cyrusff> yeah just remove that dhcp-range and enable-ra lines from dnsmasq.conf and you're good to go
Jan 21 16:21:21 <dtaht_nuc1> that didn't work either. :/
Jan 21 16:21:25 <dtaht_nuc1> will try again in a sec
Jan 21 16:21:50 <dtaht_nuc1> reboot; exit
Jan 21 16:21:52 <dtaht_nuc1> ooos
Jan 21 16:21:54 <cyrusff> well then you need
Jan 21 16:22:05 <cyrusff> to add individual config section in /etc/config/dhcp
Jan 21 16:22:22 <cyrusff> for each logical interface: config dhcp 'wan6'
Jan 21 16:22:24 <cyrusff> option ra server
Jan 21 16:22:27 <cyrusff> option dhcpv6 server
Jan 21 16:22:44 <cyrusff> replace wan6 with se00,sw00 etc.
Jan 21 16:25:10 <cyrusff> dtaht_nuc: for each logical downstrean interface (sw00,se00, ...) add a section to /etc/config/dhcp: config dhcp 'sw00' \n option ra server \n option dhcpv6 server
Jan 21 16:25:25 <cyrusff> that should do the trick
Jan 21 16:30:49 <dtaht_nuc> option ndp hybrid and option master
Jan 21 16:30:50 <dtaht_nuc> ?
Jan 21 16:34:10 * dtaht_nuc reboots anyway
Jan 21 16:35:38 <dtaht_nuc> nifty.
Jan 21 16:36:48 <dtaht_nuc> yea. ipv6.
Jan 21 16:38:29 <dtaht_nuc> now all that's left is getting /128s assigned to ahcp mesh interfaces somehow but that can await another day. THANK YOU cyrusff, blogic, kanjimonster. I've been away from irc too long....
Jan 21 16:39:05 <cyrusff> no don't use master on downstrea interfaces
Jan 21 16:39:13 <dtaht_nuc> didn't just wan6
Jan 21 16:39:25 <cyrusff> yeah wan6 is upstrea
Jan 21 16:39:29 <cyrusff> +m
Jan 21 16:39:31 <dtaht_nuc> config dhcp 'wan6'
Jan 21 16:39:31 <dtaht_nuc> 	option dhcpv6 'server'
Jan 21 16:39:31 <dtaht_nuc> 	option ra 'server'
Jan 21 16:39:31 <dtaht_nuc> #	option ndp 'hybrid'
Jan 21 16:39:31 <dtaht_nuc> 	option master '1'
Jan 21 16:39:36 <cyrusff> ah ok
Jan 21 16:39:44 <dtaht_nuc> don't know what ndp does
Jan 21 16:39:57 <cyrusff> well if you use server it doesn't matter if you use master
Jan 21 16:40:13 <dtaht_nuc> does the gui respect this stuff?
Jan 21 16:40:19 <cyrusff> yes
Jan 21 16:40:24 <dtaht_nuc> groovy
Jan 21 16:40:42 <cyrusff> it even does static leases now using mac addresses
Jan 21 16:40:49 <cyrusff> for dhcpv6
Jan 21 16:41:11 <cyrusff> anyway hybrid mode (and ndp) is just for crappy ISPs / ISP routers that don't hand out PDs
Jan 21 16:41:26 <cyrusff> to create a virtual l3 bridge
Jan 21 16:41:46 <cyrusff> and use the same /64 on both sides of the router
Jan 21 16:41:48 <dtaht_nuc> for my next trick, after I slam this into my build... I will now observe everything "just work" with hurricane added.
Jan 21 16:41:50 <dtaht_nuc> got it
Jan 21 16:41:55 * dtaht_nuc is even happier
Jan 21 16:41:56 <dtaht_nuc> ping6 nuc
Jan 21 16:41:56 <dtaht_nuc> PING nuc (2601:3:8180:9a2::f3d): 56 data bytes
Jan 21 16:41:56 <dtaht_nuc> 64 bytes from 2601:3:8180:9a2::f3d: seq=0 ttl=64 time=2.518 ms
Jan 21 16:41:56 <dtaht_nuc> 64 bytes from 2601:3:8180:9a2::f3d: seq=1 ttl=64 time=1.119 ms
Jan 21 16:42:01 <cyrusff> cool
Jan 21 16:42:17 <dtaht_nuc> :crosses fingers:
Jan 21 16:43:04 <dtaht_nuc> should I use option sourcerouting '1' in the he tunnel?
Jan 21 16:43:42 <cyrusff> sourcerouting 1 is the default and creates source-restricted routes
Jan 21 16:43:55 <cyrusff> as described in emails yesterday / this morning
Jan 21 16:44:13 <cyrusff> if you set it to 0 you get a single old-fashioned non-souce-restricted default route
Jan 21 16:44:24 <dtaht_nuc> got it
Jan 21 16:45:33 <stintel> yay, now that my ISP started enabling IPv6 on a big chunk of its cable modems, my country is #2 world wide in IPv6 adoption \o/
Jan 21 16:46:24 <dtaht_nuc> kabooom
Jan 21 16:46:26 <stintel> let's hope more will follow :)
Jan 21 16:48:12 <blogic> stintel: what country is that ?
Jan 21 16:48:31 <dtaht_nuc> with he + comcast... roughly the same number of extra processes as before, all routes get clobbered, then rebuilt badly. he alone is same problem.
Jan 21 16:49:19 <dtaht_nuc> http://pastebin.com/ehkAbdbW
Jan 21 16:49:21 <stintel> blogic: Belgium
Jan 21 16:49:23 <dtaht_nuc> so he is stil broke
Jan 21 16:49:51 <blogic> dtaht_nuc: works very well here on trunk head
Jan 21 16:49:52 <stintel> blogic: the 2 largest ISPs here have enabled native IPv6 on their most recent modem types
Jan 21 16:49:57 <blogic> i wonder what the foobar is ...
Jan 21 16:50:10 <blogic> and that isp is belgacom ?
Jan 21 16:50:25 <stintel> Belgacom is one of the two. their customers with BBOX3 have v6 enabled
Jan 21 16:50:36 <stintel> BBOX2 and older will never support it. and you have to pay for a tradeup
Jan 21 16:50:56 <stintel> tradeup, tradein, dunno
Jan 21 16:51:14 <dtaht_nuc> well, my guess WAS that since I had 6 interfaces that I was overruning ubus.Certainly the system is pretty wedged at this point.
Jan 21 16:51:28 <stintel> Telenet is enabling it for the HGW3.0 type modems (eurodocsis 3.0 modem+router in one)
Jan 21 16:51:29 <dtaht_nuc> however this time I only have 3 interfaces up and the wan, still doing it.
Jan 21 16:52:16 <stintel> Telenet customers who use a modem will be later, but fortunately I work there and had mine enabled anyway
Jan 21 16:54:03 <blogic> stintel: did you open a bug in trac for the log_size issue ?
Jan 21 16:54:17 <blogic> i will push the fix now and would reference the bug and close it if you did
Jan 21 16:54:19 <stintel> no I did not. I wasn't sure what was wrong
Jan 21 16:54:23 <blogic> ok
Jan 21 16:54:24 <stintel> so I asked here first
Jan 21 17:01:31 <dtaht_nuc> does stuff in /etc/uci-defaults not get run (and deleted) on boot anymore?
Jan 21 17:02:09 <blogic> yes
Jan 21 17:02:10 <jow_laptop> its not deleted if the exit code is != 0
Jan 21 17:02:11 <blogic> on firstboot
Jan 21 17:02:24 <blogic> jow_laptop: i did not know that
Jan 21 17:02:39 <dtaht_nuc> well, didn't run, on 3 boots, didn't get deleted. I was using it to generate a ssl key for the gui.
Jan 21 17:02:46 <jow_laptop> maybe it failed
Jan 21 17:02:53 <dtaht_nuc> ran it by hand, worked.
Jan 21 17:02:56 <jow_laptop> race condition or something
Jan 21 17:03:10 <jow_laptop> time not set, whatever
Jan 21 17:03:55 <dtaht_nuc> could be. will check.
Jan 21 17:04:23 <dtaht_nuc> other tiny issue, ipv6 address for the router itself is not tossed into /tmp/hosts
Jan 21 17:10:59 <dtaht_nuc> patch
Jan 21 17:11:02 <dtaht_nuc> grump
Jan 21 17:20:31 <OpenWrt-Commits> juhosg r39361 trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-n750.c * ar71xx: mynet-n750: define LEDs connected to the AR8327 switch
Jan 21 17:28:16 <roh> hmmm... did somebody remove the mib counters from swconfig?
Jan 21 17:28:40 <roh> i thought i have seen them on a ar9331 already some time ago
Jan 21 17:28:40 <blogic> roh: check git log to see what was changed
Jan 21 17:29:25 <stintel> roh: works for me on RSPro with BB r39333
Jan 21 17:29:35 <dtaht_nuc> yea, it's probably the date in the ssl generation
Jan 21 17:31:12 <stintel> roh: maybe r39359 or r39360 caused it, if you are running an image that recent
Jan 21 17:34:51 <roh> r39047
Jan 21 17:35:44 <roh> maybe i am mistaken and its only on the gbit series
Jan 21 17:36:39 <roh> but i know the registers are there, so if the support is just missing.. maybe i'll take a look
Jan 21 17:36:43 <stintel> I could check on one of my rb2011's when Iget home
Jan 21 17:36:56 <stintel> I don't remember it either
Jan 21 17:37:03 <roh> could really use them right now. it seems my coreswitch sees jumboframes out of these aps
Jan 21 17:37:17 <roh> r35995 doesnt have it either
Jan 21 17:41:05 <roh> so i am propably mistaken
Jan 21 17:45:38 <roh> or it was some test or patch of lynxis
Jan 21 18:22:56 <builder_> build #427 of ixp4xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/427
Jan 21 18:52:40 <OpenWrt-Commits> florian r39362 trunk/target/linux/ brcm63xx/patches-3.10/341-MIPS-BCM63XX-add-support-for-BCM6318.patch brcm63xx/patches-3.10/339-MIPS-BCM63XX-add-support-for-BCM63268.patch * brcm63xx: improve BCM63268 support
Jan 21 18:52:59 <OpenWrt-Commits> florian r39363 trunk/target/linux/ brcm63xx/patches-3.10/557-board_bcm963269bhr.patch brcm63xx/patches-3.10/801-ssb_export_fallback_sprom.patch * brcm63xx: add support for BCM963269BHR board
Jan 21 18:53:15 <OpenWrt-Commits> florian r39364 trunk/target/linux/brcm63xx/config-3.10 * brcm63xx: enable support for BCM63268
Jan 21 19:55:23 <builder_> build #409 of ar71xx is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/409
Jan 21 20:52:15 <russell--> on soekris net4826: [ 1924.630564] kworker/0:2 invoked oom-killer: gfp_mask=0x201d0, order=0, oom_score_adj=0
Jan 21 20:52:26 <russell--> panic-panic-panic
Jan 21 21:01:53 <OpenWrt-Commits> blogic r39365 trunk/package/system/ubox/Makefile * ubox: update to latest git head
Jan 21 21:23:06 <russell--> [ 1699.632080] ieee80211 phy0: failed to copy skb for adhoc0
Jan 21 21:23:10 <russell--> a bunch of times
Jan 21 21:23:43 <russell--> then boom, oom
Jan 21 21:25:39 <russell--> ath5k is the radio driver
Jan 21 22:23:40 <builder_> build #182 of mpc85xx is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/182
Jan 21 23:53:20 <builder_> build #409 of au1000 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/409
Jan 22 00:19:29 <builder_> build #366 of adm5120 is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/366
**** ENDING LOGGING AT Wed Jan 22 02:59:59 2014