Re: NetworkManager and Madwifi connection loss
Walter, when you say you see no such issues are you using the -Dmadwifi or -Dwext with wpa_supplicant. I have my Network Manager patched so it waits 60 seconds before deciding the link has timed out, however every 15-30 seconds wpa_supplicant scans, this I see using the -Dmadwifi driver. With -Dwext it is rock solid on my home wpa2 network. However at work -Dmadwifi is needed for leap/eap since -Dwext is unreliable for this type of connection. When you connect can you run "watch -n1 wpa_cli status" and see if it keeps dropping and scanning. I am kind of curious since I would love a solution/workaround for the scanning ...rescanning etc. Walter Neumann wrote: > I have no such problem with madwifi-ng-r2594-20070719. > > On Tue, 27 Nov 2007, Darren Albers wrote: > >> > On Tue, 2007-11-27 at 12:18 -0500, Philip A. Culver wrote: >> Hi, >> >> >> >> I am using NetworkManager 0.6.5 on Fedora 7 with the madwifi 0.9.3.3 >> drivers.I am experiencing an issue where NetworkManager thinks >> that the link has time out and shuts down the connection. It then >> tries to reconnect, which fails. At this point the device is >> deactivated. If I restart NetworkManager it usually reconnects >> immediately. >> >> >> My questions are as follows: >> >> >> >> * Is this a known issue with madwifi? If so does anyone know of any >> fixes for this? > > I have had similar issues with Athero's based cards and MadWifi. This > was the sole reason I selected a T61 over a Macbook this year. > I /think/ the reason for the disconnect is that Madwifi reports it's > signal strength differently than most other cards and therefore reports > significantly lower strength than other cards. So in one room of my > house if I am using an Intel 2200 B/G MiniPCI card I have 3 bars and a > stable connection, if I am using an IBM branded Atheros A/B/G MiniPCI > card I show one bar and get disconnected frequently. There was a hack > posted by Robert Love almost two years ago that "Translated" (If that is > the right way to describe it) the Madwifi signal reporting into a rough > approximation of what most cards use. This helped make the cards more > usable but still not enough to compare with other cards. > > I have been watching Ath5k development and I hope it will resolve these > issues since the author's won't be tied into working with a closed HAL. > In the meantime I would try and steer clear of Atheros based cards if > possible. > >> >> * Why is the device deactivated? Why wouldnÿÿt the device try to >> reconnect again after some period of time? Will I have to manually >> tell NetworkManager to reconnect? >> >> * I also experienced a crash in network manager in the same >> situation. >> >> >> I suspect my problems are perhaps related to madwifi but figured I >> would start here based on the crash and the fact that if I restart >> NetworkManager the connection is reestablished. >> >> >> >> I have included logs for both problems. >> >> >> Thanks, >> >> Phil >> >> >> >> Logs for deactivation and loss of link: >> >> Nov 27 11:22:22 localhost NetworkManager: DHCP daemon state is >> now 3 (renew) for interface ath0 >> Nov 27 11:22:22 localhost dhclient: bound to 192.168.2.253 -- renewal >> in 142 seconds. >> >> Nov 27 11:24:44 localhost dhclient: DHCPREQUEST on ath0 to >> 192.168.2.55 port 67 >> >> Nov 27 11:24:44 localhost dhclient: DHCPACK from 192.168.2.55 >> >> Nov 27 11:24:44 localhost NetworkManager: DHCP daemon state is >> now 3 (renew) for interface ath0 >> Nov 27 11:24:44 localhost dhclient: bound to 192.168.2.253 -- renewal >> in 119 seconds. >> >> Nov 27 11:26:35 localhost NetworkManager: nm-netlink-monitor.c >> - nm_netlink_monitor_event_handler (724) netlink reports device ath0 >> link now 0 >> Nov 27 11:26:35 localhost NetworkManager: nm-netlink-monitor.c >> - nm_netlink_monitor_event_handler (724) netlink reports device ath0 >> link now 0 >> Nov 27 11:26:43 localhost dhclient: DHCPREQUEST on ath0 to >> 192.168.2.55 port 67 >> >> Nov 27 11:26:51 localhost last message repeated 2 times >> >> Nov 27 11:26:55 localhost NetworkManager: ath0: link timed >> out. >> Nov 27 11:26:55 localhost NetworkManager: nm-device.c - >> nm_device_set_active_link (596) device ath0 link state set to 0 >> Nov 27 11:26:55 localhost NetworkManager: SWITCH: found better >> connection 'ath0/GEM_RD_TEST' than current connection >> 'ath0/GEM_RD_TEST'. same_ssid=1, have_link=0 >> Nov 27 11:26:55 localhost NetworkManager: Will activate >> connection 'ath0/GEM_RD_TEST'. >> Nov 27 11:26:55 localhost NetworkManager: Device ath0 >> activation scheduled... >> Nov 27 11:26:55 localhost NetworkManager: Deactivating device >> ath0. >> Nov 27 11:26:55 localhost dhclient: wifi0: unknown hardware address >> type 801 >> >> Nov 27 11:26:55 localhost dhclient: wifi0: unknown hardware address >> type 801 >> >> Nov 27 11:26:55 localhost dhclient: DHCPRELEASE on ath0 to >> 192.168.2.55 port 67 >> >> Nov 27 11:26:56 localhost avahi-daemon[1597]:
Re: NetworkManager and Madwifi connection loss
On Wed, 2007-11-28 at 20:08 +1300, Simon Geard wrote: > On Tue, 2007-11-27 at 12:47 -0500, Darren Albers wrote: > > I have been watching Ath5k development and I hope it will resolve > > these > > issues since the author's won't be tied into working with a closed HAL. > > In the meantime I would try and steer clear of Atheros based cards if > > possible. > > Speaking of those drivers, do you know what state they're in with regard > to joining the mainline kernel? Was reading up on them recently, and > noticed that while they were in the 2.6.23 -mm kernels, there's no > mention of them in the 2.6.24 -mm patch list. ath5k is in linville's wireless-2.6/everything, which is upstream for wireless drivers. They certainly won't be in 2.6.24 since they aren't in good enough shape yet. They seem on-track to hit 2.6.25 though. ath5k doesn't yet support late-model N-capable chipsets that have recently started appearing though, since the hardware there hasn't been reverse-engineered yet and the register layouts are apparently different. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and Madwifi connection loss
On Nov 27, 2007 7:47 PM, Darren Albers <[EMAIL PROTECTED]> wrote: > card I show one bar and get disconnected frequently. There was a hack > posted by Robert Love almost two years ago that "Translated" (If that is > the right way to describe it) the Madwifi signal reporting into a rough > approximation of what most cards use. This helped make the cards more > usable but still not enough to compare with other cards. The hack lived in suse packages but users reported the drivers changed and because of that hack, NM always showed 100% signal strength. So apparently the driver is fixed now. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and Madwifi connection loss
On Tue, 2007-11-27 at 12:47 -0500, Darren Albers wrote: > I have been watching Ath5k development and I hope it will resolve > these > issues since the author's won't be tied into working with a closed HAL. > In the meantime I would try and steer clear of Atheros based cards if > possible. Speaking of those drivers, do you know what state they're in with regard to joining the mainline kernel? Was reading up on them recently, and noticed that while they were in the 2.6.23 -mm kernels, there's no mention of them in the 2.6.24 -mm patch list. Simon. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: NetworkManager and Madwifi connection loss
I will give the 0.9.4 madwifi drivers a whirl. Thanks, Phil -Original Message- From: Walter Neumann [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 3:14 PM To: Darren Albers Cc: Philip A. Culver; networkmanager-list@gnome.org Subject: Re: NetworkManager and Madwifi connection loss I have no such problem with madwifi-ng-r2594-20070719. On Tue, 27 Nov 2007, Darren Albers wrote: > On Tue, 2007-11-27 at 12:18 -0500, Philip A. Culver wrote: > Hi, > > > > I am using NetworkManager 0.6.5 on Fedora 7 with the madwifi 0.9.3.3 > drivers.I am experiencing an issue where NetworkManager thinks > that the link has time out and shuts down the connection. It then > tries to reconnect, which fails. At this point the device is > deactivated. If I restart NetworkManager it usually reconnects > immediately. > > > > My questions are as follows: > > > > * Is this a known issue with madwifi? If so does anyone know of any > fixes for this? I have had similar issues with Athero's based cards and MadWifi. This was the sole reason I selected a T61 over a Macbook this year. I /think/ the reason for the disconnect is that Madwifi reports it's signal strength differently than most other cards and therefore reports significantly lower strength than other cards. So in one room of my house if I am using an Intel 2200 B/G MiniPCI card I have 3 bars and a stable connection, if I am using an IBM branded Atheros A/B/G MiniPCI card I show one bar and get disconnected frequently. There was a hack posted by Robert Love almost two years ago that "Translated" (If that is the right way to describe it) the Madwifi signal reporting into a rough approximation of what most cards use. This helped make the cards more usable but still not enough to compare with other cards. I have been watching Ath5k development and I hope it will resolve these issues since the author's won't be tied into working with a closed HAL. In the meantime I would try and steer clear of Atheros based cards if possible. > > * Why is the device deactivated? Why wouldnÿÿt the device try to > reconnect again after some period of time? Will I have to manually > tell NetworkManager to reconnect? > > * I also experienced a crash in network manager in the same > situation. > > > > I suspect my problems are perhaps related to madwifi but figured I > would start here based on the crash and the fact that if I restart > NetworkManager the connection is reestablished. > > > > I have included logs for both problems. > > > > Thanks, > > Phil > > > > Logs for deactivation and loss of link: > > Nov 27 11:22:22 localhost NetworkManager: DHCP daemon state is > now 3 (renew) for interface ath0 > > Nov 27 11:22:22 localhost dhclient: bound to 192.168.2.253 -- renewal > in 142 seconds. > > Nov 27 11:24:44 localhost dhclient: DHCPREQUEST on ath0 to > 192.168.2.55 port 67 > > Nov 27 11:24:44 localhost dhclient: DHCPACK from 192.168.2.55 > > Nov 27 11:24:44 localhost NetworkManager: DHCP daemon state is > now 3 (renew) for interface ath0 > > Nov 27 11:24:44 localhost dhclient: bound to 192.168.2.253 -- renewal > in 119 seconds. > > Nov 27 11:26:35 localhost NetworkManager: nm-netlink-monitor.c > - nm_netlink_monitor_event_handler (724) netlink reports device ath0 > link now 0 > > Nov 27 11:26:35 localhost NetworkManager: nm-netlink-monitor.c > - nm_netlink_monitor_event_handler (724) netlink reports device ath0 > link now 0 > > Nov 27 11:26:43 localhost dhclient: DHCPREQUEST on ath0 to > 192.168.2.55 port 67 > > Nov 27 11:26:51 localhost last message repeated 2 times > > Nov 27 11:26:55 localhost NetworkManager: ath0: link timed > out. > > Nov 27 11:26:55 localhost NetworkManager: nm-device.c - > nm_device_set_active_link (596) device ath0 link state set to 0 > > Nov 27 11:26:55 localhost NetworkManager: SWITCH: found better > connection 'ath0/GEM_RD_TEST' than current connection > 'ath0/GEM_RD_TEST'. same_ssid=1, have_link=0 > > Nov 27 11:26:55 localhost NetworkManager: Will activate > connection 'ath0/GEM_RD_TEST'. > > Nov 27 11:26:55 localhost NetworkManager: Device ath0 > activation scheduled... > > Nov 27 11:26:55 localhost NetworkManager: Deactivating device > ath0. > > Nov 27 11:26:55 localhost dhclient: wifi0: unknown hardware address > type 801 > > Nov 27 11:26:55 localhost dhclient: wifi0: unknown hardware address > type 801 > > Nov 27 11:26:55 localhost dhclient: DHCPRELEASE on ath0 to > 192.168.2.55 port 67 > > Nov 27 11:26:56 localhost avahi-daemon[1597]: Withdrawing address > record for 192.168.2.2
Re: NetworkManager and Madwifi connection loss
I have no such problem with madwifi-ng-r2594-20070719. On Tue, 27 Nov 2007, Darren Albers wrote: On Tue, 2007-11-27 at 12:18 -0500, Philip A. Culver wrote: Hi, I am using NetworkManager 0.6.5 on Fedora 7 with the madwifi 0.9.3.3 drivers.I am experiencing an issue where NetworkManager thinks that the link has time out and shuts down the connection. It then tries to reconnect, which fails. At this point the device is deactivated. If I restart NetworkManager it usually reconnects immediately. My questions are as follows: * Is this a known issue with madwifi? If so does anyone know of any fixes for this? I have had similar issues with Athero's based cards and MadWifi. This was the sole reason I selected a T61 over a Macbook this year. I /think/ the reason for the disconnect is that Madwifi reports it's signal strength differently than most other cards and therefore reports significantly lower strength than other cards. So in one room of my house if I am using an Intel 2200 B/G MiniPCI card I have 3 bars and a stable connection, if I am using an IBM branded Atheros A/B/G MiniPCI card I show one bar and get disconnected frequently. There was a hack posted by Robert Love almost two years ago that "Translated" (If that is the right way to describe it) the Madwifi signal reporting into a rough approximation of what most cards use. This helped make the cards more usable but still not enough to compare with other cards. I have been watching Ath5k development and I hope it will resolve these issues since the author's won't be tied into working with a closed HAL. In the meantime I would try and steer clear of Atheros based cards if possible. * Why is the device deactivated? Why wouldnÿÿt the device try to reconnect again after some period of time? Will I have to manually tell NetworkManager to reconnect? * I also experienced a crash in network manager in the same situation. I suspect my problems are perhaps related to madwifi but figured I would start here based on the crash and the fact that if I restart NetworkManager the connection is reestablished. I have included logs for both problems. Thanks, Phil Logs for deactivation and loss of link: Nov 27 11:22:22 localhost NetworkManager: DHCP daemon state is now 3 (renew) for interface ath0 Nov 27 11:22:22 localhost dhclient: bound to 192.168.2.253 -- renewal in 142 seconds. Nov 27 11:24:44 localhost dhclient: DHCPREQUEST on ath0 to 192.168.2.55 port 67 Nov 27 11:24:44 localhost dhclient: DHCPACK from 192.168.2.55 Nov 27 11:24:44 localhost NetworkManager: DHCP daemon state is now 3 (renew) for interface ath0 Nov 27 11:24:44 localhost dhclient: bound to 192.168.2.253 -- renewal in 119 seconds. Nov 27 11:26:35 localhost NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device ath0 link now 0 Nov 27 11:26:35 localhost NetworkManager: nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device ath0 link now 0 Nov 27 11:26:43 localhost dhclient: DHCPREQUEST on ath0 to 192.168.2.55 port 67 Nov 27 11:26:51 localhost last message repeated 2 times Nov 27 11:26:55 localhost NetworkManager: ath0: link timed out. Nov 27 11:26:55 localhost NetworkManager: nm-device.c - nm_device_set_active_link (596) device ath0 link state set to 0 Nov 27 11:26:55 localhost NetworkManager: SWITCH: found better connection 'ath0/GEM_RD_TEST' than current connection 'ath0/GEM_RD_TEST'. same_ssid=1, have_link=0 Nov 27 11:26:55 localhost NetworkManager: Will activate connection 'ath0/GEM_RD_TEST'. Nov 27 11:26:55 localhost NetworkManager: Device ath0 activation scheduled... Nov 27 11:26:55 localhost NetworkManager: Deactivating device ath0. Nov 27 11:26:55 localhost dhclient: wifi0: unknown hardware address type 801 Nov 27 11:26:55 localhost dhclient: wifi0: unknown hardware address type 801 Nov 27 11:26:55 localhost dhclient: DHCPRELEASE on ath0 to 192.168.2.55 port 67 Nov 27 11:26:56 localhost avahi-daemon[1597]: Withdrawing address record for 192.168.2.253 on ath0. Nov 27 11:26:56 localhost avahi-daemon[1597]: Leaving mDNS multicast group on interface ath0.IPv4 with address 192.168.2.253. Nov 27 11:26:56 localhost avahi-daemon[1597]: Interface ath0.IPv4 no longer relevant for mDNS. Nov 27 11:26:56 localhost avahi-daemon[1597]: Withdrawing address record for fe80::240:96ff:feb5:68e on ath0. Nov 27 11:26:56 localhost avahi-daemon[1597]: Leaving mDNS multicast group on interface ath0.IPv6 with address fe80::240:96ff:feb5:68e. Nov 27 11:26:56 localhost avahi-daemon[1597]: Interface ath0.IPv6 no longer relevant for mDNS. Nov 27 11:26:56 localhost NetworkManager: Activation (ath0) started... Nov 27 11:26:56 localhost NetworkManager: Activation (ath0) Stage 1 of 5 (Device Prepare) scheduled... Nov 27 11:26:56 localhost NetworkManager: Activation (ath0) Stage 1 of 5 (Device Prepare) started... Nov 27 11:2
Re: NetworkManager and Madwifi connection loss
On Tue, 2007-11-27 at 12:18 -0500, Philip A. Culver wrote: > Hi, > > > > I am using NetworkManager 0.6.5 on Fedora 7 with the madwifi 0.9.3.3 > drivers.I am experiencing an issue where NetworkManager thinks > that the link has time out and shuts down the connection. It then > tries to reconnect, which fails. At this point the device is > deactivated. If I restart NetworkManager it usually reconnects > immediately. > > > > My questions are as follows: > > > > * Is this a known issue with madwifi? If so does anyone know of any > fixes for this? I have had similar issues with Athero's based cards and MadWifi. This was the sole reason I selected a T61 over a Macbook this year. I /think/ the reason for the disconnect is that Madwifi reports it's signal strength differently than most other cards and therefore reports significantly lower strength than other cards. So in one room of my house if I am using an Intel 2200 B/G MiniPCI card I have 3 bars and a stable connection, if I am using an IBM branded Atheros A/B/G MiniPCI card I show one bar and get disconnected frequently. There was a hack posted by Robert Love almost two years ago that "Translated" (If that is the right way to describe it) the Madwifi signal reporting into a rough approximation of what most cards use. This helped make the cards more usable but still not enough to compare with other cards. I have been watching Ath5k development and I hope it will resolve these issues since the author's won't be tied into working with a closed HAL. In the meantime I would try and steer clear of Atheros based cards if possible. > > * Why is the device deactivated? Why wouldn’t the device try to > reconnect again after some period of time? Will I have to manually > tell NetworkManager to reconnect? > > * I also experienced a crash in network manager in the same > situation. > > > > I suspect my problems are perhaps related to madwifi but figured I > would start here based on the crash and the fact that if I restart > NetworkManager the connection is reestablished. > > > > I have included logs for both problems. > > > > Thanks, > > Phil > > > > Logs for deactivation and loss of link: > > Nov 27 11:22:22 localhost NetworkManager: DHCP daemon state is > now 3 (renew) for interface ath0 > > Nov 27 11:22:22 localhost dhclient: bound to 192.168.2.253 -- renewal > in 142 seconds. > > Nov 27 11:24:44 localhost dhclient: DHCPREQUEST on ath0 to > 192.168.2.55 port 67 > > Nov 27 11:24:44 localhost dhclient: DHCPACK from 192.168.2.55 > > Nov 27 11:24:44 localhost NetworkManager: DHCP daemon state is > now 3 (renew) for interface ath0 > > Nov 27 11:24:44 localhost dhclient: bound to 192.168.2.253 -- renewal > in 119 seconds. > > Nov 27 11:26:35 localhost NetworkManager: nm-netlink-monitor.c > - nm_netlink_monitor_event_handler (724) netlink reports device ath0 > link now 0 > > Nov 27 11:26:35 localhost NetworkManager: nm-netlink-monitor.c > - nm_netlink_monitor_event_handler (724) netlink reports device ath0 > link now 0 > > Nov 27 11:26:43 localhost dhclient: DHCPREQUEST on ath0 to > 192.168.2.55 port 67 > > Nov 27 11:26:51 localhost last message repeated 2 times > > Nov 27 11:26:55 localhost NetworkManager: ath0: link timed > out. > > Nov 27 11:26:55 localhost NetworkManager: nm-device.c - > nm_device_set_active_link (596) device ath0 link state set to 0 > > Nov 27 11:26:55 localhost NetworkManager: SWITCH: found better > connection 'ath0/GEM_RD_TEST' than current connection > 'ath0/GEM_RD_TEST'. same_ssid=1, have_link=0 > > Nov 27 11:26:55 localhost NetworkManager: Will activate > connection 'ath0/GEM_RD_TEST'. > > Nov 27 11:26:55 localhost NetworkManager: Device ath0 > activation scheduled... > > Nov 27 11:26:55 localhost NetworkManager: Deactivating device > ath0. > > Nov 27 11:26:55 localhost dhclient: wifi0: unknown hardware address > type 801 > > Nov 27 11:26:55 localhost dhclient: wifi0: unknown hardware address > type 801 > > Nov 27 11:26:55 localhost dhclient: DHCPRELEASE on ath0 to > 192.168.2.55 port 67 > > Nov 27 11:26:56 localhost avahi-daemon[1597]: Withdrawing address > record for 192.168.2.253 on ath0. > > Nov 27 11:26:56 localhost avahi-daemon[1597]: Leaving mDNS multicast > group on interface ath0.IPv4 with address 192.168.2.253. > > Nov 27 11:26:56 localhost avahi-daemon[1597]: Interface ath0.IPv4 no > longer relevant for mDNS. > > Nov 27 11:26:56 localhost avahi-daemon[1597]: Withdrawing address > record for fe80::240:96ff:feb5:68e on ath0. > > Nov 27 11:26:56 localhost avahi-daemon[1597]: Leaving mDNS multicast > group on interface ath0.IPv6 with address fe80::240:96ff:feb5:68e. > > Nov 27 11:26:56 localhost avahi-daemon[1597]: Interface ath0.IPv6 no > longer relevant for mDNS. > > Nov 27 11:26:56 localhost NetworkManager: Activation (ath0) > started... > > Nov 27 11:26:56 localhost NetworkManager: Activation (ath0) > Stage 1 of 5 (Dev
