[clug] Problem getting a working IPv6 connection

[Simon Fowler]

On Sat, Feb 02, 2013 at 05:01:27PM +1100, Craig Small wrote:
> On Sat, Feb 02, 2013 at 02:04:55PM +1100, Simon Fowler wrote:
> > int. +------+ eth +-----+ adsl +---+
> > -----|Server|-----|modem|------|ISP|
> > net  +------+     +-----+      +---+
> >         |          PPPoE         |
> >         +- - - - - - - - - - - - +
> Are you sure you're pinging using the global address and not the link
> address?  Also use the -n flag with ping6 as it sometimes has problems 
> reverse resolving.
> 
> I have a gogo/gw6c tunnel but the idea is much the same. I have a
> "tunnel" address of /128 and a "LAN" address of /64
> 
> ip -f inet6 addr show  | grep global
>     inet6 2001:44b8:62:180::1/64 scope global 
>     inet6 2001:44b8:61::6f/128 scope global 
> 
simon at lassus:~$ ip -f inet6 addr show
<snip>
7: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qlen 3
    inet6 fe80::50b6:b3b7:8c89:f2e/10 scope link
       valid_lft forever preferred_lft forever

The PPP link comes up with a link scoped address, with another link
scoped address on the remote end (in this case
fe80::224:14ff:fe9a:a410).

When I ping the remote address, I get a response:

simon at lassus:~$ ping6 -c 2 -I ppp0 fe80::224:14ff:fe9a:a410
PING fe80::224:14ff:fe9a:a410(fe80::224:14ff:fe9a:a410) from
fe80::50b6:b3b7:8c89:f2e ppp0: 56 data bytes
64 bytes from fe80::224:14ff:fe9a:a410: icmp_seq=1 ttl=64 time=36.0
ms
64 bytes from fe80::224:14ff:fe9a:a410: icmp_seq=2 ttl=64 time=66.8
ms

--- fe80::224:14ff:fe9a:a410 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 36.021/51.434/66.848/15.415 ms

> The first being the LAN address, the second being my tunnel address.
> Your addresses should be 2001:44b8:something as you use Internode too.
> If you see your pings with addresses with things like fe80:whatever then
> thats a link local address, its not going to go anywhwere.

Yeah, the /56 they assigned me is indeed under 2001:44b8. 
 
> Then try (you will have to replace the addresses with yours):
>  ping6 -n 2001:44b8:61::6f  
>    this is your tunnel address, failure means your tunnel is messed up
>    locally
>  ping6 -n 2001:44b8:61::6e  
>    one less than your tunnel, failure means the tunnel is messed up
>  ping6 -I 2001:44b8:62:180::1 -n 2001:44b8:61::6e
>    -I eth0 didn't work for me (used tun address).
>    ping same as before, but using source address of your LAN. failure
>    means most likely YOUR end is messed up, ip6tables or forwarding
>  ping6 www.internode.on.net
>    pinging from your tunnel to beyond, failure often means your routing
>    (route 2000::/3 via tun) is wrong
>  ping6 -I 2001:44b8:62:180::1 -n www.internode.on.net
>    ping from your LAN to beyond, failure is funky filters on your end
>    OR their return routing is wrong.
> 
> All the time you are doing this, you should have a tshark/tcpdump on
> your tunnel interface.
>   tshark -i tun icmp6

Thing is, I'm not using a tunnel - I'm using a native dual stack
setup. My link to Internode isn't being assigned global addresses
(though I can easily assign it one myself - it doesn't make any
difference). I can ping the far end, but if I try and ping a global
address I get nothing:

simon at lassus:~$ ping6 -c 3 -I 2001:44b8:317e:8a01::1 -n
www.internode.on.net
PING www.internode.on.net(2001:44b8:69:2:1::100) from
2001:44b8:317e:8a01::1 : 56 data bytes

--- www.internode.on.net ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms

> mtr -6 is another fine tool for checking where its dying, its not that
> good for the what though.

traceroute6 behaves exactly the same as ping6 - no responses. If I
try to hit an IPv6 only site (i.e. ipv6.google.com) it simply times
out, with tcpdump showing a string of syn packets going out with no
responses.

I'm totally at a loss with this.

Simon

--
PGP public key Id 0x96263cef
Homepage: http://himi.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/linux/attachments/20130202/bc5c08b0/attachment-0001.pgp>