Hi Dave,
On Feb 8, 2014, at 04:52 , Dave Taht <[email protected]> wrote: > > On Feb 7, 2014 10:46 AM, "Sebastian Moeller" <[email protected]> wrote: > > > > Hi Mikael, hi Dave, > > > > On Feb 7, 2014, at 19:33 , Dave Taht <[email protected]> wrote: > > > > > get rid of the fd route, and or try traceroute with the -s option > > > > So on cerowrt (as secondary router) "traceroute ipv6.google.com" > > works just as well as traceroute -s my_wan_interface_IP6 ipv6.google.com. > > From the linux machine sitting in cero's se00 subnet, neither of these work. > The more correct test is -s my se00 address. From the linux machine: happy-horse:~ # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 28:92:4A:30:5D:BE inet addr:172.30.42.22 Bcast:172.30.42.31 Mask:255.255.255.224 inet6 addr: 2003:6b:f2a:9c01:2a92:4aff:fe30:5dbe/64 Scope:Global inet6 addr: fd65:570:d00e:1:2a92:4aff:fe30:5dbe/64 Scope:Global inet6 addr: fe80::2a92:4aff:fe30:5dbe/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:320829008 errors:0 dropped:0 overruns:0 frame:0 TX packets:166168903 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:469076940313 (447346.6 Mb) TX bytes:21392778864 (20401.7 Mb) Interrupt:18 happy-horse:~ # traceroute -s 2003:6b:f2a:9c01:2a92:4aff:fe30:5dbe ipv6.google.com traceroute to ipv6.google.com (2607:f8b0:4007:804::1003), 30 hops max, 80 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * happy-horse:~ # So that does not lead anywhere... > > Which doesn't have an address in your paste below. Sorry or not including it before; by the way is my assumption correct that happy-horse's global ip6 is 2003:6b:f2a:9c01:2a92:4aff:fe30:5dbe at least 2003:6b:f2a:9c0 is the prefix my telekom router distributes on its internal interfaces and 30:5dbe is part of happy-horse's mac address. Best Regards Sebastian > > > > > > > > > > > (and take this public please, I'm terribly buried right now) > > > > Oops, sorry Dave. I will try to keep this public. > > > > Best Regards > > sebastian > > > > > > > > On Fri, Feb 7, 2014 at 1:16 PM, Sebastian Moeller <[email protected]> wrote: > > >> Hi Mikael, > > >> > > >> On Feb 7, 2014, at 19:11 , Mikael Abrahamsson <[email protected]> wrote: > > >> > > >>> > > >>> What does "ip -6 a l" and "ip -6 r l" say? > > >> > > >> On cerowrt: > > >> root@nacktmulle:~# ip -6 a l > > >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 > > >> inet6 ::1/128 scope host > > >> valid_lft forever preferred_lft forever > > >> 2: se00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 > > >> inet6 fe80::a021:b7ff:feb9:5c22/64 scope link > > >> valid_lft forever preferred_lft forever > > >> 3: ge00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 > > >> inet6 2003:6b:f2a:9c01:a221:b7ff:feb9:5c23/64 scope global dynamic > > >> valid_lft 14328sec preferred_lft 1728sec > > >> inet6 fd65:570:d00e:1:a221:b7ff:feb9:5c23/64 scope global dynamic > > >> valid_lft 1814328sec preferred_lft 604728sec > > >> inet6 fe80::a221:b7ff:feb9:5c23/64 scope link > > >> valid_lft forever preferred_lft forever > > >> 6: ifb0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 32 > > >> inet6 fe80::8c4d:74ff:feea:d5e9/64 scope link > > >> valid_lft forever preferred_lft forever > > >> 14: gw11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 > > >> inet6 fe80::a221:b7ff:feb9:5c24/64 scope link > > >> valid_lft forever preferred_lft forever > > >> 15: gw01: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 > > >> inet6 fe80::a221:b7ff:feb9:5c22/64 scope link > > >> valid_lft forever preferred_lft forever > > >> 16: sw10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 > > >> inet6 fe80::a021:b7ff:feb9:5c24/64 scope link > > >> valid_lft forever preferred_lft forever > > >> 17: sw00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 > > >> inet6 fe80::a021:b7ff:feb9:5c22/64 scope link > > >> valid_lft forever preferred_lft forever > > >> 18: gw00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 > > >> inet6 fe80::a421:b7ff:feb9:5c22/64 scope link > > >> valid_lft forever preferred_lft forever > > >> 19: gw10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 > > >> inet6 fe80::a421:b7ff:feb9:5c24/64 scope link > > >> valid_lft forever preferred_lft forever > > >> > > >> > > >> root@nacktmulle:~# ip -6 r l > > >> default from :: via fe80::1 dev ge00 proto static metric 512 > > >> default from 2003:6b:f2a:9c01::/64 via fe80::1 dev ge00 proto static > > >> metric 512 > > >> default from fd65:570:d00e:1::/64 via fe80::1 dev ge00 proto static > > >> metric 512 > > >> fe80::/64 dev se00 proto kernel metric 256 > > >> fe80::/64 dev ge00 proto kernel metric 256 > > >> fe80::/64 dev sw00 proto kernel metric 256 > > >> fe80::/64 dev sw10 proto kernel metric 256 > > >> fe80::/64 dev gw00 proto kernel metric 256 > > >> fe80::/64 dev gw10 proto kernel metric 256 > > >> fe80::/64 dev ifb0 proto kernel metric 256 > > >> fe80::/64 dev gw01 proto kernel metric 256 > > >> fe80::/64 dev gw11 proto kernel metric 256 > > >> > > >> > > >> on the connected linux box: > > >> moeller@happy-horse:~> ip -6 r l > > >> 2003:6b:f2a:9c01::/64 dev eth0 proto kernel metric 256 expires > > >> 14387sec > > >> fd65:570:d00e:1::/64 dev eth0 proto kernel metric 256 expires > > >> 1814387sec > > >> fe80::/64 dev eth0 proto kernel metric 256 > > >> default via fe80::a021:b7ff:feb9:5c22 dev eth0 proto ra metric 1024 > > >> expires 167sec > > >> > > >> > > >> moeller@happy-horse:~> ip -6 a l > > >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 > > >> inet6 ::1/128 scope host > > >> valid_lft forever preferred_lft forever > > >> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 > > >> inet6 2003:6b:f2a:9c01:2a92:4aff:fe30:5dbe/64 scope global dynamic > > >> valid_lft 14383sec preferred_lft 1783sec > > >> inet6 fd65:570:d00e:1:2a92:4aff:fe30:5dbe/64 scope global dynamic > > >> valid_lft 1814383sec preferred_lft 604783sec > > >> inet6 fe80::2a92:4aff:fe30:5dbe/64 scope link > > >> valid_lft forever preferred_lft forever > > >> moeller@happy-horse:~> > > >> > > >> > > >>> > > >>> I'm nostly interested in if there is a route for the delegated prefix > > >>> or if DHCPv6-PD failed. > > >> > > >> What is your verdict, based on the information above? > > >> > > >> Best Regards > > >> Sebastian > > >> > > >> > > >>> > > >>> On Fri, 7 Feb 2014, Sebastian Moeller wrote: > > >>> > > >>>> Hi Dave, > > >>>> > > >>>> small update... > > >>>> > > >>>> from the router: > > >>>> root@nacktmulle:~# ping -6 -c 1 ipv6.google.com > > >>>> PING ipv6.google.com (2a00:1450:4008:801::1009): 56 data bytes > > >>>> 64 bytes from 2a00:1450:4008:801::1009: seq=0 ttl=57 time=70.764 ms > > >>>> > > >>>> --- ipv6.google.com ping statistics --- > > >>>> 1 packets transmitted, 1 packets received, 0% packet loss > > >>>> round-trip min/avg/max = 70.764/70.764/70.764 ms > > >>>> > > >>>> > > >>>> So it seems cerowrt itself has ip6 connectivity, and what fails is > > >>>> passing tho on to the connected networks/interfaces, at least partly, > > >>>> as my macbook gets: > > >>>> hms-beagle:test moeller$ ifconfig > > >>>> en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > > >>>> ether 68:a8:6d:3d:c5:8c > > >>>> inet6 fe80::6aa8:6dff:fe3d:c58c%en1 prefixlen 64 scopeid 0x5 > > >>>> inet6 fd65:570:d00e:1:6aa8:6dff:fe3d:c58c prefixlen 64 autoconf > > >>>> inet6 fd65:570:d00e:1:2998:55c2:d019:ad3c prefixlen 64 autoconf > > >>>> temporary > > >>>> inet6 2003:6b:f2a:9c01:6aa8:6dff:fe3d:c58c prefixlen 64 autoconf > > >>>> inet6 2003:6b:f2a:9c01:499c:a3dd:b91c:abc6 prefixlen 64 autoconf > > >>>> temporary > > >>>> inet 172.30.42.112 netmask 0xffffffe0 broadcast 172.30.42.127 > > >>>> media: autoselect > > >>>> status: active > > >>>> > > >>>> but: > > >>>> hms-beagle:test moeller$ ping6 -c 1 ipv6.google.com > > >>>> PING6(56=40+8+8 bytes) 2003:6b:f2a:9c01:499c:a3dd:b91c:abc6 --> > > >>>> 2a00:1450:4008:801::1003 > > >>>> > > >>>> --- ipv6.l.google.com ping6 statistics --- > > >>>> 1 packets transmitted, 0 packets received, 100.0% packet loss > > >>>> > > >>>> So somehow what used to be the default gateway under ip4 seems to be > > >>>> misconfigured... > > >>>> > > >>>> > > >>>> On Feb 6, 2014, at 22:06 , Dave Taht <[email protected]> wrote: > > >>>> > > >>>>> Changing the title of this thread as it's forked something incredible. > > >>>>> > > >>>>> On Thu, Feb 6, 2014 at 2:41 PM, Sebastian Moeller <[email protected]> > > >>>>> wrote: > > >>>>>> Hi Mikael, > > >>>>>> > > >>>>>> thank you so much. I got a bit further, by enabling relaying I now > > >>>>>> routinely get IP6 addresses on the connected machines. > > >>>>> > > >>>>>> Note to Dave, in /et/config/dhcp I replaced the 'server' occurrences > > >>>>>> with 'hybrid', under the assumption that hybrid will act as server > > >>>>>> if a prefix was delegated and fall back to relay if not; might be > > >>>>>> interesting to test whether this also works with comcast's IP6). > > >>>>> > > >>>>> Well, hybrid is there to work with dnsmasq mostly, so in that case you > > >>>>> need to enable dnsmasq's handling of RAs in /etc/dnsmasq.conf. > > >>>> > > >>>> From > > >>>> http://wiki.openwrt.org/doc/uci/network6#native.ipv6.connection it > > >>>> looks like hybrid tries PD first and then falls back to relay (but I > > >>>> do not claim I understand any of this) > > >>>> > > >>>> Router Advertisement & DHCPv6 > > >>>> > > >>>> OpenWrt features a versatile RA & DHCPv6 server and relay. Per default > > >>>> SLAAC, stateless and stateful DHCPv6 are enabled on an interface. If > > >>>> there are prefix of size /64 or greater present then addresses will be > > >>>> handed out from each prefix. If all prefixes on an interface have a > > >>>> size greater /64 then DHCPv6-Prefix Delegation is enabled for > > >>>> downstream-routers. If a default route is present the router > > >>>> advertises itself as default router on the interface. > > >>>> > > >>>> OpenWrt is also able to detect when there is no prefix available from > > >>>> an upstream interface and can switch into relaying mode automatically > > >>>> to extend the upstream interface configuration onto its downstream > > >>>> interfaces. This is useful for putting an OpenWrt behind another > > >>>> IPv6-router which doesn't offer prefixes via DHCPv6-PD. > > >>>> > > >>>> Example configuration section (/etc/config/dhcp) > > >>>> > > >>>> config dhcp lan > > >>>> option dhcpv6 hybrid > > >>>> option ra hybrid > > >>>> option ndp hybrid > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> > > >>>>> Still, there should be a way to correctly configure ND proxying in a > > >>>>> multi-lan environment in the base system with odhcpd. > > >>>> > > >>>> I think the "option ndp 'something'" are missing in 3.10.28-1, the > > >>>> version I am still using... > > >>>> > > >>>>> I think looking > > >>>>> at the original openwrt configuration for such might be productive. > > >>>> > > >>>> Good idea, I will try my luck and report back if there is anything > > >>>> new. > > >>>> > > >>>>> > > >>>>> But it is still not the correct way to get /60s. It's not clear to me > > >>>>> if DT is using 6rd or not. > > >>>> > > >>>> Nor do I, what I learned is supposedly they assign a /64 to the > > >>>> modem/router, and then use PD to delegate a /56; but their supplied > > >>>> modem/router only hands out /64 to connected machines. (And I am lost > > >>>> in IP6, I would have guessed that a /64 should be plenty to subnet for > > >>>> cerowrt's needs ;) ) > > >>>> How would I test for 6rd? According to wikipedia I should expect > > >>>> substrings of the IP4 to show up in the IP6, but I do not really see > > >>>> this > > >>>> My current public IP4 address is: 217.86.112.208 (in hex: D9.56.70.D0) > > >>>> And my current IP6 prefix is: 2003:6b:f2a:9c00:: /56 > > >>>> the primary (non-cerowrt) routers internal IP6 is: > > >>>> 2003:6b:f2a:9c01:366b:d3ff:fe45:4937/64 (LAN) > > >>>> the primary (non-cerowrt) routers external IP6 is : > > >>>> 2003:6b:f7f:aaa6:366b:d3ff:fe45:4938/64 (WAN) > > >>>> > > >>>> Does that tell you anything? > > >>>> > > >>>> > > >>>>> > > >>>>> I have discovered that several forms of tunnelling no longer work > > >>>>> (sigh, 1 step forward, 2 back) on networks like AT&Ts. This shows some > > >>>>> documentation on how people used to get 6rd up on AT&T > > >>>>> > > >>>>> https://www.tunnelbroker.net/forums/index.php?topic=2293.0 > > >>>>> > > >>>>> And this reports it broken. > > >>>>> > > >>>>> http://www.dslreports.com/forum/r28530086-AT-T-now-blocking-IPv6-tunnels > > >>>>> > > >>>>> I have ordered a ipv6 capable dsl box for the one AT&T based network I > > >>>>> have access to. > > >>>>> > > >>>>> I still haven't got hurricane electric to work again on comcast, > > >>>>> either, since I got an ipv6 capable modem. This has caused all sorts > > >>>>> of renumbering headaches... and I don't know what to point fingers at. > > >>>> > > >>>> interesting, I have not tried a tunnel yet (and would prefer to avoid > > >>>> that since native ip6 seems just a grasp away ;) ) > > >>>> > > >>>>> > > >>>>> > > >>>>>> What does not work at all is routing, none of the mains with IP6 > > >>>>>> addresses after and >including the cerowrt router can actually reach > > >>>>>> the internet via ip6. When I connect my >laptop (macosx 10.8.5) > > >>>>>> directly to the DT supplied modem/router I get working p6 > > >>>>>> >connectivity to the internet according to http://test-ipv6.com, the > > >>>>>> same test fails behind >the cerowrt router. > > >>>>> > > >>>>> ip -6 route show would help on the cero box and the host. > > >>>> > > >>>> Okay, so here is cerowrt: > > >>>> root@nacktmulle:~# ip -6 route > > >>>> default from :: via fe80::1 dev ge00 proto static metric 512 > > >>>> default from 2003:6b:f2a:9c01::/64 via fe80::1 dev ge00 proto static > > >>>> metric 512 > > >>>> default from fd65:570:d00e:1::/64 via fe80::1 dev ge00 proto static > > >>>> metric 512 > > >>>> fe80::/64 dev se00 proto kernel metric 256 > > >>>> fe80::/64 dev ge00 proto kernel metric 256 > > >>>> fe80::/64 dev sw00 proto kernel metric 256 > > >>>> fe80::/64 dev sw10 proto kernel metric 256 > > >>>> fe80::/64 dev gw00 proto kernel metric 256 > > >>>> fe80::/64 dev gw10 proto kernel metric 256 > > >>>> fe80::/64 dev ifb0 proto kernel metric 256 > > >>>> fe80::/64 dev gw01 proto kernel metric 256 > > >>>> fe80::/64 dev gw11 proto kernel metric 256 > > >>>> > > >>>> and here from happy-horse (my linux box on se00): > > >>>> moeller@happy-horse:~> ip -6 route > > >>>> 2003:6b:f2a:9c01::/64 dev eth0 proto kernel metric 256 expires > > >>>> 14360sec > > >>>> fd65:570:d00e:1::/64 dev eth0 proto kernel metric 256 expires > > >>>> 1814360sec > > >>>> fe80::/64 dev eth0 proto kernel metric 256 > > >>>> default via fe80::a021:b7ff:feb9:5c22 dev eth0 proto ra metric 1024 > > >>>> expires 140sec > > >>>> > > >>>> with: > > >>>> moeller@happy-horse:~> sudo /sbin/ifconfig > > >>>> root's password: > > >>>> eth0 Link encap:Ethernet HWaddr 28:92:4A:30:5D:BE > > >>>> inet addr:172.30.42.22 Bcast:172.30.42.31 Mask:255.255.255.224 > > >>>> inet6 addr: 2003:6b:f2a:9c01:2a92:4aff:fe30:5dbe/64 Scope:Global > > >>>> inet6 addr: fd65:570:d00e:1:2a92:4aff:fe30:5dbe/64 Scope:Global > > >>>> inet6 addr: fe80::2a92:4aff:fe30:5dbe/64 Scope:Link > > >>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > >>>> RX packets:181875378 errors:0 dropped:0 overruns:0 frame:0 > > >>>> TX packets:96658636 errors:0 dropped:0 overruns:0 carrier:0 > > >>>> collisions:0 txqueuelen:1000 > > >>>> RX bytes:265753690758 (253442.4 Mb) TX bytes:15245790971 > > >>>> (14539.5 Mb) > > >>>> Interrupt:18 > > >>>> > > >>>> happy-horse cannot ping6 : > > >>>> moeller@happy-horse:~> ping6 -c1 ipv6.google.com > > >>>> PING ipv6.google.com(lax04s08-in-x00.1e100.net) 56 data bytes > > >>>> > > >>>> --- ipv6.google.com ping statistics --- > > >>>> 1 packets transmitted, 0 received, 100% packet loss, time 0ms > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> > > >>>>>> Unfortunately the ip6 handling of openwrt currently seems in heavy > > >>>>>> >flux and the documentations is a bit behind, so it is a nice > > >>>>>> challenge to get this going. > > >>>>> > > >>>>> No kidding. > > >>>> > > >>>> It looks like somethings got just fixed in odhcpd that might be > > >>>> relevant: > > >>>> https://github.com/sbyx/odhcpd/commit/b618ad5373ae619e3d01a49f2c672a8cc1dc59a6 > > >>>> > > >>>> I am impressed by the rate of change in openwrt currently, and the > > >>>> amount of infrastructure work they are doing but it makes the learning > > >>>> curve almost vertical given the lag of the documentation... > > >>>> > > >>>>> > > >>>>>> Getting information "straight from the horse's mouths" obviously > > >>>>>> would be really great. > > >>>>> > > >>>>> We'll get it sorted as time allows. Exciting times! > > >>>> > > >>>> Great. My internet works really well, in a big part thanks to your > > >>>> great work on cerowrt. Getting ip6 to work is not urgent for me, so > > >>>> please do not waste too much time on this (my secret hope is that is > > >>>> going to be fixed magically by openwrt upstream if we wait long enough > > >>>> ;) ) > > >>>> > > >>>> Best Regards > > >>>> Sebastian > > >>>> > > >>>>> > > >>>>>> Thanks for you help > > >>>>>> Best Regards > > >>>>>> Sebastian > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On Feb 6, 2014, at 15:14 , Mikael Abrahamsson <[email protected]> > > >>>>>> wrote: > > >>>>>> > > >>>>>>> > > >>>>>>> I forwarded this internally but I have yet to receive a response. > > >>>>>>> I'll ping them again. > > >>>>>>> > > >>>>>>> On Sun, 26 Jan 2014, Dave Taht wrote: > > >>>>>>> > > >>>>>>>> I don't know a lot about DT and their ipv6 support. > > >>>>>>>> > > >>>>>>>> It sounds like they are not using dhcpv6pd, or there is some other > > >>>>>>>> option > > >>>>>>>> you need to supply. > > >>>>>>>> > > >>>>>>>> Perhaps Mikael (ccd) knows. > > >>>>>>>> On Jan 26, 2014 3:42 PM, "Sebastian Moeller" <[email protected]> > > >>>>>>>> wrote: > > >>>>>>>> > > >>>>>>>>> Hi Dave, > > >>>>>>>>> > > >>>>>>>>> so 3.10.28-1 seems to work quite well (if I do not jinx anything > > >>>>>>>>> by saying > > >>>>>>>>> after only 1 hour testing ;) ). > > >>>>>>>>> > > >>>>>>>>> Doing: > > >>>>>>>>> ./netperf-wrapper -l 60 -H gw.home.lan rrul -p all_scaled > > >>>>>>>>> -disable-log -t > > >>>>>>>>> hms-beagle_cerowrt3.10.21-1_2_nacktmulle > > >>>>>>>>> > > >>>>>>>>> still earns me: > > >>>>>>>>> [ 1473.128906] ath: phy1: Failed to stop TX DMA, queues=0x00e! > > >>>>>>>>> root@nacktmulle:~# cat > > >>>>>>>>> /sys/kernel/debug/ieee80211/phy1/ath9k/reset > > >>>>>>>>> Baseband Hang: 0 > > >>>>>>>>> Baseband Watchdog: 0 > > >>>>>>>>> Fatal HW Error: 0 > > >>>>>>>>> TX HW error: 0 > > >>>>>>>>> TX Path Hang: 1 > > >>>>>>>>> PLL RX Hang: 0 > > >>>>>>>>> MCI Reset: 0 > > >>>>>>>>> > > >>>>>>>>> But this is not changed. Unaligned instructions are still at 0, > > >>>>>>>>> by the way. > > >>>>>>>>> > > >>>>>>>>> Now, me biggest question is how can I join the ip6 fun? My ISP > > >>>>>>>>> deutsche telekom supplies my primary router/modem combo (supplied > > >>>>>>>>> by > > >>>>>>>>> telekom) with a /56 as far as I know, this router however only > > >>>>>>>>> passes /64s > > >>>>>>>>> on, so cerowrt sees: > > >>>>>>>>> Address: 2003:6b:f2a:9c01:a221:b7ff:feb9:5c23/64 > > >>>>>>>>> Gateway: FE80:0:0:0:0:0:0:1 > > >>>>>>>>> Connected: 0h 30m 31s > > >>>>>>>>> > > >>>>>>>>> But the other interfaces see nothing (from log read): > > >>>>>>>>> Sun Jan 26 21:19:00 2014 daemon.warn odhcpd[965]: A default route > > >>>>>>>>> is > > >>>>>>>>> present but there is no public prefix on sw10 thus we don't > > >>>>>>>>> announce a > > >>>>>>>>> default route! > > >>>>>>>>> > > >>>>>>>>> Do you, by chance know what I did wrong? (Or is a /64 too little?) > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> best regards > > >>>>>>>>> Sebastian > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On Jan 26, 2014, at 20:15 , Dave Taht <[email protected]> wrote: > > >>>>>>>>> > > >>>>>>>>>> Yea I think it was 2. > > >>>>>>>>>> > > >>>>>>>>>> I have been running with 1 to no messages thanks for looking it > > >>>>>>>>>> up. :-) > > >>>>>>>>>> > > >>>>>>>>>> I put out a 3.10.28-1 today in the comcast subdir. > > >>>>>>>>>> > > >>>>>>>>>> Ssh... Don't tell anyone. > > >>>>>>>>>> > > >>>>>>>>>> Toatally untested has all the procd work to date in it although > > >>>>>>>>>> I may > > >>>>>>>>> have goofed on rngd.... > > >>>>>>>>>> > > >>>>>>>>>> Getting on a plane in 2 hrs. > > >>>>>>>>>> > > >>>>>>>>>> On Jan 26, 2014 1:42 PM, "Sebastian Moeller" <[email protected]> > > >>>>>>>>>> wrote: > > >>>>>>>>>> Hi Dave, > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> On Jan 24, 2014, at 18:06 , Dave Taht <[email protected]> > > >>>>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>>> On Tue, Jan 21, 2014 at 3:59 PM, Dave Taht <[email protected]> > > >>>>>>>>> wrote: > > >>>>>>>>>>>> This is a special release intended only for comcast users with > > >>>>>>>>>>>> ipv6 > > >>>>>>>>>>>> capable modems and CMTSes. > > >>>>>>>>>>> > > >>>>>>>>>>> There have been several testers getting back to me privately. > > >>>>>>>>>>> All > > >>>>>>>>> report > > >>>>>>>>>>> good results IF you reflash from scratch. > > >>>>>>>>>>> > > >>>>>>>>>>> the biggest problem people have had is the switch to https vs > > >>>>>>>>>>> http > > >>>>>>>>>>> for the gui, their webbrowsers' cache rewrite the url back to > > >>>>>>>>>>> http, > > >>>>>>>>>>> and lighttpd, > > >>>>>>>>>>> unlike apache, doesn't give any sign as to why the connection is > > >>>>>>>>>>> not working. > > >>>>>>>>>>> > > >>>>>>>>>>> remember: https://gw.home.lan:81 from now on... > > >>>>>>>>>>> ^^ > > >>>>>>>>>>>> NOTE: If you are running any form of tunneling for ipv6 (e.g. > > >>>>>>>>> hurricane) > > >>>>>>>>>>>> do NOT try this release, as it breaks badly. > > >>>>>>>>>>> > > >>>>>>>>>>> It turns out that source-specific routing for he tunneling is > > >>>>>>>>>>> what is > > >>>>>>>>> broken. > > >>>>>>>>>>> It's not broken if you turn off sourcerouting in the 6in4 > > >>>>>>>>> /etc/config/network > > >>>>>>>>>>> stanza by adding > > >>>>>>>>>>> > > >>>>>>>>>>> option sourcerouting '0' > > >>>>>>>>>>> > > >>>>>>>>>>> The bug is also specific to cerowrt. the openwrt folk report it > > >>>>>>>>>>> works > > >>>>>>>>> for them. > > >>>>>>>>>>> > > >>>>>>>>>>> As a temporary workaround, IF you try this unrelease and still > > >>>>>>>>>>> want a > > >>>>>>>>> tunnel > > >>>>>>>>>>> up, add the above to your 6in4 configuration. Hopefully we'll > > >>>>>>>>>>> find an > > >>>>>>>>> answer > > >>>>>>>>>>> soon, sourcerouting solves a whole raft of other problems if > > >>>>>>>>>>> applied > > >>>>>>>>>>> consistently. > > >>>>>>>>>>> > > >>>>>>>>>>> I am otherwise pretty happy with this unrelease, I've been > > >>>>>>>>>>> running it > > >>>>>>>>> all week, > > >>>>>>>>>>> with only 4 instruction traps in the last 20 hours. > > >>>>>>>>>>> > > >>>>>>>>>>> Finding these last instruction traps is going to be a PITA. Can > > >>>>>>>>>>> I > > >>>>>>>>> encourage > > >>>>>>>>>>> people to add this to their config? > > >>>>>>>>>>> > > >>>>>>>>>>> echo 1 > /sys/kernel/debug/mips/unaligned_action > > >>>>>>>>>> > > >>>>>>>>>> Since I am about to upgrade to 3.10.26-7 (the syncs are not done > > >>>>>>>>>> but I > > >>>>>>>>> had to stop them temporarily anyway) do you mean > > >>>>>>>>>> > > >>>>>>>>>> echo 2 > /sys/kernel/debug/mips/unaligned_action > > >>>>>>>>>> > > >>>>>>>>>> as according to http://www.linux-mips.org/wiki/Alignment > > >>>>>>>>>> Mode Action > > >>>>>>>>>> 0 silently fixup the unaligned access > > >>>>>>>>>> 1 send SIGBUS > > >>>>>>>>>> 2 dump registers, process name, etc. and fixup > > >>>>>>>>>> > > >>>>>>>>>> and the last seems to be the most convenient for finding the > > >>>>>>>>>> culprits > > >>>>>>>>> yet having a still functional router; then again I might have > > >>>>>>>>> gotten this > > >>>>>>>>> wrong. Please advise > > >>>>>>>>>> > > >>>>>>>>>> Best Regards > > >>>>>>>>>> Sebastian > > >>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> and check their logfile once in a while, perhaps we can isolate > > >>>>>>>>>>> where > > >>>>>>>>> and > > >>>>>>>>>>> why it happens. > > >>>>>>>>>>> > > >>>>>>>>>>> I went to town last night adding procd support to various easy > > >>>>>>>>>>> daemons, > > >>>>>>>>>>> it gets simpler after the first 3... > > >>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/comcast/3.10.26-7/ > > >>>>>>>>>>>> > > >>>>>>>>>>>> I strongly recommend all cerowrt users on comcast, upgrade.[1] > > >>>>>>>>>>>> > > >>>>>>>>>>>> If you are on comcast and dare not upgrade to this, comment > > >>>>>>>>>>>> out these > > >>>>>>>>>>>> lines in /etc/config/network > > >>>>>>>>>>>> > > >>>>>>>>>>>> #config interface ge01 # wan6 on some release. > > >>>>>>>>>>>> # option ifname @ge00 > > >>>>>>>>>>>> # option proto dhcpv6 > > >>>>>>>>>>>> # option 'broadcast' '1' > > >>>>>>>>>>>> # option 'metric' '2048' > > >>>>>>>>>>>> # option 'reqprefix' '60' > > >>>>>>>>>>>> > > >>>>>>>>>>>> and reboot to disable dhcpv6 on the external interface > > >>>>>>>>>>>> entirely. > > >>>>>>>>>>> > > >>>>>>>>>>> I still recomend that everyone on comcast & not running this > > >>>>>>>>>>> release > > >>>>>>>>> do this. > > >>>>>>>>>>> > > >>>>>>>>>>>> I have been having flashbacks to the IPX/SPX transition... but > > >>>>>>>>>>>> it > > >>>>>>>>>>>> really did bring a tear to my eye to finally have ipv6 > > >>>>>>>>>>>> connectivity > > >>>>>>>>>>>> for the first time, native. And to see no real difference in > > >>>>>>>>>>>> RTT > > >>>>>>>>>>>> between ipv4 and v6. > > >>>>>>>>>>>> > > >>>>>>>>>>>> http://snapon.lab.bufferbloat.net/~d/bev/comcast_native_ipv6/ > > >>>>>>>>>>>> > > >>>>>>>>>>>> Oh brave new world that may have new protocols in it. > > >>>>>>>>>>>> > > >>>>>>>>>>>> A bunch of other stuff landed in cero, and if you are not > > >>>>>>>>>>>> tunneling, > > >>>>>>>>>>>> and your spouse and family are willing, you can try: > > >>>>>>>>>>>> > > >>>>>>>>>>>> + openwrt sync from head > > >>>>>>>>>>>> + RA spamming filter stopping mega firewall reloads on comcast > > >>>>>>>>>>>> ipv6 - > > >>>>>>>>>>>> thx steven barth! > > >>>>>>>>>>>> + switch from dnsmasq to using odhcpd for ipv6 RAs (thx > > >>>>>>>>>>>> #openwrt!) > > >>>>>>>>>>>> + Comcast ipv6 actually tested by me > > >>>>>>>>>>>> + GUI is now https - thx sebastian! (we still have some work > > >>>>>>>>>>>> left > > >>>>>>>>> here) > > >>>>>>>>>>>> For snowden points, it also does perfect forward secrecy. > > >>>>>>>>>>>> + GUI has selectable skins (pick one, any one) > > >>>>>>>>>>>> + SQM starts correctly on boot and other restarts > > >>>>>>>>>>>> + SQM now scales better to higher rates > > >>>>>>>>>>>> + updated on-board documentation ( example: > > >>>>>>>>>>>> http://cero2.bufferbloat.net/cerowrt/index.html ) > > >>>>>>>>>>>> + updated uftp, ccnx, new libnettle package (for dnsmasq 2.69) > > >>>>>>>>>>>> - thx > > >>>>>>>>>>>> stephen walker > > >>>>>>>>>>>> + sysupgrade fixed > > >>>>>>>>>>>> > > >>>>>>>>>>>> on the minus side > > >>>>>>>>>>>> > > >>>>>>>>>>>> - We still have some timing problems in picking up the RAs, > > >>>>>>>>>>>> particularly from wifi. > > >>>>>>>>>>>> If you don't get ipv6 addresses on your wifi client after a > > >>>>>>>>>>>> fresh > > >>>>>>>>>>>> boot of cero, > > >>>>>>>>>>>> reconnect the wifi client. After cero is fully booted. and has > > >>>>>>>>>>>> dhcpv6-pd'd addresses, you'll get them. Usually. > > >>>>>>>>>>>> > > >>>>>>>>>>>> - bcp38: didn't get 'round2it src/dst routing solves half of it > > >>>>>>>>>>>> - updated shaperprobe, ditg, same > > >>>>>>>>>>>> - HT40+ DOES appear to be NOT working. (this has been the case > > >>>>>>>>>>>> for a > > >>>>>>>>> while) > > >>>>>>>>>>>> - Hurricane electric ipv6 tunnels are *badly broken* as in > > >>>>>>>>>>>> *will > > >>>>>>>>>>>> disable your router* with a zillion extra processes. > > >>>>>>>>>>>> > > >>>>>>>>>>>> a huge change in openwrt made saturday was a switch to source > > >>>>>>>>> specific routing, > > >>>>>>>>>>>> > > >>>>>>>>>>>> e.g, if you have two ipv6 providers, (or a vpn, and so on) > > >>>>>>>>>>>> stuff from source A will go out the right destination for > > >>>>>>>>>>>> destination > > >>>>>>>>> A, > > >>>>>>>>>>>> and stuff from source B will go out the right destination for > > >>>>>>>>>>>> destination B. At least in theory. > > >>>>>>>>>>>> > > >>>>>>>>>>>> so you will see "from" routes. > > >>>>>>>>>>>> > > >>>>>>>>>>>> root@cerowrt:~# ip -6 route > > >>>>>>>>>>>> default from :: via fe80::201:5cff:de41:b841 dev ge00 proto > > >>>>>>>>>>>> static > > >>>>>>>>> metric 1024 > > >>>>>>>>>>>> default from 2001:E:L:I:D:E:D:Z via fe80::201:5ccf:fe41:b841 > > >>>>>>>>>>>> dev ge00 > > >>>>>>>>>>>> proto static metric 1024 > > >>>>>>>>>>>> default from 2601:X:Y::0::/60 via fe80::201:5ccf:fe41:b841 dev > > >>>>>>>>>>>> ge00 > > >>>>>>>>>>>> proto static metric 1024 > > >>>>>>>>>>>> 2601:X:Y:0::/64 dev gw00 proto kernel metric 256 expires > > >>>>>>>>>>>> 345262sec > > >>>>>>>>>>>> 2601:X:Y:1::/64 dev gw10 proto kernel metric 256 expires > > >>>>>>>>>>>> 345262sec > > >>>>>>>>>>>> 2601:X:Y:2::/64 dev se00 proto kernel metric 256 expires > > >>>>>>>>>>>> 345262sec > > >>>>>>>>>>>> 2601:X:Y:3::/64 dev sw00 proto kernel metric 256 expires > > >>>>>>>>>>>> 345262sec > > >>>>>>>>>>>> 2601:X:Y:4::/64 dev sw10 proto kernel metric 256 expires > > >>>>>>>>>>>> 345262sec > > >>>>>>>>>>>> unreachable 2601:X:X:0::/60 dev lo proto static metric > > >>>>>>>>>>>> 2147483647 > > >>>>>>>>> error -128 > > >>>>>>>>>>>> > > >>>>>>>>>>>> I figure there is much work to be done to get things like > > >>>>>>>>>>>> ipsec and > > >>>>>>>>> openvpn > > >>>>>>>>>>>> and bird/quagga/babeld to work well again, but source/dest > > >>>>>>>>>>>> routing was > > >>>>>>>>>>>> desparately needed, so... > > >>>>>>>>>>>> > > >>>>>>>>>>>> [1] All my testing was done on an ARRIS TM822G cablemodem. (I > > >>>>>>>>>>>> have a > > >>>>>>>>> profoundly > > >>>>>>>>>>>> low opinion of several other cablemodems, notably the > > >>>>>>>>>>>> technicolor...) > > >>>>>>>>>>>> There are a few other testers on other cablemodems, please > > >>>>>>>>>>>> report > > >>>>>>>>>>>> in... > > >>>>>>>>>>>> > > >>>>>>>>>>>> I return now to my regularly scheduled workweek from last > > >>>>>>>>>>>> wednesday. > > >>>>>>>>>>>> Share and enjoy. > > >>>>>>>>>>>> > > >>>>>>>>>>>> -- > > >>>>>>>>>>>> Dave Täht > > >>>>>>>>>>>> > > >>>>>>>>>>>> Fixing bufferbloat with cerowrt: > > >>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> -- > > >>>>>>>>>>> Dave Täht > > >>>>>>>>>>> > > >>>>>>>>>>> Fixing bufferbloat with cerowrt: > > >>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html > > >>>>>>>>>>> _______________________________________________ > > >>>>>>>>>>> Cerowrt-devel mailing list > > >>>>>>>>>>> [email protected] > > >>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>>> -- > > >>>>>>> Mikael Abrahamsson email: [email protected] > > >>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> Dave Täht > > >>>>> > > >>>>> Fixing bufferbloat with cerowrt: > > >>>>> http://www.teklibre.com/cerowrt/subscribe.html > > >>>> > > >>> > > >>> -- > > >>> Mikael Abrahamsson email: [email protected] > > >> > > > > > > > > > > > > -- > > > Dave Täht > > > > > > Fixing bufferbloat with cerowrt: > > > http://www.teklibre.com/cerowrt/subscribe.html > > _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
