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