Extra info: I also have problems when my laptop is not turned on.<br>---------- Forwarded message ----------<br><span class="gmail_quote">From: <b class="gmail_sendername">Krsnendu dasa</b> <<a href="mailto:krsnendu108@gmail.com">krsnendu108@gmail.com</a>><br>
Date: 25 Feb 2008 06:53<br>Subject: Re: moving HD with 32bit Feisty from 64 bit motherboard to 32 bit motherboard<br>To: Charles Austin <<a href="mailto:ceaustin@gmail.com">ceaustin@gmail.com</a>><br><br></span>Thanks for your patient and practical help. I have given more infomation below.<br>
<br><div><span class="q"><span class="gmail_quote">On 25/02/2008, <b class="gmail_sendername">Charles Austin</b> <<a href="mailto:ceaustin@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ceaustin@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sun, Feb 24, 2008 at 3:26 AM, Krsnendu dasa <<a href="mailto:krsnendu108@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">krsnendu108@gmail.com</a>> wrote:<br> > I took the advice of Charles and a friend who is a geek. I installed<br>
> Wireshark. Straight away I noticed a lot of bad checksum messages. Thousands<br>
> of them! I am not sure what that means, but I'm sure it has something to do<br> > with the problem. Any ideas what causes checksum errors?<br> ><br> <br>Bad checksums mean that the TCP packet your device is receiving is<br>
corrupt. Any number of things can cause this - physical network,<br> software, rouge device, etc. Are there any changes to the<br> environment? New lighting (can cause interference if network cables<br> run close to it)? New network switch? New patch cable for a<br>
workstation? (I once saw a LAN crippled by single patch cable that was<br> not Cat 5.) Does Wireshark give you any info about the origin of the<br> bad checksum packages?</blockquote></span><div><br>Thanks for this information. The messages I saw mostly yesterday were from the server .254 to my windows laptop .5 using ssh protocol.<br>
I was using NX client to connect to FreeNX to connect to my server desktop through a wireless connection.<br>The routing is as follows Edubuntu Server (running FreeNX) -- Main Gigaswitch -- Secondary 100Mhz switch -- Wireless access point with 4 port switch (but only connected to the other switch; extra ports unused)-- Windows laptop (running NX client software).<br>
<br>See the packet information at the end of this message.<br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
> Next steps: Try to isolate the problem more.<br>
> 1. Connect the server to just one client and see if it disconnects. If that<br> > works...<br> > 2. Connect to one client through the switch<br> > 3. Connect the second server<br> > 4. Connect secondary switches<br>
> etc...<br> ></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You are on the right track. Let us know which device it turns out to be.</blockquote>
</span><div><br>I haven't had a chance to do this yet. I will probably try in a few days time. <br>
</div>Here is the Wireshark output for one packet. <br></div>No. Time Source Destination Protocol Info<br> 30 0.376735 <a href="http://192.168.0.254" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.254</a> <a href="http://192.168.0.5" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.5</a> SSH Encrypted response packet len=48<br>
<br>Frame 30 (102 bytes on wire, 102 bytes captured)<br> Arrival Time: Feb 24, 2008 17:26:08.410371000<br> [Time delta from previous packet: 0.001369000 seconds]<br> [Time since reference or first frame: 0.376735000 seconds]<br>
Frame Number: 30<br> Packet Length: 102 bytes<br> Capture Length: 102 bytes<br> [Frame is marked: True]<br> [Protocols in frame: eth:ip:tcp:ssh]<br> [Coloring Rule Name: Checksum Errors]<br> [Coloring Rule String: edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad || udp.checksum_bad]<br>
Ethernet II, Src: Micro-St_b8:c1:5b (00:0c:76:b8:c1:5b), Dst: 00:1b:77:94:eb:06 (00:1b:77:94:eb:06)<br> Destination: 00:1b:77:94:eb:06 (00:1b:77:94:eb:06)<br> Address: 00:1b:77:94:eb:06 (00:1b:77:94:eb:06)<br> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)<br>
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)<br> Source: Micro-St_b8:c1:5b (00:0c:76:b8:c1:5b)<br> Address: Micro-St_b8:c1:5b (00:0c:76:b8:c1:5b)<br> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)<br>
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)<br> Type: IP (0x0800)<br>Internet Protocol, Src: <a href="http://192.168.0.254" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.254</a> (<a href="http://192.168.0.254" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.254</a>), Dst: <a href="http://192.168.0.5" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.5</a> (<a href="http://192.168.0.5" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.5</a>)<br>
Version: 4<br> Header length: 20 bytes<br> Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)<br> 0001 00.. = Differentiated Services Codepoint: Unknown (0x04)<br> .... ..0. = ECN-Capable Transport (ECT): 0<br>
.... ...0 = ECN-CE: 0<br> Total Length: 88<br> Identification: 0x0e71 (3697)<br> Flags: 0x04 (Don't Fragment)<br> 0... = Reserved bit: Not set<br> .1.. = Don't fragment: Set<br> ..0. = More fragments: Not set<br>
Fragment offset: 0<br> Time to live: 64<br> Protocol: TCP (0x06)<br> Header checksum: 0xa9cb [correct]<br> [Good: True]<br> [Bad : False]<br> Source: <a href="http://192.168.0.254" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.254</a> (<a href="http://192.168.0.254" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.254</a>)<br>
Destination: <a href="http://192.168.0.5" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.5</a> (<a href="http://192.168.0.5" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">192.168.0.5</a>)<br>
Transmission Control Protocol, Src Port: ssh (22), Dst Port: 4245 (4245), Seq: 6352, Ack: 160, Len: 48<br> Source port: ssh (22)<br>
Destination port: 4245 (4245)<br> Sequence number: 6352 (relative sequence number)<br> [Next sequence number: 6400 (relative sequence number)]<br> Acknowledgement number: 160 (relative ack number)<br>
Header length: 20 bytes<br> Flags: 0x18 (PSH, ACK)<br> 0... .... = Congestion Window Reduced (CWR): Not set<br> .0.. .... = ECN-Echo: Not set<br> ..0. .... = Urgent: Not set<br> ...1 .... = Acknowledgment: Set<br>
.... 1... = Push: Set<br> .... .0.. = Reset: Not set<br> .... ..0. = Syn: Not set<br> .... ...0 = Fin: Not set<br> Window size: 1170<br> Checksum: 0x829e [incorrect, should be 0x23ee (maybe caused by checksum offloading?)]<br>
[SEQ/ACK analysis]<br> [This is an ACK to the segment in frame: 29]<br> [The RTT to ACK the segment was: 0.001369000 seconds]<br>SSH Protocol<br> Encrypted Packet: 50E8BEC5AAC2566782574FB05971902326B84E6D7825D0FE...<br>