[Cerowrt-devel] [Bloat] ipv6 not quite working for me on internal networks
Dave Taht
dave.taht at gmail.com
Tue Jun 21 18:01:59 EDT 2016
On Tue, Jun 21, 2016 at 2:20 PM, Simon Dalley <dalley.simon at gmail.com> wrote:
> On 17/06/16 15:21, Dave Taht wrote:
>>
>> On Thu, Jun 16, 2016 at 8:56 PM, Simon Dalley<dalley.simon at gmail.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> First, thanks for all the work to make cerowrt what it is.
>>
>> Was. I am really encouraging everyone to update to lede at this point,
>> which has nearly everything that was "good" about cerowrt in it.
>
> Well, the nice thing about cerowrt "was" its improved list of setup defaults
> vs. openwrt, not least the routed-instead-of-bridged subnets which is so
> helpful on mixed wired/wireless. Has this been carried over into lede? Is
> there a recommended cerowrt-flavoured git branch in lede?
No, and no. I've gotten quite fast on unbridging stuff by hand, but
decided that it was too lonely in the general case to do more than
follow the herd on this front, at least for when I was not actively
testing wifi's multicast behaviors.
One of the "big ideas" in cerowrt was to rename interfaces on creation
and before they came up by their security model (gXXX for guest, sXXX
for secure) so that there could be a stateless firewall that you'd
never have to reload, and would never be vulnerable for an instant.
It used pattern matching so you could bring up a "s+" rule and have
iptables match all that all the time, and have interfaces come and go
underneath it. Among other things this meant you'd never break
conntracking for nailed up nat connections.
Nobody bought into that - even after going through hell on interfaces
and ipv6 addresses coming and going, triggering so many firewall
reloads that the default openwrt system was basically useless at one
point in it's development, the answer was to rate limit firewall
changes and keep the loose coupling between a bridge/firewall
"interface" and reality... and I'd never got anywhere on renaming
vlans properly, so I gave up.
Nowadays the systemd folk are off creating memorable, distinct names
for interfaces, like a new random usb+mac hash for enx029b514afb6f for
what used to be called usb0, enp2s0 for what was eth2, and so on. This
does not strike me as an improvement, either.
It was primarily not being able to figure out how to map "eth0.2" into
se00 and eth0.3 into ge01 portion of the pattern matching problem that
caused me to give up on the "cerowall" design.
https://www.bufferbloat.net/projects/cerowrt/wiki/CeroWall/
I have some hope (but only some) that nftables might straighten some
of this out.
I have mildly more hope that the iptables rules will gain chains and
filter out protocols by frequency, one day, at least.
>>> I am having some difficulty with ipv6 on the "last hop", namely my
>>> internal
>>> network.
>>>
>>> Platform: Netgear WNDR3800
>>> Cerowrt version: CeroWrt Toronto 3.10.50-1 / LuCI Trunk (svn-r10459)
>>>
>>> AQUISS, my UK ISP, provides an ipv6 address range:
>>> IPv6 Address 20xx:xxxx:xx55:ae00::/56
>>
>> Are you getting this via dhcp-pd or is it static?
>
> I had set the Network | Interfaces | GE00 check box "Enable IPv6 negotiation
> on the PPP link" and the options below for the WAN6 interface, but that
> didn't seem to do anything. Only when I added an explicit value for the
> "ipv6prefix" option did any global ipv6 addresses appear. In
> /etc/config/networks:
> config interface 'wan6'
> option ifname '@ge00'
> option proto 'dhcpv6'
> option broadcast '1'
> option metric '2048'
> option reqprefix '56'
> option reqaddress 'try'
> option ip6prefix '20xx:xxxx:xx55:ae00::/56'
>
> config interface 'ge00'
> option _orig_ifname 'ge00'
> option _orig_bridge 'false'
> option ifname 'ge00'
> option proto 'pppoe'
> option ipv6 '1'
> option username 'xxxxx at aquiss.com'
> option password 'xxxxx'
> option mtu '1458'
I am sorry but I am confused, is this a 6rd device?
I regret that I do not know anyone that tested pppoe in this scenario.
>
>>> Recommended MTU: 1458 bytes
>>>
>>> I can make ipv6 work when connecting PC host "centaur" directly to the
>>> cable
>>> modem and running pppd. ping6 ipv6.google.com etc works fine.
>>
>> The "cable" modem is running over ppp???
>
> Sorry, I shouldn't have just glibly said "cable modem". It's actually a FTTC
> DSL modem, serving via PPPoE. When I was trying it directly from the PC, I
> set it up using pppoeconf under ubuntu.
>>>
>>> Reconnecting via the WNDR3800, everything ipv4 related works fine with
>>> "centaur" on the se00 subnet.
>>>
>>> I can also ping6 without problems from the WNDR3800:
>>> root at cerowrt:~# ping6 ipv6.google.com
>>> PING ipv6.google.com (2a00:1450:4009:80f::200e): 56 data bytes
>>> 64 bytes from 2a00:1450:4009:80f::200e: seq=0 ttl=53 time=15.576 ms
>>> 64 bytes from 2a00:1450:4009:80f::200e: seq=1 ttl=53 time=14.959 ms
>>> 64 bytes from 2a00:1450:4009:80f::200e: seq=2 ttl=53 time=15.156 ms
>>> 64 bytes from 2a00:1450:4009:80f::200e: seq=3 ttl=53 time=15.044 ms
>>> ^C
>>> --- ipv6.google.com ping statistics ---
>>> 4 packets transmitted, 4 packets received, 0% packet loss
>>> round-trip min/avg/max = 14.959/15.183/15.576 ms
>>>
>>> but ping6 can't get through from centaur on se00:
>>
>> A traceroute6 would be better. Try it from various source addresses on
>> the router.
>
> From centaur on se00:
> root at centaur:/etc/network# traceroute6 ipv6.google.com
> traceroute to ipv6.l.google.com (2a00:1450:400b:c00::71) from
> 20xx:xxxx:xx55:ae02::f48, 30 hops max, 24 byte packets
> 1 20xx:xxxx:xx55:ae02::1 (20xx:xxxx:xx55:ae02::1) 0.498 ms !N 0.559 ms !N
> 0.438 ms !N
>
> From cerowrt using default interface:
> root at cerowrt:/etc/config# traceroute6 ipv6.google.com
> traceroute to ipv6.google.com (2a00:1450:4009:80e::200e), 30 hops max, 16
> byte packets
> 1 fe80::f60f:1bff:fe17:8d00%pppoe-ge00
> (fe80::f60f:1bff:fe17:8d00%pppoe-ge00) 8.742 ms 8.763 ms 8.595 ms
> 2 gi1-2.inx.dist.dsl.enta.net (2001:4d48:feed:58::a) 8.901 ms 8.512 ms
> 8.410 ms
> 3 te2-2.interxion.dsl.enta.net (2001:4d48:feed:4b::a) 8.825 ms 8.628 ms
> 8.749 ms
> 4 te2-3.interxion.core.enta.net (2001:4d48:feed:22::a) 9.024 ms 7.482 ms
> 9.070 ms
> 5 2001:4d48:ace::44 (2001:4d48:ace::44) 15.690 ms 17.611 ms 15.333 ms
> 6 2001:4d48:ace::43 (2001:4d48:ace::43) 15.427 ms 15.566 ms 16.255 ms
> 7 2001:4860:1:1:0:2114:0:5 (2001:4860:1:1:0:2114:0:5) 15.109 ms 14.715 ms
> 14.300 ms
> 8 2001:4860:1:1:0:2114:0:4 (2001:4860:1:1:0:2114:0:4) 14.467 ms 15.516 ms
> 14.986 ms
> 9 2001:4860::1:0:cd12 (2001:4860::1:0:cd12) 15.367 ms 15.571 ms 15.638
> ms
> 10 2001:4860::8:0:87b7 (2001:4860::8:0:87b7) 14.824 ms 24.848 ms 15.119
> ms
> 11 2001:4860::8:0:ac54 (2001:4860::8:0:ac54) 15.387 ms 29.964 ms 15.637
> ms
> 12 2001:4860::1:0:ab9d (2001:4860::1:0:ab9d) 16.347 ms 16.363 ms 15.685
> ms
> 13 2001:4860:0:1::1b27 (2001:4860:0:1::1b27) 16.147 ms 16.556 ms 15.459
> ms
> 14 2001:4860:0:1::1755 (2001:4860:0:1::1755) 15.657 ms 15.828 ms 15.434
> ms
> 15 lhr25s01-in-x200e.1e100.net (2a00:1450:4009:80e::200e) 15.515 ms
> 15.551 ms 15.457 ms
>
> From cerowrt but using se00 interface's address:
> root at cerowrt:/etc/config# traceroute6 -s 20xx:xxxx:xx55:ae02::1
> ipv6.google.com
> traceroute to ipv6.google.com (2a00:1450:4009:80e::200e) from
> 20xx:xxxx:xx55:ae02::1, 30 hops max, 16 byte packets
> 1traceroute6: sendto: Operation not permitted
You have now narrowed it down a bit. Are you sure you are getting a /56?
Do try disabling the firewall rule below.
Do a traceroute6 from the outside and see where it stops.
>
>> Disabling the firewall for ipv6 is sometimes helpful also, for debugging.
>
> I tried
> /etc/init.d/firewall stop
>
> but that disabled all traffic. What's the recommended way of temporarily
> enabling everything?
ip6tables -P FORWARD ACCEPT;
>> You might also want a reqprefix of 56 in the wan stanza.
>
> Already done.
>
>> We did not have much chance to test against any other prefix sizes
>> than 64, 60, and 48.
>>
>>> root at centaur:/etc/network# ping6 ipv6.google.com
>>> PING ipv6.google.com(lhr25s02-in-x200e.1e100.net) 56 data bytes
>>> From lhr25s02-in-x200e.1e100.net icmp_seq=1 Destination unreachable:
>>> No
>>> route
>>> From lhr25s02-in-x200e.1e100.net icmp_seq=2 Destination unreachable:
>>> No
>>> route
>>> From lhr25s02-in-x200e.1e100.net icmp_seq=3 Destination unreachable:
>>> No
>>> route
>>> From lhr25s02-in-x200e.1e100.net icmp_seq=4 Destination unreachable:
>>> No
>>> route
>>> ^C
>>> --- ipv6.google.com ping statistics ---
>>> 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time
>>> 3024ms
>>>
>>> For your information, ipv6 routes on centaur are:
>>> root at centaur:/etc/network# ip -6 route
>>> 20xx:xxxx:xx55:ae10::f48 dev eth0 proto kernel metric 256 expires
>>> 84847sec pref medium
>>> 20xx:xxxx:xx55:ae10::/64 dev eth0 proto ra metric 100 pref medium
>>> 20xx:xxxx:xx55:ae00::/56 via fe80::2cb0:5dff:fea6:94ad dev eth0 proto
>>> ra
>>> metric 100 pref medium
>>> fe80::/64 dev eth0 proto kernel metric 256 pref medium
>>> default via fe80::2cb0:5dff:fea6:94ad dev eth0 proto static metric
>>> 100
>>> pref medium
Maybe you can setup centaur directly, and give it the ipv6 address
that is failing and repeat the traceroute6 -s thataddress test there.
>>> and on the router are:
>>> root at cerowrt:~# ip -6 route
>>> default from :: via fe80::f60f:1bff:fe17:8d00 dev pppoe-ge00 proto
>>> static
>>> metric 1024
>>> default from 20:xx:xxxx:xx00:55ae::/64 via fe80::f60f:1bff:fe17:8d00
>>> dev
>>> pppoe-ge00 proto static metric 1024
>>
>> you should also have had a default from
>>
>> 20xx:xxxx:xx55:ae00::/56
>>
>> I think.
>>
>> ip -6 route add default from
>>
>>> 20xx:xxxx:xx55:ae00::/64 dev gw00 proto kernel metric 256
>>> 20xx:xxxx:xx55:ae01::/64 dev gw10 proto kernel metric 256
>>> 20xx:xxxx:xx55:ae02::/64 dev sw00 proto kernel metric 256
>>> 20xx:xxxx:xx55:ae03::/64 dev sw10 proto kernel metric 256
>>> 20xx:xxxx:xx55:ae10::/60 dev se00 proto kernel metric 256
>>
>> This appears wrong to me in that ae10 should have been a /64
>
> I changed the "config interface 'se00'" option ip6assign back from '60' to
> '64'. Did not affect the routing problem. (I had earlier changed it to '60'
> to see if it made any difference.)
>
>>> unreachable 20xx:xxxx:xx55:ae00::/56 dev lo proto static metric
>>> 2147483647 error -128
>>> fe80::/64 dev se00 proto kernel metric 256
>>> fe80::/64 dev ifb0 proto kernel metric 256
>>> fe80::/64 dev sw10 proto kernel metric 256
>>> fe80::/64 dev sw00 proto kernel metric 256
>>> fe80::/64 dev gw10 proto kernel metric 256
>>> fe80::/64 dev gw00 proto kernel metric 256
>>> fe80::/64 dev ge00 proto kernel metric 256
>>> fe80::/10 dev pppoe-ge00 metric 1
>>> fe80::/10 dev pppoe-ge00 proto kernel metric 256
>>>
>>> I'm stumped. Can anybody help?
>>>
>>> regards, Simon
>>>
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>>
>>
>
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
More information about the Cerowrt-devel
mailing list