Troubleshooting connection loss (continued) - Networking

This is a discussion on Troubleshooting connection loss (continued) - Networking ; (I posted a similar thread to this newsgroup on October 29. Due to continuing problems, I'm opening this thread.) I run Fedora 7 and use Verizon DSL. My modem is a Westell 6100-E90 modem/router.I have no other networking hardware. My ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 39

Thread: Troubleshooting connection loss (continued)

  1. Troubleshooting connection loss (continued)

    (I posted a similar thread to this newsgroup on October 29. Due to
    continuing problems, I'm opening this thread.)

    I run Fedora 7 and use Verizon DSL. My modem is a Westell 6100-E90
    modem/router.I have no other networking hardware. My DSL connection
    usually runs well, but about once every seven to ten days I lose my
    Internet connection. I can regain my connection by rebooting Fedora.
    I've not been able to regain my Internet connection without a reboot
    (e.g. "service network restart" hangs).

    I'm trying to troubleshoot this loss of connection. I've collected a
    bunch of troubleshooting info. I'd like to know what is the next
    troubleshooting step.

    Following is what I've got so far:

    Modem status: the DSL LED is solid green. The Internet and Ethernet
    LED's are blinking green. I interpret this as meaning that I've not lost
    sync, and that the modem is actually transmitting data to the Internet.

    NIC LEDs: NIC is Intel Pro/100 M with two LEDs. The LEDs are both lit.
    The 100Mb LED is solid green. The LINK/ACT LED is blinking green. The
    status of these LEDs is the same as when I have an Internet connection.

    GKrellm: The eth0 monitor shows zero activity. When I have an Internet
    connection, the eth0 monitor shows continuous activity, even when I'm
    not accessing anything.

    KNetstats monitor: (analogous to the Gnome desktop applet). This shows
    I'm disconnected. The icon has a red circle containing a white "X".


    ifconfig: eth0 UP, BROADCAST, and MULTICAST, but *not* RUNNING. IP
    address 192.168.1.47

    ethtool eth0: link detected: yes

    ping 192.168.1.47 OK

    ping 192.168.1.1 Destination host unreachable.

    I'm running with my IP address statically assigned, instead of using the
    DHCP server on the modem/router.

    Following is output of " tail /var/log/messages". The connection was
    lost at 11:30. At around 13:00, I power cycled the modem/router and then
    issued "service network restart", which hung. I then issued ifconfig,
    which also hung.

    [root@localhost ~]# tail /var/log/messages
    Nov 8 11:29:33 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3996 DF PROTO=TCP
    SPT=1198 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 11:29:39 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3997 DF PROTO=TCP
    SPT=1198 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 11:30:03 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=3998 DF PROTO=TCP
    SPT=1198 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 11:30:21 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4015 DF PROTO=TCP
    SPT=1199 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 11:30:26 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4016 DF PROTO=TCP
    SPT=1199 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 11:30:50 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4017 DF PROTO=TCP
    SPT=1199 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 11:51:44 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out
    Nov 8 13:16:45 localhost ntpd[1743]: sendto(207.150.167.80) (fd=21):
    Invalid argument
    Nov 8 13:17:26 localhost ntpd[1743]: sendto(209.67.219.106) (fd=21):
    Invalid argument
    Nov 8 13:19:27 localhost ntpd[1743]: sendto(198.144.194.12) (fd=21):
    Invalid argument
    [root@localhost ~]# route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use
    Iface
    [root@localhost ~]# ifconfig

    Following the connection loss, but prior to issuing "service network
    restart", I issued "route -n". The output was the same as before the
    connection loss.

    Following is a listing of my network config. It was taken after
    rebooting (my Internet connection was re-established.)

    Thu Nov 8 14:00:53 EST 2007
    ======== cat /etc/*release ==========
    Fedora release 7 (Moonshine)
    Fedora release 7 (Moonshine)
    ======== uname -rvi =============
    2.6.23.1-21.fc7 #1 SMP Thu Nov 1 21:09:24 EDT 2007 i386
    ======== cat /etc/*version ==========
    cat: /etc/subversion: Is a directory
    ======== cat /proc/version ==========
    Linux version 2.6.23.1-21.fc7
    (kojibuilder@xenbuilder4.fedora.phx.redhat.com) (gcc version 4.1.2
    20070925 (Red Hat 4.1.2-27)) #1 SMP Thu Nov 1 21:09:24 EDT 2007
    ======== lsb_release -a ==========
    LSB Version:
    :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
    Distributor ID: Fedora
    Description: Fedora release 7 (Moonshine)
    Release: 7
    Codename: Moonshine

    ======== free ==========
    total used free shared buffers cached
    Mem: 125128 122368 2760 0 1752 30144
    -/+ buffers/cache: 90472 34656
    Swap: 771080 138024 633056
    ======== chkconfig --list ==========
    Double check if /avahi/ needs to be disabled on boot
    avahi-daemon 0ff 1ff 2ff 3n 4n 5ff 6ff
    avahi-dnsconfd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    Double check if /named/ needs to be disabled on boot
    named 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    ConsoleKit 0ff 1ff 2ff 3n 4n 5n 6ff
    NetworkManager 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    NetworkManagerDispatcher 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    acpid 0ff 1ff 2ff 3n 4n 5n 6ff
    anacron 0ff 1ff 2n 3n 4n 5n 6ff
    apmd 0ff 1ff 2n 3n 4n 5n 6ff
    atd 0ff 1ff 2ff 3n 4n 5n 6ff
    autofs 0ff 1ff 2ff 3n 4n 5n 6ff
    avahi-daemon 0ff 1ff 2ff 3n 4n 5ff 6ff
    avahi-dnsconfd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    bluetooth 0ff 1ff 2n 3n 4n 5ff 6ff
    capi 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    cpuspeed 0ff 1n 2n 3n 4n 5ff 6ff
    crond 0ff 1ff 2n 3n 4n 5n 6ff
    cups 0ff 1ff 2n 3n 4n 5ff 6ff
    dhcdbd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    dund 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    firestarter 0ff 1ff 2n 3n 4n 5n 6ff
    firstboot 0ff 1ff 2ff 3n 4ff 5ff 6ff
    gkrellmd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    gpm 0ff 1ff 2n 3n 4n 5n 6ff
    haldaemon 0ff 1ff 2ff 3n 4n 5n 6ff
    hddtemp 0ff 1ff 2ff 3ff 4ff 5n 6ff
    hidd 0ff 1ff 2n 3n 4n 5ff 6ff
    hplip 0ff 1ff 2n 3n 4n 5ff 6ff
    httpd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    ip6tables 0ff 1ff 2n 3n 4n 5ff 6ff
    iptables 0ff 1ff 2ff 3ff 4ff 5n 6ff
    irda 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    irqbalance 0ff 1ff 2n 3n 4n 5ff 6ff
    isdn 0ff 1ff 2n 3n 4n 5ff 6ff
    kdump 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    kudzu 0ff 1ff 2ff 3n 4n 5n 6ff
    lisa 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    lm_sensors 0ff 1ff 2n 3n 4n 5ff 6ff
    mcstrans 0ff 1ff 2n 3n 4n 5n 6ff
    mdmonitor 0ff 1ff 2n 3n 4n 5ff 6ff
    messagebus 0ff 1ff 2ff 3n 4n 5n 6ff
    named 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    nasd 0ff 1ff 2ff 3n 4n 5n 6ff
    netconsole 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    netfs 0ff 1ff 2ff 3n 4n 5ff 6ff
    netplugd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    network 0ff 1ff 2n 3n 4n 5n 6ff
    nfs 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    nfslock 0ff 1ff 2ff 3n 4n 5ff 6ff
    nscd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    ntpd 0ff 1ff 2ff 3ff 4ff 5n 6ff
    pand 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    psacct 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    rdisc 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    readahead_early 0ff 1ff 2n 3n 4n 5n 6ff
    readahead_later 0ff 1ff 2ff 3ff 4ff 5n 6ff
    restorecond 0ff 1ff 2n 3n 4n 5n 6ff
    rpcbind 0ff 1ff 2ff 3n 4n 5ff 6ff
    rpcgssd 0ff 1ff 2ff 3n 4n 5ff 6ff
    rpcidmapd 0ff 1ff 2ff 3n 4n 5ff 6ff
    rpcsvcgssd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    saslauthd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    sendmail 0ff 1ff 2n 3n 4n 5n 6ff
    smartd 0ff 1ff 2n 3n 4n 5n 6ff
    spamassassin 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    sshd 0ff 1ff 2n 3n 4n 5ff 6ff
    syslog 0ff 1ff 2n 3n 4n 5n 6ff
    tomcat5 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    vncserver 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    winbind 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    wpa_supplicant 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    xfs 0ff 1ff 2n 3n 4n 5n 6ff
    ypbind 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    yum-updatesd 0ff 1ff 2ff 3n 4n 5n 6ff
    ======== grep hosts: /etc/nsswitch.conf ==========
    #hosts: db files nisplus nis dns
    hosts: files dns
    ======== grep -v '^#' /etc/resolv.conf ==========
    ; generated by /sbin/dhclient-script
    search myhome.westell.com
    nameserver 192.168.1.1
    nameserver 192.168.1.1
    ======== hostname ==========
    localhost.localdomain
    ======== grep eth /etc/mod*.conf ==========
    alias eth0 e100
    ======== grep -v '^#' /etc/host.conf ==========
    order hosts,bind
    ================ ifconfig -a ==============
    eth0 Link encap:Ethernet HWaddr 00:07:E9:01:B2:09
    inet addr:192.168.1.47 Bcast:192.168.1.255 Mask:255.255.255.0
    inet6 addr: fe80::207:e9ff:fe01:b209/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:303 errors:0 dropped:0 overruns:0 frame:0
    TX packets:195 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:39088 (38.1 KiB) TX bytes:17423 (17.0 KiB)

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1/128 Scope:Host
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:3319 errors:0 dropped:0 overruns:0 frame:0
    TX packets:3319 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:6522340 (6.2 MiB) TX bytes:6522340 (6.2 MiB)

    ============== route -n =================
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use
    Iface
    192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
    169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
    0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
    ======== cat /etc/sysconfig/network ==========
    NETWORKING=yes
    HOSTNAME=localhost.localdomain
    ========== head -15 /etc/hosts ===========
    192.168.1.1 gateway
    ======== ethtool eth0 ==========
    Settings for eth0:
    Supported ports: [ TP MII ]
    Supported link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    Supports auto-negotiation: Yes
    Advertised link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    Advertised auto-negotiation: Yes
    Speed: 100Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: g
    Wake-on: g
    Current message level: 0x00000007 (7)
    Link detected: yes
    === dmesg | grep eth0 | grep -v SRC= ===
    e100: eth0: e100_probe: addr 0xfc9ff000, irq 11, MAC addr 00:07:E9:01:B2:09
    ADDRCONF(NETDEV_UP): eth0: link is not ready
    e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
    ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    eth0: no IPv6 routers present
    === grep eth0 /var/log/messages | tail -10 ===
    Nov 8 13:58:29 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2396 DF PROTO=TCP
    SPT=1036 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 13:58:47 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2413 DF PROTO=TCP
    SPT=1037 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 13:58:52 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2414 DF PROTO=TCP
    SPT=1037 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 13:59:16 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2415 DF PROTO=TCP
    SPT=1037 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 13:59:35 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2432 DF PROTO=TCP
    SPT=1038 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 13:59:40 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2433 DF PROTO=TCP
    SPT=1038 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 14:00:04 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2434 DF PROTO=TCP
    SPT=1038 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 14:00:22 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2451 DF PROTO=TCP
    SPT=1039 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 14:00:28 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2452 DF PROTO=TCP
    SPT=1039 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 8 14:00:52 localhost kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.47 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=2453 DF PROTO=TCP
    SPT=1039 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    ======== cat /etc/sysconfig/network-scripts/ifcfg-eth0 ==========
    # Intel Corporation 82557/8/9 [Ethernet Pro 100]
    DEVICE=eth0
    ONBOOT=yes
    BOOTPROTO=none
    HWADDR=00:07:e9:01:b2:09
    TYPE=Ethernet
    USERCTL=yes
    IPV6INIT=no
    PEERDNS=yes
    NETMASK=255.255.255.0
    IPADDR=192.168.1.47
    GATEWAY=192.168.1.1
    ======== tail -18 /var/lib/dhclient/dhclient-eth0.leases ==========
    rebind 3 2007/11/7 12:23:43;
    expire 3 2007/11/7 15:23:43;
    }
    lease {
    interface "eth0";
    fixed-address 192.168.1.47;
    option subnet-mask 255.255.255.0;
    option routers 192.168.1.1;
    option dhcp-lease-time 86400;
    option dhcp-message-type 5;
    option domain-name-servers 192.168.1.1,192.168.1.1;
    option dhcp-server-identifier 192.168.1.1;
    option broadcast-address 255.255.255.255;
    option domain-name "myhome.westell.com";
    renew 3 2007/11/7 05:23:24;
    rebind 3 2007/11/7 15:31:25;
    expire 3 2007/11/7 18:31:25;
    }
    === dmesg | grep eth1 | grep -v SRC= ===
    === grep eth1 /var/log/messages | tail -10 ===
    === dmesg | grep eth2 | grep -v SRC= ===
    === grep eth2 /var/log/messages | tail -10 ===
    ======== grep -v '^#' /etc/hosts.allow ==========

    ======== grep -v '^#' /etc/hosts.deny ==========

    ======= end of config/network data dump ===========


    What troubleshooting step should I do next?

  2. Re: Troubleshooting connection loss (continued)

    On Thu, 08 Nov 2007 19:08:10 GMT, Allen Weiner wrote:
    > (I posted a similar thread to this newsgroup on October 29. Due to
    > continuing problems, I'm opening this thread.)
    >
    > I run Fedora 7 and use Verizon DSL. My modem is a Westell 6100-E90
    > modem/router.I have no other networking hardware. My DSL connection
    > usually runs well, but about once every seven to ten days I lose my
    > Internet connection. I can regain my connection by rebooting Fedora.
    > I've not been able to regain my Internet connection without a reboot
    > (e.g. "service network restart" hangs).
    >
    > GKrellm: The eth0 monitor shows zero activity. When I have an Internet
    > connection, the eth0 monitor shows continuous activity, even when I'm
    > not accessing anything.


    You have activity like arp ack/req, email checks, ntp time
    check/sync.... Not to mention anything sent by the router
    "even when you'r not accessing anything"


    > Nov 8 11:51:44 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out


    No experience with netdev watchdog. I wonder if it is tearing down
    your connection.

    > [root@localhost ~]# route -n
    > Kernel IP routing table
    > Destination Gateway Genmask Flags Metric Ref Use
    > Iface


    Well, there goes your routing so the "no route to 192.168.1.1" is correct.

    > [root@localhost ~]# ifconfig


    Yep, and that is sad.

    > Following the connection loss, but prior to issuing "service network
    > restart", I issued "route -n". The output was the same as before the
    > connection loss.


    What you posted above, did not show us that fact.


    > Double check if /avahi/ needs to be disabled on boot
    > avahi-daemon 0ff 1ff 2ff 3n 4n 5ff 6ff


    avahi-daemon is still not disabled.
    You need to click up a terminal and do the following:
    su - root
    service avahi-daemon stop
    chkconfig --del avahi-daemon




    > ========== head -15 /etc/hosts ===========
    > 192.168.1.1 gateway



    That bites, you should have a local host entry.
    I suggest one for the node, if you would give it a node name.

    Looking in your dhcp lease file we find
    option domain-name "myhome.westell.com";

    So you could name it that if you like, but I wonder what is going on
    because I see

    $ host westell.com
    westell.com has address 216.203.29.175
    westell.com mail is handled by 10 cluster9.us.messagelabs.com.
    westell.com mail is handled by 20 cluster9a.us.messagelabs.com.

    Something is not looking good in the router, from what I can guess so far.
    You better get into the router and veify that the dns servers belong
    to verizon.

    Come on just to make eveything standard, Please modify /etc/sysconfig/network
    to set a unique node name, not localhost.localdomain

    /etc/sysconfig/network
    NETWORKING=yes
    NEEDHOSTNAME=no <==== add this line
    HOSTNAME=darkstar.home.invalid <==== pick your own node name
    put .invalid on the end

    Now your /etc/hosts should have something like:
    127.0.0.1 localhost
    192.168.1.1 gateway
    192.168.1.47 darkstar.home.invalid darkstar


    I will suggest changing your ip address to 192.168.1.140
    It is hard to prove if you are running static or dhcp.

    Change ip addy in /etc/sysconfig/network-scripts/ifcfg-eth0,
    /etc/hosts to match ip addy and reboot. You should have no problem.

    > ======== cat /etc/sysconfig/network-scripts/ifcfg-eth0 ==========
    > # Intel Corporation 82557/8/9 [Ethernet Pro 100]
    > DEVICE=eth0
    > ONBOOT=yes
    > BOOTPROTO=none
    > HWADDR=00:07:e9:01:b2:09
    > TYPE=Ethernet
    > USERCTL=yes
    > IPV6INIT=no
    > PEERDNS=yes
    > NETMASK=255.255.255.0
    > IPADDR=192.168.1.47
    > GATEWAY=192.168.1.1


    BOOTPROTO= seems to indicate static but look,
    renew 3 2007/11/7 05:23:24;
    rebind 3 2007/11/7 15:31:25;
    expire 3 2007/11/7 18:31:25;

    Why are you getting a new dhcp lease??????
    Something is still not right. Maybe PEERDNS=yes caused the lease request.

    When you made your changes, did you use the gui interface, or did you
    just edit files?
    If edited files for eth0, use gui interface to modify eth0.



    > ======== tail -18 /var/lib/dhclient/dhclient-eth0.leases ==========
    > rebind 3 2007/11/7 12:23:43;
    > expire 3 2007/11/7 15:23:43;
    > }
    > lease {
    > interface "eth0";
    > fixed-address 192.168.1.47;
    > option subnet-mask 255.255.255.0;
    > option routers 192.168.1.1;
    > option dhcp-lease-time 86400;
    > option dhcp-message-type 5;
    > option domain-name-servers 192.168.1.1,192.168.1.1;
    > option dhcp-server-identifier 192.168.1.1;
    > option broadcast-address 255.255.255.255;
    > option domain-name "myhome.westell.com";
    > renew 3 2007/11/7 05:23:24;
    > rebind 3 2007/11/7 15:31:25;
    > expire 3 2007/11/7 18:31:25;


    > What troubleshooting step should I do next?


    After my suggested changes,
    echo "nameserver 192.168.1.1" > /etc/resolv.conf
    cp /dev/null /var/lib/dhclient/dhclient-eth0.leases
    reboot, because of node name changes, and when the system comes up, do a
    cat /var/lib/dhclient/dhclient-eth0.leases
    and verify no dhcp lease.

    If so, I would
    cd /etc/sysconfig/network-scripts/
    cp ifcfg-eth0 ifcfg-eth0.bkup

    change
    BOOTPROTO=static
    PEERDNS=no
    in /etc/sysconfig/network-scripts/ifcfg-eth0

    cp /dev/null /var/lib/dhclient/dhclient-eth0.leases
    service network restart
    echo "nameserver 192.168.1.1" > /etc/resolv.conf
    cat /var/lib/dhclient/dhclient-eth0.leases
    I would now think there would be a null dhclient-eth0.leases file.

    if restart fails
    cp ifcfg-eth0.bkup ifcfg-eth0
    and change
    PEERDNS=no
    cp /dev/null /var/lib/dhclient/dhclient-eth0.leases
    echo "nameserver 192.168.1.1" > /etc/resolv.conf
    service network restart
    cat /var/lib/dhclient/dhclient-eth0.leases

    cat /etc/resolv.conf should show only one nameserver line. If two,
    your dhcp client is still running.

    Do veify ip address is 192.168.1.140 in
    ifconfig


  3. Re: Troubleshooting connection loss (continued)

    Bit Twister wrote:
    > On Thu, 08 Nov 2007 19:08:10 GMT, Allen Weiner wrote:
    >> (I posted a similar thread to this newsgroup on October 29. Due to
    >> continuing problems, I'm opening this thread.)
    >>
    >> I run Fedora 7 and use Verizon DSL. My modem is a Westell 6100-E90
    >> modem/router.I have no other networking hardware. My DSL connection
    >> usually runs well, but about once every seven to ten days I lose my
    >> Internet connection. I can regain my connection by rebooting Fedora.
    >> I've not been able to regain my Internet connection without a reboot
    >> (e.g. "service network restart" hangs).
    >>
    >> GKrellm: The eth0 monitor shows zero activity. When I have an Internet
    >> connection, the eth0 monitor shows continuous activity, even when I'm
    >> not accessing anything.

    >
    > You have activity like arp ack/req, email checks, ntp time
    > check/sync.... Not to mention anything sent by the router
    > "even when you'r not accessing anything"


    I believe ntp runs only occasionally. I don't have automatic email
    checks. While my connection is up, the Gkrellm eth0 monitor never goes
    blank, even if I'm just browsing local files on my HDD. A partial
    explanation, from the other thread, is that every 15 seconds, Verizon is
    probing to see if I'm running a server.
    >
    >
    >> Nov 8 11:51:44 localhost kernel: NETDEV WATCHDOG: eth0: transmit timed out

    >
    > No experience with netdev watchdog. I wonder if it is tearing down
    > your connection.
    >
    >> [root@localhost ~]# route -n
    >> Kernel IP routing table
    >> Destination Gateway Genmask Flags Metric Ref Use
    >> Iface

    >
    > Well, there goes your routing so the "no route to 192.168.1.1" is correct.
    >
    >> [root@localhost ~]# ifconfig

    >
    > Yep, and that is sad.
    >
    >> Following the connection loss, but prior to issuing "service network
    >> restart", I issued "route -n". The output was the same as before the
    >> connection loss.

    >
    > What you posted above, did not show us that fact.


    "service network restart" clears the routing table and then hangs.

    1. Connection loss.

    2. I issue route -n. Result is same as before connection loss.

    3. I issue "service network restart". It hangs.

    4. I issue route -n. Routing table is empty.

    5. I issue ifconfig. It hangs.


    >
    >
    >> Double check if /avahi/ needs to be disabled on boot
    >> avahi-daemon 0ff 1ff 2ff 3n 4n 5ff 6ff

    >
    > avahi-daemon is still not disabled.
    > You need to click up a terminal and do the following:
    > su - root
    > service avahi-daemon stop
    > chkconfig --del avahi-daemon
    >
    >

    I boot into runlevel 5. The above result shows that avahi-daemon is not
    activated for runlevel 5. I confirmed this by issuing KDE -> system ->
    services. I selected avahi-daemon, and it reported avahi-daemon is not
    running. Also, if I issue dmesg, those multicast transmissions to/from
    port 5353 are no longer being logged.
    >
    >
    >> ========== head -15 /etc/hosts ===========
    >> 192.168.1.1 gateway

    >
    >
    > That bites, you should have a local host entry.
    > I suggest one for the node, if you would give it a node name.


    Novice question: What is the rationale for having a local host entry?
    >
    > Looking in your dhcp lease file we find
    > option domain-name "myhome.westell.com";
    >
    > So you could name it that if you like, but I wonder what is going on
    > because I see
    >
    > $ host westell.com
    > westell.com has address 216.203.29.175
    > westell.com mail is handled by 10 cluster9.us.messagelabs.com.
    > westell.com mail is handled by 20 cluster9a.us.messagelabs.com.
    >
    > Something is not looking good in the router, from what I can guess so far.
    > You better get into the router and veify that the dns servers belong
    > to verizon.


    When I originally configured for static IP, I got the DNS server
    addresses from the router. Primary: 68.237.161.12. Secondary:
    71.250.0.12. Isn't everything in "12" Verizon? Besides, as long as I can
    browse the web, DNS must be working even if the servers aren't from Verizon.
    >
    > Come on just to make eveything standard, Please modify /etc/sysconfig/network
    > to set a unique node name, not localhost.localdomain
    >
    > /etc/sysconfig/network
    > NETWORKING=yes
    > NEEDHOSTNAME=no <==== add this line
    > HOSTNAME=darkstar.home.invalid <==== pick your own node name
    > put .invalid on the end
    >
    > Now your /etc/hosts should have something like:
    > 127.0.0.1 localhost
    > 192.168.1.1 gateway
    > 192.168.1.47 darkstar.home.invalid darkstar


    Novice comment: I don't understand the rationale for making this change.
    >
    >
    > I will suggest changing your ip address to 192.168.1.140
    > It is hard to prove if you are running static or dhcp.


    In the other thread you suggested 192.168.1.147, and that's what I used
    at first. But I had a setback.

    My PC is dual-boot: Fedora 7 and Windows/ME. Nowadays I mostly run
    Fedora, but at least once a week I run Windows/ME.

    I ran Fedora with static IP for several days with no problem. During
    that time I did not run Windows/ME. When I eventually ran Windows/ME I
    also configured that for static IP. It ran OK, but the domain I selected
    on the DNS configuration screen is not what is recommended.


    A few days later, Fedora would not boot. It hung in boot on "starting
    sendmail". I booted back into Windows/ME. It could not locate Google.

    After switching Fedora and Windows back to dynamic IP, everything was OK.

    So, I've made a second attempt with static IP. I thought I'd play it
    safe and use the same IP address that DHCP was giving me.
    >
    > Change ip addy in /etc/sysconfig/network-scripts/ifcfg-eth0,
    > /etc/hosts to match ip addy and reboot. You should have no problem.
    >
    >> ======== cat /etc/sysconfig/network-scripts/ifcfg-eth0 ==========
    >> # Intel Corporation 82557/8/9 [Ethernet Pro 100]
    >> DEVICE=eth0
    >> ONBOOT=yes
    >> BOOTPROTO=none
    >> HWADDR=00:07:e9:01:b2:09
    >> TYPE=Ethernet
    >> USERCTL=yes
    >> IPV6INIT=no
    >> PEERDNS=yes
    >> NETMASK=255.255.255.0
    >> IPADDR=192.168.1.47
    >> GATEWAY=192.168.1.1

    >
    > BOOTPROTO= seems to indicate static but look,
    > renew 3 2007/11/7 05:23:24;
    > rebind 3 2007/11/7 15:31:25;
    > expire 3 2007/11/7 18:31:25;
    >
    > Why are you getting a new dhcp lease??????
    > Something is still not right. Maybe PEERDNS=yes caused the lease request.
    >
    > When you made your changes, did you use the gui interface, or did you
    > just edit files?
    > If edited files for eth0, use gui interface to modify eth0.


    I used the GUI.
    >



  4. Re: Troubleshooting connection loss (continued)

    On Thu, 08 Nov 2007 23:03:02 GMT, Allen Weiner wrote:
    > Bit Twister wrote:
    >
    > I believe ntp runs only occasionally.


    Very true if clock is close to time server.

    I don't have automatic email checks.

    I had no idea if you had someting like thunderbird up. Default is
    check every 10 minutes.


    > While my connection is up, the Gkrellm eth0 monitor never goes
    > blank, even if I'm just browsing local files on my HDD. A partial
    > explanation, from the other thread, is that every 15 seconds, Verizon is
    > probing to see if I'm running a server.


    Yea, saw that. but I never see those in my Verizon router log. You would think
    they would check for servers on us FiOs users.


    >> What you posted above, did not show us that fact.

    >
    > "service network restart" clears the routing table and then hangs.


    Yes, but, while down, the proof would be
    route -n > down.txt
    ifconfig >> down.txt
    and include down.txt in your reply

    > 1. Connection loss.
    > 2. I issue route -n. Result is same as before connection loss.


    I'll take your word for it. :-)


    > avahi-daemon 0ff 1ff 2ff 3n 4n 5ff 6ff


    > I boot into runlevel 5. The above result shows that avahi-daemon is not
    > activated for runlevel 5.


    Ok, I guess I'll need to add code to get runlevel. :-D


    >>> ========== head -15 /etc/hosts ===========
    >>> 192.168.1.1 gateway

    >>
    >>
    >> That bites, you should have a local host entry.
    >> I suggest one for the node, if you would give it a node name.

    >
    > Novice question: What is the rationale for having a local host entry?


    There are apps which want to commicate and they just want to do it on
    the local host (127.0.0.1)

    > When I originally configured for static IP, I got the DNS server
    > addresses from the router. Primary: 68.237.161.12. Secondary:
    > 71.250.0.12. Isn't everything in "12" Verizon?


    Make sure, host ip_here_2_check

    > Besides, as long as I can
    > browse the web, DNS must be working even if the servers aren't from Verizon.


    Very true, but what if some cracker manages to put their DNS servers
    in there. :-(

    I was worried, because of the myhome.westell.com hostname being issued to your
    node via dhcp.

    >>
    >> Now your /etc/hosts should have something like:
    >> 127.0.0.1 localhost
    >> 192.168.1.1 gateway
    >> 192.168.1.47 darkstar.home.invalid darkstar

    >
    > Novice comment: I don't understand the rationale for making this change.


    Need the 127. entry for local communications.
    I left the gateway line.
    The darkstar.home.invalid darkstar was so there was an entry for your
    static ip which matched your node name.
    That ip is normally used by your desktop manager for when it
    uses your node name for ip resolution.


    > In the other thread you suggested 192.168.1.147,


    Yep, that was to tell me if dhcp gave you an address or you were realy
    were using a static value. When I indicated 140 in this thread, it
    was to help keep anyone from confusing .147 with .47. Next time I'll
    choose .150

    > and that's what I used at first. But I had a setback.
    >
    > My PC is dual-boot: Fedora 7 and Windows/ME. Nowadays I mostly run
    > Fedora, but at least once a week I run Windows/ME.


    I would think one OS set dhcp and other OS set static should not
    matter as long as ip address is different.
    I do it all the time. First install uses dhcp and some time later I
    pick a static ip. My XP Home ran dhcp until the next Second Tuesday
    when I booted for updates.

    > I ran Fedora with static IP for several days with no problem.


    Past the normal failure date???

    > During
    > that time I did not run Windows/ME. When I eventually ran Windows/ME I
    > also configured that for static IP. It ran OK, but the domain I selected
    > on the DNS configuration screen is not what is recommended.


    If static, I would have set actual verizon dns values found in router.
    But, if you wanted you can use the router's dns vaule (192.168.1.1)

    > A few days later, Fedora would not boot.
    > It hung in boot on "starting sendmail".


    Yep, it may have not been able to lookup node name in /etc/hosts.
    It may have hung because it wanted to look up the upline
    relay/smart host to send email still in the mail queue and network was
    not up.

    > I booted back into Windows/ME. It could not locate Google.


    If WinME could not ping 72.14.207.99 (google.com) or 208.101.56.232
    (www.google.com) then connection was still down.

    > After switching Fedora and Windows back to dynamic IP, everything was OK.


    I would set both static with verizon dns values, power off everything,
    wait 1 minute by the wall clock, powerup modem, let leds settle, power
    up pc.

    If you switched them to the original .47 then, the router still thinks
    it handed out the lease and it is being used.

    As an FYI. I answered yes to a XP Home Windows Update nic driver and I could
    no longer use the nic under linux. :-(

    > So, I've made a second attempt with static IP. I thought I'd play it
    > safe and use the same IP address that DHCP was giving me.


    And that is why I asked for 147. We have to break the dhcp server/client
    out of the loop to see which end of the connection is causing your
    drop out problem.

    > I used the GUI.


    Ok, good, I had booted my fedora 7 install and found there is another
    eth0 config file in a default/ directory awhile ago. No idea which one
    is being used to control the nic.

    Freaking mlocate cron script does not seem to update the locate database. I
    installed updatates and need to go back and boot fc7, update the
    locate database and see if locate eth0 shows all the config files when logged
    in as root.

    I did check, and FC7 GUI does not have a selection to allow setting
    PEERDNS=no in nic config file.

    If you have about 10 gig of free space, I can get you setup on
    Mandriva Linux and we can rule out Fedora as your problem. :-P


    Something else to play with the next time your connection drops.
    Before you do the service network restart, I want you to unplug the
    ethernet to pc cable from the modem or nic.
    Wait at least 30 seconds by the wall clock, plug it in and do the
    serice network restart and see if network comes up.

    Once in a great while when playing with my network, I have had to
    restart my firewall after restarting the network.


  5. Re: Troubleshooting connection loss (continued)

    Bit Twister wrote:
    > On Thu, 08 Nov 2007 23:03:02 GMT, Allen Weiner wrote:
    >> Bit Twister wrote:
    >>
    >> I believe ntp runs only occasionally.

    >
    > Very true if clock is close to time server.
    >
    > I don't have automatic email checks.
    >
    > I had no idea if you had someting like thunderbird up. Default is
    > check every 10 minutes.


    I am using Thunderbird for USENET but not for email. My Thunderbird
    profile broke when I switched ISPs and I can't fix it.
    >
    >
    >> While my connection is up, the Gkrellm eth0 monitor never goes
    >> blank, even if I'm just browsing local files on my HDD. A partial
    >> explanation, from the other thread, is that every 15 seconds, Verizon is
    >> probing to see if I'm running a server.

    >
    > Yea, saw that. but I never see those in my Verizon router log. You would think
    > they would check for servers on us FiOs users.
    >

    My Westell modem/router log hardly shows anything. That's another puzzle
    to solve someday.
    >
    >>> What you posted above, did not show us that fact.

    >> "service network restart" clears the routing table and then hangs.

    >
    > Yes, but, while down, the proof would be
    > route -n > down.txt
    > ifconfig >> down.txt
    > and include down.txt in your reply
    >
    >> 1. Connection loss.
    >> 2. I issue route -n. Result is same as before connection loss.

    >
    > I'll take your word for it. :-)
    >
    >
    >> avahi-daemon 0ff 1ff 2ff 3n 4n 5ff 6ff

    >
    >> I boot into runlevel 5. The above result shows that avahi-daemon is not
    >> activated for runlevel 5.

    >
    > Ok, I guess I'll need to add code to get runlevel. :-D
    >
    >
    >>>> ========== head -15 /etc/hosts ===========
    >>>> 192.168.1.1 gateway
    >>>
    >>> That bites, you should have a local host entry.
    >>> I suggest one for the node, if you would give it a node name.

    >> Novice question: What is the rationale for having a local host entry?

    >
    > There are apps which want to commicate and they just want to do it on
    > the local host (127.0.0.1)
    >
    >> When I originally configured for static IP, I got the DNS server
    >> addresses from the router. Primary: 68.237.161.12. Secondary:
    >> 71.250.0.12. Isn't everything in "12" Verizon?

    >
    > Make sure, host ip_here_2_check


    68.237.161.12 nsnyny01.verizon.net
    71.250.0.12 nsnwrk01.verizon.net
    I wasn't aware of the host command.
    >
    >> Besides, as long as I can
    >> browse the web, DNS must be working even if the servers aren't from Verizon.

    >
    > Very true, but what if some cracker manages to put their DNS servers
    > in there. :-(
    >
    > I was worried, because of the myhome.westell.com hostname being issued to your
    > node via dhcp.
    >
    >>> Now your /etc/hosts should have something like:
    >>> 127.0.0.1 localhost
    >>> 192.168.1.1 gateway
    >>> 192.168.1.47 darkstar.home.invalid darkstar

    >> Novice comment: I don't understand the rationale for making this change.

    >
    > Need the 127. entry for local communications.
    > I left the gateway line.
    > The darkstar.home.invalid darkstar was so there was an entry for your
    > static ip which matched your node name.
    > That ip is normally used by your desktop manager for when it
    > uses your node name for ip resolution.
    >
    >
    >> In the other thread you suggested 192.168.1.147,

    >
    > Yep, that was to tell me if dhcp gave you an address or you were realy
    > were using a static value. When I indicated 140 in this thread, it
    > was to help keep anyone from confusing .147 with .47. Next time I'll
    > choose .150
    >
    >> and that's what I used at first. But I had a setback.
    >>
    >> My PC is dual-boot: Fedora 7 and Windows/ME. Nowadays I mostly run
    >> Fedora, but at least once a week I run Windows/ME.

    >
    > I would think one OS set dhcp and other OS set static should not
    > matter as long as ip address is different.
    > I do it all the time. First install uses dhcp and some time later I
    > pick a static ip. My XP Home ran dhcp until the next Second Tuesday
    > when I booted for updates.
    >
    >> I ran Fedora with static IP for several days with no problem.

    >
    > Past the normal failure date???

    There is no normal failure date. I can go as short as 2 days and as long
    as 10 days between failures. There does seem to be a normal failure time
    of 2 to 2.5 hours into the session. Does not reoccur after reboot.
    >
    >> During
    >> that time I did not run Windows/ME. When I eventually ran Windows/ME I
    >> also configured that for static IP. It ran OK, but the domain I selected
    >> on the DNS configuration screen is not what is recommended.

    >
    > If static, I would have set actual verizon dns values found in router.
    > But, if you wanted you can use the router's dns vaule (192.168.1.1)


    I used the same DNS servers for Fedora and Windows. On the Windows DNS
    configuration screen, besides the server IP's, there were entries for
    hostname and domain name. For domain name, it is recommended to use
    something like verizon.net. I used "localdomain".

    If someone can confirm that that error is what caused my subsequent boot
    failure, then I'll gladly change my static IP address to 192.168.1.150.
    >
    >> A few days later, Fedora would not boot.
    >> It hung in boot on "starting sendmail".

    >
    > Yep, it may have not been able to lookup node name in /etc/hosts.
    > It may have hung because it wanted to look up the upline
    > relay/smart host to send email still in the mail queue and network was
    > not up.
    >
    >> I booted back into Windows/ME. It could not locate Google.

    >
    > If WinME could not ping 72.14.207.99 (google.com) or 208.101.56.232
    > (www.google.com) then connection was still down.
    >
    >> After switching Fedora and Windows back to dynamic IP, everything was OK.

    >
    > I would set both static with verizon dns values, power off everything,
    > wait 1 minute by the wall clock, powerup modem, let leds settle, power
    > up pc.
    >
    > If you switched them to the original .47 then, the router still thinks
    > it handed out the lease and it is being used.
    >
    > As an FYI. I answered yes to a XP Home Windows Update nic driver and I could
    > no longer use the nic under linux. :-(
    >
    >> So, I've made a second attempt with static IP. I thought I'd play it
    >> safe and use the same IP address that DHCP was giving me.

    >
    > And that is why I asked for 147. We have to break the dhcp server/client
    > out of the loop to see which end of the connection is causing your
    > drop out problem.
    >
    >> I used the GUI.

    >
    > Ok, good, I had booted my fedora 7 install and found there is another
    > eth0 config file in a default/ directory awhile ago. No idea which one
    > is being used to control the nic.
    >
    > Freaking mlocate cron script does not seem to update the locate database. I
    > installed updatates and need to go back and boot fc7, update the
    > locate database and see if locate eth0 shows all the config files when logged
    > in as root.
    >
    > I did check, and FC7 GUI does not have a selection to allow setting
    > PEERDNS=no in nic config file.
    >
    > If you have about 10 gig of free space, I can get you setup on
    > Mandriva Linux and we can rule out Fedora as your problem. :-P

    I have a Knoppix Live CD. Was thinking about that. But I've never gone
    online with Knoppix.
    >
    >
    > Something else to play with the next time your connection drops.
    > Before you do the service network restart, I want you to unplug the
    > ethernet to pc cable from the modem or nic.
    > Wait at least 30 seconds by the wall clock, plug it in and do the
    > serice network restart and see if network comes up.

    will do.
    >
    > Once in a great while when playing with my network, I have had to
    > restart my firewall after restarting the network.
    >


  6. Re: Troubleshooting connection loss (continued)

    On Fri, 09 Nov 2007 01:53:43 GMT, Allen Weiner wrote:
    >
    > I am using Thunderbird for USENET but not for email. My Thunderbird
    > profile broke when I switched ISPs and I can't fix it.


    Delete old servers, set new ones.
    incoming.verizon.net. (pop3)
    outgoing.verizon.net. (smtp)


    > I wasn't aware of the host command.


    I use it to get ip addies and look up ip addies.
    I think it is the replacement for nslookup


    >> Past the normal failure date???

    > There is no normal failure date. I can go as short as 2 days and as long
    > as 10 days between failures.


    That is where I picked up "fails every ten days"


    > There does seem to be a normal failure time
    > of 2 to 2.5 hours into the session.


    Which is odd, because if a dhcp renew failure, it should be half way
    through the lease time, I.E noon after a Midnight lease. That is based
    on the rebind/renew times given in a lease relative to when you
    recived the lease.

    > Does not reoccur after reboot.


    And that makes no sense unless, the first boot is after a WinME session.
    If so, just after boot, do a service network restart and verify
    network comes up. Then watch for failure.

    > I used the same DNS servers for Fedora and Windows. On the Windows DNS
    > configuration screen, besides the server IP's, there were entries for
    > hostname and domain name. For domain name, it is recommended to use
    > something like verizon.net.


    Well, I wouldn't/didn't follow the suggestion.
    There is nothing wrong with making someting up and putting .invalid on the end.

    > I used "localdomain".


    Yes, and that is the one name I want to talk you out of.
    I do not do windoze, but use the search feature in your FILE explorer
    and look for the etc.hosts file. Take a look at it.


    > If someone can confirm that that error is what caused my subsequent boot
    > failure, then I'll gladly change my static IP address to 192.168.1.150.


    I am leaning towards a router glitch.
    Do make my node name and /etc/hosts change suggestions.

    Just for fun, pick node.domain names like,
    winme.here.invalid
    and fedora.here.invalid
    Give each OS static numbers, .140 and .150

    >> If you have about 10 gig of free space, I can get you setup on
    >> Mandriva Linux and we can rule out Fedora as your problem. :-P

    > I have a Knoppix Live CD. Was thinking about that. But I've never gone
    > online with Knoppix.


    knoppis will automagically do your DHCP address selection for you during boot.

    Somewhere in the menu is knoppix which is where you can configure the network.

  7. Re: Troubleshooting connection loss (continued)

    On Fri, 09 Nov 2007 02:26:23 GMT, Bit Twister wrote:
    >
    > Yes, and that is the one name I want to talk you out of.
    > I do not do windoze, but use the search feature in your FILE explorer
    > and look for the etc.hosts file. Take a look at it.


    that should be etc/hosts


    > I am leaning towards a router glitch.
    > Do make my node name and /etc/hosts change suggestions.
    >
    > Just for fun, pick node.domain names like,
    > winme.here.invalid
    > and fedora.here.invalid
    > Give each OS static numbers, .140 and .150


    After you make the second system static setup, do power reset the router.


  8. Re: Troubleshooting connection loss (continued)

    On Fri, 09 Nov 2007 02:37:34 GMT, Bit Twister wrote:
    > On Fri, 09 Nov 2007 02:26:23 GMT, Bit Twister wrote:
    >>
    >> Yes, and that is the one name I want to talk you out of.
    >> I do not do windoze, but use the search feature in your FILE explorer
    >> and look for the etc.hosts file. Take a look at it.

    >
    > that should be etc/hosts


    dang, for windows it's \hosts

    I think you will find it under C:\Windows or C:\Windows\etc

    Please tell me where you find it.


  9. Re: Troubleshooting connection loss (continued)

    Allen Weiner wrote:
    > (I posted a similar thread to this newsgroup on October 29. Due to
    > continuing problems, I'm opening this thread.)


    Hey, you've now opened 4 threads here. Gotta admire your tenacity.

    Here's a suggestion which is a flat-out guess:

    Next time things stop try

    ethtool -r eth0

    and then check the "ifconfig eth0" output for RUNNING.

    Hey, it's quick anyway.

    Regards-
    --
    Clifford Kite
    /* My confidence in this answer (X), on a scale of 0 to 10:
    |----|----|----|Roll the dice!|----|----|----|----|
    0----1----2----3----4----5----6----7----8----9----10 */


  10. Re: Troubleshooting connection loss (continued)

    Bit Twister wrote:
    > On Fri, 09 Nov 2007 02:37:34 GMT, Bit Twister wrote:
    >> On Fri, 09 Nov 2007 02:26:23 GMT, Bit Twister wrote:
    >>> Yes, and that is the one name I want to talk you out of.
    >>> I do not do windoze, but use the search feature in your FILE explorer
    >>> and look for the etc.hosts file. Take a look at it.

    >> that should be etc/hosts

    >
    > dang, for windows it's \hosts
    >
    > I think you will find it under C:\Windows or C:\Windows\etc
    >
    > Please tell me where you find it.
    >

    I haven't confirmed this on my PC, but from a Google search:

    (2.) Try to locate any existing hosts file on your computer:

    Windows 95/98/Me c:\windows\hosts


    About Thunderbird, I can't access the profile to edit it. This issue has
    been discussed on Fedoraforum. Thunderbird on Fedora is broken. A
    bugzilla on this issue has been filed.

  11. Re: Troubleshooting connection loss (continued)

    Clifford Kite wrote:
    > Allen Weiner wrote:
    >> (I posted a similar thread to this newsgroup on October 29. Due to
    >> continuing problems, I'm opening this thread.)

    >
    > Hey, you've now opened 4 threads here. Gotta admire your tenacity.


    This problem is frustrating. I firmly believe (with almost no supporting
    evidence) that a reboot to regain a lost Internet connection should be a
    last resort.

    I also believe (again with no supprting evidence), that there should be
    a straightforward troubleshooting procedure when a "service network
    restart" hangs.
    >
    > Here's a suggestion which is a flat-out guess:
    >
    > Next time things stop try
    >
    > ethtool -r eth0
    >
    > and then check the "ifconfig eth0" output for RUNNING.


    I've done ethtool eth0 and ifconfig after connection loss but before
    issuing "service network restart". Eth0 is UP but not RUNNING. Link
    detected = yes.
    >
    > Hey, it's quick anyway.
    >
    > Regards-


  12. Re: Troubleshooting connection loss (continued)

    On Fri, 09 Nov 2007 04:22:10 GMT, Allen Weiner wrote:
    >
    > This problem is frustrating. I firmly believe (with almost no supporting
    > evidence) that a reboot to regain a lost Internet connection should be a
    > last resort.


    I agree.

    I might have missed it, but is that first boot after winME was running?


    > I also believe (again with no supprting evidence), that there should be
    > a straightforward troubleshooting procedure when a "service network
    > restart" hangs.


    It is staight forward, ethtoo/mii-tool says the nic is connected and
    ping should tell where it fails.

    So far, my guess is riding on the router is refusing the connection
    because the dhcp lease issued to winME has expired.
    That is why I wanted your fedora
    /etc/hosts file set somewhat as follows:
    $ head -3 /etc/hosts
    127.0.0.1 localhost
    192.168.1.140 fedora.home.invalid fedora
    192.168.1.1 gateway


    $ cat /etc/sysconfig/network
    NETWORKING=yes
    HOSTNAME=fedora.home.invalid

    and you have set eth0 up as static for ip 192.168.1.140


  13. Re: Troubleshooting connection loss (continued)

    Allen Weiner wrote:
    > Clifford Kite wrote:
    >>
    >> Next time things stop try
    >>
    >> ethtool -r eth0
    >>
    >> and then check the "ifconfig eth0" output for RUNNING.


    > I've done ethtool eth0 and ifconfig after connection loss but before
    > issuing "service network restart". Eth0 is UP but not RUNNING. Link
    > detected = yes.


    Well, just to be sure we understand one another, "ethtool eth0" the -r
    option tries to restart autonegotiation.

    Regards-
    --
    Clifford Kite



  14. Re: Troubleshooting connection loss (continued)

    Bit Twister wrote:
    > On Fri, 09 Nov 2007 04:22:10 GMT, Allen Weiner wrote:
    >> This problem is frustrating. I firmly believe (with almost no supporting
    >> evidence) that a reboot to regain a lost Internet connection should be a
    >> last resort.

    >
    > I agree.
    >
    > I might have missed it, but is that first boot after winME was running?
    >

    I'm not sure what you're asking. If you are asking about the time that
    Fedora became unbootable, here is the history:

    1. WinME ran with static IP on 11/3
    2. Fedora ran OK with static IP on 11/4
    3. Fedora failed to boot on 11/5.

    You commented that it is OK to have dual boot where Linux uses static IP
    and Windows uses dynamic IP. To keep things simple, this is the config I
    would prefer. I kinda thought that when I configured for static IP,
    something was being permanently stored in flash memory in the NIC and/or
    modem/router. I thought that if I left Windows with dynamic IP, it would
    undo those flash changes I configured from Fedora.


    >
    >> I also believe (again with no supprting evidence), that there should be
    >> a straightforward troubleshooting procedure when a "service network
    >> restart" hangs.

    >
    > It is staight forward, ethtoo/mii-tool says the nic is connected and
    > ping should tell where it fails.
    >
    > So far, my guess is riding on the router is refusing the connection
    > because the dhcp lease issued to winME has expired.
    > That is why I wanted your fedora
    > /etc/hosts file set somewhat as follows:
    > $ head -3 /etc/hosts
    > 127.0.0.1 localhost
    > 192.168.1.140 fedora.home.invalid fedora
    > 192.168.1.1 gateway
    >
    >
    > $ cat /etc/sysconfig/network
    > NETWORKING=yes
    > HOSTNAME=fedora.home.invalid
    >
    > and you have set eth0 up as static for ip 192.168.1.140
    >


    I've been going over your suggested changes from both threads. For the
    time being, I want to make only changes needed for troubleshooting. For
    now, I'm not concerned about apps which want to communicate over
    127.0.0.1. (I'm not aware of any problem this has caused.)

    I'm concerned about making changes that will render Fedora unbootable.
    (I've already had a close call with the change to static IP). I don't
    have the experience to repair Fedora if it becomes unbootable.

    Before making changes, I'm going to do some googling into /etc/hosts and
    FQDN to try to raise my confidence level. Also, I'd feel much more
    comfortable if I understood what went wrong with my change to static IP.

    By the way, I remembered that I have a Ubuntu 6.06 CD. I've got many
    gigs of free HDD space, and available logical partitions. But that is
    too much of a detour to fix this problem.

  15. Re: Troubleshooting connection loss (continued)

    Clifford Kite wrote:
    > Allen Weiner wrote:
    >> Clifford Kite wrote:
    >>> Next time things stop try
    >>>
    >>> ethtool -r eth0
    >>>
    >>> and then check the "ifconfig eth0" output for RUNNING.

    >
    >> I've done ethtool eth0 and ifconfig after connection loss but before
    >> issuing "service network restart". Eth0 is UP but not RUNNING. Link
    >> detected = yes.

    >
    > Well, just to be sure we understand one another, "ethtool eth0" the -r
    > option tries to restart autonegotiation.
    >
    > Regards-

    Thanks for pointing that out. I wasn't aware of the -r option and I'll
    put that on my list of things to try on the next connection loss.

  16. Re: Troubleshooting connection loss (continued)

    On Fri, 09 Nov 2007 16:36:24 GMT, Allen Weiner wrote:
    > Bit Twister wrote:
    >> On Fri, 09 Nov 2007 04:22:10 GMT, Allen Weiner wrote:
    >>> This problem is frustrating. I firmly believe (with almost no supporting
    >>> evidence) that a reboot to regain a lost Internet connection should be a
    >>> last resort.

    >>
    >> I agree.
    >>
    >> I might have missed it, but is that first boot after winME was running?
    >>

    > I'm not sure what you're asking.


    What I was after is the sequences of boots with regard to what was
    running before the boot. Example: Both systems are set dhcp.

    Boot WinMe and run for awhile.
    boot fedora and some time later connection goes down
    boot fedora and no problem

    If connection failure is always in that order, then my theory is the router
    remembers the dhcp lease assigned to doze and cannot get a renewal
    when you are running fedora on your first boot.

    That will cause the connection drop and the router will refuse
    traffic connections with fedore.

    I was guessing winME was not Releasing the lease on shutdown.
    You boot fedora, it gets the connection up on it's old lease contents,
    But, does not get a lease renewal from the router.

    Why does reboot not have the problem you ask.

    When you reboot, while going down, fedora sends a lease cancel to router,
    comes up, and the router and fedora shake hands over lease
    info and have no problems thereafter.

    > If you are asking about the time that
    > Fedora became unbootable, here is the history:
    >
    > 1. WinME ran with static IP on 11/3
    > 2. Fedora ran OK with static IP on 11/4
    > 3. Fedora failed to boot on 11/5.


    Here I would be guessing,
    o you used the dhcp ip addresses as static
    o router still thought the ip address was DHCP
    o lease expired
    o no new lease negotiated and refused the connection to 192.168.1.47

    And/Or /etc/hosts not set per my sugestions and gave you the hard time.

    > You commented that it is OK to have dual boot where Linux uses static IP
    > and Windows uses dynamic IP. To keep things simple, this is the config I
    > would prefer.


    Yes, but we are troubleshooting here and need to reduce the suspect list
    and get a known working baseline with the least amount of interaction.

    Assuming Verizon does not get into the mix, I see no setup problem
    with doing what you want. IF you use a different static ip, no
    localhost node name, /etc/hosts set as asked.

    > I kinda thought that when I configured for static IP,
    > something was being permanently stored in flash memory in the NIC


    I do not think so.

    > and/or modem/router.


    Yes, and I am guessing the router is the problem. Why you ask. If it
    was fedora, the reboot should have the same problem as a normal boot.

    > I thought that if I left Windows with dynamic IP, it would
    > undo those flash changes I configured from Fedora.


    But you left static ip same as dhcp and if the lease is not renewed, modem
    will drop the connection to 192.168.1.47.

    >> That is why I wanted your fedora
    >> /etc/hosts file set somewhat as follows:
    >> $ head -3 /etc/hosts
    >> 127.0.0.1 localhost
    >> 192.168.1.140 fedora.home.invalid fedora
    >> 192.168.1.1 gateway
    >>
    >>
    >> $ cat /etc/sysconfig/network
    >> NETWORKING=yes
    >> HOSTNAME=fedora.home.invalid
    >>
    >> and you have set eth0 up as static for ip 192.168.1.140
    >>

    >
    > I've been going over your suggested changes from both threads.


    Yeah, but your piecemeal approach about putting in my suggestions is
    causing more problems.

    Upside is, all the experience/knowledge you are gaining.

    > For the
    > time being, I want to make only changes needed for troubleshooting.


    So far you are fighting me on getting the job done. :-D
    What I have been after is:

    Get fedora in a normal configuration (node/hosts).
    Static connection with ip address different than dhcp ip.
    Power reset modem, prove fedora boots, reboots and runs without problems.

    If so, that would leave fedora's dhcp client as a suspect.
    That is ruled out because you say after reboot, fedora does not have
    the problem when runinnig dhcp.

    To cut modem's dhcp server out of the loop, set static ips and verify
    connection does not have problems.

    With both OSs set static different ips, and booting winME/fedora does not
    have connection drops, you now have isolated the modem as the culprit.

    Now, you boot doze, change it back to dhcp, reboot doze, boot fedora.
    Connection drops you know the modem is causing the problem and have a
    working solution to fall back on.

    > For now, I'm not concerned about apps which want to communicate over
    > 127.0.0.1.


    HAHAHAHHaHahahaha, cough, cough, choke. whew....

    Did you remember when sendmail stalled your boot.

    On normal setups/install, 127.0.0.1 localhost is in /etc/hosts.

    On your system you named your node localhost and the ip address comes
    in from the nic. When the network fails to come up, you start seeing
    problems. So far you have been lucky, connection comes up, localhost
    ip addy resolves to 192.168.1.47 and all is well.

    When node named localhost, cannot be resolved, you will see problems.

    > I'm concerned about making changes that will render Fedora unbootable.
    > (I've already had a close call with the change to static IP). I don't
    > have the experience to repair Fedora if it becomes unbootable.


    I hear where you are comming from. Had /etc/hosts contained the
    127.0.0.1 localhost, you would not have had the problem.

    Trust me. give your node a FQDN with a name beside localhost.
    In a static setup, a line with ip FQDN alias in /etc/hosts with a
    127.0.0.1 localhost line.

    Here is my suggestion:

    Get into the network gui, set it static 192.168.1.150 with a
    node/domain name as fedora.home.invalid, 192.168.1.1 as your DNS
    server. Close the gui.

    cat these files and verify contents.
    If not the same, use an editor and fix them

    # cat /etc/sysconfig/network
    NETWORKING=yes
    HOSTNAME=fedora.home.invalid

    # cat /etc/hosts
    127.0.0.1 localhost
    192.168.1.150 fedora.home.invalid fw
    192.168.1.1 gateway

    Power down modem. Wait 30 seconds by watch/clock.
    Power up modem, wait for leds to settle
    Reboot Fedora to prove fedora works.

    As far as "render Fedora unbootable" that is the problem with using
    gui to modify config files. Knowing which confif files to backup, and
    edit from a command line in failsafe/rescue cd helps.

    I recommend that you play with vi in a terminal and write these very basic
    commands down and put them in a binder where you can find them.

    vi fn_here
    i <======= puts you into the insert mode

    Now you can use arrow keys and whatnot.
    When ready to get out,

    Esc <==== (escape key) gets you into the command mode
    :wq <=== save changes and quit
    :q! <==== quit without saving.



    With Mandriva linux, it provides a rosetta stone file which has what
    values in what file does what. (/usr/share/doc/initscripts/sysconfig.txt)

    If you can not find docs about config files, what you could do is
    install aide.
    That would let you baseline the system.
    Use your gui to make changes, run an aide check and the report would give
    you all the files that changed.
    Other option, read source code.


    > Before making changes, I'm going to do some googling into /etc/hosts and
    > FQDN to try to raise my confidence level. Also, I'd feel much more
    > comfortable if I understood what went wrong with my change to static IP.


    My guess, with node name = localhost, no 127.0.0.1 and hostname/ip in
    /etc/hosts; that is what helped you into the ditch.

    > By the way, I remembered that I have a Ubuntu 6.06 CD. I've got many
    > gigs of free HDD space, and available logical partitions. But that is
    > too much of a detour to fix this problem.


    Well, you started out with, why is fedora having these problems. If
    running ubuntu and have the same problem, what would your guess be.

    Hey, create a 10 gig logical partition. install ubuntu and pick Manual
    during partition phase, set new partition as / and click format box,
    and you will have a multi-boot system. Let it
    run dhcp and if the connection drops out, you know that fedora is
    not the problem.

    Another solution/option you may want to consider, have a hot
    backup/fallback install of fedora.

    That is what I do for my install. Anytime I think I might put the
    system in the ditch, I boot the hot backup and play there.

    Create/format a logical 10 gig partition with mount point as /hotbu.

    e2label /dev/XdYZ hotbu <==== creates a label for booting
    You solve for X [h,s], Y [a,b,c...] & Z [1,2,3..]


    mkdir /fc7 <==== create mount point for original install
    to be used in hotbu's /etc/fstab
    cd /etc
    cp fstab fstab_works
    cp fstab fstab_hotbu

    Edit fstab_hotbu and change the label for / and change the hotbu
    line to whatever label the original / had and the mount point to /fc7.
    See the following:


    # cat /hotbu/etc/fstab
    LABEL=hotbu / ext3 defaults 1 1
    LABEL=fedora /fc7 ext3 defaults 1 2
    LABEL=accounts /accounts ext3 defaults 1 2
    tmpfs /dev/shm tmpfs defaults 0 0
    devpts /dev/pts devpts gid=5,mode=620 0 0
    sysfs /sys sysfs defaults 0 0
    proc /proc proc defaults 0 0
    LABEL=2008_0 /2008_0 ext3 user,noauto,defaults 1 2
    LABEL=2007_0 /2007_0 ext3 user,noauto,defaults 1 2
    LABEL=bk_up /bk_up ext3 user,noauto,defaults 1 2
    LABEL=2007_1 /2007_1 ext3 user,noauto,defaults 1 2
    LABEL=local /local ext3 defaults 1 2
    LABEL=kubu7 /kubu7 ext3 user,noauto,defaults 1 2
    /dev/sda6 swap swap defaults 0 0

    Next you can edt /boot/grub/menu.lst, duplicate the fedora stanza, change
    the label to hotbu, save exit.

    Next you need to note which partition have what. Assuming two drives
    blkid /dev/Xda*
    blkid /dev/Xdb*

    If you have a printer, I would get a hardcopy.

    Now you boot a rescue cd

    mkdir /old
    mkdir /new
    mount -t auto /dev/XdYZ /old
    mount -t auto /dev/XdYZ /new

    Double/triple check /dev/XdYZ /old is current fedora and
    /dev/XdYZ /new is the newly formated partition.


    # Copy fedora partition contents into new partition.

    cd /old
    cp -a . /new

    # fix new copy's fstab to use new partition a /

    cd /new/etc
    cp fstab_hotbu fstab

    # all done close the partitions, and get out of rescue cd.
    cd
    umount /old /new

    shutdown -r


    Eject rescue cd, pick hotbu from grub menu and you
    should be running in your hotbu partition.

    Another option is run a virtual machine. http://www.vmware.com has a
    free player where you should be able to find an fc7 install to play in.

    --
    The warranty and liability expired as you read this message.
    If the above breaks your system, it's yours and you keep both pieces.
    Practice safe computing. Backup the file before you change it.
    Do a, man command_here or cat command_here, before using it.

  17. Re: Troubleshooting connection loss (continued)

    Bit Twister wrote:
    > On Fri, 09 Nov 2007 16:36:24 GMT, Allen Weiner wrote:
    >> Bit Twister wrote:
    >>> On Fri, 09 Nov 2007 04:22:10 GMT, Allen Weiner wrote:
    >>>> This problem is frustrating. I firmly believe (with almost no supporting
    >>>> evidence) that a reboot to regain a lost Internet connection should be a
    >>>> last resort.
    >>> I agree.
    >>>
    >>> I might have missed it, but is that first boot after winME was running?
    >>>

    >> I'm not sure what you're asking.

    >
    > What I was after is the sequences of boots with regard to what was
    > running before the boot. Example: Both systems are set dhcp.
    >
    > Boot WinMe and run for awhile.
    > boot fedora and some time later connection goes down
    > boot fedora and no problem
    >
    > If connection failure is always in that order, then my theory is the router
    > remembers the dhcp lease assigned to doze and cannot get a renewal
    > when you are running fedora on your first boot.
    >
    > That will cause the connection drop and the router will refuse
    > traffic connections with fedore.
    >
    > I was guessing winME was not Releasing the lease on shutdown.
    > You boot fedora, it gets the connection up on it's old lease contents,
    > But, does not get a lease renewal from the router.
    >
    > Why does reboot not have the problem you ask.
    >
    > When you reboot, while going down, fedora sends a lease cancel to router,
    > comes up, and the router and fedora shake hands over lease
    > info and have no problems thereafter.
    >
    >> If you are asking about the time that
    >> Fedora became unbootable, here is the history:
    >>
    >> 1. WinME ran with static IP on 11/3
    >> 2. Fedora ran OK with static IP on 11/4
    >> 3. Fedora failed to boot on 11/5.

    >
    > Here I would be guessing,
    > o you used the dhcp ip addresses as static
    > o router still thought the ip address was DHCP
    > o lease expired
    > o no new lease negotiated and refused the connection to 192.168.1.47
    >
    > And/Or /etc/hosts not set per my sugestions and gave you the hard time.


    Interesting theory. I don't have detailed recollection of what happened.
    Maybe while in troubleshooting mode I need to keep a log book.
    >
    >> You commented that it is OK to have dual boot where Linux uses static IP
    >> and Windows uses dynamic IP. To keep things simple, this is the config I
    >> would prefer.

    >
    > Yes, but we are troubleshooting here and need to reduce the suspect list
    > and get a known working baseline with the least amount of interaction.
    >
    > Assuming Verizon does not get into the mix, I see no setup problem
    > with doing what you want. IF you use a different static ip, no
    > localhost node name, /etc/hosts set as asked.
    >
    >> I kinda thought that when I configured for static IP,
    >> something was being permanently stored in flash memory in the NIC

    >
    > I do not think so.
    >
    >> and/or modem/router.

    >
    > Yes, and I am guessing the router is the problem. Why you ask. If it
    > was fedora, the reboot should have the same problem as a normal boot.
    >
    >> I thought that if I left Windows with dynamic IP, it would
    >> undo those flash changes I configured from Fedora.

    >
    > But you left static ip same as dhcp and if the lease is not renewed, modem
    > will drop the connection to 192.168.1.47.
    >
    >>> That is why I wanted your fedora
    >>> /etc/hosts file set somewhat as follows:
    >>> $ head -3 /etc/hosts
    >>> 127.0.0.1 localhost
    >>> 192.168.1.140 fedora.home.invalid fedora
    >>> 192.168.1.1 gateway
    >>>
    >>>
    >>> $ cat /etc/sysconfig/network
    >>> NETWORKING=yes
    >>> HOSTNAME=fedora.home.invalid
    >>>
    >>> and you have set eth0 up as static for ip 192.168.1.140
    >>>

    >> I've been going over your suggested changes from both threads.

    >
    > Yeah, but your piecemeal approach about putting in my suggestions is
    > causing more problems.
    >

    Thanks for your patience.

    > Upside is, all the experience/knowledge you are gaining.
    >

    Agreed. I feel these threads are a really worthwhile learning
    experience. I appreciate all the information and help you are giving me.

    >> For the
    >> time being, I want to make only changes needed for troubleshooting.

    >
    > So far you are fighting me on getting the job done. :-D
    > What I have been after is:
    >
    > Get fedora in a normal configuration (node/hosts).
    > Static connection with ip address different than dhcp ip.
    > Power reset modem, prove fedora boots, reboots and runs without problems.
    >
    > If so, that would leave fedora's dhcp client as a suspect.
    > That is ruled out because you say after reboot, fedora does not have
    > the problem when runinnig dhcp.
    >
    > To cut modem's dhcp server out of the loop, set static ips and verify
    > connection does not have problems.
    >
    > With both OSs set static different ips, and booting winME/fedora does not
    > have connection drops, you now have isolated the modem as the culprit.
    >
    > Now, you boot doze, change it back to dhcp, reboot doze, boot fedora.
    > Connection drops you know the modem is causing the problem and have a
    > working solution to fall back on.
    >
    >> For now, I'm not concerned about apps which want to communicate over
    >> 127.0.0.1.

    >
    > HAHAHAHHaHahahaha, cough, cough, choke. whew....
    >
    > Did you remember when sendmail stalled your boot.
    >
    > On normal setups/install, 127.0.0.1 localhost is in /etc/hosts.
    >
    > On your system you named your node localhost and the ip address comes
    > in from the nic. When the network fails to come up, you start seeing
    > problems. So far you have been lucky, connection comes up, localhost
    > ip addy resolves to 192.168.1.47 and all is well.
    >
    > When node named localhost, cannot be resolved, you will see problems.
    >
    >> I'm concerned about making changes that will render Fedora unbootable.
    >> (I've already had a close call with the change to static IP). I don't
    >> have the experience to repair Fedora if it becomes unbootable.

    >
    > I hear where you are comming from. Had /etc/hosts contained the
    > 127.0.0.1 localhost, you would not have had the problem.
    >
    > Trust me. give your node a FQDN with a name beside localhost.
    > In a static setup, a line with ip FQDN alias in /etc/hosts with a
    > 127.0.0.1 localhost line.
    >
    > Here is my suggestion:
    >
    > Get into the network gui, set it static 192.168.1.150 with a
    > node/domain name as fedora.home.invalid, 192.168.1.1 as your DNS
    > server. Close the gui.
    >
    > cat these files and verify contents.
    > If not the same, use an editor and fix them
    >
    > # cat /etc/sysconfig/network
    > NETWORKING=yes
    > HOSTNAME=fedora.home.invalid
    >
    > # cat /etc/hosts
    > 127.0.0.1 localhost
    > 192.168.1.150 fedora.home.invalid fw
    > 192.168.1.1 gateway
    >
    > Power down modem. Wait 30 seconds by watch/clock.
    > Power up modem, wait for leds to settle
    > Reboot Fedora to prove fedora works.


    Good news. I spent several hours on Google searching on /etc/hosts &
    localhost. Google pointed me to several Linux books which confirmed your
    recommendations and gave *excellent* explanations that addressed my
    concerns. For example, I was skepticsl about adding 127.0.0.1 to
    /etc/hosts. I thought, "if it's so important, it would have been there
    in the default config". Well, that concern was addressed in one of the
    book sections. So I'm now ready to accept your recommended changes.
    >




  18. Re: Troubleshooting connection loss (continued)

    On Fri, 09 Nov 2007 20:25:43 GMT, Allen Weiner wrote:
    >
    > Interesting theory. I don't have detailed recollection of what happened.
    > Maybe while in troubleshooting mode I need to keep a log book.


    Or a file with before/after values.

    >>
    >> Yeah, but your piecemeal approach about putting in my suggestions is
    >> causing more problems.
    >>

    > Thanks for your patience.


    I was beginning to wonder, if I was getting anyting across.

    >> Upside is, all the experience/knowledge you are gaining.
    >>

    > Agreed. I feel these threads are a really worthwhile learning
    > experience. I appreciate all the information and help you are giving me.


    Just trying to repay the time given to me on Usenet when I started out.


    > Good news. I spent several hours on Google searching on /etc/hosts &
    > localhost. Google pointed me to several Linux books which confirmed your
    > recommendations and gave *excellent* explanations that addressed my
    > concerns.
    > That concern was addressed in one of the book sections.


    I do try to keep the lurkers and people using google in mind when
    posting. It would have been nice had you posted the link which best
    described/provided the informaition you needed.


    > For example, I was skepticsl about adding 127.0.0.1 to
    > /etc/hosts. I thought, "if it's so important, it would have been there
    > in the default config".


    Hmmm, was for me
    cat /fc7/etc/hosts_orig
    # Do not remove the following line, or various programs
    # that require network functionality will fail.
    ::1 localhost6.localdomain6 localhost6
    127.0.0.1 localhost.localdomain localhost <-------.
    |
    You might want to cut/paste that line into your /etc/hosts---'


    > So I'm now ready to accept your recommended changes.


    Here is another recommended change,
    TRIM YOUR POST, leave just enough context above your reply.

    You are quoting tooo much of the original text.

  19. Re: Troubleshooting connection loss (continued)

    On Fri, 09 Nov 2007 20:40:48 GMT, Bit Twister wrote:
    >
    >> For example, I was skepticsl about adding 127.0.0.1 to
    >> /etc/hosts. I thought, "if it's so important, it would have been there
    >> in the default config".

    >
    > Hmmm, was for me
    > cat /fc7/etc/hosts_orig

    # Do not remove the following line, or various programs
    # that require network functionality will fail.
    ::1 localhost6.localdomain6 localhost6 <-------.
    127.0.0.1 localhost.localdomain localhost <-------+
    |
    You might want to cut/paste both lines into your /etc/hosts---'

  20. Re: Troubleshooting connection loss (continued)

    Bit Twister wrote:

    < snip>
    >
    >> What troubleshooting step should I do next?

    >
    > After my suggested changes,
    > echo "nameserver 192.168.1.1" > /etc/resolv.conf
    > cp /dev/null /var/lib/dhclient/dhclient-eth0.leases
    > reboot, because of node name changes, and when the system comes up, do a
    > cat /var/lib/dhclient/dhclient-eth0.leases
    > and verify no dhcp lease.
    >
    > If so, I would
    > cd /etc/sysconfig/network-scripts/
    > cp ifcfg-eth0 ifcfg-eth0.bkup
    >
    > change
    > BOOTPROTO=static
    > PEERDNS=no
    > in /etc/sysconfig/network-scripts/ifcfg-eth0
    >
    > cp /dev/null /var/lib/dhclient/dhclient-eth0.leases
    > service network restart
    > echo "nameserver 192.168.1.1" > /etc/resolv.conf
    > cat /var/lib/dhclient/dhclient-eth0.leases
    > I would now think there would be a null dhclient-eth0.leases file.
    >
    > if restart fails
    > cp ifcfg-eth0.bkup ifcfg-eth0
    > and change
    > PEERDNS=no
    > cp /dev/null /var/lib/dhclient/dhclient-eth0.leases
    > echo "nameserver 192.168.1.1" > /etc/resolv.conf
    > service network restart
    > cat /var/lib/dhclient/dhclient-eth0.leases
    >
    > cat /etc/resolv.conf should show only one nameserver line. If two,
    > your dhcp client is still running.
    >


    >


    I don't understand *any* of the above. I've now got Fedora configured
    for static IP of 150 and WinME configured for static IP of 140. The
    dhclient-leases lists an expiration date of 11/7 (today is 11/11).

    I'll post my config-dump below. How does it look?

    So could you please clarify what is the next step in troubleshooting.
    Some explanatory comments along with the procedural steps might make it
    more understandable. Thanks.

    Sun Nov 11 07:09:47 EST 2007
    ======== cat /etc/*release ==========
    Fedora release 7 (Moonshine)
    Fedora release 7 (Moonshine)
    ======== uname -rvi =============
    2.6.23.1-21.fc7 #1 SMP Thu Nov 1 21:09:24 EDT 2007 i386
    ======== cat /etc/*version ==========
    cat: /etc/subversion: Is a directory
    ======== cat /proc/version ==========
    Linux version 2.6.23.1-21.fc7
    (kojibuilder@xenbuilder4.fedora.phx.redhat.com) (gcc version 4.1.2
    20070925 (Red Hat 4.1.2-27)) #1 SMP Thu Nov 1 21:09:24 EDT 2007
    ======== lsb_release -a ==========
    LSB Version:
    :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch
    Distributor ID: Fedora
    Description: Fedora release 7 (Moonshine)
    Release: 7
    Codename: Moonshine

    ======== free ==========
    total used free shared buffers cached
    Mem: 125128 122368 2760 0 1728 31216
    -/+ buffers/cache: 89424 35704
    Swap: 771080 134656 636424
    ======== chkconfig --list ==========
    Double check if /avahi/ needs to be disabled on boot
    avahi-daemon 0ff 1ff 2ff 3n 4n 5ff 6ff
    avahi-dnsconfd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    Double check if /named/ needs to be disabled on boot
    named 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    ConsoleKit 0ff 1ff 2ff 3n 4n 5n 6ff
    NetworkManager 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    NetworkManagerDispatcher 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    acpid 0ff 1ff 2ff 3n 4n 5n 6ff
    anacron 0ff 1ff 2n 3n 4n 5n 6ff
    apmd 0ff 1ff 2n 3n 4n 5n 6ff
    atd 0ff 1ff 2ff 3n 4n 5n 6ff
    autofs 0ff 1ff 2ff 3n 4n 5n 6ff
    avahi-daemon 0ff 1ff 2ff 3n 4n 5ff 6ff
    avahi-dnsconfd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    bluetooth 0ff 1ff 2n 3n 4n 5ff 6ff
    capi 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    cpuspeed 0ff 1n 2n 3n 4n 5ff 6ff
    crond 0ff 1ff 2n 3n 4n 5n 6ff
    cups 0ff 1ff 2n 3n 4n 5ff 6ff
    dhcdbd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    dund 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    firestarter 0ff 1ff 2n 3n 4n 5n 6ff
    firstboot 0ff 1ff 2ff 3n 4ff 5ff 6ff
    gkrellmd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    gpm 0ff 1ff 2n 3n 4n 5n 6ff
    haldaemon 0ff 1ff 2ff 3n 4n 5n 6ff
    hddtemp 0ff 1ff 2ff 3ff 4ff 5n 6ff
    hidd 0ff 1ff 2n 3n 4n 5ff 6ff
    hplip 0ff 1ff 2n 3n 4n 5ff 6ff
    httpd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    ip6tables 0ff 1ff 2n 3n 4n 5ff 6ff
    iptables 0ff 1ff 2ff 3ff 4ff 5n 6ff
    irda 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    irqbalance 0ff 1ff 2n 3n 4n 5ff 6ff
    isdn 0ff 1ff 2n 3n 4n 5ff 6ff
    kdump 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    kudzu 0ff 1ff 2ff 3n 4n 5n 6ff
    lisa 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    lm_sensors 0ff 1ff 2n 3n 4n 5ff 6ff
    mcstrans 0ff 1ff 2n 3n 4n 5n 6ff
    mdmonitor 0ff 1ff 2n 3n 4n 5ff 6ff
    messagebus 0ff 1ff 2ff 3n 4n 5n 6ff
    named 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    nasd 0ff 1ff 2ff 3n 4n 5n 6ff
    netconsole 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    netfs 0ff 1ff 2ff 3n 4n 5ff 6ff
    netplugd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    network 0ff 1ff 2n 3n 4n 5n 6ff
    nfs 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    nfslock 0ff 1ff 2ff 3n 4n 5ff 6ff
    nscd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    ntpd 0ff 1ff 2ff 3ff 4ff 5n 6ff
    pand 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    psacct 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    rdisc 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    readahead_early 0ff 1ff 2n 3n 4n 5n 6ff
    readahead_later 0ff 1ff 2ff 3ff 4ff 5n 6ff
    restorecond 0ff 1ff 2n 3n 4n 5n 6ff
    rpcbind 0ff 1ff 2ff 3n 4n 5ff 6ff
    rpcgssd 0ff 1ff 2ff 3n 4n 5ff 6ff
    rpcidmapd 0ff 1ff 2ff 3n 4n 5ff 6ff
    rpcsvcgssd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    saslauthd 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    sendmail 0ff 1ff 2n 3n 4n 5n 6ff
    smartd 0ff 1ff 2n 3n 4n 5n 6ff
    spamassassin 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    sshd 0ff 1ff 2n 3n 4n 5ff 6ff
    syslog 0ff 1ff 2n 3n 4n 5n 6ff
    tomcat5 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    vncserver 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    winbind 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    wpa_supplicant 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    xfs 0ff 1ff 2n 3n 4n 5n 6ff
    ypbind 0ff 1ff 2ff 3ff 4ff 5ff 6ff
    yum-updatesd 0ff 1ff 2ff 3n 4n 5n 6ff
    ======== grep hosts: /etc/nsswitch.conf ==========
    #hosts: db files nisplus nis dns
    hosts: files dns
    ======== grep -v '^#' /etc/resolv.conf ==========
    ; generated by /sbin/dhclient-script
    search myhome.westell.com
    nameserver 192.168.1.1
    nameserver 192.168.1.1
    ======== hostname ==========
    alweiner.nowhere.invalid
    ======== grep eth /etc/mod*.conf ==========
    alias eth0 e100
    ======== grep -v '^#' /etc/host.conf ==========
    order hosts,bind
    ================ ifconfig -a ==============
    eth0 Link encap:Ethernet HWaddr 00:07:E9:01:B2:09
    inet addr:192.168.1.150 Bcast:192.168.1.255 Mask:255.255.255.0
    inet6 addr: fe80::207:e9ff:fe01:b209/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:1793 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1360 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:2126783 (2.0 MiB) TX bytes:79504 (77.6 KiB)

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1/128 Scope:Host
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:2721 errors:0 dropped:0 overruns:0 frame:0
    TX packets:2721 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:5660648 (5.3 MiB) TX bytes:5660648 (5.3 MiB)

    ============== route -n =================
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use
    Iface
    192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
    169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
    0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
    ======== cat /etc/sysconfig/network ==========
    NETWORKING=yes
    HOSTNAME=alweiner.nowhere.invalid
    ========== head -15 /etc/hosts ===========
    127.0.0.1 alweiner.nowhere.invalid alweiner localhost
    192.168.1.1 gateway
    192.168.1.150 alweiner.invalid alweiner
    ======== ethtool eth0 ==========
    Settings for eth0:
    Supported ports: [ TP MII ]
    Supported link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    Supports auto-negotiation: Yes
    Advertised link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    Advertised auto-negotiation: Yes
    Speed: 100Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: g
    Wake-on: g
    Current message level: 0x00000007 (7)
    Link detected: yes
    === dmesg | grep eth0 | grep -v SRC= ===
    e100: eth0: e100_probe: addr 0xfc9ff000, irq 11, MAC addr 00:07:E9:01:B2:09
    ADDRCONF(NETDEV_UP): eth0: link is not ready
    e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
    ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    eth0: no IPv6 routers present
    === grep eth0 /var/log/messages | tail -10 ===
    Nov 11 07:07:12 alweiner kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1052 DF PROTO=TCP
    SPT=1038 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 11 07:07:36 alweiner kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1062 DF PROTO=TCP
    SPT=1038 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 11 07:07:58 alweiner kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1093 DF PROTO=TCP
    SPT=1039 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 11 07:08:04 alweiner kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1095 DF PROTO=TCP
    SPT=1039 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 11 07:08:28 alweiner kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1103 DF PROTO=TCP
    SPT=1039 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 11 07:08:50 alweiner kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1129 DF PROTO=TCP
    SPT=1040 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 11 07:08:56 alweiner kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1132 DF PROTO=TCP
    SPT=1040 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 11 07:09:20 alweiner kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1141 DF PROTO=TCP
    SPT=1040 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 11 07:09:42 alweiner kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1178 DF PROTO=TCP
    SPT=1041 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    Nov 11 07:09:47 alweiner kernel: Inbound IN=eth0 OUT=
    MAC=00:07:e9:01:b2:09:00:18:3a:53:f7:fb:08:00 SRC=192.168.1.1
    DST=192.168.1.150 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1179 DF PROTO=TCP
    SPT=1041 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
    ======== cat /etc/sysconfig/network-scripts/ifcfg-eth0 ==========
    # Intel Corporation 82557/8/9 [Ethernet Pro 100]
    DEVICE=eth0
    ONBOOT=yes
    BOOTPROTO=none
    HWADDR=00:07:e9:01:b2:09
    TYPE=Ethernet
    USERCTL=yes
    IPV6INIT=no
    PEERDNS=yes
    NETMASK=255.255.255.0
    IPADDR=192.168.1.150
    GATEWAY=192.168.1.1
    ======== tail -18 /var/lib/dhclient/dhclient-eth0.leases ==========
    rebind 3 2007/11/7 12:23:43;
    expire 3 2007/11/7 15:23:43;
    }
    lease {
    interface "eth0";
    fixed-address 192.168.1.47;
    option subnet-mask 255.255.255.0;
    option routers 192.168.1.1;
    option dhcp-lease-time 86400;
    option dhcp-message-type 5;
    option domain-name-servers 192.168.1.1,192.168.1.1;
    option dhcp-server-identifier 192.168.1.1;
    option broadcast-address 255.255.255.255;
    option domain-name "myhome.westell.com";
    renew 3 2007/11/7 05:23:24;
    rebind 3 2007/11/7 15:31:25;
    expire 3 2007/11/7 18:31:25;
    }
    === dmesg | grep eth1 | grep -v SRC= ===
    === grep eth1 /var/log/messages | tail -10 ===
    === dmesg | grep eth2 | grep -v SRC= ===
    === grep eth2 /var/log/messages | tail -10 ===
    ======== grep -v '^#' /etc/hosts.allow ==========

    ======== grep -v '^#' /etc/hosts.deny ==========

    ======= end of config/network data dump ===========


+ Reply to Thread
Page 1 of 2 1 2 LastLast