Broken Pipe issue

[rpedde]

@niamh wrote:

@niamh wrote:

now to see what I’ve captured in the almost 4 million packets

Something that crashes wireshark!

18:46:28 Err file emem.c: line 291: assertion failed: (npc->buf != NULL)

Press any key to exit

Lol! But can you control EIP? That would get you some recognition, as well as a nice way to root an IDS (if the bug is in libpcap). Har.

[niamh]

@rpedde wrote:

Lol! But can you control EIP? That would get you some recognition, as well as a nice way to root an IDS (if the bug is in libpcap). Har.

Well one might find out more, I’m doing a build of wireshark on a desktop FC4 PC behind me.

And I’m hoping to get a smaller capture file today.

[niamh]

@rpedde wrote:

[Can you get a network capture of it at the time of the disconnect? It would be nice to know who is resetting the connection — the soundbridge or the firefly server. If it’s the soundbridge, then we might have to take it to them.

OK, my reading of what Wireshark is telling me is that the source of the reset is the Soundbridge.

Frame 239265 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: RokuLlc_09:14:b1 (00:0d:4b:09:14:b1), Dst: D-Link_02:9a:9f (00:05:5d:02:9a:9f)
Internet Protocol, Src: 10.0.0.12 (10.0.0.12), Dst: 10.0.0.18 (10.0.0.18)
Transmission Control Protocol, Src Port: 35968 (35968), Dst Port: 3689 (3689), Seq: 201, Len: 0
Flags: 0x04 (RST)

Shame I haven’t worked out how to trim the capture file to just the relevant portion so far.

If anyone more expert than me wants to take a look the firefly log and capture file are available at

http://www.niamh.org.uk/niamh-firefly-190107.tgz

[yak0v]

@niamh wrote:

Frame 239265 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: RokuLlc_09:14:b1 (00:0d:4b:09:14:b1), Dst: D-Link_02:9a:9f (00:05:5d:02:9a:9f)
Internet Protocol, Src: 10.0.0.12 (10.0.0.12), Dst: 10.0.0.18 (10.0.0.18)
Transmission Control Protocol, Src Port: 35968 (35968), Dst Port: 3689 (3689), Seq: 201, Len: 0
Flags: 0x04 (RST)

If you look at the capture you will see that starting with frame 233006 10.0.0.18(mt-daapd) keeps resending the same TCP frame with SEQ 2207962 and never gets and ACK from 10.0.0.12(SoundBridge). Two minutes later SoundBridge sends a FIN packet (frame 233738) closing the connection. That’s why when mt-daapd sends another retransmit SoundBridge send back a RST since it already closed connecting.
So the problem looks to be that either packets were not delivered to SoundBridge or ACK replies were not getting back to mt-daapd.

[niamh]

@yak0v wrote:

So the problem looks to be that either packets were not delivered to SoundBridge or ACK replies were not getting back to mt-daapd.

I’ll not dispute that at all, these tests were deliberately done to collect data in marginal wireless network conditions so that the problems would happen.

I will be reorganising the domestic network setup at the weekend and should, hopefully, stop getting any such problems myself. But hopefully the data gathering will help others who see the same symptoms.

Anyway over to you experts to ponder over that data 😉

[rpedde]

@niamh wrote:

@yak0v wrote:

So the problem looks to be that either packets were not delivered to SoundBridge or ACK replies were not getting back to mt-daapd.

I’ll not dispute that at all, these tests were deliberately done to collect data in marginal wireless network conditions so that the problems would happen.

Now, I need to see if I can get anyone at roku to get the same problem. It doesn’t look (at least this one) like a firefly problem here… this one looks like either legitimate bad connection, or something kaflooey on the roku ip stack (re-acquire dhcp?)

Good data here… thanks.

— Ron

[niamh]

@rpedde wrote:

Now, I need to see if I can get anyone at roku to get the same problem. It doesn’t look (at least this one) like a firefly problem here… this one looks like either legitimate bad connection, or something kaflooey on the roku ip stack (re-acquire dhcp?)

Good data here… thanks.

— Ron

Hopefully having spent today running CAT5 up through the attic I won’t experience the problems… Unless someone asks me to rerun a simulation of the circumstances 🙂

[Author]

Posts