[Samba] Packet Size 'Tuning'

[Guntram]

IMO, this is not an error at all; instead, tcpdump is trying to analyze 
the SMB packets, sees 1353 bytes of payload within the TCP packet (1353 
bytes + 52 bytes headers = 1405 bytes seems to make sense to me), and, 
since it's a continuation packet, can't analyze it any further.

Continuation packets are common with smb, if a client wants to read, 
say, 16 KB from a file on the server, the server will send a SMB header 
(which tools like tcpdump or wireshark can analyze), and approximately 
12 (16 K / 1353 Bytes) continuation packets that contain file data (and 
which analyzers can't make sense of). So, except for the odd packet size 
(1405), there's really nothing that seems wrong to me.

The fact that packets not travelling on samba ports don't emit the 
"error" is just because tcpdump isn't trying to analyze any smb protocol 
on them.

Guntram



Am 07.08.2012 20:01, schrieb Andrew Mark:
> Thanks for your suggestion of WireShark.
>
> I'm hesitant to adjust the MTU of PPP0 too much as I'll have to
> ifdown/ifup the ppp0 interface and this is a live environment.
> Also, data packets travelling not on port 137-139 or 445 do not emit the
> displayed error.
>
> I will implement WireShark and post my findings
>
> Cheers,
>
>
> Andrew Mark | Development Analyst | www.aimsystems.ca
> local: 519-837-1072 | fax: 519-837-4063 | int'l 800-465-2961
> 12-350 Speedvale Ave. W. | Guelph, ON | N1H 7M7 | Canada
>
> On 12-08-07 04:20 AM, Andrew Bartlett wrote:
>> On Wed, 2012-08-01 at 13:36 -0400, Andrew Mark wrote:
>>> Hi all,
>>>
>>> I'm hoping someone has gone through the pain I'm going through in trying
>>> to 'tune' the packet size Samba uses such that we don't get packet
>>> overflow errors.
>>>
>>> I'm getting these error when I perform: #> tcpdump -i ppp0 -n -n
>> Isn't this a matter of your MTU on your PPP link if anything?
>>
>> Is this a real error you are seeing, or just an artifact of tcpdump?
>>
>> Do you see any real issues with a more modern sniffer, such as wireshark
>> (such as fragmentation at the other end)?
>>
>> Andrew Bartlett
>>
>
>