Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] FC Protocol ??

From: "Daniel Koepke" <dkoepke@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 30 Jan 2008 22:37:31 -0600
Thanks Guy;

You are kind of confirming what I was thinking. The packet scans are coming from a Netware server using pktscan.nlm. I have run this on many servers without issues. But now I have two new Dell servers using the Broadcom NIC cards showing the same scan pattern. We are working with Dell to resolve but it can be long road.

I have swapped in a Intel NIC on a Dell with Suse Linux and it corrected some re-transmission errors (advice from other forum members)

I am thinking that it is hardware based as I have issues with the same model Dell with Linux, Netware, Windows 2003 and I have never seen such bad scans

Thanks again for your input
Dan

----- Original Message ----- From: "Guy Harris" <guy@xxxxxxxxxxxx> To: "Daniel Koepke" <dkoepke@xxxxxxxxxxxxxxxxxxx>; "Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>
Sent: Wednesday, January 30, 2008 5:36 PM
Subject: Re: [Wireshark-users] FC Protocol ??



On Jan 30, 2008, at 11:00 AM, Daniel Koepke wrote:

Sorry for the delay, was pulled in different directions

Here is a sample of the scan taken today

How did you do that capture? With what type of machine are you capturing?

At least some of the packets appear to have been damaged in the process of capturing.

The first packet, for example, has an Ethernet type field value of 0, which is not a valid type value (or length value) - Wireshark interprets that as Fibre Channel because of the way some Cisco equipment works (I think some Cisco Fibre Channel equipment can dump internal traffic, and it looks like Ethernet traffic with an all-zero type field).

The third packet has an Ethernet type value of 0xffff, which is also not a valid type value (or length value).

The first byte *after* the bogus Ethernet type values in those packets is 0x45 in both packets, so they look as if they might be IP packets - and, if I use the Analyze > Decode As menu item to force Wireshark to decode 0xffff as IP, those packets, at least, are IP packets; unfortunately, as the Ethernet type value for those packets isn't the type value for IP, so Wireshark (correctly) doesn't decode them as IP packets by default.

Perhaps there's something wrong with the hardware you used to capture the traffic, or with the low-level software doing the capture (OS, drivers, etc.).