[opensuse] help please - message log and wifi link loss - what does this mean?
Hi! Have diagnosed for umpteenth time why on earth I might always loose the wifi connection to my access point. I can connect to access point, and ping my gateway 192.168.1.1 for a while, then suddenly no more ping comes back. Have found the following message log sequence below which also co-incides with a prompt name change in root terminal session (attached file extract below). some questions - why does linux-b9ze kernel change to mshome kernel ? SIGHUP means what? why does avahi-daemon withdraw something? Help muchly appreciated! Thanks, Peter start of successful use of wifi: optimistically plugging in the pcmcia card to connect: ;-) May 5 21:04:57 linux-b9ze kernel: pccard: CardBus card inserted into slot 0 May 5 21:04:57 linux-b9ze kernel: ndiswrapper: driver lsbcmnds (The Linksys Group, Inc.,02/14/2005, 3.90.36.0) loaded May 5 21:04:57 linux-b9ze kernel: PCI: Enabling device 0000:03:00.0 (0000 -> 0002) May 5 21:04:57 linux-b9ze kernel: ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 May 5 21:04:57 linux-b9ze kernel: PCI: Setting latency timer of device 0000:03:00.0 to 64 May 5 21:04:57 linux-b9ze kernel: ndiswrapper: using IRQ 11 May 5 21:04:58 linux-b9ze kernel: wlan0: ethernet device 00:18:f8:66:f6:10 using NDIS driver: lsbcmnds, version: 0x3644000, NDIS version: 0x501, vendor: 'NDIS Network Adapter', 14E4:4318.5.conf May 5 21:04:58 linux-b9ze kernel: wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK May 5 21:04:58 linux-b9ze kernel: wlan0 renamed to eth1 May 5 21:04:58 linux-b9ze kernel: ndiswrapper: changing interface name from 'wlan0' to 'eth1' May 5 21:04:58 linux-b9ze kernel: udev: renamed network interface wlan0 to eth1 May 5 21:04:58 linux-b9ze ifup: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:04:58 linux-b9ze kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready May 5 21:04:58 linux-b9ze ifup-dhcp: Starting DHCP Client Daemon on eth1... May 5 21:04:58 linux-b9ze ifup-dhcp: . May 5 21:04:58 linux-b9ze kernel: NET: Registered protocol family 17 May 5 21:04:59 linux-b9ze kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready May 5 21:04:59 linux-b9ze ifup-dhcp: . May 5 21:04:59 linux-b9ze ifup-dhcp: . May 5 21:05:00 linux-b9ze avahi-daemon[3210]: Registering new address record for fe80::218:f8ff:fe66:f610 on eth1.*. May 5 21:05:01 linux-b9ze ifup-dhcp: . May 5 21:05:01 linux-b9ze ifup-dhcp: . May 5 21:05:02 linux-b9ze avahi-daemon[3210]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.1.5. comment sofar sounds(reads) all just fine as expected ;-) May 5 21:05:02 linux-b9ze avahi-daemon[3210]: New relevant interface eth1.IPv4 for mDNS. May 5 21:05:02 linux-b9ze avahi-daemon[3210]: Registering new address record for 192.168.1.5 on eth1.IPv4. May 5 21:05:03 linux-b9ze modify_resolvconf: Service dhcpcd modified /etc/resolv.conf. See info block in this file May 5 21:05:03 linux-b9ze ifup: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:05:03 linux-b9ze ifup-dhcp: IP/Netmask: 192.168.1.5 May 5 21:05:03 linux-b9ze ifup-dhcp: / 255.255.255.0 May 5 21:05:03 linux-b9ze ifup-dhcp: ('mshome') May 5 21:05:03 linux-b9ze ifup-dhcp: May 5 21:05:04 linux-b9ze SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... May 5 21:05:04 linux-b9ze SuSEfirewall2: using default zone 'ext' for interface eth1 May 5 21:05:04 linux-b9ze SuSEfirewall2: batch committing... May 5 21:05:04 linux-b9ze SuSEfirewall2: Firewall rules successfully set comment: I presume up to here all is working fine - addresses seem what they should be, then what is the sighup event???? - is this maybe the reason for ubsequent loss of the wifi link to access point? why the change from 'linux-b9ze' to 'mshome' ? May 5 21:05:04 linux-b9ze syslog-ng[2068]: SIGHUP received, restarting syslog-ng May 5 21:05:05 mshome syslog-ng[2068]: new configuration initialized May 5 21:05:05 mshome kernel: klogd 1.4.1, ---------- state change ---------- May 5 21:05:09 mshome kernel: eth1: no IPv6 routers present May 5 21:07:23 mshome sudo: root : TTY=pts/4 ; PWD=/root ; USER=root ; COMMAND=/opt/kde3/bin/kate May 5 21:08:39 mshome su: (to root) peter on /dev/pts/1 May 5 21:12:57 mshome ifplugd(eth0)[2933]: Exiting. May 5 21:12:57 mshome ifdown: eth0 device: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) May 5 21:12:58 mshome ifdown: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:12:58 mshome dhcpcd[3879]: terminating on signal 15 May 5 21:12:58 mshome avahi-daemon[3210]: Withdrawing address record for 192.168.1.5 on eth1. comment and question: why this withdrawal? May 5 21:12:58 mshome avahi-daemon[3210]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.1.5. May 5 21:12:58 mshome avahi-daemon[3210]: Interface eth1.IPv4 no longer relevant for mDNS. May 5 21:12:58 mshome avahi-daemon[3210]: Withdrawing address record for fe80::218:f8ff:fe66:f610 on eth1. May 5 21:12:58 mshome modify_resolvconf: restored /etc/resolv.conf.saved.by.dhcpcd.eth1 to /etc/resolv.conf May 5 21:13:00 mshome ifup: lo May 5 21:13:00 mshome ifup: lo May 5 21:13:00 mshome ifup: IP address: 127.0.0.1/8 May 5 21:13:00 mshome ifup: May 5 21:13:00 mshome ifplugd(eth0)[4809]: ifplugd 0.28 initializing. May 5 21:13:00 mshome kernel: eth0: setting half-duplex. May 5 21:13:00 mshome kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready May 5 21:13:00 mshome ifplugd(eth0)[4809]: Using interface eth0/00:08:74:23:22:71 with driver <3c59x> (version: ) May 5 21:13:00 mshome ifplugd(eth0)[4809]: Using detection mode: SIOCETHTOOL May 5 21:13:00 mshome ifplugd(eth0)[4809]: Initialization complete, link beat not detected. May 5 21:13:01 mshome ifup: eth0 device: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) May 5 21:13:01 mshome ifup: eth0 is controlled by ifplugd May 5 21:13:01 mshome ifup: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:13:01 mshome kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready May 5 21:13:01 mshome ifup-dhcp: eth1 (DHCP) May 5 21:13:01 mshome ifup-dhcp: . May 5 21:13:06 mshome syslog-ng[2068]: last message repeated 4 times May 5 21:13:06 mshome ifup-dhcp: no IP address yet... backgrounding. May 5 21:13:07 mshome SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... May 5 21:13:07 mshome SuSEfirewall2: using default zone 'ext' for interface eth1 May 5 21:13:07 mshome SuSEfirewall2: batch committing... May 5 21:13:07 mshome SuSEfirewall2: Firewall rules successfully set -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, May 5, 2008 at 1:05 PM, Peter Breger
Hi! Have diagnosed for umpteenth time why on earth I might always loose the wifi connection to my access point. I can connect to access point, and ping my gateway 192.168.1.1 for a while, then suddenly no more ping comes back.
Have found the following message log sequence below which also co-incides with a prompt name change in root terminal session (attached file extract below).
some questions - why does linux-b9ze kernel change to mshome kernel ? SIGHUP means what? why does avahi-daemon withdraw something?
They are both caused by you allowing dhcp to change the host name. Never do that. Go into yast and prevent dhcp from changing the host name upon connection. -- ----------JSA--------- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, May 5, 2008 at 1:11 PM, John Andersen
On Mon, May 5, 2008 at 1:05 PM, Peter Breger
wrote: Hi! Have diagnosed for umpteenth time why on earth I might always loose the wifi connection to my access point. I can connect to access point, and ping my gateway 192.168.1.1 for a while, then suddenly no more ping comes back.
Have found the following message log sequence below which also co-incides with a prompt name change in root terminal session (attached file extract below).
some questions - why does linux-b9ze kernel change to mshome kernel ? SIGHUP means what? why does avahi-daemon withdraw something?
They are both caused by you allowing dhcp to change the host name. Never do that. Go into yast and prevent dhcp from changing the host name upon connection.
Sighup ("signal heads up" is how I remember this) is sent to the logger that the name of the host has changed. Logging then resumes using the new name. SUGHUP usually just tells a daemon (the logger in this case) to perform some portion (or all) of its initialization routines. -- ----------JSA--------- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
Sighup ("signal heads up" is how I remember this) is sent to the logger that the name of the host has changed.
Close, but no cigar. HUP means "hangup" as when a session is ended (revealing AT&T roots) Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, May 5, 2008 at 2:33 PM, Sloan
John Andersen wrote:
Sighup ("signal heads up" is how I remember this) is sent to the logger that the name of the host has changed.
Close, but no cigar. HUP means "hangup" as when a session is ended (revealing AT&T roots)
Joe
Perhaps historically, but not with regard to daemons in linux. In that context, specifically in this case with regard to the logging daemon, it is as Sam and I mentioned, a signal to the daemon to re-initialize. -- ----------JSA--------- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
On Mon, May 5, 2008 at 2:33 PM, Sloan
wrote: Close, but no cigar. HUP means "hangup" as when a session is ended (revealing AT&T roots)
Perhaps historically, but not with regard to daemons in linux.
In that context, specifically in this case with regard to the logging daemon, it is as Sam and I mentioned, a signal to the daemon to re-initialize.
Trust me, HUP still means "hangup" - but you are right about the hangup signal being used to reinitialize daemons. That has always been the case, "kill -1 1" being a classic example... There is also the "nohup" (no hang up!) command, which is used to keep a process running after the tty of the parent process is closed, i.e. the user on the other end of the modem connection has hung up. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
On Mon, May 5, 2008 at 2:33 PM, Sloan
wrote: John Andersen wrote:
Sighup ("signal heads up" is how I remember this) is sent to the logger that the name of the host has changed.
Close, but no cigar. HUP means "hangup" as when a session is ended (revealing AT&T roots)
Joe
Perhaps historically, but not with regard to daemons in linux.
That's because deamons detach themselves from the terminal, and therefore don't have to worry about any controlling terminal getting hung up, and so the signal gets re-used, shall we say, as a SIG-REINITIALIZE. However SIGHUP is still SIGHUP for every other process out there...if you close a pseudo-tty with an editor running in it, the kernel will issue SIGHUP to the editor, so that it has an opportunity to take appropriate action.
In that context, specifically in this case with regard to the logging daemon, it is as Sam and I mentioned, a signal to the daemon to re-initialize.
But that's ONLY for deamons, and is an isolated use of SIGHUP. For all processes EXCEPT deamons (and only because deamons don't have a controlling TTY) SIGHUP means SIGNAL: HUNG UP (i.e. the telephone modem connection was lost). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
----- Original Message -----
From: "John Andersen"
On Mon, May 5, 2008 at 2:33 PM, Sloan
wrote: John Andersen wrote:
Sighup ("signal heads up" is how I remember this) is sent to the logger that the name of the host has changed.
Close, but no cigar. HUP means "hangup" as when a session is ended (revealing AT&T roots)
Joe
Perhaps historically, but not with regard to daemons in linux.
In that context, specifically in this case with regard to the logging daemon, it is as Sam and I mentioned, a signal to the daemon to re-initialize.
It doesn't matter what a given program does in response to a given signal. The signal is called "hangup" simple as that. It's not something that's "historical" and no longer used that way or anything like that. Any program may react to any trappable signal in any way it wants, including not reacting at all. Some daemons use the hangup signal to re-read their config and/or reinit their whole runtime, and do so on any unix and in some cases have done so since before Linux even existed. There was nothing to correct about Joes statement. Not even slightly. But the implications in your statement are in fact incorrect. Those daemons don't behave that way just on Linux, nor just today vs "historically", and regardless which daemons behave that way and where and when, that still doesn't change the name, nominal meaning, or most common and expected function, in any of the countless, COUNTLESS, binaries extant besides the few daemons that happen to have special behaviour, of the HUP signal. If you think it's confusing that the hangup signal doesn't cause certain special case daemons to "hang up", then maybe you need a better grasp of what init actually does, paying special attention to it's job of _respawinging_ things that it launches, including itself. In some sense, and indeed in the past it was actually implimented just that way, the daemon does hang up, and init immediately respawns it, which from the outside sort of looks like it never stopped running but just re-read it's config. And then at some point the daemon was updated to do what it looks like it's doing, merely update it's state without actually dying and being respawned by init. And init itself is the ultimate special case that does the same thing. So because this one uber special case, init, and very few others, behave in that special way, you propose to teach someone who doesn't know any better that HUP really shouldn't be called or thought of as "hangup", disregarding the fact that every other binary that even catches the signal (which is most of them) does treat a hangup as a hangup or the closest reasonable approximation for whatever context the binary runs in? Um, No. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Peter Breger wrote:
Hi! Have diagnosed for umpteenth time why on earth I might always loose the wifi connection to my access point. I can connect to access point, and ping my gateway 192.168.1.1 for a while, then suddenly no more ping comes back.
Have found the following message log sequence below which also co-incides with a prompt name change in root terminal session (attached file extract below).
some questions - why does linux-b9ze kernel change to mshome kernel ? SIGHUP means what? why does avahi-daemon withdraw something?
SIGHUP is the abbreviation for SIGNAL: HANG UP. This signal originated back in the days of terminals connected to the computer by serial lines...possibly with a modem<-->modem pair on either end of a telephone line. Originally (and still to this day) SIG HUP is sent to a process when the connection was lost between the computer and the terminal on which the process was running. SIGHUP can also be used for other purposes. For example, most deamons never have a controlling terminal, so SIGHUP is used for other things, such as a method to force the deamon to re-read its configuration file (saving the trouble of stopping and restarting the deamon).
Help muchly appreciated! Thanks, Peter
start of successful use of wifi: optimistically plugging in the pcmcia card to connect: ;-)
May 5 21:04:57 linux-b9ze kernel: pccard: CardBus card inserted into slot 0 May 5 21:04:57 linux-b9ze kernel: ndiswrapper: driver lsbcmnds (The Linksys Group, Inc.,02/14/2005, 3.90.36.0) loaded May 5 21:04:57 linux-b9ze kernel: PCI: Enabling device 0000:03:00.0 (0000 -> 0002) May 5 21:04:57 linux-b9ze kernel: ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 May 5 21:04:57 linux-b9ze kernel: PCI: Setting latency timer of device 0000:03:00.0 to 64 May 5 21:04:57 linux-b9ze kernel: ndiswrapper: using IRQ 11 May 5 21:04:58 linux-b9ze kernel: wlan0: ethernet device 00:18:f8:66:f6:10 using NDIS driver: lsbcmnds, version: 0x3644000, NDIS version: 0x501, vendor: 'NDIS Network Adapter', 14E4:4318.5.conf May 5 21:04:58 linux-b9ze kernel: wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK May 5 21:04:58 linux-b9ze kernel: wlan0 renamed to eth1 May 5 21:04:58 linux-b9ze kernel: ndiswrapper: changing interface name from 'wlan0' to 'eth1' May 5 21:04:58 linux-b9ze kernel: udev: renamed network interface wlan0 to eth1 May 5 21:04:58 linux-b9ze ifup: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:04:58 linux-b9ze kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready May 5 21:04:58 linux-b9ze ifup-dhcp: Starting DHCP Client Daemon on eth1... May 5 21:04:58 linux-b9ze ifup-dhcp: . May 5 21:04:58 linux-b9ze kernel: NET: Registered protocol family 17 May 5 21:04:59 linux-b9ze kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready May 5 21:04:59 linux-b9ze ifup-dhcp: . May 5 21:04:59 linux-b9ze ifup-dhcp: . May 5 21:05:00 linux-b9ze avahi-daemon[3210]: Registering new address record for fe80::218:f8ff:fe66:f610 on eth1.*. May 5 21:05:01 linux-b9ze ifup-dhcp: . May 5 21:05:01 linux-b9ze ifup-dhcp: . May 5 21:05:02 linux-b9ze avahi-daemon[3210]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.1.5.
comment sofar sounds(reads) all just fine as expected ;-)
May 5 21:05:02 linux-b9ze avahi-daemon[3210]: New relevant interface eth1.IPv4 for mDNS. May 5 21:05:02 linux-b9ze avahi-daemon[3210]: Registering new address record for 192.168.1.5 on eth1.IPv4. May 5 21:05:03 linux-b9ze modify_resolvconf: Service dhcpcd modified /etc/resolv.conf. See info block in this file May 5 21:05:03 linux-b9ze ifup: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:05:03 linux-b9ze ifup-dhcp: IP/Netmask: 192.168.1.5 May 5 21:05:03 linux-b9ze ifup-dhcp: / 255.255.255.0 May 5 21:05:03 linux-b9ze ifup-dhcp: ('mshome') May 5 21:05:03 linux-b9ze ifup-dhcp: May 5 21:05:04 linux-b9ze SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... May 5 21:05:04 linux-b9ze SuSEfirewall2: using default zone 'ext' for interface eth1 May 5 21:05:04 linux-b9ze SuSEfirewall2: batch committing... May 5 21:05:04 linux-b9ze SuSEfirewall2: Firewall rules successfully set
comment: I presume up to here all is working fine - addresses seem what they should be, then what is the sighup event???? - is this maybe the reason for ubsequent loss of the wifi link to access point? why the change from 'linux-b9ze' to 'mshome' ?
May 5 21:05:04 linux-b9ze syslog-ng[2068]: SIGHUP received, restarting syslog-ng May 5 21:05:05 mshome syslog-ng[2068]: new configuration initialized May 5 21:05:05 mshome kernel: klogd 1.4.1, ---------- state change ---------- May 5 21:05:09 mshome kernel: eth1: no IPv6 routers present
May 5 21:07:23 mshome sudo: root : TTY=pts/4 ; PWD=/root ; USER=root ; COMMAND=/opt/kde3/bin/kate
May 5 21:08:39 mshome su: (to root) peter on /dev/pts/1 May 5 21:12:57 mshome ifplugd(eth0)[2933]: Exiting. May 5 21:12:57 mshome ifdown: eth0 device: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) May 5 21:12:58 mshome ifdown: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:12:58 mshome dhcpcd[3879]: terminating on signal 15 May 5 21:12:58 mshome avahi-daemon[3210]: Withdrawing address record for 192.168.1.5 on eth1.
comment and question: why this withdrawal?
May 5 21:12:58 mshome avahi-daemon[3210]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.1.5. May 5 21:12:58 mshome avahi-daemon[3210]: Interface eth1.IPv4 no longer relevant for mDNS. May 5 21:12:58 mshome avahi-daemon[3210]: Withdrawing address record for fe80::218:f8ff:fe66:f610 on eth1. May 5 21:12:58 mshome modify_resolvconf: restored /etc/resolv.conf.saved.by.dhcpcd.eth1 to /etc/resolv.conf May 5 21:13:00 mshome ifup: lo May 5 21:13:00 mshome ifup: lo May 5 21:13:00 mshome ifup: IP address: 127.0.0.1/8 May 5 21:13:00 mshome ifup: May 5 21:13:00 mshome ifplugd(eth0)[4809]: ifplugd 0.28 initializing. May 5 21:13:00 mshome kernel: eth0: setting half-duplex. May 5 21:13:00 mshome kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready May 5 21:13:00 mshome ifplugd(eth0)[4809]: Using interface eth0/00:08:74:23:22:71 with driver <3c59x> (version: ) May 5 21:13:00 mshome ifplugd(eth0)[4809]: Using detection mode: SIOCETHTOOL May 5 21:13:00 mshome ifplugd(eth0)[4809]: Initialization complete, link beat not detected. May 5 21:13:01 mshome ifup: eth0 device: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) May 5 21:13:01 mshome ifup: eth0 is controlled by ifplugd May 5 21:13:01 mshome ifup: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:13:01 mshome kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready May 5 21:13:01 mshome ifup-dhcp: eth1 (DHCP) May 5 21:13:01 mshome ifup-dhcp: . May 5 21:13:06 mshome syslog-ng[2068]: last message repeated 4 times May 5 21:13:06 mshome ifup-dhcp: no IP address yet... backgrounding. May 5 21:13:07 mshome SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... May 5 21:13:07 mshome SuSEfirewall2: using default zone 'ext' for interface eth1 May 5 21:13:07 mshome SuSEfirewall2: batch committing... May 5 21:13:07 mshome SuSEfirewall2: Firewall rules successfully set
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
One issue I see is that you are using ndiswrapper and a broadcom
wireless. At lease since 10.2, SuSE and other versions of Linux have a
native broadcom driver. Additionally, you would need to get the latest
version of fwcutter, and install the firmware, usually
into /lib/firmware either under the kernel of into /lib/firmware/b43. I
no longer run SuSE on my laptop (because of a work requirement to use
Ubuntu), but when it ran SuSE 10.2 I found the native driver to work
rather well, and more reliably than ndiswrapper. IMHO, you should run
ndiswrapper only if you have no other option.
Other than this, try to disable your firewall, and see if the
connection stabilizes. I'm wondering if the firewall might be killing
the wireless connection.
On Mon, 05 May 2008 22:05:15 +0200
Peter Breger
Hi! Have diagnosed for umpteenth time why on earth I might always loose the wifi connection to my access point. I can connect to access point, and ping my gateway 192.168.1.1 for a while, then suddenly no more ping comes back.
Have found the following message log sequence below which also co-incides with a prompt name change in root terminal session (attached file extract below).
some questions - why does linux-b9ze kernel change to mshome kernel ? SIGHUP means what? why does avahi-daemon withdraw something?
Help muchly appreciated! Thanks, Peter
start of successful use of wifi: optimistically plugging in the pcmcia card to connect: ;-)
May 5 21:04:57 linux-b9ze kernel: pccard: CardBus card inserted into slot 0 May 5 21:04:57 linux-b9ze kernel: ndiswrapper: driver lsbcmnds (The Linksys Group, Inc.,02/14/2005, 3.90.36.0) loaded May 5 21:04:57 linux-b9ze kernel: PCI: Enabling device 0000:03:00.0 (0000 -> 0002) May 5 21:04:57 linux-b9ze kernel: ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 May 5 21:04:57 linux-b9ze kernel: PCI: Setting latency timer of device 0000:03:00.0 to 64 May 5 21:04:57 linux-b9ze kernel: ndiswrapper: using IRQ 11 May 5 21:04:58 linux-b9ze kernel: wlan0: ethernet device 00:18:f8:66:f6:10 using NDIS driver: lsbcmnds, version: 0x3644000, NDIS version: 0x501, vendor: 'NDIS Network Adapter', 14E4:4318.5.conf May 5 21:04:58 linux-b9ze kernel: wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK May 5 21:04:58 linux-b9ze kernel: wlan0 renamed to eth1 May 5 21:04:58 linux-b9ze kernel: ndiswrapper: changing interface name from 'wlan0' to 'eth1' May 5 21:04:58 linux-b9ze kernel: udev: renamed network interface wlan0 to eth1 May 5 21:04:58 linux-b9ze ifup: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:04:58 linux-b9ze kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready May 5 21:04:58 linux-b9ze ifup-dhcp: Starting DHCP Client Daemon on eth1... May 5 21:04:58 linux-b9ze ifup-dhcp: . May 5 21:04:58 linux-b9ze kernel: NET: Registered protocol family 17 May 5 21:04:59 linux-b9ze kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready May 5 21:04:59 linux-b9ze ifup-dhcp: . May 5 21:04:59 linux-b9ze ifup-dhcp: . May 5 21:05:00 linux-b9ze avahi-daemon[3210]: Registering new address record for fe80::218:f8ff:fe66:f610 on eth1.*. May 5 21:05:01 linux-b9ze ifup-dhcp: . May 5 21:05:01 linux-b9ze ifup-dhcp: . May 5 21:05:02 linux-b9ze avahi-daemon[3210]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.1.5.
comment sofar sounds(reads) all just fine as expected ;-)
May 5 21:05:02 linux-b9ze avahi-daemon[3210]: New relevant interface eth1.IPv4 for mDNS. May 5 21:05:02 linux-b9ze avahi-daemon[3210]: Registering new address record for 192.168.1.5 on eth1.IPv4. May 5 21:05:03 linux-b9ze modify_resolvconf: Service dhcpcd modified /etc/resolv.conf. See info block in this file May 5 21:05:03 linux-b9ze ifup: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:05:03 linux-b9ze ifup-dhcp: IP/Netmask: 192.168.1.5 May 5 21:05:03 linux-b9ze ifup-dhcp: / 255.255.255.0 May 5 21:05:03 linux-b9ze ifup-dhcp: ('mshome') May 5 21:05:03 linux-b9ze ifup-dhcp: May 5 21:05:04 linux-b9ze SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... May 5 21:05:04 linux-b9ze SuSEfirewall2: using default zone 'ext' for interface eth1 May 5 21:05:04 linux-b9ze SuSEfirewall2: batch committing... May 5 21:05:04 linux-b9ze SuSEfirewall2: Firewall rules successfully set
comment: I presume up to here all is working fine - addresses seem what they should be, then what is the sighup event???? - is this maybe the reason for ubsequent loss of the wifi link to access point? why the change from 'linux-b9ze' to 'mshome' ?
May 5 21:05:04 linux-b9ze syslog-ng[2068]: SIGHUP received, restarting syslog-ng May 5 21:05:05 mshome syslog-ng[2068]: new configuration initialized May 5 21:05:05 mshome kernel: klogd 1.4.1, ---------- state change ---------- May 5 21:05:09 mshome kernel: eth1: no IPv6 routers present
May 5 21:07:23 mshome sudo: root : TTY=pts/4 ; PWD=/root ; USER=root ; COMMAND=/opt/kde3/bin/kate
May 5 21:08:39 mshome su: (to root) peter on /dev/pts/1 May 5 21:12:57 mshome ifplugd(eth0)[2933]: Exiting. May 5 21:12:57 mshome ifdown: eth0 device: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) May 5 21:12:58 mshome ifdown: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:12:58 mshome dhcpcd[3879]: terminating on signal 15 May 5 21:12:58 mshome avahi-daemon[3210]: Withdrawing address record for 192.168.1.5 on eth1.
comment and question: why this withdrawal?
May 5 21:12:58 mshome avahi-daemon[3210]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.1.5. May 5 21:12:58 mshome avahi-daemon[3210]: Interface eth1.IPv4 no longer relevant for mDNS. May 5 21:12:58 mshome avahi-daemon[3210]: Withdrawing address record for fe80::218:f8ff:fe66:f610 on eth1. May 5 21:12:58 mshome modify_resolvconf: restored /etc/resolv.conf.saved.by.dhcpcd.eth1 to /etc/resolv.conf May 5 21:13:00 mshome ifup: lo May 5 21:13:00 mshome ifup: lo May 5 21:13:00 mshome ifup: IP address: 127.0.0.1/8 May 5 21:13:00 mshome ifup: May 5 21:13:00 mshome ifplugd(eth0)[4809]: ifplugd 0.28 initializing. May 5 21:13:00 mshome kernel: eth0: setting half-duplex. May 5 21:13:00 mshome kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready May 5 21:13:00 mshome ifplugd(eth0)[4809]: Using interface eth0/00:08:74:23:22:71 with driver <3c59x> (version: ) May 5 21:13:00 mshome ifplugd(eth0)[4809]: Using detection mode: SIOCETHTOOL May 5 21:13:00 mshome ifplugd(eth0)[4809]: Initialization complete, link beat not detected. May 5 21:13:01 mshome ifup: eth0 device: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) May 5 21:13:01 mshome ifup: eth0 is controlled by ifplugd May 5 21:13:01 mshome ifup: eth1 device: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) May 5 21:13:01 mshome kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready May 5 21:13:01 mshome ifup-dhcp: eth1 (DHCP) May 5 21:13:01 mshome ifup-dhcp: . May 5 21:13:06 mshome syslog-ng[2068]: last message repeated 4 times May 5 21:13:06 mshome ifup-dhcp: no IP address yet... backgrounding. May 5 21:13:07 mshome SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... May 5 21:13:07 mshome SuSEfirewall2: using default zone 'ext' for interface eth1 May 5 21:13:07 mshome SuSEfirewall2: batch committing... May 5 21:13:07 mshome SuSEfirewall2: Firewall rules successfully set
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
--
--
Jerry Feldman
On Mon, May 5, 2008 at 2:10 PM, Jerry Feldman
One issue I see is that you are using ndiswrapper and a broadcom wireless. At lease since 10.2, SuSE and other versions of Linux have a native broadcom driver. Additionally, you would need to get the latest version of fwcutter, and install the firmware, usually into /lib/firmware either under the kernel of into /lib/firmware/b43. I no longer run SuSE on my laptop (because of a work requirement to use Ubuntu), but when it ran SuSE 10.2 I found the native driver to work rather well, and more reliably than ndiswrapper. IMHO, you should run ndiswrapper only if you have no other option.
First, please don't top post on this list. Second, I've used ndiswrapper for years and never had this problem. Its utterly reliable. The problem is appearing at dhcp renewal time. Machine changes its name (a dhcp option that should not be used), and this causes all sorts of issues of connectivity. -- ----------JSA--------- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 5 May 2008 14:25:46 -0700
"John Andersen"
On Mon, May 5, 2008 at 2:10 PM, Jerry Feldman
wrote: One issue I see is that you are using ndiswrapper and a broadcom wireless. At lease since 10.2, SuSE and other versions of Linux have a native broadcom driver. Additionally, you would need to get the latest version of fwcutter, and install the firmware, usually into /lib/firmware either under the kernel of into /lib/firmware/b43. I no longer run SuSE on my laptop (because of a work requirement to use Ubuntu), but when it ran SuSE 10.2 I found the native driver to work rather well, and more reliably than ndiswrapper. IMHO, you should run ndiswrapper only if you have no other option.
First, please don't top post on this list.
Second, I've used ndiswrapper for years and never had this problem. Its utterly reliable.
The problem is appearing at dhcp renewal time. Machine changes its name (a dhcp option that should not be used), and this causes all sorts of issues of connectivity.
Sorry for the top post. I usually try to follows the conventions of the
list.
I used to use ndiswrapper myself, but it has been implicated in many
problems over the years. The newer broadcom drivers are more reliable,
and while ndiswrapper does work, and possibly is not a problem on your
system, there are some other things I may have pointed out. Try
disabling your firewall temporarily and see if that has any affect on
the connectivity. Additionally, are you able to get the wireless back
by temporarily taking ndiswrapper down with rmmod and then bringing it
back up with insmod or modprobe. Have you used iwconfig manually.
--
--
Jerry Feldman
participants (6)
-
Brian K. White
-
Jerry Feldman
-
John Andersen
-
Peter Breger
-
Sam Clemens
-
Sloan