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.).