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 bi
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
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 playbac
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:4f
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. -- Wichert Akkerman <wichert@xxxxxxxxx> h
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 hav
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 resul
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. I'll ask the ISPs involved to check if this might be happenin
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 wo
I was able to reproduce the problem again. I have been using ethereal to sniff instead of tcpdump and gave out some more info. basically the icecast server at certain time (but i can't predict exactl
Selective ACK is mandatory in IPv6 and uses a somewhat different algorithm, so you shouldn't be seeing nearly as many ACKs as an IPv4 client would do by default. Andrew --On Wednesday, January 08, 20
--On Wednesday, January 08, 2003 19:05:36 +0100 Fabio Massimo Di Nitto <fabbione@xxxxxxxxxxxx> wrote: I was able to reproduce the problem again. I have been using ethereal to sniff instead of tcpdump
The fact that this problem does not seem to occur when using a window XP client seems to contradict the suggestions that it may be a router problem. Wichert. -- Wichert Akkerman <wichert@xxxxxxxxx> h