Forum Discussion
Cirrustcpdump - bad capture on BigIP or insane client?
I'm troubleshooting an issue where my users in a certain country cannot access a certain VIP on LTM. In this instance my client-side sees a full 3-way handshake and tries to negotiate SSLv2 (don't say a word). Using tcpdump on BigIP and capturing with an appropriate IP-based filter on the appropriate VLAN interface I don't see all the packets. In fact I'm missing the TCP SYN and SYN/ACK packets for each connection. Why would this be?
The VIP Syncookie status is "off". There is not a protocol profile assigned with hardware SYN cookie protection enabled. The appliance is nowhere near the SYNcheck activation threshold.
What the client sees:
What the BigIP sees:
7 Replies
Brad_Parker_139Nacreous
Leaning toward insane client or some other device eating packets.
Renato_166638Nimbostratus
I would consider a bad capture as well. Sometimes I note weird problems with captured files when I try to open them with wireshark. I was looking for one example here, but I deleted all my old capture files.
Brad_ParkerLeaning toward insane client or some other device eating packets.
- Renato_166638I would consider a bad capture as well. Sometimes I note weird problems with captured files when I try to open them with wireshark. I was looking for one example here, but I deleted all my old capture files.
SynACk_128568Cirrostratus
have you checked the ltm logs for syncookie activation ? And have you checked the device before the F5 if they are seeing the packets which client is sending .
also in the capture you can try seraching with the sequence number tcp.seq == 23
Please apply more granular tcpdump filter if possible or you can try on all the vlans may be some routing issue.
Thanks
- Kevin_Stewart
Employee
I don't recall which versions were affected, but there have been instances where the tcpdump command didn't capture everything. Is that what you're doing here? Capturing with tcpdump and importing into wireshark?
Mike_HoHere's an HTTP connection attempt between the same client and VIP whereas in the OP it was HTTPS. In this instance notice how the TCP ISN sent by the BigIP (as recorded by tcpdump) does not match the ISN received by the client (as recorded by tcpdump). On retransmitted SYN/ACK packets however the ISN matches on both ends. I'm scratching my head on this. Not all but most HTTP (TCP/80) connection attempts result in this behavior.
BigIP sees:
Client sees:
