**** BEGIN LOGGING AT Fri Sep 25 02:59:59 2015
Sep 25 03:22:33 <rmilecki> russell--: sounds like some not-brcm47xx specific problem
Sep 25 03:22:49 <rmilecki> russell--: maybe try "make clean"?
Sep 25 03:22:54 <rmilecki> or even "make distclean"
Sep 25 03:39:55 <builder> build #101 of brcm47xx.legacy is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.legacy/builds/101
Sep 25 04:17:31 <rmilecki> russell--: or... maybe not
Sep 25 04:23:40 <OpenWrt-Commits> rmilecki r47047 trunk/target/linux/generic/files/crypto/ocf/ubsec_ssb/ubsec_ssb.c * kernel: crypto: fix ubsec_ssb.c compilation with 4.0+
Sep 25 04:23:40 <rmilecki> russell--: fixed ^^
Sep 25 04:40:23 <builder> build #100 of brcm47xx is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/100
Sep 25 04:43:08 <builder> build #100 of cobalt is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/100
Sep 25 04:46:15 <builder> build #100 of cns21xx is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/100
Sep 25 04:49:03 <builder> build #100 of orion is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/100
Sep 25 04:51:20 <russell--> rmilecki: thank you!
Sep 25 07:21:49 <rmilecki> russell--: thanks for testing & report
Sep 25 07:24:42 <heffer_> if I required a specific PATA driver in the x86 to boot a device from internal memory. would a patch upstream adding this to the x86-64 target likely be rejected because it's device specific?
Sep 25 07:25:05 <heffer> i was thinking about adding a subtarget with it's own config-default in that case
Sep 25 07:26:01 <heffer> specifically we're talking about a FSC Futro S550 thin client that has an embedded CF Card connected to an ATI Southbridge that requires the somewhat arcane pata_atiixp driver
Sep 25 07:26:19 <heffer> this driver needs to be built into the kernel, otherwise the rootfs will not be found
Sep 25 07:37:32 <rmilecki> russell--: i plan to upstream WGT634U NVRAM (env) support
Sep 25 07:37:41 <rmilecki> russell--: so we don't hit another regressions over and over
Sep 25 07:37:54 <rmilecki> russell--: i guess I'll need to ask you for some testing at some point
Sep 25 07:39:32 <jow_laptop> heffer: personally I would think including another patap driver would not hurt, therese little space constraints to worry about on x86/64
Sep 25 07:40:24 <jow_laptop> heffer: however I think kaloz wanted to keep the x86-64 bit generic clean, as in no legacy stuff so not sure whether he would object
Sep 25 07:41:05 <heffer> jow_laptop: okay. so i'll go ahead and submit a patch against target/linux/x86/64/config-default and see how that turns out
Sep 25 07:41:17 <heffer> more of a RFC then I guess :D
Sep 25 07:45:00 <russell--> rmilecki: happy to
Sep 25 07:45:48 <russell--> or i could just mail you one from my pile ;-)
Sep 25 07:46:26 <russell--> i still have some in shrink wrap, that was EOL'd 10 years ago, lol.
Sep 25 07:47:03 <russell--> mini-PCI + USB-host was rare back then
Sep 25 07:54:23 <jbj1> cyrusff: are you present? I've got an interesting thing happening with my ISP vis-a-vis ipv6
Sep 25 08:02:08 <cyrusff> jbj1: go ahead
Sep 25 08:02:54 <jbj1> cyrusff: so my ISP previously offered 6rd, which they advertise in the DHCPv4 options. now they also offer a more "normal" dual-stack with icmpv6 router-adverstisment showing Managed address setup
Sep 25 08:03:24 <jbj1> what I find is that the router automatically configures 6rd though rather than DHCPv6
Sep 25 08:03:38 <cyrusff> it should configure both actually
Sep 25 08:03:58 <SwedeMike> jbj1: if there is an option somewhere, tell it to use DHCPv6-PD
Sep 25 08:04:03 <jbj1> also, I was running odhcp6c manually and I noticed that with vanilla options their DHCPv6 server would only offer a single ipv6 address
Sep 25 08:04:41 <heffer> okay, i sent my patch :)
Sep 25 08:05:00 <jbj1> when I added the parameter to specify a prefix length, the dhcpv6 request included an IA_PD option and only then would they offer me a prefix
Sep 25 08:05:24 <cyrusff> so with -P0 you didn't get a prefix?
Sep 25 08:05:49 <jbj1> cyrusff: I didn't run it like that, just no param at all, but I can try it
Sep 25 08:05:58 <cyrusff> without param it doesn't ask for PD
Sep 25 08:06:03 <cyrusff> so you won't getone
Sep 25 08:06:20 <jbj1> no normally what would start odhcp6c and under what condition? netifd?
Sep 25 08:06:42 <cyrusff> depends on our /etc/config/network
Sep 25 08:07:11 <cyrusff> and your type of connection: ethernet, ppp, 3g etc.
Sep 25 08:07:27 <cyrusff> and your openwrt version ;)
Sep 25 08:08:29 <cyrusff> so let me know what you have installed and how you configured it
Sep 25 08:11:59 <jow_laptop> cyrusff: dhcpv6 autosetup only happens for ppp-like connections I guess?
Sep 25 08:12:17 <jbj1> cyrusff: so I'm running 15.05 release
Sep 25 08:12:58 <jbj1> and I had various /etc/config/network along the way... but at the moment it actually has proto=dhcpv6
Sep 25 08:13:04 <cyrusff> jow_laptop: ppp, and all the funny 3g/4g modem things
Sep 25 08:13:23 <cyrusff> basically you don't need a dhcpv6 section where you don't need a dhcp section
Sep 25 08:13:49 <jbj1> my connection is fairly vanilla, ie. I have a cable model and it comes up with a public IP via DHCPv6
Sep 25 08:14:05 <cyrusff> jbj1: okay, so if you have a proto=dhcpv6 section you should see an odhcp6c process running (given your ifname is correct)
Sep 25 08:14:24 <cyrusff> can you paste the dhcp and dhcpv6 sections?
Sep 25 08:14:26 <jbj1> interestingly I do not have an odhcp6c running which I found surprising
Sep 25 08:14:34 <jbj1> sure
Sep 25 08:15:28 <jbj1> ummm, there's sections for that in config/network?
Sep 25 08:15:40 <cyrusff> hmm?
Sep 25 08:15:45 <cyrusff> yeah
Sep 25 08:16:02 <cyrusff> netifd brings up what is in config/network
Sep 25 08:16:31 <jbj1> http://pastebin.com/AYs8fzQD that's config/network
Sep 25 08:16:53 <cyrusff> your wan6 is lacking an "option ifname"
Sep 25 08:16:54 <jow_laptop> jbj1: your wan6 interface lacks an ifname
Sep 25 08:17:00 <cyrusff> ;)
Sep 25 08:17:12 <cyrusff> just set it to eth0.2 as in the dhcp section
Sep 25 08:17:21 <jbj1> ok, lemee do that
Sep 25 08:18:13 <jbj1> ok, so I uci set/commit that, do I need /etc/init.d/networking reload?
Sep 25 08:18:20 <jow_laptop> ifup wan6
Sep 25 08:18:22 <jow_laptop> is enough
Sep 25 08:18:33 <cyrusff> nah need to do a reload first so netifd reloads uci?
Sep 25 08:18:47 <cyrusff> or does it do that on ifup?
Sep 25 08:18:47 <jow_laptop> cyrusff: happens implicitely on ifup
Sep 25 08:18:50 <cyrusff> ah okay
Sep 25 08:19:09 <cyrusff> if in doubt just run: reload_config
Sep 25 08:19:12 <cyrusff> ;)
Sep 25 08:19:27 <jbj1> ok so I see dhcp6c is running now, that's cool
Sep 25 08:19:36 <jow_laptop> jbj1: with -P0 ?
Sep 25 08:19:44 <cyrusff> you can type "ifstatus wan6" to see what you got
Sep 25 08:20:25 <jbj1> {
Sep 25 08:20:27 <jbj1> 	"up": false,
Sep 25 08:20:28 <jbj1> 	"pending": true,
Sep 25 08:20:30 <jbj1> 	"available": true,
Sep 25 08:20:31 <jbj1> 	"autostart": true,
Sep 25 08:20:33 <jbj1> 	"proto": "dhcpv6",
Sep 25 08:20:34 <jbj1> 	"device": "eth0.2",
Sep 25 08:20:36 <jbj1> 	"data": {
Sep 25 08:20:37 <jbj1> 		
Sep 25 08:20:39 <jbj1> 	}
Sep 25 08:20:40 <jbj1> }
Sep 25 08:20:42 <jbj1> sorry for the flood
Sep 25 08:21:03 <cyrusff> doesn't seem to have gotten a lease yet
Sep 25 08:21:31 <jbj1> I'm running tcpdump and I can see advertise
Sep 25 08:21:33 <jbj1> it's offering
Sep 25 08:21:42 <jbj1> I'll pastebin the packet info
Sep 25 08:21:44 <zorun> try logread
Sep 25 08:22:25 <jbj1> http://pastebin.com/NQKzeerX
Sep 25 08:23:30 <jbj1> not much useful in logread, I'll paste that as well
Sep 25 08:23:47 <jbj1> there's the logread: http://pastebin.com/db9qdZhv
Sep 25 08:24:55 <jbj1> does it have something to do with the fact that they are offering IA_ADDR as well?
Sep 25 08:24:57 <zorun> the DHCPv6 server replies with a ULA address, that's unusual
Sep 25 08:25:36 <jbj1> oh yeah I didn't notice that
Sep 25 08:25:57 <jbj1> perhaps odhcp6c doesn't even get the packet because it hasn't setup an ip on that ULA segment?
Sep 25 08:26:22 <jow_laptop> in any case its kind of an unexpected source for the dhcp reply I guess
Sep 25 08:26:52 <zorun> I think it's a firewall issue then
Sep 25 08:26:57 <jbj1> I can definitely see eth0.2 hasn't configured an address in that prefix
Sep 25 08:27:07 <jow_laptop> zorun: we do have explicit whitelist rules for dhcpv6 though
Sep 25 08:27:21 <zorun> jow_laptop: yes, but only from fe80::/10, it seems
Sep 25 08:27:25 <jbj1> though I think the ULA prefix was advertised in ICMPv6 router-advertise
Sep 25 08:27:37 <jow_laptop> jbj1: try the following
Sep 25 08:27:50 <jow_laptop> jbj1: edit /etc/config/firewall, find the "Allow-DHCPv6" rule
Sep 25 08:27:56 <zorun> :)
Sep 25 08:28:01 <jow_laptop> jbj1: comment out option src_ip 'fe80::/7'
Sep 25 08:28:07 <jow_laptop> jbj1: and proceed with fw3 reload
Sep 25 08:28:27 <jow_laptop> jbj1: then issue ifup wan6 to renegotiate dhcpv6
Sep 25 08:28:39 <jbj1> ok on it
Sep 25 08:29:02 <jow_laptop> right, fe80::/10. not /7
Sep 25 08:29:39 <cyrusff> hmm i'm wondering
Sep 25 08:30:19 <jbj1> what's comment in the config files, '#'?
Sep 25 08:30:52 <jow_laptop> yep
Sep 25 08:31:35 <zorun> right, RFC3315 doesn't seem to impose that servers must use a link-local address
Sep 25 08:31:43 <cyrusff> yeah i checked as well
Sep 25 08:31:59 <jbj1> here's the RA: http://pastebin.com/WC2SEhep
Sep 25 08:31:59 <cyrusff> though sending with a globally scoped address to a locally scoped on is odd
Sep 25 08:32:05 <zorun> yes
Sep 25 08:32:37 <jbj1> well, it's just replying to the same address it received from right?
Sep 25 08:32:57 <cyrusff> no the solicit was sent to a link-local multicast address
Sep 25 08:32:57 <jbj1> because my eth0.2 only has a link-local address configured
Sep 25 08:33:07 <cyrusff> ah well yeah
Sep 25 08:33:18 <cyrusff> but normally you use a link-local source address
Sep 25 08:33:24 <cyrusff> if you sent to alink-local destionation
Sep 25 08:33:52 <jbj1> sure, yeah, "normally" ;-)
Sep 25 08:34:00 <jbj1> so with the firewall rule change the address now comes up
Sep 25 08:34:39 <jbj1> it acquired and address and also a prefix that is now adverstised on br-lan
Sep 25 08:34:43 <jbj1> which is super cool
Sep 25 08:34:59 <jow_laptop> cyrusff: maybe we should use fc00::/6 instead of fe80::/10
Sep 25 08:35:22 <jow_laptop> that will cover both ula and link local space
Sep 25 08:35:25 <jbj1> I'm wondering if it will stop doing 6rd now then, that would be cool 'cause I don't wanna use that
Sep 25 08:35:49 <cyrusff> it will set up both but the native connection will have a better metric
Sep 25 08:36:36 <jbj1> is there any way I can force it to not use 6rd though? oh wait, I can probably just uninstall 6rd :-)
Sep 25 08:37:18 <cyrusff> "option iface6rd 0" in the dhcp-section
Sep 25 08:37:31 <jbj1> k00l
Sep 25 08:37:51 <jbj1> I dont' have that section in network, I just add it I guess eh?
Sep 25 08:38:04 <cyrusff> just add that option under the dhcp-section
Sep 25 08:38:04 <jow_laptop> jbj1: below you existing wan iface
Sep 25 08:38:10 <cyrusff> yeah the wan-section
Sep 25 08:38:22 <jow_laptop> jbj1: the one having proto dhcp
Sep 25 08:38:36 <cyrusff> jow_laptop: ack for fc00
Sep 25 08:40:17 <jbj1> ok that worked.
Sep 25 08:40:26 <jbj1> the 6rd interface went way. yay :-)
Sep 25 08:41:03 <cyrusff> jbj1: you mind telling us what isp that is?
Sep 25 08:41:11 <jbj1> StarHub (Singapore)
Sep 25 08:41:16 <cyrusff> okay thanks
Sep 25 08:41:44 <zorun> when tracerouting the IPv6 address in the pastebin, the last few hops are ULA
Sep 25 08:41:56 <zorun> maybe they don't have enough IPv6 addresses ;)
Sep 25 08:42:31 <OpenWrt-Commits> jow r47048 trunk/package/network/config/firewall/files/firewall.config * firewall: allow DHCPv6 traffic to/from fc00::/6 instead of fe80::/10
Sep 25 08:42:49 <jow_laptop> jbj1: you can do the same: change src_ip from fe80::/10 to fc00::/6
Sep 25 08:43:09 <jow_laptop> that will cover the entire "private" ipv6 address space
Sep 25 08:43:18 <jow_laptop> ula + link local
Sep 25 08:43:37 <jbj1> got it, on it
Sep 25 08:45:26 <zorun> I wonder if it's not a potential security issue
Sep 25 08:45:27 <jbj1> ugh, I don't have vi keystrokes memorized. that's what I get for being an emacs guy
Sep 25 08:45:38 <zorun> because spoofing an ULA address isn't hard
Sep 25 08:46:19 <jbj1> I suppose it could dynamically add rules for prefixes advertised by routers?
Sep 25 08:46:32 <jbj1> just ULA addrs that is
Sep 25 08:47:15 <cyrusff> zorun: i guess not harder than spoofing a link-local source?
Sep 25 08:47:22 <zorun> hmm, ok, there seems to be a unique identifier in DHCPv6 requests (XID)
Sep 25 08:48:04 <zorun> cyrusff: that's true, but I don't think a packet with a link-local source will be forwarded by a router
Sep 25 08:48:43 <cyrusff> well in any case, as long as i haven't screwed up the packet parsing it should be relatively fine
Sep 25 08:48:48 <cyrusff> ;)
Sep 25 08:49:16 <cyrusff> there is XID, server id and client id which essentially have to match once the client has a lease
Sep 25 08:49:26 <jbj1> sometimes I wish tcpdump could mark packets that get dropped by firewall rules :-)
Sep 25 08:49:43 <jbj1> or is there a fake interface that would just show me dropped packets?
Sep 25 08:49:53 <jbj1> tcpdump -i where_packets_go_to_die
Sep 25 08:50:06 <cyrusff> nah tcpdump happens before the firewall is involved
Sep 25 08:50:33 <cyrusff> you have to add a LOG target to the firewall
Sep 25 08:50:35 <jbj1> cyrussff: yeah it's pretty intuitive why it doesn't...
Sep 25 08:50:43 <zorun> From fe80::216:3eff:fe00:310 icmp_seq=1 Destination unreachable: Beyond scope of source address
Sep 25 08:50:54 <cyrusff> interesting
Sep 25 08:50:57 <zorun> that's when doing "ping6 -n -I fe80::ec4:7aff:fe4c:24d8%eth0 destination"
Sep 25 08:51:18 <zorun> and the router throwing the ICMPv6 error is the first router on the path to the destination
Sep 25 08:51:34 <zorun> (running Linux)
Sep 25 08:53:30 <builder> build #99 of pxa is complete: Failure [failed shell_10]  Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/99
Sep 25 09:14:54 <jbj1> cyrussff: another little question, I'm trying to help a guyin #openwrt, his ISP (a university) provides IPv6 via DHCPv6 but they don't give out IA_PD, only IA_ADDR. is there a way to get dnsmasq or something to forward requests from LAN to WAN and get an address for each client that way? is there even a way to make that work?
Sep 25 09:19:53 <zorun> I think you're looking for the relay mode
Sep 25 09:20:18 <cyrusff> http://wiki.openwrt.org/doc/uci/network6#router_advertisement_dhcpv6
Sep 25 09:20:23 <cyrusff> 3rd example
Sep 25 09:20:28 <cyrusff> with some luck it actually works
Sep 25 09:20:31 <cyrusff> ;)
Sep 25 09:20:34 <zorun> http://wiki.openwrt.org/doc/uci/network6#router_advertisement_dhcpv6
Sep 25 09:20:37 <cyrusff> other than that, could always use nat ;)
Sep 25 09:20:37 <zorun> too late :p
Sep 25 09:20:43 <cyrusff> :P
Sep 25 09:21:10 <zorun> cyrusff: last time I tried, the router tended to loose ND entries after a while, but I didn't investigate
Sep 25 09:21:27 <zorun> it seems quite hacky
Sep 25 09:21:31 <cyrusff> it is
Sep 25 09:21:37 <cyrusff> but i think that is fixed now
Sep 25 09:21:42 <zorun> ok :)
Sep 25 09:21:47 <cyrusff> some guy helped me debug it few months ago
Sep 25 09:22:16 <zorun> yeah, I don't think there's a clean way to do that, it basically emulating one L2 segment across two L2 segments...
Sep 25 09:22:24 <zorun> cool
Sep 25 09:26:34 <jbj1> zorun: so yeah I had him set relay-mode in the LAN DHCP IPv6 settings for both Router Advertisement-Service and DHCPv6 Service but that doesn't seem to work :-(
Sep 25 09:26:57 <cyrusff> you need to do ndp as well
Sep 25 09:27:08 <cyrusff> ra and dhcpv6 alone will not work
Sep 25 09:27:24 <jbj1> cyrusff: you know I don't think we tried that...
Sep 25 09:28:24 <cyrusff> your router needs to answer NDP on behalf of the client behind it, because the "ISP" assumes the /64 is directly reachable
Sep 25 09:30:36 <jbj1> right, yeah that makes sense
Sep 25 09:31:02 <jbj1> though shouldn't we have at least seen the outbound RS/DHCPv6 packets?
Sep 25 09:37:36 <Kaloz> morning
Sep 25 09:37:43 <Kaloz> heffer: I did object :)
Sep 25 09:41:34 <heffer> Kaloz: okay :) thanks for your feedback. are you maintainer of the x86-generic target as well or is that Felix?
Sep 25 09:43:58 <Kaloz> pretty much everyone, but jow_laptop pushed a lot of updates for it lately
Sep 25 09:44:54 <heffer> okay :) i'll just send the patches against x86-generic and see how that goes
Sep 25 09:51:40 <nbd> btw. memory addressing is not the only reason why one might want to use a 64 bit target on a 64 bit x86 cpu
Sep 25 09:52:25 <nbd> x86_64 has the advantage of not being so crippled in the number of cpu registers ;)
Sep 25 09:57:24 <heffer> i will test our use case with 32 and 64 bit to see if it makes any difference
Sep 25 09:58:47 <Kaloz> nbd: on a thin client with 1gb ram... ;)
Sep 25 09:58:54 <Kaloz> nbd: not everyone is as pervert as you ;)
Sep 25 10:00:14 <nbd> since you call me pervert, maybe i should call you fascist ;)
Sep 25 10:00:48 <nbd> the number of cpu registers is a performance factor regardless of the amount of RAM
Sep 25 10:01:15 <nbd> especially crypto code might benefit from those
Sep 25 10:02:46 <cyrusff> you also get more cpu instructions
Sep 25 10:02:57 <cyrusff> sse etc.
Sep 25 10:06:24 <Kaloz> cyrusff: heh? sse isn't 64bit specific
Sep 25 10:06:37 <Kaloz> cyrusff: it's there since like 98 or 99 :)
Sep 25 10:07:04 <cyrusff> sure but iirc it is madnatory for x64 isn't it?
Sep 25 10:07:11 <Kaloz> yeah, pentium 3, '99
Sep 25 10:07:13 <nbd> SSE is more limited on 32 bit
Sep 25 10:07:34 <Kaloz> well, nothing is mandatory, but you won't start removing support for instructions on newer cpus
Sep 25 10:07:36 <nbd> e.g. registers XMM8-XMM15 are only accessible in 64 bit mode
Sep 25 10:08:22 <cyrusff> iirc SSE and SSE2 are part of the base standard
Sep 25 10:08:27 <cyrusff> for x64
Sep 25 10:08:30 <cyrusff> you can't make that assumption for x86
Sep 25 10:11:13 <cyrusff> could even use x32 if you cared about pointer sizes
Sep 25 13:02:49 <attila_lendvai> so, I've made this package, all seems to work fine, except when I opkg remove it, then it leaves behind several directories (not files). is that something that should be fixed? if so, is there a way other than listing every directory using $(INSTALL_BIN) (assuming here that it records the required metainfo into the ipkg)
Sep 25 16:11:08 <karlp> what's the purpose of the 04_led_migration script? is that so that sysupgrade for devices that had different led names in the past work properly?
Sep 25 16:11:57 <jow_laptop> karlp: yes
Sep 25 16:12:14 <jow_laptop> any *_migration script in fact attempts to transform existing configs into new ones
Sep 25 16:13:24 <jow_laptop> it appears to do nothing though...
Sep 25 16:13:48 <jow_laptop> oh nvm, looked at its initial revision
Sep 25 16:14:15 <karlp> better hope nothing ever changes leds twice?
Sep 25 16:14:40 <jow_laptop> hm?
Sep 25 16:14:47 <jow_laptop> that script is deleted after firstboot
Sep 25 16:16:14 <karlp> it's a minor thing, but if the versions/leds names were AA:green, BB:fuschia and CC:purple, then the script can only ever handle one of the migrations, either AA->CC or BB->CC but not either to CC
Sep 25 16:16:43 <jow_laptop> yes
Sep 25 16:16:47 <karlp> all I need to know is I don't need t put anything in that file :)
Sep 26 02:57:42 <builder> build #92 of ramips.mt7620 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/92
**** ENDING LOGGING AT Sat Sep 26 02:59:59 2015