Fwd: backing up to a Drobo CIFS VFS: Error -11 sending data on socket to server, Bufferbloat?

[Richard Sharpe]

On Mon, May 15, 2017 at 1:39 PM, Robert Kudyba <rkudyba at fordham.edu> wrote:
>>> Sorry still getting used to WS but I couldn't find (!smb2.request_in)
>>> == but  (smb2.flags.response == 0) was there. Am I supposed to run
>>> tshark on the exported results?
>>
>> Hmmm, in Wireshark it should have an area where you can enter a filter
>> expression. I use the Windows version so it shows up under the icon
>> bar. On Linux with the gtk version it shows up under the icon bar as
>> well with the word Filter: to the left.
>
>> In that text box enter (!smb2.request_in) && (smb2.flags.response == 0)
>
> Yep that's what I thought here's the error:
> (!smb2.request_in) && (smb2.flags.response == 0) isn't a valid display
> filter: "smb2.request_in" is neither a field nor a protocol name.

OK, that wouldn't have helped because it is SMB1 traffic ... different
syntax. Sorry.

>> OK, you need to find the port numbers used in the early packets in the
>> capture for SMB traffic. They should be 445 and another port. Use that
>> other port for the expression above. If the two ports are 445 and
>> 12743 then you want (tcp.port == 12743). That will isolate all packets
>> on the first connection, and then you can look towards the end to see
>> what is going wrong. You could even save just those packets and maybe
>> send them to us (compressed).
>
> So the filter should be this as the port # is 53854 when I just use the "or"
> clause?
>
> ( (tcp.flags.reset == 1) || (tcp.flags.fin == 1) )&& (tcp.port == 53854)
>
> Just exprting the one packet I see this:
> No.     Time           Source                Destination           Protocol
> Length Info
>    7940 120.507576397  fedora-ws         drobo         TCP      66     53854
> → 445 [FIN, ACK] Seq=277 Ack=1 Win=312 Len=0 TSval=831046843 TSecr=655916326
>
> Frame 7940: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
> Ethernet II, Src: HewlettP_25:8e:ee (2c:27:d7:25:8e:ee), Dst:
> CheckPoi_3f:32:29 (00:1c:7f:3f:32:29)
>     Destination: CheckPoi_3f:32:29 (00:1c:7f:3f:32:29)
>     Source: HewlettP_25:8e:ee (2c:27:d7:25:8e:ee)
>     Type: IPv4 (0x0800)
> Internet Protocol Version 4, Src: fedora-ws, Dst: drobo
> Transmission Control Protocol, Src Port: 53854, Dst Port: 445, Seq: 277,
> Ack: 1, Len: 0
>     Source Port: 53854
>     Destination Port: 445
>     [Stream index: 3]
>     [TCP Segment Len: 0]
>     Sequence number: 277    (relative sequence number)
>     Acknowledgment number: 1    (relative ack number)
>     Header Length: 32 bytes
>     Flags: 0x011 (FIN, ACK)
>     Window size value: 312
>     [Calculated window size: 312]
>     [Window size scaling factor: -1 (unknown)]
>     Checksum: 0xb14e [unverified]
>     [Checksum Status: Unverified]
>     Urgent pointer: 0
>     Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
>         No-Operation (NOP)
>         No-Operation (NOP)
>         Timestamps: TSval 831046843, TSecr 655916326
>
> 0000  00 1c 7f 3f 32 29 2c 27 d7 25 8e ee 08 00 45 00   ...?2),'.%....E.
> 0010  00 34 ef 97 40 00 40 06 9a 04 96 6c 40 38 96 6c   .4.. at .@....l at 8.l
> 0020  44 17 d2 5e 01 bd d3 ec 30 f3 9e 4b c6 91 80 11   D..^....0..K....
> 0030  01 38 b1 4e 00 00 01 01 08 0a 31 88 c4 bb 27 18   .8.N......1...'.
> 0040  7d 26                                             }&
>
> 63 MB gzipped pcap file uploaded here:
> http://storm.cis.fordham.edu/rkudyba/wireshark-capture.pcap.gz

OK, that helped, although I had to insert ~ before your username to download it.

The problem appears to be firewall related because I am seeing ICMP
Dest Unreachable responses to an SMB Write&X Response (frame 5816 and
5817).

Do a search on tcp.port == 42166 and you will see the response and
then a DEST Unreachable, then a retransmit in 120 seconds and another
DEST Unreachable etc.

However, there is also another SMB session on tcp.port == 53858 where
the Drobo is returning INVALID handle on the WRITES ... which seems to
be the fundamental problem.

However, stuff is missing from the capture.

This session seems to indicate the problem: tcp.port == 53860

There are a bunch of writes, but eventually the Windows fills up and
the Drobo stops responding at the TCP layer and eventually one party
or other RSTs the connection. Looks like a Drobo problem to me.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)