Very Computer

by **Wichert Akkerma** » Thu, 09 Jan 2003 15:20:13

Recently a few friends setup an ipv6 icecast server to play with ipv6
and encourage people to use ipv6 more. When using linux this does
not work perfectly though: after a certain period (usually a bit
over 10 minutes) of listening to the stream traffic suddenly stops and
one has to reconnect. A tcpdump of the traffic seems to indicate that
the linux client suddenly stops sending ACKs and as a result the server
stops sending us data:

13:57:39.812123 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9352713 win 32616 <nop,nop,timestamp 846062 369670698>
13:57:39.823581 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9352713:9353921(1208) ack 1 win 5712 <nop,nop,timestamp 369670698 846028> [class 0x2]
13:57:39.823636 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9353921 win 32616 <nop,nop,timestamp 846063 369670698>
13:57:39.835144 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9353921:9355129(1208) ack 1 win 5712 <nop,nop,timestamp 369670698 846028> [class 0x2]
13:57:39.835197 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9355129 win 32616 <nop,nop,timestamp 846064 369670698>
13:57:39.844277 2001:968:1::2.8000 > tornado.wiggy.net.33035: P 9355129:9355601(472) ack 1 win 5712 <nop,nop,timestamp 369670701 846062> [class 0x2]
13:57:39.844326 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9355601 win 32616 <nop,nop,timestamp 846065 369670701>
13:57:40.221776 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9355601:9356809(1208) ack 1 win 5712 <nop,nop,timestamp 369670739 846065> [class 0x2]
13:57:40.221846 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9356809 win 32616 <nop,nop,timestamp 846103 369670739>
13:57:40.233558 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9356809:9358017(1208) ack 1 win 5712 <nop,nop,timestamp 369670739 846065> [class 0x2]
13:57:40.233613 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9358017 win 32616 <nop,nop,timestamp 846104 369670739>
13:57:40.245110 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9358017:9359225(1208) ack 1 win 5712 <nop,nop,timestamp 369670739 846065> [class 0x2]
13:57:40.245160 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 <nop,nop,timestamp 846105 369670739>
13:57:40.282351 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369670744 846103>
13:57:40.284307 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9360433:9360653(220) ack 1 win 5712 <nop,nop,timestamp 369670744 846103>
13:57:40.297307 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9360653:9361861(1208) ack 1 win 5712 <nop,nop,timestamp 369670745 846104>
13:57:40.297376 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 <nop,nop,timestamp 846111 369670744,nop,nop,sack sack 1 {9360653:9361861} >
13:57:40.308222 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9362081:9363289(1208) ack 1 win 5712 <nop,nop,timestamp 369670745 846104> [class 0x2]
13:57:40.308271 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 <nop,nop,timestamp 846112 369670744,nop,nop,sack sack 2 {9362081:9363289}{9360653:9361861} >
13:57:40.310424 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9361861:9362081(220) ack 1 win 5712 <nop,nop,timestamp 369670745 846105>
13:57:40.310471 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 <nop,nop,timestamp 846112 369670744,nop,nop,sack sack 1 {9360653:9363289} >
13:57:40.325396 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9363289:9363509(220) ack 1 win 5712 <nop,nop,timestamp 369670750 846111> [class 0x2]
13:57:40.325447 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack 9359225 win 32616 <nop,nop,timestamp 846113 369670744,nop,nop,sack sack 1 {9360653:9363509} >
13:57:40.568652 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369670773 846113>
13:57:41.121608 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369670829 846113>
13:57:42.242095 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369670941 846113>
13:57:44.481379 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369671165 846113>
13:57:48.963035 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369671613 846113>
13:57:53.955118 fe80::250:4ff:fe0b:dd79 > tornado.wiggy.net: icmp6: neighbor sol: who has tornado.wiggy.net
13:57:53.955183 tornado.wiggy.net > fe80::250:4ff:fe0b:dd79: icmp6: neighbor adv: tgt is tornado.wiggy.net
13:57:57.921294 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369672509 846113>
13:58:15.841902 2001:968:1::2.8000 > tornado.wiggy.net.33035: . 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369674301 846113>
13:58:28.296672 tornado.wiggy.net.33035 > 2001:968:1::2.8000: F 1:1(0) ack 9359225 win 32616 <nop,nop,timestamp 850911 369670744,nop,nop,sack sack 1 {9360653:9363509} >
13:58:28.323604 2001:968:1::2.8000 > tornado.wiggy.net.33035: . ack 2 win 5712 <nop,nop,timestamp 369675550 850911>

tornado.wiggy.net is my client running Linux 2.4.19 (unpatched, UP machine),
and 2001:968:1::2 is the icecast server running Linux 2.4.20-rc2-ac3 (SMP).
If you want to test the stream yourself, please stream from
http://ipv6.lkml.org:8000/difm .

Wichert.

--

A random hacker
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Maciej Soltysia** » Thu, 09 Jan 2003 15:30:25

Quote:> tornado.wiggy.net is my client running Linux 2.4.19 (unpatched, UP machine),
> and 2001:968:1::2 is the icecast server running Linux 2.4.20-rc2-ac3 (SMP).
> If you want to test the stream yourself, please stream from
> http://ipv6.lkml.org:8000/difm .

Which ipv6 client should i be using ?

Regards,
Maciej

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Wichert Akkerma** » Thu, 09 Jan 2003 15:40:13

> Which ipv6 client should i be using ?

I am using a patched version of xmms using the patch from
http://bugs.debian.org/155955 . (Don't forget to rerun autoconf
after applying the patch). If you want I can create an ipv6
enabled xmms.deb for you if you are using Debian.

Wichert.

--

A random hacker
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Maciej Soltysia** » Thu, 09 Jan 2003 16:00:10

Quote:> I am using a patched version of xmms using the patch from
> http://bugs.debian.org/155955 . (Don't forget to rerun autoconf
> after applying the patch). If you want I can create an ipv6
> enabled xmms.deb for you if you are using Debian.

Well, i have xmms from deb package, so i would rather use an
ip6 enabled deb. If that's not a problem.

Maciej

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Wichert Akkerma** » Thu, 09 Jan 2003 16:00:18

> Well, i have xmms from deb package, so i would rather use an
> ip6 enabled deb. If that's not a problem.

No problem. Are you running stable, testing or unstable?

Wichert.

--

A random hacker
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Maciej Soltysia** » Thu, 09 Jan 2003 16:10:09

Quote:> No problem. Are you running stable, testing or unstable?

stable here.

Maciej

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Wichert Akkerma** » Thu, 09 Jan 2003 16:20:13

> stable here.

Packages are at http://www.wiggy.net/tmp/xmms/ now.

Wichert.

--

A random hacker
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Maciej Soltysia** » Thu, 09 Jan 2003 16:50:06

I had no problems listening to the stream, except a gap after about 3mins.
tcpdump showed the client closed the connection, and quickly initiated a
new one. Since then i had 15mins of nonstop playback and it stopped,
similarily to your dump.

The tcpdump is similar to yours, except i do not have traffic class info.
And rarely sack was used.

Is there a ip6 mangling router in your route to the icecast server?

I have been listening on an ip6 enabled host behind my ip6 tunnelling
router to my MAN.

Client: linux-2.4.21-pre1
Router: linux-2.4.20-grsec

I have to go now, i will look into that later.

Regards,
Maciej

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Wichert Akkerma** » Thu, 09 Jan 2003 17:00:26

> Is there a ip6 mangling router in your route to the icecast server?

Not to my knowledge. traceroute6 shows:

traceroute to ipv6.lkml.org (2001:968:1::2) from
3ffe:8280:10:1d0:290:27ff:fe2d:968c, 30 hops max, 16 byte packets
1 thunder.wiggy.net (3ffe:8280:10:1d0:250:4ff:fe0b:dd79) 0.666 ms 0.22 ms 0.199 ms
2 xs4all-29.ipv6.xs4all.nl (3ffe:8280:0:2001::58) 27.568 ms 28.012 ms 30.177 ms
3 26.ge-0-2-0.xr1.pbw.xs4all.net (2001:888:0:3::1) 22.035 ms 19.528 ms 44.644 ms
4 0.ge-0-3-0.xr1.sara.xs4all.net (2001:888:2:1::1) 19.519 ms 19.002 ms 21.974 ms
5 fe-0-0-0.ams-core-01.network6.isp-services.nl (2001:7f8:1::a502:4875:1) 19.978 ms 30.278 ms 20.248 ms
6 2001:968::2 (2001:968::2) 24.246 ms 24.083 ms 22.918 ms
7 2001:968:1::2 (2001:968:1::2) 24.978 ms 23.866 ms 23.661 ms

thunder.wiggy.net is my Linux router running 2.4.19-pre5-ac3-freeswan196
currently. The second hop is a normal sit tunnel and all the other
hops are native ipv6 using Cisco and Juniper routers as far as I know.
If you want I can get a detailed list of the routers and the IOS/JunOS
versions they are running.

Wichert.

--

A random hacker
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Wichert Akkerma** » Thu, 09 Jan 2003 17:10:13

> traceroute to ipv6.lkml.org (2001:968:1::2) from
> 3ffe:8280:10:1d0:290:27ff:fe2d:968c, 30 hops max, 16 byte packets
> 1 thunder.wiggy.net (3ffe:8280:10:1d0:250:4ff:fe0b:dd79) 0.666 ms 0.22 ms 0.199 ms
> 2 xs4all-29.ipv6.xs4all.nl (3ffe:8280:0:2001::58) 27.568 ms 28.012 ms 30.177 ms
> 3 26.ge-0-2-0.xr1.pbw.xs4all.net (2001:888:0:3::1) 22.035 ms 19.528 ms 44.644 ms
> 4 0.ge-0-3-0.xr1.sara.xs4all.net (2001:888:2:1::1) 19.519 ms 19.002 ms 21.974 ms
> 5 fe-0-0-0.ams-core-01.network6.isp-services.nl (2001:7f8:1::a502:4875:1) 19.978 ms 30.278 ms 20.248 ms
> 6 2001:968::2 (2001:968::2) 24.246 ms 24.083 ms 22.918 ms
> 7 2001:968:1::2 (2001:968:1::2) 24.978 ms 23.866 ms 23.661 ms

> thunder.wiggy.net is my Linux router running 2.4.19-pre5-ac3-freeswan196
> currently. The second hop is a normal sit tunnel and all the other
> hops are native ipv6 using Cisco and Juniper routers as far as I know.

Slight correction to that: xs4all-29.ipv6.xs4all.nl is a FreeBSD-4.5
tunnel server. The toher xs4all.net hops are Junipers running JunOS 5.3
or 5.5.

Wichert.

--

A random hacker
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Fabio Massimo Di Nitt** » Thu, 09 Jan 2003 17:30:17

Hi

> tornado.wiggy.net is my client running Linux 2.4.19 (unpatched, UP machine),
> and 2001:968:1::2 is the icecast server running Linux 2.4.20-rc2-ac3 (SMP).
> If you want to test the stream yourself, please stream from
> http://ipv6.lkml.org:8000/difm .

I have no problem to stream from there. kernel-source-2.4.19 here. several
tunnels in the middle and different brand of routers...
anyway Im farly sure that the xmms patch is not the problem. We have been
testing it for more than 6 months now (for inclusion in debian, we are
not the upstream) and yes we hit a similar problems with one icecast
server but at that time we didn't care too much since it was basically at
the first tests round. I will see if i can get it up and running again
(it is not under my control) and investigate a bit more into it.

Thanks
Fabio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Maciej Soltysia** » Thu, 09 Jan 2003 18:50:05

> > traceroute to ipv6.lkml.org (2001:968:1::2) from
> > 3ffe:8280:10:1d0:290:27ff:fe2d:968c, 30 hops max, 16 byte packets
> > 1 thunder.wiggy.net (3ffe:8280:10:1d0:250:4ff:fe0b:dd79) 0.666 ms 0.22 ms 0.199 ms
> > 2 xs4all-29.ipv6.xs4all.nl (3ffe:8280:0:2001::58) 27.568 ms 28.012 ms 30.177 ms
> > 3 26.ge-0-2-0.xr1.pbw.xs4all.net (2001:888:0:3::1) 22.035 ms 19.528 ms 44.644 ms
> > 4 0.ge-0-3-0.xr1.sara.xs4all.net (2001:888:2:1::1) 19.519 ms 19.002 ms 21.974 ms
> > 5 fe-0-0-0.ams-core-01.network6.isp-services.nl (2001:7f8:1::a502:4875:1) 19.978 ms 30.278 ms 20.248 ms
> > 6 2001:968::2 (2001:968::2) 24.246 ms 24.083 ms 22.918 ms
> > 7 2001:968:1::2 (2001:968:1::2) 24.978 ms 23.866 ms 23.661 ms

> > thunder.wiggy.net is my Linux router running 2.4.19-pre5-ac3-freeswan196
> > currently. The second hop is a normal sit tunnel and all the other
> > hops are native ipv6 using Cisco and Juniper routers as far as I know.

> Slight correction to that: xs4all-29.ipv6.xs4all.nl is a FreeBSD-4.5
> tunnel server. The toher xs4all.net hops are Junipers running JunOS 5.3
> or 5.5.

I had four contiguous listenings:
3 mins
10mins
19mins
13mins

When i increased the buffer in xmms i got better uninterrupted timings.
And survived data gaps better.

I seem to be getting better results than you, i think that it is not an
issue of ipv6 implementation but simply the case of time sensitive
traffic fighting with other Internet traffic over tunnels through ipv4
networks.

I do not know how many tunnels are in my path, i know that hop distance to
my tunnel is exactly 1 hop (ipv6 broker and ipv4 provider are the same)

If there is immense traffic at one of the routers (total traffic on an
interface) stream packets can be simply dropped if there are no queuing
disciplines that would take eg. flow control into account.

What do you think?

btw. what the hell is JunOs ?

Regards,
Maciej Soltysiak

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Wichert Akkerma** » Thu, 09 Jan 2003 18:50:09

> I do not know how many tunnels are in my path, i know that hop distance to
> my tunnel is exactly 1 hop (ipv6 broker and ipv4 provider are the same)

My tunnel provider is 5 hops away. To my knowledge non of the ipv4 or
ipv6 hops in the path are congested and no traffic shaping is done.

Quote:> If there is immense traffic at one of the routers (total traffic on an
> interface) stream packets can be simply dropped if there are no queuing
> disciplines that would take eg. flow control into account.

I'll ask the ISPs involved to check if this might be happening, but I
highly doubt it.

Quote:> btw. what the hell is JunOs ?

Juniper OS, running on Juniper routers.

Wichert.

--

A random hacker
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Wichert Akkerma** » Thu, 09 Jan 2003 19:10:09

> I seem to be getting better results than you, i think that it is not an
> issue of ipv6 implementation but simply the case of time sensitive
> traffic fighting with other Internet traffic over tunnels through ipv4
> networks.

Actually, I don't follow this. How could any kind of traffic shaping
result in my client not sending ACKs, which is what the tcpdump
seems to indicate? I can understand packets being dropped which
would result in retransmits, but that is not the case here.

Wichert.

(usual I'm-no-network-guru-and-might-be-misreading-things disclaimer here)

--

A random hacker
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

by **Maciej Soltysia** » Thu, 09 Jan 2003 19:50:11

Quote:> Actually, I don't follow this. How could any kind of traffic shaping
> result in my client not sending ACKs, which is what the tcpdump
> seems to indicate?

Well, i think i made a mistake, writing about routers dropping the
packets, it's not the case here, you are right.

Maciej

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Very Computer

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs

ipv6 stack seems to forget to send ACKs