gordonb3 wrote:
> Except that 10053 points to either the client or some network component
> closing the socket. If LMS closed the connection you would have seen a
> 10054.
>
> Should also note that retransmit requests are not done by the receiver
> (i.e. the peer waiting for some response) but the sender. Since the
> socket is created as "non blocking", not receiving an ACK from the
> server likely causes the app to go into a loop until finally giving up
> (and generating the 10053), which explains the 100% CPU you're seeing.
>
> Is your switch capable of port mirroring? If so you could bind your Pi
> to receive the same data as the windows machine and use tcpdump to
> verify what wireshark is telling you on the Windows machine. This would
> allow you to see whether it is the outgoing traffic being blocked, or
> the incoming.
Strangely it seems to be both ways, TCP:[Keep alive] initiated by the
host as well as by the client.
See the following excerpts from a capture with Microsoft Network Monitor
(I have actual IP addresses replaced with 'CLIENT' and 'HOST'):
Time / SourceToDestination / FrameNumber / Description
9.5011191 CLIENT to HOST 316 TCP:[Keep alive]Flags=...A....,
SrcPort=56579, DstPort=9000, PayloadLen=1, Seq=2774461185 - 2774461186,
Ack=3913298766, Win=8208 {TCP:125, IPv4:13}
9.5013944 HOST to CLIENT 317 TCP:[Keep alive ack]Flags=...A....,
SrcPort=9000, DstPort=56579, PayloadLen=0, Seq=3913298766,
Ack=2774461186, Win=1332 {TCP:125, IPv4:13}
and
32.9651553 HOST to CLIENT 3982 TCP:[Keep alive]Flags=...A....,
SrcPort=9000, DstPort=56925, PayloadLen=0, Seq=2162354824,
Ack=1382232115, Win=229 (scale factor 0x7) = 29312 {TCP:323, IPv4:13}
32.9652022 CLIENT to HOST 3983 TCP:[Dup Ack #3977]Flags=...A....,
SrcPort=56925, DstPort=9000, PayloadLen=0, Seq=1382232115,
Ack=2162354825, Win=0 (scale factor 0x8) = 0 {TCP:323, IPv4:13}
33.0935782 CLIENT to HOST 3984 TCP:[Keep alive]Flags=...A....,
SrcPort=56579, DstPort=9000, PayloadLen=1, Seq=2774462837 - 2774462838,
Ack=3913300530, Win=8209 {TCP:125, IPv4:13}
33.0965046 HOST to CLIENT 3985 TCP:[Keep alive ack]Flags=...A....,
SrcPort=9000, DstPort=56579, PayloadLen=0, Seq=3913300530,
Ack=2774462838, Win=1332 {TCP:125, IPv4:13}
33.1615348 CLIENT to HOST 3986 HTTP:Request, POST /jsonrpc.js
{HTTP:31,
TCP:30, IPv4:13}
33.1618417 HOST to CLIENT 3987 TCP:Flags=...A...., SrcPort=9000,
DstPort=55966, PayloadLen=0, Seq=2820479526, Ack=4154110742,
Win=2097 {TCP:30, IPv4:13}
33.3604901 HOST to CLIENT 3988 TCP:Flags=...AP..., SrcPort=3483,
DstPort=56585, PayloadLen=30, Seq=2271133931 - 2271133961,
Ack=2859076443, Win=583 {TCP:14, IPv4:13}
33.3608028 CLIENT to HOST 3989 TCP:Flags=...AP..., SrcPort=56585,
DstPort=3483, PayloadLen=61, Seq=2859076443 - 2859076504,
Ack=2271133961, Win=8208 {TCP:14, IPv4:13}
33.3655584 HOST to CLIENT 3990 HTTP:Response, HTTP/1.1, Status: Ok,
URL:
/jsonrpc.js {HTTP:31, TCP:30, IPv4:13}
33.3737269 HOST to CLIENT 3991 TCP:Flags=...A...., SrcPort=3483,
DstPort=56585, PayloadLen=0, Seq=2271133961, Ack=2859076504,
Win=583 {TCP:14, IPv4:13}
33.4051077 HOST to CLIENT 3992 TCP:[Keep alive][Dup Ack
#3982]Flags=...A...., SrcPort=9000, DstPort=56925, PayloadLen=0,
Seq=2162354824, Ack=1382232115, Win=229 (scale factor 0x7) =
29312 {TCP:323, IPv4:13}
33.4051521 CLIENT to HOST 3993 TCP:[Dup Ack #3977]Flags=...A....,
SrcPort=56925, DstPort=9000, PayloadLen=0, Seq=1382232115,
Ack=2162354825, Win=0 (scale factor 0x8) = 0 {TCP:323, IPv4:13}
34.2371206 HOST to CLIENT 4001 TCP:[Keep alive][Dup Ack
#3982]Flags=...A...., SrcPort=9000, DstPort=56925, PayloadLen=0,
Seq=2162354824, Ack=1382232115, Win=229 (scale factor 0x7) =
29312 {TCP:323, IPv4:13}
34.2371686 CLIENT to HOST 4002 TCP:[Request Fast-Retransmit from
Seq2162354825]Flags=...A...., SrcPort=56925, DstPort=9000, PayloadLen=0,
Seq=1382232115, Ack=2162354825, Win=0 (scale factor 0x8) = 0 {TCP:323,
IPv4:13}
Whenever TCP:[Keep alive] is initiated by the client (squeezelite), the
host's (LMS) response is TCP:[Keep alive ack]. That seems to be OK.
Whenever TCP:[Keep alive] is initiated by the host however, the client's
response is TCP:[Dup Ack #frame number]. Is that OK? I was assuming here
is where the issue takes off.
When TCP:[Keep alive][Dup Ack #frame] is sent by the host, the client's
response is TCP:[Request Fast-Retransmit from Seq...].
After some time I get this:
86.5249184 HOST to CLIENT 5239 TCP:[Keep alive][Request Fast-Retransmit
from Seq1382232115]Flags=...A...., SrcPort=9000, DstPort=56925,
PayloadLen=0, Seq=2162354824, Ack=1382232115, Win=229 (scale factor 0x7)
= 29312 {TCP:323, IPv4:13}
86.5249691 CLIENT to HOST 5240 TCP:[Request Fast-Retransmit
from
Seq2162354825]Flags=...A...., SrcPort=56925, DstPort=9000, PayloadLen=0,
Seq=1382232115, Ack=2162354825, Win=0 (scale factor 0x8) = 0 {TCP:323,
IPv4:13}
and further down still
120.2225124 HOST to CLIENT 7665 TCP:Flags=...A...F, SrcPort=9000,
DstPort=56925, PayloadLen=0, Seq=2164454887, Ack=1382232115, Win=229
(scale factor 0x7) = 29312 {TCP:323, IPv4:13}
the latter seems to me the point where the host tears down the
connection.
My current assumption is that in this code
Code:
--------------------
while (running && !new_server) {
....
if ((ev = wait_readwake(ehandles, 1000)) != EVENT_TIMEOUT) {
....
}
....
}
--------------------
in function static void slimproto_run() the ev value is unexpected and
this results in a tight loop. Does that make sense?
This exchange above is apparently not on the application level but
within the TCP stack. The correct behavior has to be configured on the
application level upfront.
------------------------------------------------------------------------
fpo's Profile: http://forums.slimdevices.com/member.php?userid=71212
View this thread: http://forums.slimdevices.com/showthread.php?t=113554
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins
