Icecast Streaming Media Server

[nitrolinux]

I can stream from my DSL connection at my business to the icecast 2 server. I can even stream from my 3G cell phone back to my icecast2 server. But I cannot steam from my cable connection which is a 6Mbps connection with a 500K upload back to the same icecast2 server. The icecast logs keep logging this:

WARN source/get_next_buffer Disconnecting source due to socket timeout


When the stream starts, within 5 to 6 seconds it dies. Has anyone every experienced this?

I am using ices to stream (version 2.0.1) Ubuntu 12.10, Icecast2 (2.3.2) running on a raspberry pi.

I have determine it has to be specific with my cable connection because it will run on every other type connection but this cable connection, which is a mom and pop operation here in my very rural town. Any help would be appreciated.

[karlH]

I would check that that data is getting sent initially (tcpdump), if it drops the connection at the first hurdle then it sounds like the stream is not being sent rather than a starvation issue, although a connection is being made. Maybe the issue is that the source client not sending anything.

karl.

[nitrolinux]

[karlH]

like I said tcpdump or even wireshark should suffice. As for possible cases as to why a source client could freeze up after connection, I'm not sure, the only time I've seen ices freeze up completely is when the next filename to pick from a scripted playlist sat there waiting for a response which never comes. Whether you have issues of transparent proxies is not something I would have knowledge of.

karl.

[nitrolinux]

[nitrolinux]

Here is tcpdump output from the ices side:

00:43:13.705091 IP miner717-OptiPlex-755.local.44313 > 75-120-31-195.dyn.centurytel.net.8009: Flags [.], seq 297:1745, ack 21, win 115, options [nop,nop,TS val 6593328 ecr 12993902], length 1448


Here is tcpdump output from icecast side:

00:43:19.381168 IP 192.168.1.150.8009 > 173.214.217.20.44313: Flags [F.], seq 20, ack 298, win 272, options [nop,nop,TS val 12998704 ecr 6580003,nop,nop,sack 1 {3194:3747}], length 0

This was what was happening while I tried to stream.

[karlH]

Basic new connection for TCP is [S] from source to dest the [S.] returned from dest to src the a last [.] from src to dest, then normal communication occurs which for source connections involves packets for headers and the OK response from icecast, then the stream packets going to icecast.

The fact that you see none of these on the ices side would tend to indicate that to have a misconfiguration, maybe IP lookup or routing is wrong. Use -n to avoid the reverse name lookup as that can be slow and make sure you are listening on the correct network interface but assuming that is correct then you should at least see an outgoing connection attempt even if a firewall drops it.

karl.