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

[Richard Sharpe]

On Fri, May 12, 2017 at 7:40 PM, Robert Kudyba <rkudyba at fordham.edu> wrote:
>> One thing you can do is to search for all those SMB requests where
>> there is no response. Of course since there are packet drops you might
>> find a few of those, but you can search for (!smb2.request_in) &&
>> (smb2.flags.response == 0) and that will show you all the requests for
>> which there is no response.
>
> 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)

It is difficult to do this with tshark because of the single pass
nature of tshark.

>> Another thing you can do is look for where the connection drops.
>> Search on (tcp.flags.reset == 1) || (tcp.flags.fin == 1) select one,
>> and then filter for all packets on the connection (tcp,port ==
>> portnum) where portnum is not 445 so you get just one TCP connection
>> and then you can look at what happened at the end of that tcp
>> connection.
>>
>> This last approach might be the best if the problem is that the Linux
>> CIFS module is forgetting to send data at some point and we are not
>> looking for a Write request that the Drobo did not respond to.
>
> How do I ' filter for all packets on the connection (tcp,port ==
> portnum) where portnum is not 445'?

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).

> Using the 2 searches here I get these kind of logs:
>
> 140622  25.417347 drobo → fedora TCP 66 445 → 34050 [ACK] Seq=228277
> Ack=293608973 Win=26508 Len=0 TSval=632244604 TSecr=2339550377
> 140623  25.417645 drobo → fedora TCP 66 445 → 34050 [ACK] Seq=228277
> Ack=293611869 Win=26508 Len=0 TSval=632244604 TSecr=2339550377
> 140624  25.417912 drobo → fedora TCP 66 445 → 34050 [ACK] Seq=228277
> Ack=293614765 Win=26508 Len=0 TSval=632244604 TSecr=2339550378
> 140625  25.417925 fedora → drobo TCP 11650 [TCP segment of a reassembled PDU]
> 140626  25.417942 drobo → fedora TCP 66 445 → 34050 [ACK] Seq=228277
> Ack=293617661 Win=26508 Len=0 TSval=632244604 TSecr=2339550378
> 140627  25.418193 drobo → fedora TCP 66 445 → 34050 [ACK] Seq=228277
> Ack=293620557 Win=26508 Len=0 TSval=632244604 TSecr=2339550378
> 140628  25.418662 drobo → fedora TCP 66 445 → 34050 [ACK] Seq=228277
> Ack=293623453 Win=26508 Len=0 TSval=632244604 TSecr=2339550378
> 140629  25.418672 drobo → fedora TCP 66 445 → 34050 [ACK] Seq=228277
> Ack=293626349 Win=26508 Len=0 TSval=632244604 TSecr=2339550379
> 140630  25.419048 drobo → fedora TCP 66 445 → 34050 [ACK] Seq=228277
> Ack=293629245 Win=26508 Len=0 TSval=632244604 TSecr=2339550379
> 140631  25.419076 fedora → drobo TCP 14546 [TCP segment of a reassembled PDU]
> 140632  25.419328 drobo → fedora TCP 66 445 → 34050 [ACK] Seq=228277
> Ack=293632141 Win=26508 Len=0 TSval=632244604 TSecr=2339550379



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