Nigel Smith wrote:
> Hi Matt
> Well this time you have filtered out any SSH traffic on port 22 successfully.
> 
> But I'm still only seeing half of the conversation!

Grr this is my day, I think I know what the problem was...user error as 
I'm not used to snoop.

> I see packets sent from client to server.
> That is from source: 10.194.217.12 to destination: 10.194.217.3
> So a different client IP this time
> 
> And the Duplicate ACK packets (often long bursts) are back in this capture.
> I've looked at these a little bit more carefully this time,
> and I now notice it's using the 'TCP selective acknowledgement' feature 
> (SACK) 
> on those packets.
> 
> Now this is not something I've come across before, so I need to do some
> googling!  SACK is defined in RFC1208.
> 
>  http://www.ietf.org/rfc/rfc2018.txt
> 
> I found this explanation of when SACK is used:
> 
>  http://thenetworkguy.typepad.com/nau/2007/10/one-of-the-most.html
>  http://thenetworkguy.typepad.com/nau/2007/10/tcp-selective-a.html
> 
> This seems to indicate these 'SACK' packets are triggered as a result 
> of 'lost packets', in this case, it must be the packets sent back from
> your server to the client, that is during your video playback.

Well thats a bit above me. I can understand the lost packets though, it 
sounds about right for the situation.

> Of course I'm not seeing ANY of those packets in this capture
> because there are none captured from server to client!  
> I'm still not sure why you cannot seem to capture these packets!

I think I know the problem, I thought I should enable promiscuous mode, 
so I quickly scanned the help output and added the -P switch. However 
that does the opposide of what I thought and takes the snoop out of 
promiscuous mode.

> Oh, by the way, I probably should advise you to run...
> 
>  # netstat -i

Yes one of the previous replies to this thread advised me to try that. 
The count does increase, however quite slowly to me.

After being up for 6 hours with a few video playback tests the Oerr 
count sits at 92 currently.

> ..on the OpenSolaris box, to see if any errors are being counted
> on the network interface.
> 
> Are you still seeing the link going up/down in '/var/admin/message'?
> You are never going to do any good while that is happening.
> I think you need to try a different network card in the server.

Strangely the link up/down problem was only present on the second switch 
  I tried (which works perfectly for other connections). On the first 
switch the link appears stable at first glance however we're getting 
these duplicate acks, and checksum errors (although the csums might be 
caused by the hardware offloading of that client as you pointed out).

I've got a couple of brand new Intel Pro 1000s and a new switch arriving 
  by courier tomorrow morning, so with any luck I should see some 
difference.

I'm getting a bit busy but I will attempt to make another snoop 
*without* disabling promiscuous mode.

Thanks for all your input

Matt

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to