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
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: 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: 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: 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
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
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
