> From: Bob Friesenhahn [mailto:[email protected]] > > Unless TCP is offloaded from the kernel (so that checksums are in an > adaptor card), it is exceedingly difficult for wrong data to pass > TCP's checksumming and get passed up to the socket that SSH uses.
In the one packet capture that I was able to do so far, running wireshark on the OI side of the connection, I saw all the checksums were 0's and triggering the bad checksum flag in wireshark. When I googled around, some wireshark FAQ said if all your bad checksums are 0's and only on sent packets (not received packets) then it means the checksumming is happening at a layer lower than wireshark, and you can ignore the errors, by toggling a checkbox. This fit the description, so I did it. A "lower layer" might be either kernel or hardware; I don't know. The second thing I saw was ... For every time I sent/received a single character (typing on my keyboard) the OI system received an ssh packet, sent an ssh packet (terminal echo), and sent an ssh ACK for the first packet. But then when I pasted some command that caused the failure ... the OI machine saw the packet come in, and get repeated like 100 times all within 1ms of each other. Then it spewed out like 100 responses, all with about 1ms, and wireshark flagged as error, like 100 duplicate ACKs, that were again, all within like 1ms. And the TCP FIN. ... I know my laptop didn't send like 100 times. (First of all, it happened too quickly for that to be possible, second, it only happens when connected to an OI server, third, it happens for both ssh and vnc traffic.) It's the sort of thing that makes me suspect some sort of faulty interrupt or interrupt handler. The more I think about it, the more I am suspicious of the broadcom NIC driver. _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
