tcpdump: snaplen set to 0 but still get "Packet size limited during capture"?

Question

Due to this problem, I'm going to sniff some packets on the MySQL server backend to see what happens:

# tcpdump -vv -s0 -c 100 -i bond0 tcp port 3306 and host 192.168.3.87 -w /home/quanta/3.87_aborted.pcap

As you can see, I set snaplen to 0, but still get the message "Packet size limited during capture":

MySQL Protocol
    Packet Length: 579
    Packet Number: 96
    text: 336
    text: 1004352
    text: 147619
    text: 336
[Packet size limited during capture: MySQL truncated]

The offload settings on my interface:

# ethtool -k bond0
Offload parameters for bond0:
Cannot get device rx csum settings: Operation not supported
rx-checksumming: off
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off

---

/proc/net/bonding/bond0:

Ethernet Channel Bonding Driver: v3.4.0-1 (October 7, 2008)

Bonding Mode: adaptive load balancing
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:30:48:c3:20:be

---

Reply to @HeatfanJohn:

# ethtool -k eth1
Offload parameters for eth1:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: on

---

Reply to @Doon:

bond0     UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

Sniffing with -s 1500 also shows:

 41  11.371783  192.168.6.7 -> 192.168.3.87 MySQL Response OK
 42  11.371974 192.168.3.87 -> 192.168.6.7  MySQL Request Ping
 43  11.371996  192.168.6.7 -> 192.168.3.87 MySQL Response OK
 44  11.378562 192.168.3.87 -> 192.168.6.7  MySQL Request Query
 45  11.379604  192.168.6.7 -> 192.168.3.87 MySQL Response
 46  11.402431 192.168.3.87 -> 192.168.6.7  MySQL Request Query
 47  11.402992  192.168.6.7 -> 192.168.3.87 MySQL Response[Packet size limited during capture]

Solution 1

Here it is in answer form, with correct wording :) I would try this with segmentation offload disabled. With it enabled, it's very possible that tcpdump isn't able to get what it is expecting.

--Matt

Solution 2

Something about TCP offloading I fully comply with: http://www.linuxfoundation.org/collaborate/workgroups/networking/toe

Comments

[Mike Pennington]

What bond mode are you using?

[Greg Petersen]

adaptive load balancing. updated my question.

[HeatfanJohn]

Do you have TCP offload enabled? I have seen very large TCP packets returned to WinPCAP when TCP offload is enabled.

[Doon]

What is MTU? Have you tried doing a snaplen of MTU size? -s0 normally set it back to default length

[Greg Petersen]

MTU=1500. I've tried to set snaplen to MTU size but still get that message.

[mcauth]

I would try this with segmentation offload disabled. With it enabled, it's very possible that tcpdump able to get what it is expecting.

[Tyler Szabo]

I'm very unfamilar with bonding, but from what I can read I suspect that both of your issues might be due to jumbo frames. I think you can disable them by forcing the MTU to 1500 (pthree.org/2012/02/26/setup-network-interfaces-in-debian).