Re: CVS-1-27
The NM failure reported earlier appears to have been caused by a firmware crash for ipw2200 driver. This driver is still subject to random crashes. This is an active bug. The firmware restart usually slows NM down or makes it fail. I have been able to make several successful wireless connections. -- Bill Moss Professor, Mathematical Sciences Clemson University ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: CVS-1-27
On Thu, 27 Jan 2005, Bill Moss wrote: > Note that the essid and key have been set but no MAC address has been > set for the AP. This is where the problem lies. Bill, We don't set the MAC address of the AP on the card itself, the address you see there comes from the card's firmware and is valid when the card thinks it's associated with a base station. Most drivers don't support locking to a particular AP anyway, so setting the AP address would do no good. What this says is that somehow, we fail to connect to the access point. I'll have to send you a patch that will print out the WEP key in hashed form so that you can verify that it is _indeed_ the correct key being set on the card (and so you can verify that the key is right with 'iwconfig' and all that). Sorry for the recent instability, I'm trying to track about 5 problems at once here... Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
CVS-1-27
The changes made this afternoon have made NM fail to make a wireless connection. syslog shows an attempt to make an Open System connection, which would normally be successful. Then an attempt is make to make a Shared Key connection. No connection is made. After stoping NM and NMInfo, iwconfig eth1 shows eth1 unassociated ESSID:"mosswap" Mode:Managed Channel=0 Access Point: 00:00:00:00:00:00 Bit Rate=0kb/s Tx-Power=20 dBm RTS thr:off Fragment thr:off Encryption key:------xx Security mode:restricted Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:1 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Note that the essid and key have been set but no MAC address has been set for the AP. This is where the problem lies. -- Bill Moss Professor, Mathematical Sciences Clemson University ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems connecting using ahteros based wireless card
Hi, On Thu, 27 Jan 2005 15:46:49 -0500, Dan Williams wrote: > On Thu, 2005-01-27 at 21:28 +0100, Stefan Zechmeister wrote: >> NetworkManager: Activation (ath0) started... NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): access point 'ESSID' is encrypted, and a key exists. >> No new key needed. NetworkManager: Activation (ath0/wireless): using >> essid 'ESSID', with Open System authentication. NetworkManager: >> Activation (ath0/wireless): no hardware link to 'ESSID' in Open System >> mode, trying Shared Key. NetworkManager: Activation (ath0/wireless): >> using essid 'ESSID', with Shared Key authentication. NetworkManager: >> Activation (ath0/wireless): no hardware link to 'ESSID' in Shared Key >> mode, trying another access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Activation >> (ath0/wireless): waiting for an access point. NetworkManager: Caught >> SIGINT/SIGTERM NetworkManager: Caught terminiation signal >> NetworkManager: nm_device_activation_cancel(ath0): cancelling... >> NetworkManager: nm_device_activation_worker(ath0): activation canceled. >> NetworkManager: nm_device_activation_worker(ath0): activation canceled. >> NetworkManager: Activation (ath0) ended. NetworkManager: >> nm_device_activation_cancel(ath0): cancelled. > > Hi, > > What you need to do to debug this is the following... In a separate > window, run the command "watch -n 1 iwconfig ath0" and let that run while > NM is trying to associate with the AP. Look at the MAC address that the > card reports, and if it changes to FF:FF:FF:FF:FF:FF too often during the > link check, then we need to figure out what to do. > > > So, if you could do the "watch" thing, that would be great, and report teh > results, ie do you see the MAC address be FF:FF:FF... for most of the > period when NetworkManager tries to connect to it? Dos it usually stay at > the access points MAC? > > Second, what is the output of "lspci", and what brand/model is your > Atheros card? I personally use a Netgear WG511T to test out the madwifi > drivers and haven't noticed any problems, but that's because the card is > b/g only most likely, and doesn't do 802.11a. Mine is a/b/g. 02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) > > Thanks! > Dan I also have this problem with an atheros card, FC3, kernel 2.6.10. Manually configured works OK, and I have a stable ath0 IEEE 802.11a ESSID:"home" Mode:Managed Frequency:5.17GHz Access Point: 00:05:4E:45:DC:D5 Bit Rate:54Mb/s Tx-Power:50 dBm Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=60/94 Signal level=-35 dBm Noise level=-95 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 when I run NM, I found out in the "watch -n 1 iwconfig ath0", that it stays few seconds associated this ap, then it starts to change frequencies/channels and of course looses the connection (the ap MAC changes to FF.FF.FF.FF.FF.FF and no essid). The AP is another linux with the same model atheros card as master, and as I said before it is working fine. I tested it in all a/b/g modes (set the ap in mode 1/2/3 manually with iwpriv) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems connecting using ahteros based wireless card
Dan Williams wrote: What you need to do to debug this is the following... In a separate window, run the command "watch -n 1 iwconfig ath0" and let that run while NM is trying to associate with the AP. Look at the MAC address that the card reports, and if it changes to FF:FF:FF:FF:FF:FF too often during the link check, then we need to figure out what to do. Also do "watch -n 1 iwpriv ath0 get_mode" in another window to see what mode the Atheros card is being put into. I expect you will see it get stuck in mode 1, which is 802.11a on the Atheros. I experience the same problem with my T41 but have not had time to track down what is pushing the card into 802.11a mode. --[Lance] -- Celebrate The Circle: http://www.celebratethecircle.org/ Carolina Spirit Quest: http://www.carolinaspiritquest.org/ My LiveJournal: http://www.livejournal.com/users/labrown/ GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems connecting using ahteros based wireless card
On Thu, 2005-01-27 at 21:28 +0100, Stefan Zechmeister wrote: > NetworkManager: Activation (ath0) started... > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): access point 'ESSID' is > encrypted, and a key exists. No new key needed. NetworkManager: > Activation (ath0/wireless): using essid 'ESSID', with Open System > authentication. NetworkManager: Activation (ath0/wireless): no hardware > link to 'ESSID' in Open System mode, trying Shared Key. NetworkManager: > Activation (ath0/wireless): using essid 'ESSID', with Shared Key > authentication. NetworkManager: Activation (ath0/wireless): no hardware > link to 'ESSID' in Shared Key mode, trying another access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Activation (ath0/wireless): waiting for an access point. > NetworkManager: Caught SIGINT/SIGTERM NetworkManager: Caught terminiation > signal NetworkManager: nm_device_activation_cancel(ath0): cancelling... > NetworkManager: nm_device_activation_worker(ath0): activation canceled. > NetworkManager: nm_device_activation_worker(ath0): activation canceled. > NetworkManager: Activation (ath0) ended. NetworkManager: > nm_device_activation_cancel(ath0): cancelled. Hi, What you need to do to debug this is the following... In a separate window, run the command "watch -n 1 iwconfig ath0" and let that run while NM is trying to associate with the AP. Look at the MAC address that the card reports, and if it changes to FF:FF:FF:FF:FF:FF too often during the link check, then we need to figure out what to do. What NM currently does for a link-check is to wait around 6 or 8 seconds, I think, and for every half-second during that time it wakes up, checks the MAC address the card reports, and if its a valid MAC address (ie not all 0s, all 4s, or all Fs) it increments a counter. If by the end of that full 6 or 8 seconds, the counter is above a certain value, then we decided that we have a link. This particular song & dance is necessary for a couple reasons. Some cards need to load firmware into the card whenever you set the ESSID on the card, and that takes a round-trip to user-space hotplug scripts, then back into the kernel to upload the firmware to the card. Then, the card has to boot the firmware, and try to associate. This takes time. Second, some cards have more channels that others, specifically a/b/g cards. They need more time to scan all channels for the access point we're trying to find, and to associate with it. Third, some cards are just plain flaky and will take a while to stabilize the MAC address of the associated AP (they scan around and evidentally pick up the MAC addresses of other APs before they settle on the correct one, I think the problem child here is Orinoco w/ HermesI chipset). So, if you could do the "watch" thing, that would be great, and report teh results, ie do you see the MAC address be FF:FF:FF... for most of the period when NetworkManager tries to connect to it? Dos it usually stay at the access points MAC? Second, what is the output of "lspci", and what brand/model is your Atheros card? I personally use a Netgear WG511T to test out the madwifi drivers and haven't noticed any problems, but that's because the card is b/g only most likely, and doesn't do 802.11a. Thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Problems connecting using ahteros based wireless card
Hello! i have problems using networkmanager with my atheros based wireless card (built in wlan in ibm thinkpad t41). the madwifi drivers seem to work, but networkmanager does not get a connection: iwconfig reports: ath0 IEEE 802.11g ESSID:"ESSID" Nickname:"NICK" Mode:Managed Frequency:2.472 GHz Access Point: 00:09:5B:CC:BF:BA Bit Rate:54 Mb/s Tx-Power:50 dBm Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Encryption key:------XX Security mode:restricted Power Management:off Link Quality=33/94 Signal level=-62 dBm Noise level=-95 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:349 Invalid misc:349 Missed beacon:0 so the card did already associate with the accesspoint! (a netgear wgr614v4). here is the log of networkmanager: NetworkManager: starting... NetworkManager: eth0: Driver support level is fully-supported NetworkManager: nm_device_new(): waiting for device's worker thread to start. NetworkManager: nm_device_new(): device's worker thread started, continuing. NetworkManager: Adding device 'eth0' (wired) to our list. NetworkManager: ath0: Driver support level is fully-supported NetworkManager: nm_device_new(): waiting for device's worker thread to start. NetworkManager: nm_device_new(): device's worker thread started, continuing. NetworkManager: Adding device 'ath0' (wireless) to our list. NetworkManager: SWITCH: best device changed NetworkManager: Activation (ath0) started... NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): access point 'ESSID' is encrypted, and a key exists. No new key needed. NetworkManager: Activation (ath0/wireless): using essid 'ESSID', with Open System authentication. NetworkManager: Activation (ath0/wireless): no hardware link to 'ESSID' in Open System mode, trying Shared Key. NetworkManager: Activation (ath0/wireless): using essid 'ESSID', with Shared Key authentication. NetworkManager: Activation (ath0/wireless): no hardware link to 'ESSID' in Shared Key mode, trying another access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Activation (ath0/wireless): waiting for an access point. NetworkManager: Caught SIGINT/SIGTERM NetworkManager: Caught terminiation signal NetworkManager: nm_device_activation_cancel(ath0): cancelling... NetworkManager: nm_device_activation_worker(ath0): activation canceled. NetworkManager: nm_device_activation_worker(ath0): activation canceled. NetworkManager: Activation (ath0) ended. NetworkManager: nm_device_activation_cancel(ath0): cancelled. so networkmanager seems to find the right accesspoint and also determines that i'm using encryption with shared keys. the networkmanager applet already stored the key within gconf (btw. why is this key stored human readable in gconf and not for example in gnome-keyring?). but then networkmanager tells me that no hardware link is present? why that? if manually configure the card (ifconfig ipaddr etc.) everthing works great! why does networkmanager think there is no link? what i'm using: - Fedora Core 3 (all updates applied) - NetworkManager from 20050124 - madwifi driver snapshot from today (+patch to get the correct quality when scanning) - wireless tools 28pre4 (these include some madwifi based fixes. now scanning using iwlist finally works using the madwifi drivers). any hints? what can i do to get networkmanager working? bye stefan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Do you need any further info on Intersil PRISM2 (orinoco_cs)?
On Tue, 2005-01-25 at 13:53 -0500, Dan Williams wrote: > Great to hear you're interested... One thing you _could_ do is to grab > the upstream Orinoco drivers (orinoco.sf.net) and try to build it, then > use it with NetworkManager and report what seems to be broken. I'm very happy to do that. By upstream do you mean the CVS version from here? http://savannah.nongnu.org/cvs/?group=orinoco Otherwise the latest driver seems to be 0.15rc2 which was released on 2004/07/28 which doesn't seem very upstream to me! (BTW, how do you determine which version of the drivers is in pcmcia-cs package?) Are there any tips to installing from source over drivers from an RPM? If the upstream driver won't work what's the best way to rollback to what I'm currently using, and how do I ensure that a yum upgrade doesn't overwrite what I have from source? Best, Darren -- = D. D. Brierton[EMAIL PROTECTED] www.dzr-web.com Trying is the first step towards failure (Homer Simpson) = ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: integration of nonphysical interfaces in NM
On Thu, 27 Jan 2005 16:31:56 +0100, Tomislav Vujec wrote: > This is not a huge time server, but it is definitely something worth ^^ I obviously wanted to say time saver here :-) Tomislav ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: integration of nonphysical interfaces in NM
> Colin Walters and I have talked about a configurable server that you > could "ping" (like some internal server that you can't get to from > outside) that would identify whether or not you're on the company LAN. > Other than that, we could do something based on DHCP reply (ie if you're > given an IP address in a specific range or the nameservers/DNS-search- > name are somethign specific, then your on the internal network). I guess that either this ping solution, or checking the domain-name option in the DHCP offer would work. Address range checks might cause problems, since it often happens that while visiting a client, I get the address on their network which also exist in my corporate network, and that would give false impressions. As alternative, we can use some of the application servers DHCP options from the section 8 of the rfc 2132. > Evolution should be getting online/offline support for NetworkManager at > some future point, but the problem is that Evolution doesn't really have > an "offline now" state. What Evo does is to signal each plugin that > its /going/ offline soon, and when each plugin has repsonded OK, then it > goes offline. That's fine for syncing your mail, but if the cable is > pulled you're /already/ offline, and you don't want Evolution to sit > there and try to sync your mail when you're already offline. This is a > core assumption throughout evolution and its plugin structure, and isn't > easily changed. The second idea is to just make Evolution not check for > new messages when NetworkManager says you're offline, but that's a hack > and the only thing it solves is the annoying dialog that pops up when it > tries to check the mail and can't contact the server. That's precisely why I use OfflineIMAP and evolution with maildir folders. However, two things should be implemented in the future: 1) Evolution should handle network disappearance gracefully, remembering the non-synced stuff in some kind of journals. 2) NM should have a force offline feature, which would signal all applications to go offline, and then somehow wait for them to do that like the evolution does that for its plugins. Now imagine the following scenario: 1) I close my laptop lid, signaling acpi to suspend 2) NM gets the suspend signal, and forces offline mode 3) All applications go offline 4) My laptop suspends . 5) I open the lid again, and the laptop wakes up 6) NM gets the signal and starts connecting through the available preferred network to the Internet 7) NM announces Internet availability, and my yahoo account goes online in the evolution 8) NM recognizes the current network connection as my home net, which has a flag to start company VPN tunnel automatically 9) evolution switches my company email account to online This is not a huge time server, but it is definitely something worth implementing. Now days I almost need to use a checklist to make sure I synced and unmounted everything before suspending. Tomislav ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hal net.80203.link bug
David Zeuthen released hal-0.4.7.cvs20050126-1 hal-gnome-0.4.7.cvs20050126-1 hal-devel-0.4.7.cvs20050126-1 last night which fixed for me the net.80203.link bug that I reported to yesterday bugzilla and to this list since it affected the operation of NM. Wow, that fix was fast! 8-) -- Bill Moss Professor, Mathematical Sciences Clemson University ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: integration of nonphysical interfaces in NM
On Thu, 2005-01-27 at 12:24 +0100, Tomislav Vujec wrote: > I think some applications might care, e.g. email client. My usage pattern > looks like this: > 1) Connect to the Internet > 2) If I am in the company LAN, go to step 4 > 3) connect to the VPN > 4) Sync my email > Now NM removes the requirement on doing the step 1 manually. While I would > like to keep the opportunity to run step 3 manually, I would still like to > avoid having to perform step 4 manually, if there is a way for an Colin Walters and I have talked about a configurable server that you could "ping" (like some internal server that you can't get to from outside) that would identify whether or not you're on the company LAN. Other than that, we could do something based on DHCP reply (ie if you're given an IP address in a specific range or the nameservers/DNS-search- name are somethign specific, then your on the internal network). > application to receive this notice. Imagine evolution plug which would > automatically switch an email account to online / offline, based on the > specific VPN availability. Evolution should be getting online/offline support for NetworkManager at some future point, but the problem is that Evolution doesn't really have an "offline now" state. What Evo does is to signal each plugin that its /going/ offline soon, and when each plugin has repsonded OK, then it goes offline. That's fine for syncing your mail, but if the cable is pulled you're /already/ offline, and you don't want Evolution to sit there and try to sync your mail when you're already offline. This is a core assumption throughout evolution and its plugin structure, and isn't easily changed. The second idea is to just make Evolution not check for new messages when NetworkManager says you're offline, but that's a hack and the only thing it solves is the annoying dialog that pops up when it tries to check the mail and can't contact the server. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Do you need any further info on Intersil PRISM2 (orinoco_cs)?
On Tue, 2005-01-25 at 18:24 +, D. D. Brierton wrote: > waiting for upstream improvements in the orinoco driver. I just wanted > to know if I could help out (no I'm not a developer so I can't help with > programming). Darren, Great to hear you're interested... One thing you _could_ do is to grab the upstream Orinoco drivers (orinoco.sf.net) and try to build it, then use it with NetworkManager and report what seems to be broken. The upstream drivers from orinoco.sf.net should have wireless scanning support, which is pretty much required for a good NM experience. Cheers, Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: integration of nonphysical interfaces in NM
On Thu, 20 Jan 2005 09:54:39 -0500, Dan Williams wrote: > In the case of VPN, why do other programs _care_? What good does it do > to advertise VPN connections to other applications at all? Most > applications care about "getting to the internet", which a VPN does for > you. In the case of a VPN, routing-table+DNS magic will provide the > ability to use VPN connections for certain blocks of addresses (both IP > and DNS) which is completely transparent to the application anyway, even > without NetworkManager. The kernel is doing the packet routing here, > not user applications. I think some applications might care, e.g. email client. My usage pattern looks like this: 1) Connect to the Internet 2) If I am in the company LAN, go to step 4 3) connect to the VPN 4) Sync my email Now NM removes the requirement on doing the step 1 manually. While I would like to keep the opportunity to run step 3 manually, I would still like to avoid having to perform step 4 manually, if there is a way for an application to receive this notice. Imagine evolution plug which would automatically switch an email account to online / offline, based on the specific VPN availability. I think that the NM would be the right place to do this, since it should operate network interfaces, VPN included. Tomislav ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
