Hi, When using the same SPAN session OR when installing a hub between a local server and switch, Wireshark does not display packets from one remote server on a Lenovo T400 or an HP Elitebook 8460P, but it does display on a different model HP laptop. The missing packets are only from one remote server. Packets from different remote servers show in Wireshark. The flow is TCP based on server port 5030 (it's a retail point of sale application.) We have a NetScout deployment at our data center and are able to confirm that the return packets from the remote server are flowing. We have also run what's called an "Enhanced LAN Trace" on the local server and know the packets are getting to the server. Wireshark simply does not display any packets from this one particular remote server on multiple Lenovo T400 laptops (as well the HP Elitebook 8460P). There are no filters configured (capture or display.) During the TCP 3 way handshake I see the SYN and ACK from the local server, but never the SYN,ACK from the remote server. Wireshark also does not complain of the missing packets for this TCP stream(?) I'm not sure where to turn. NIC Drivers? Wireshark configuration? I have also tried TSHARK and get the same result. Thx! asked 25 Jul '12, 05:00  Mik Willy |
3 Answers:
The frames captured by the HP that works, should identify if they are VLAN tagged or not (assuming it does not strip the VLAN header itself). Most Lenovos using the Intel LM825XXX series NIC require either a MonitorMode or a MonitorModeEnabled DWORD to be added to the registry and set to a value of 1. Try searching the registry for a "DriverDesc" entry that is set to the NIC. Normally if not set, all this would do is strip off the VLAN header, not drop the packet. If you put the Lenovo on some different SPAN, do they see both directions of the expected traffic? What firewall are you running, some need to be turned off before you will see all traffic? I use a Lenovo T420 on Windows 7 & once the MonitorMode was set to 1 in the registry, everything works fine. answered 25 Jul '12, 11:18  KeithFrench |
Wireshark and Tshark both use WinPcap to capture the packets, so indeed the results should be the same. As you noticed too. One thing that might cause differences is the encapsulation of some packets (vlan tagged or not for instance), but that mostly will only effect which packets are captured when you do filter. And you're not filtering. There are a lot of pieces of software that can interfere with the capture process in many different ways. VPN clients and personal firewalls are the most notorious ones. Have a look at http://wiki.wireshark.org/CaptureSetup/InterferingSoftware for more details. If that does not help, could you please add a comment to your question with more details on the the laptops, the NICs, the NIC driver versions and NIC configuration? answered 25 Jul '12, 05:10  SYN-bit ♦♦ Actually, my bet is that the frames ARE VLAN tagged. IBM (and now Lenovo) laptops have a long history of stubbornly ignoring VLAN tagged frames (capture filter or not), no matter what you try to convince the NIC to accept them... (25 Jul '12, 05:57) Jasper ♦♦ Ah, one learns every day, thank you for the addition @Jasper! (25 Jul '12, 06:13) SYN-bit ♦♦
Hm.. if the VLAN tagged frames are dropped, the local application would not see the SYN-ACK and thus there would be no ACK. I guess it's a kind of interfering software that keeps WinPcap from capturing the packets, especially because it works on one HP Laptop and not on another HP laptop. Possible difference: Software on that laptop (besides NIC driver) Forget what I said ;-) He is capturing on a SPAN port not on the server itself. (25 Jul '12, 09:20) Kurt Knochner ♦ Thanks for the feedback. The frames are not VLAN tagged. I did have to modify the MonitorModeEnabled DWORD value to 1 about a year ago to see DOT1Q headers on another issue I was working on. It did work for me. I have at least isolated that it's not the hardware. If I boot my T400 under Backtrack Linux and run Wireshark I am able to see the complete conversation (i.e. the SYN, ACK from the remote server.) I now know to focus my effort within Windows 7 and all the apps. I may next run Win7 in safe mode with networking enabled and see what result I get. I am running an Intel 82567LM Gigabit Network adapter. The driver is Intel v10.1.14.0 dated 7/20/2011. (26 Jul '12, 04:34) Mik Willy |
What happens if you turn your firewall off? Another thing, are you sure that you do not have an existing capture or display filter in place that is filtering that direction out? From V1.8.0, the capture filters are sort of hidden. You have to double click on an interface in the Capture options, to see the capture filters. This allows different filters to be applied to different NICs when capturing on multiple interfaces. answered 26 Jul '12, 11:14 KeithFrench |
good hint!
Maybe the packets are "damaged" (bad crc or something) and the driver drops them without MonitorMode.