|
Problem with IPv6 streams
![[fi]](/s/countries/fi.gif) Shadow Hawkins on Friday, 12 March 2004 12:34:34
Hi,
I'm having difficulties accessing http://www.icecast6.remcom.org/ and same thing with the streams. I can connect, but after that nothing happens. Pinging the host is no problem either. I just changed POPs to fihel01 so that might have something to do with it.
Can anyone else access the page and the streams?
Thanks in advance.
--
Mattias Nordström
Problem with IPv6 streams
8<----------------------------
Welcome [3ffe:8114:2000:240:200:39ff:fe77:1f3f], you are accessing this site via IPv6. We are
DO SOMETHING DIFFERENT WITH YOUR IPv6 CONNECTIVITY !!!
(than ping6 and irc ;-)
--------------------------->8
Thus HTTP works here, and also from the fihel01 POP you might want to do some tcpdumps, telnets, traceroutes and other methods. "It doesn't work" doesn't describe your problem accuratly.
Problem with IPv6 streams
Shadow Hawkins on Saturday, 13 March 2004 11:48:11
Well, the weird thing is that everything seems ok, I can ping traceroute and even connect. It sends the HTTP request but hangs there, waiting for a response. Same thing with XMMS, when I try to listen, it connects without any problems but hangs at prebuffering 0/64kb. Maybe I'm banned :?
Every other IPv6 service/site/whatever works fine, the problem is only with this site. And the same thing happens from all computers here, linux and win xp. So I'm quite lost. Maybe I should ask them directly.
Problem with IPv6 streams
Shadow Hawkins on Saturday, 13 March 2004 11:54:13
And I just realised that I can access http://ipv6.lkml.org/ perfectly. It's the same machine, same ip. Any ideas?
Problem with IPv6 streams
Maybe I should ask them directly.
Now there is an idea ;)
Problem with IPv6 streams
Shadow Hawkins on Tuesday, 16 March 2004 02:54:39
I'm having the same difficulties with fihel01. The mtu/pmtu configuration seems broken at the sixxs end. :(
Problem with IPv6 streams
That certainly is not broken:
$ tracepath6 ipv6.lkml.org
1?: [LOCALHOST] pmtu 1280
1: hki2r2.ip6.kv9.net 2.404ms
2: ge-0-2-0.ams-core-01.network6.isp-services.nl asymm 7 39.610ms
3: e3-0-1-0.dtc-core-01.network6.isp-services.nl asymm 8 42.919ms
4: ipv6.lkml.org asymm 8 46.260ms reached
Resume: pmtu 1280 hops 4 back 8
$ traceroute6 ipv6.lkml.org
traceroute to ipv6.lkml.org (2001:968:1::2) from 2001:14b8:0:2000::202, 30 hops max, 16 byte packets
1 hki2r2.ip6.kv9.net (2001:14b8:0:2000::201) 1.131 ms 1.039 ms 1.01 ms
2 ge-0-2-0.ams-core-01.network6.isp-services.nl (2001:7f8:1::a502:4875:1) 34.924 ms 35.209 ms 43.231 ms
3 e3-0-1-0.dtc-core-01.network6.isp-services.nl (2001:968::2) 38.06 ms 37.153 ms 37.284 ms
4 ipv6.lkml.org (2001:968:1::2) 37.32 ms 42.571 ms 38.102 ms
Nothing wrong there, I would even say: Absolutely not a bad latency from Finland to the Netherlands ;)
Problem with IPv6 streams
Shadow Hawkins on Tuesday, 16 March 2004 13:57:07
'ping6 -s 1500 ftp.fi.debian.org'
2001:14b8:10d::ab > 2001:708:310:54::99: frag (0x0000013a:0|1232) icmp6: echo request (len 1240, hlim 63)
2001:14b8:10d::ab > 2001:708:310:54::99: frag (0x0000013a:1232|276) (len 284, hlim 63)
2001:708:310:54::99 > 2001:14b8:10d::ab: frag (0x0000035f:1448|60) (len 68, hlim 55)
big packets get lost?
fihel01 doesn't do refragmentation correctly?
Lowering mtu lowers mss on tcp connections, which makes tcp connections to work properly?
Problem with IPv6 streams
There is no such thing as fragmentation in routers in IPv6.
When you send a packet your client hosts sends a packet outbound, one of the upstream routers will not like the MTU thus it replies with a Packet Too Big ICMP which is sent back to your clients host. your host will then adjust the packet size to that lower MTU and try again.
Again: Routers do not fragment.
In the above I see packet sizes of 1232 and 1448 which seems to me to be quite odd. Maybe you should check your configuration.
Also as seen in another reply, you might want to try tracepath6 which is meant for the pMTU discovery to be visualized as also shown in the other reply.
Problem with IPv6 streams
Shadow Hawkins on Tuesday, 16 March 2004 16:29:16
40byte ipv6 header
8byte icmp header
1232bytes payload
=1280byte ipv6 packet
40 + 8 + 1448 = 1496
The missing icmp6 reply packet was 1496bytes long.
For some reason fihel01 doesn't send Packet Too Big ICMP response to packets with size > 1480bytes?
Problem with IPv6 streams
Shadow Hawkins on Tuesday, 16 March 2004 19:48:48
I also noticed same. fihel doesn't report to ftp.fi.debian.org that pmtu is 1280 and ftp.fi.debian.org sends packets with size 1500. proof comes here.
20:32) root@juusto:~# ping6 -s 1500 ftp.fi.debian.org
PING ftp.fi.debian.org(ftp.fi.debian.org) 1500 data bytes
From hiekka.kuutio.org icmp_seq=1 Packet too big: mtu=1280
--- ftp.fi.debian.org ping statistics ---
4 packets transmitted, 0 received, +1 errors, 100% packet loss, time 3000ms
(20:36) root@juusto:~# ping6 -s 1440 ftp.fi.debian.org
PING ftp.fi.debian.org(ftp.fi.debian.org) 1440 data bytes
--- ftp.fi.debian.org ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms
(20:36) root@juusto:~# ping6 -s 1420 ftp.fi.debian.org
PING ftp.fi.debian.org(ftp.fi.debian.org) 1420 data bytes
1428 bytes from ftp.fi.debian.org: icmp_seq=2 ttl=54 time=30.1 ms
1428 bytes from ftp.fi.debian.org: icmp_seq=3 ttl=54 time=28.7 ms
1428 bytes from ftp.fi.debian.org: icmp_seq=4 ttl=54 time=42.9 ms
1428 bytes from ftp.fi.debian.org: icmp_seq=5 ttl=54 time=25.9 ms
--- ftp.fi.debian.org ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4011ms
rtt min/avg/max/mdev = 25.962/31.942/42.921/6.516 ms
(20:37) root@juusto:~# ping6 -s 1430 ftp.fi.debian.org
PING ftp.fi.debian.org(ftp.fi.debian.org) 1430 data bytes
1438 bytes from ftp.fi.debian.org: icmp_seq=1 ttl=54 time=29.4 ms
1438 bytes from ftp.fi.debian.org: icmp_seq=2 ttl=54 time=26.7 ms
--- ftp.fi.debian.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 26.774/28.121/29.469/1.357 ms
(20:37) root@juusto:~# ping6 -s 1440 ftp.fi.debian.org
PING ftp.fi.debian.org(ftp.fi.debian.org) 1440 data bytes
1448 bytes from ftp.fi.debian.org: icmp_seq=1 ttl=54 time=30.1 ms
1448 bytes from ftp.fi.debian.org: icmp_seq=2 ttl=54 time=28.8 ms
1448 bytes from ftp.fi.debian.org: icmp_seq=3 ttl=54 time=30.2 ms
Dump is here http://hiekka.kuutio.org/sixxs.dump where everybody can see that only fragments are coming back from ftp.fi.debian.org
So at some point fihel reports to ftp.fi.debian.org that other side can only receive packets with size 1280 and ftp.fi.debian.org start to send with correct size.
Is that enough to proof that problem is in sixxs and not users side? :)
Problem with IPv6 streams
Is that enough to proof that problem is in sixxs and not users side?
Nopes as that could quite well mean that a host outside of the network is not returning mtu problems properly.
Run a tracepath6 and find out because as you can see there are no problems as can be seen from the output.
Btw SixXS doesn't handle any routing, ISP's do, but that is next to the subject.
Problem with IPv6 streams
Also if it is so broken, how come I can do this:
lftp ftp.fi.debian.org:/debian-cd/images/current/sparc> get debian-30r2-sparc-binary-1.iso
---> SIZE debian-30r2-sparc-binary-1.iso
<--- 213 611155968
---> MDTM debian-30r2-sparc-binary-1.iso
<--- 213 20031206160238
---> EPSV
<--- 229 Entering Extended Passive Mode (|||59556|)
---- Connecting data socket to (2001:708:310:54::99) port 59556
---> RETR debian-30r2-sparc-binary-1.iso
<--- 150 Opening BINARY mode data connection for 'debian-30r2-sparc-binary-1.iso' (611155968 bytes).
<--- 226 Transfer complete.
---- Closing data socket
copy: get hit eof
copy: put confirmed store
copy: get is finished - all done
611155968 bytes transferred in 102 seconds (5.73M/s)
If there where MTU problems they would really show up with packets that size.
Problem with IPv6 streams
Shadow Hawkins on Tuesday, 16 March 2004 22:41:54
That's where it gets a bit tricky. :) If your local interface mtu is set to 1280 tcp mss would be less than that which causes tcp connections to work..
(everything seems to work from the host which is the tunnel endpoint)
Connections opening from LAN have tcp mss value 1440 -> causes destination host to send oversized packets -> connection hangs because fihel01 doesn't send Packet Too Big ICMP for packets bigger than 1480bytes.
Problem with IPv6 streams
Shadow Hawkins on Wednesday, 17 March 2004 03:08:55
We're currently fixing that problem with finnet staff. Problem was other side of fihel upstream tunnel with cisco router which is natively connected to ficix. So it wasn't my or Jeroen's fault :)
It's working now, thanks goes to finnet folks.
Problem with IPv6 streams
Shadow Hawkins on Wednesday, 17 March 2004 00:26:09
Great!
That solved all my problems. The mp3 streams work, I can access kame.net and ftp.ipv6.funet.fi again.
Thanks! :)
Problem with IPv6 streams
Shadow Hawkins on Tuesday, 16 March 2004 08:31:04
I have also experienced mtu problems with ftp.fi.debian.org aka trumpetti.ip6.atm.tut.fi and www.kame.net. I have to some additional research to find out where problem is.
But if I lower mtu value ex. to 1440 in my local network everything works fine.
Problem with IPv6 streams
Tunnel MTU's are set to 1280, thus if you use 1440 you are way to high already.
Use tracepath6 as show above to diagnose the problem which apparently is on your side, not ours.
Problem with IPv6 streams
Shadow Hawkins on Tuesday, 16 March 2004 12:52:44
Tunnel mtu is set 1280, but I mean local network mtu which is normal 1500. But I'll some debug when I have time. At least config worked fine with nlams04 when tunnel mtu was 1280 and local network 1500.
Problem with IPv6 streams
Which should indeed work perfectly well as that is how most of the IPv6 internet works, lot of ethernet (mtu=1500) with some tunnels, BSD uses 1280, Cisco/Linux use 1480. As SixXS is a very mixed environment with many different
endpoints we choose 1280 as a mtu size so that BSD endpoints can use it perfectly well too.
Also see IPv6 Tunnel Discovery
Problem with IPv6 streams
![[nl]](/s/countries/nl.gif) Shadow Hawkins on Tuesday, 16 March 2004 21:12:11
does this mean that I better put my LAN (IPv6) on an MTU of 1280
so no fragmentation is needed?
[edit]
I tested it, with my lan I had a MTU of 1500. streaming Audio didn't work
now with a MTU of 1280 everything works fine
[/edit]
Problem with IPv6 streams
Routers that have a link through which packets don't fit should return packet too big messages, the sending host will then fragment the packets.
You only have to configure your tunnel to have a MTU 1280 which will let it notify the rest of your network of problems with the ICMP packet too big message.
But... as you know that your are using a uplink with a MTU of 1280 you could indeed configure your network to that value thus making sure no fragmentation occurs. But that will only have a benefit if the sending program also sends packets not bigger as your MTU and I do not know of many applications that respond to that correctly, some do when the local interface is set to an MTU lower as the program is trying to sent and the kernel returns the error though, most just let the stack handle it.
Problem with IPv6 streams
Shadow Hawkins on Tuesday, 16 March 2004 22:51:25
I don't know exactely what the problem was, but I couldn't listen IPv6 Audio Streams with MediaPlayer9 on Windows XP (Routed throug a Windows 2003 machine)
but when I put the MTU to 1280 everything works just fine.
and thats funny, as you just said. Only the sending program would be affacted somewhere / somehow.
I gues something is very wrong with the IPv6 implementation of Microsoft
or it is just pure luck
|
![[ch]](/s/countries/ch.gif)
on Saturday, 13 March 2004 03:52:19
Posting is only allowed when you are