Discussion:
ipv6 on comcast with 18.06.1
(too old to reply)
Dave Taht
2018-10-01 15:30:27 UTC
Permalink
Sigh. Once upon a time I used to test this stuff on comcast. So I
finally got around to deploying
a new 18.06 gateway and ipv6 is busted with comcast.


https://bugs.openwrt.org/index.php?do=details&task_id=1763
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
Mikael Abrahamsson
2018-10-01 15:45:06 UTC
Permalink
Post by Dave Taht
Sigh. Once upon a time I used to test this stuff on comcast. So I
finally got around to deploying
a new 18.06 gateway and ipv6 is busted with comcast.
Can you please email me output from "tcpdump -n -vvv -i <wan> port 546 or
port 547 or icmp6" as your WAN is trying to get DHCPv6-PD ? Or if you dump
that to a pcap and email it to me (or make it available somewhere for me
to download).

I have 18.06.1 working with homenet on WRT1200AC,dual uplinks (two
different vlans on WAN), getting dual stack from both ISPs, /56 from both,
and both are announced out on LAN. I even configured bidirectional SQM
with CAKE on each uplink (250/50 and 250/100 respectively) and it seems to
do the right thing.
--
Mikael Abrahamsson email: ***@swm.pp.se
Dave Taht
2018-10-01 15:58:44 UTC
Permalink
Here you go! Going to go look at the firewall rules in a sec....
Post by Mikael Abrahamsson
Post by Dave Taht
Sigh. Once upon a time I used to test this stuff on comcast. So I
finally got around to deploying
a new 18.06 gateway and ipv6 is busted with comcast.
Can you please email me output from "tcpdump -n -vvv -i <wan> port 546 or
port 547 or icmp6" as your WAN is trying to get DHCPv6-PD ? Or if you dump
that to a pcap and email it to me (or make it available somewhere for me
to download).
I have 18.06.1 working with homenet on WRT1200AC,dual uplinks (two
different vlans on WAN), getting dual stack from both ISPs, /56 from both,
and both are announced out on LAN. I even configured bidirectional SQM
with CAKE on each uplink (250/50 and 250/100 respectively) and it seems to
do the right thing.
--
--
Dave TÀht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
Dave Taht
2018-10-01 16:12:01 UTC
Permalink
Post by Dave Taht
Here you go! Going to go look at the firewall rules in a sec....
I changed the rules to allow 547 and 546, no difference. I even
flushed the ipv6tables rules entirely,
and I'm running without that for a while. I can certainly imagine
comcast's dhcpv6 server giving up on me....

It's nice to know, btw, someone is still messing with homenet. Having
zero funding for
too many years burned me out on even trying. But I expected ipv6 to
keep working without
any more help from me! :(
Post by Dave Taht
Post by Mikael Abrahamsson
Post by Dave Taht
Sigh. Once upon a time I used to test this stuff on comcast. So I
finally got around to deploying
a new 18.06 gateway and ipv6 is busted with comcast.
Can you please email me output from "tcpdump -n -vvv -i <wan> port 546 or
port 547 or icmp6" as your WAN is trying to get DHCPv6-PD ? Or if you dump
that to a pcap and email it to me (or make it available somewhere for me
to download).
I have 18.06.1 working with homenet on WRT1200AC,dual uplinks (two
different vlans on WAN), getting dual stack from both ISPs, /56 from both,
and both are announced out on LAN. I even configured bidirectional SQM
with CAKE on each uplink (250/50 and 250/100 respectively) and it seems to
do the right thing.
--
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
Dave Taht
2018-10-01 16:12:57 UTC
Permalink
hmm... bad udp checksum???

:/tmp# 09:12:17.404257 IP6 (flowlabel 0xdfff4, hlim 1, next-header UDP
(17) payload length: 159) fe80::20d:b9ff:fe43:a06c.546 >
ff02::1:2.547: [bad udp cksum 0x58f4 -> 0xc4a1!]
Post by Dave Taht
Post by Dave Taht
Here you go! Going to go look at the firewall rules in a sec....
I changed the rules to allow 547 and 546, no difference. I even
flushed the ipv6tables rules entirely,
and I'm running without that for a while. I can certainly imagine
comcast's dhcpv6 server giving up on me....
It's nice to know, btw, someone is still messing with homenet. Having
zero funding for
too many years burned me out on even trying. But I expected ipv6 to
keep working without
any more help from me! :(
Post by Dave Taht
Post by Mikael Abrahamsson
Post by Dave Taht
Sigh. Once upon a time I used to test this stuff on comcast. So I
finally got around to deploying
a new 18.06 gateway and ipv6 is busted with comcast.
Can you please email me output from "tcpdump -n -vvv -i <wan> port 546 or
port 547 or icmp6" as your WAN is trying to get DHCPv6-PD ? Or if you dump
that to a pcap and email it to me (or make it available somewhere for me
to download).
I have 18.06.1 working with homenet on WRT1200AC,dual uplinks (two
different vlans on WAN), getting dual stack from both ISPs, /56 from both,
and both are announced out on LAN. I even configured bidirectional SQM
with CAKE on each uplink (250/50 and 250/100 respectively) and it seems to
do the right thing.
--
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
Anderson, Charles R
2018-10-01 16:29:53 UTC
Permalink
Is udp checksum offload enabled? If so, tcpdump/wireshark won't see
the actual checksum and assume it is bad.
Post by Dave Taht
hmm... bad udp checksum???
:/tmp# 09:12:17.404257 IP6 (flowlabel 0xdfff4, hlim 1, next-header UDP
(17) payload length: 159) fe80::20d:b9ff:fe43:a06c.546 >
ff02::1:2.547: [bad udp cksum 0x58f4 -> 0xc4a1!]
Post by Dave Taht
Post by Dave Taht
Here you go! Going to go look at the firewall rules in a sec....
I changed the rules to allow 547 and 546, no difference. I even
flushed the ipv6tables rules entirely,
and I'm running without that for a while. I can certainly imagine
comcast's dhcpv6 server giving up on me....
It's nice to know, btw, someone is still messing with homenet. Having
zero funding for
too many years burned me out on even trying. But I expected ipv6 to
keep working without
any more help from me! :(
Post by Dave Taht
Post by Mikael Abrahamsson
Post by Dave Taht
Sigh. Once upon a time I used to test this stuff on comcast. So I
finally got around to deploying
a new 18.06 gateway and ipv6 is busted with comcast.
Can you please email me output from "tcpdump -n -vvv -i <wan> port 546 or
port 547 or icmp6" as your WAN is trying to get DHCPv6-PD ? Or if you dump
that to a pcap and email it to me (or make it available somewhere for me
to download).
I have 18.06.1 working with homenet on WRT1200AC,dual uplinks (two
different vlans on WAN), getting dual stack from both ISPs, /56 from both,
and both are announced out on LAN. I even configured bidirectional SQM
with CAKE on each uplink (250/50 and 250/100 respectively) and it seems to
do the right thing.
Dave Taht
2018-10-01 16:44:59 UTC
Permalink
Post by Anderson, Charles R
Is udp checksum offload enabled? If so, tcpdump/wireshark won't see
the actual checksum and assume it is bad.
I imagine it is theoretically offloaded. I DO have an 18.06.1 arm box
now up that IS
getting dhcpv6-pd from comcast....

This arm box IS getting dhcpv6-pd from comcast correctly.

***@gw1:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='18.06.1'
DISTRIB_REVISION='r7258-5eb055306f'
DISTRIB_TARGET='ipq806x/generic'
DISTRIB_ARCH='arm_cortex-a15_neon-vfpv4'
DISTRIB_DESCRIPTION='OpenWrt 18.06.1 r7258-5eb055306f'
DISTRIB_TAINTS=''

My mips and x86_64 boxes aren't.

Otherwise based on my 4+ year old memory of this stuff, I don't see
anything immediately wrong
with the solicit.

(I updated the bug, too)
Post by Anderson, Charles R
Post by Dave Taht
hmm... bad udp checksum???
:/tmp# 09:12:17.404257 IP6 (flowlabel 0xdfff4, hlim 1, next-header UDP
(17) payload length: 159) fe80::20d:b9ff:fe43:a06c.546 >
ff02::1:2.547: [bad udp cksum 0x58f4 -> 0xc4a1!]
Post by Dave Taht
Post by Dave Taht
Here you go! Going to go look at the firewall rules in a sec....
I changed the rules to allow 547 and 546, no difference. I even
flushed the ipv6tables rules entirely,
and I'm running without that for a while. I can certainly imagine
comcast's dhcpv6 server giving up on me....
It's nice to know, btw, someone is still messing with homenet. Having
zero funding for
too many years burned me out on even trying. But I expected ipv6 to
keep working without
any more help from me! :(
Post by Dave Taht
Post by Mikael Abrahamsson
Post by Dave Taht
Sigh. Once upon a time I used to test this stuff on comcast. So I
finally got around to deploying
a new 18.06 gateway and ipv6 is busted with comcast.
Can you please email me output from "tcpdump -n -vvv -i <wan> port 546 or
port 547 or icmp6" as your WAN is trying to get DHCPv6-PD ? Or if you dump
that to a pcap and email it to me (or make it available somewhere for me
to download).
I have 18.06.1 working with homenet on WRT1200AC,dual uplinks (two
different vlans on WAN), getting dual stack from both ISPs, /56 from both,
and both are announced out on LAN. I even configured bidirectional SQM
with CAKE on each uplink (250/50 and 250/100 respectively) and it seems to
do the right thing.
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
Michael Richardson
2018-10-01 17:13:31 UTC
Permalink
Post by Dave Taht
hmm... bad udp checksum???
With some capture mechanisms, tcpdump gets bogus values because the hardware
did the checksums. I wouldn't imagine that we have hardware checksum offload
on openwrt devices, but could be.

Or it's a real issue.
Post by Dave Taht
:/tmp# 09:12:17.404257 IP6 (flowlabel 0xdfff4, hlim 1, next-header UDP
[bad udp cksum 0x58f4 -> 0xc4a1!] On Mon, Oct 1, 2018 at 9:12 AM Dave
Did you capture with -i device, or -i any?

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Dave Taht
2018-10-01 17:22:38 UTC
Permalink
Post by Michael Richardson
Post by Dave Taht
hmm... bad udp checksum???
With some capture mechanisms, tcpdump gets bogus values because the hardware
did the checksums. I wouldn't imagine that we have hardware checksum offload
on openwrt devices, but could be.
Or it's a real issue.
Checksums were good on the mips device I have not getting internal dhcpv6pd,
(dhcpv6 and slaac work on the external interface)...
but I didn't check them all, and it's possible the pool is exhausted.

Wasn't planning on doing this today! Hoped it was a firewall rule, frankly. :(
Post by Michael Richardson
Post by Dave Taht
:/tmp# 09:12:17.404257 IP6 (flowlabel 0xdfff4, hlim 1, next-header UDP
[bad udp cksum 0x58f4 -> 0xc4a1!] On Mon, Oct 1, 2018 at 9:12 AM Dave
Did you capture with -i device, or -i any?
device.
Post by Michael Richardson
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
Mikael Abrahamsson
2018-10-01 19:07:19 UTC
Permalink
Post by Dave Taht
Post by Dave Taht
Here you go! Going to go look at the firewall rules in a sec....
I changed the rules to allow 547 and 546, no difference. I even
flushed the ipv6tables rules entirely,
and I'm running without that for a while. I can certainly imagine
comcast's dhcpv6 server giving up on me....
Looking at your pcap file, there is no IPv6 to be had what so ever. No
answer to RS or DHCPv6 SOLICIT. It doesn't get more basic than that.
Post by Dave Taht
It's nice to know, btw, someone is still messing with homenet. Having
zero funding for too many years burned me out on even trying. But I
expected ipv6 to keep working without any more help from me! :(
Yes, your problem has nothing to do with basic IPv6 function. Windows
Vista on launch day does the same you're doing, but since nothing is
answering then you get no IPv6. So either your packets aren't making it to
the Comcast upstream router, or it doesn't do any of the basics.

I thought this would be a PD problem or something, but this is more basic
than that.
--
Mikael Abrahamsson email: ***@swm.pp.se
Continue reading on narkive:
Loading...