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
Author: Fabio Massimo Di Nitto <fabbione@xxxxxxxxxxxx>
Date: Wed, 8 Jan 2003 16:22:07 +0100 (CET)
Hi 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 h
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
Author: Fabio Massimo Di Nitto <fabbione@xxxxxxxxxxxx>
Date: Wed, 8 Jan 2003 19:05:36 +0100 (CET)
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 Previously Maciej Soltysiak wr
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 exact
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
Author: Fabio Massimo Di Nitto <fabbione@xxxxxxxxxxxx>
Date: Thu, 9 Jan 2003 08:29:19 +0100 (CET)
Is the WinXP client located in the same place where you are? From my side the ISP that is giving me problems is xs26.net at 2 different points. One is flapping and one is the link between them and an
Yes. (Well, not my place but a friend who had both linux and XP did that test). Wichert. -- Wichert Akkerman <wichert@xxxxxxxxx> http://www.wiggy.net/ A random hacker
Author: Fabio Massimo Di Nitto <fabbione@xxxxxxxxxxxx>
Date: Thu, 9 Jan 2003 10:43:08 +0100 (CET)
hmmmm strange because now I have forced the route to ipv6.lkml.org via another ISP (bypassing xs26.net) and it is more than 3 hours that xmms is streaming without interruptions. Fabio
The xmms patch can be adopted to work for mpg123 I suspect, I haven't tried that. Iirc mediaplayer was used. I don't think a userspace tool can cause ACKs to stop being send. Wichert. -- Wichert Akke
What other linux clients support streaming on ip6 ? patched mpg123 maybe? What XP client are you using ? Maybe it is a client issue, you say the client stops sending ACKs, maybe the client code is b