Fwd: moving HD with 32bit Feisty from 64 bit motherboard to 32 bit motherboard

[Krsnendu dasa]

Extra info: I also have problems when my laptop is not turned on.
---------- Forwarded message ----------
From: Krsnendu dasa <krsnendu108 at gmail.com>
Date: 25 Feb 2008 06:53
Subject: Re: moving HD with 32bit Feisty from 64 bit motherboard to 32 bit
motherboard
To: Charles Austin <ceaustin at gmail.com>

Thanks for your patient and practical help. I have given more infomation
below.

On 25/02/2008, Charles Austin <ceaustin at gmail.com> wrote:
>
> On Sun, Feb 24, 2008 at 3:26 AM, Krsnendu dasa <krsnendu108 at gmail.com>
> wrote:
> > I took the advice of Charles and a friend who is a geek. I installed
> > Wireshark. Straight away I noticed a lot of bad checksum messages.
> Thousands
> > of them! I am not sure what that means, but I'm sure it has something to
> do
> > with the problem. Any ideas what causes checksum errors?
> >
>
> Bad checksums mean that the TCP packet your device is receiving is
> corrupt.  Any number of things can cause this - physical network,
> software, rouge device, etc.  Are there any changes to the
> environment?  New lighting (can cause interference if network cables
> run close to it)?  New network switch? New patch cable for a
> workstation? (I once saw a LAN crippled by single patch cable that was
> not Cat 5.) Does Wireshark give you any info about the origin of the
> bad checksum packages?


Thanks for this information. The messages I saw mostly yesterday were from
the server .254 to my windows laptop .5 using ssh protocol.
I was using NX client to connect to FreeNX to connect to my server desktop
through a wireless connection.
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).

See the packet information at the end of this message.


> > Next steps: Try to isolate the problem more.
> > 1. Connect the server to just one client and see if it disconnects. If
> that
> > works...
> > 2. Connect to one client through the switch
> > 3. Connect the second server
> > 4. Connect secondary switches
> >  etc...
> >

You are on the right track.  Let us know which device it turns out to be.


I haven't had a chance to do this yet. I  will probably try in a few days
time.

Here is the Wireshark output for one packet.
No.     Time        Source                Destination           Protocol
Info
     30 0.376735    192.168.0.254         192.168.0.5           SSH
Encrypted response packet len=48

Frame 30 (102 bytes on wire, 102 bytes captured)
    Arrival Time: Feb 24, 2008 17:26:08.410371000
    [Time delta from previous packet: 0.001369000 seconds]
    [Time since reference or first frame: 0.376735000 seconds]
    Frame Number: 30
    Packet Length: 102 bytes
    Capture Length: 102 bytes
    [Frame is marked: True]
    [Protocols in frame: eth:ip:tcp:ssh]
    [Coloring Rule Name: Checksum Errors]
    [Coloring Rule String: edp.checksum_bad==1 || ip.checksum_bad==1 ||
tcp.checksum_bad || udp.checksum_bad]
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)
    Destination: 00:1b:77:94:eb:06 (00:1b:77:94:eb:06)
        Address: 00:1b:77:94:eb:06 (00:1b:77:94:eb:06)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Source: Micro-St_b8:c1:5b (00:0c:76:b8:c1:5b)
        Address: Micro-St_b8:c1:5b (00:0c:76:b8:c1:5b)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.254 (192.168.0.254), Dst: 192.168.0.5 (
192.168.0.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)
        0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 88
    Identification: 0x0e71 (3697)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0xa9cb [correct]
        [Good: True]
        [Bad : False]
    Source: 192.168.0.254 (192.168.0.254)
    Destination: 192.168.0.5 (192.168.0.5)
Transmission Control Protocol, Src Port: ssh (22), Dst Port: 4245 (4245),
Seq: 6352, Ack: 160, Len: 48
    Source port: ssh (22)
    Destination port: 4245 (4245)
    Sequence number: 6352    (relative sequence number)
    [Next sequence number: 6400    (relative sequence number)]
    Acknowledgement number: 160    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 1... = Push: Set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 1170
    Checksum: 0x829e [incorrect, should be 0x23ee (maybe caused by checksum
offloading?)]
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 29]
        [The RTT to ACK the segment was: 0.001369000 seconds]
SSH Protocol
    Encrypted Packet: 50E8BEC5AAC2566782574FB05971902326B84E6D7825D0FE...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/edubuntu-users/attachments/20080225/d6a82c49/attachment.htm