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.
>
> (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
