On Wed, Oct 29, 2008 at 05:32:39PM -0700, Nigel Smith wrote: > Hi Matt > In your previous capture, (which you have now confirmed was done > on the Windows client), all those 'Bad TCP checksum' packets sent by the > client, > are explained, because you must be doing hardware TCP checksum offloading > on the client network adaptor. WireShark will capture the packets before > that hardware calculation is done, so the checksum all appear to be wrong, > as they have not yet been calculated!
I know that the client I was using has an nForce board with nVidia network controllers. There is an option to offload to hardware but I believe that was disabled. > The strange thing is that I'm only seeing half of the conversation! > I see packets sent from client to server. > That is from source: 10.194.217.10 to destination: 10.194.217.3 > > I can also see some packets from > source: 10.194.217.5 (Your AD domain controller) to destination 10.194.217.3 > > But you've not capture anything transmitted from your > OpenSolaris server - source: 10.194.217.3 > > (I checked, and I did not have any filters applied in WireShark > that would cause the missing half!) > Strange! I'm not sure how you did that. I believe i was using the wrong filter expression...my bad :( > The half of the conversation that I can see looks fine - there > does not seem to be any problem. I'm not seeing any duplication > of ACK's from the client in this capture. > (So again somewhat strange, unless you've fixed the problem!) > > I'm assuming your using a single network card in the Solaris server, > but maybe you had better just confirm that. Confirmed, there is a single PCI NIC that i'm using (there is the dual onboard but they don't work for me anymore). > Regarding not capturing SSH traffic and only capturing traffic from > (& hopefully to) the client, try this: > > # snoop -o test.cap -d rtls0 host 10.194.217.10 and not port 22 Much better thanks. I am attaching a second snoop from the server with the full conversation. http://distfiles.genestate.com/snoop2.zip Incidentally, this is talking to a different client, which although doesn't show checksum errors, does still have a load of duplicate ACKs. If this confuses the issue, I can do it from the old client as soon as it becomes free. > Regarding those 'link down', 'link up' messages, '/var/adm/messages'. > I can tie up some of those events with your snoop capture file, > but it just shows that no packets are being received while the link is down, > which is exactly what you would expect. > But dropping the link for a second will surely disrupt your video playback! > > If the switch is ok, and the cable from the switch is ok, then it does > now point towards the network card in the OpenSolaris box. > Maybe as simple as a bad mechanical connection on the cable socket.... Very possible. I have an Intell Pro 1000 and a new GB switch on the way. > BTW, just run '/usr/X11/bin/scanpci' and identify the 'vendor id' and > 'device id' for the network card, just in case it turns out to be a driver > bug. pci bus 0x0001 cardnum 0x06 function 0x00: vendor 0x10ec device 0x8139 Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ and the two onboards that no longer function: pci bus 0x0000 cardnum 0x08 function 0x00: vendor 0x10de device 0x0373 nVidia Corporation MCP55 Ethernet pci bus 0x0000 cardnum 0x09 function 0x00: vendor 0x10de device 0x0373 nVidia Corporation MCP55 Ethernet Thanks Matt
pgpG9O5VYjefY.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
