Re: FC8 Pin error
On Wed, 2008-04-30 at 01:51 +0100, Luke Sheldrick wrote: Here's another question around the same subject... I changed contracts today on my data tarif, from T-Mobile to Vodafone. Tried the new sim in my D420 with Novatel minipci 5520, and seeing messages in the sys log saying: Apr 28 16:48:26 D420 NetworkManager: WARN check_pin_done(): PIN checking failed ?Now it only does this for the new sim, which doesn't have any pin enabled... Could you try: http://koji.fedoraproject.org/koji/buildinfo?buildID=47431 and report the serial output? That build has serial debugging enabled and should let us see what's going wrong. Thanks! Dan Not sure if anyone was able to look into this, but just tried again using the latest NM: [EMAIL PROTECTED] ~]# rpm -qa | grep Network NetworkManager-devel-0.7.0-0.9.2.svn3566.fc8 NetworkManager-0.7.0-0.9.2.svn3566.fc8 NetworkManager-glib-devel-0.7.0-0.9.2.svn3566.fc8 NetworkManager-debuginfo-0.7.0-0.9.2.svn3566.fc8 NetworkManager-gnome-0.7.0-0.9.2.svn3566.fc8 NetworkManager-glib-0.7.0-0.9.2.svn3566.fc8 and still seeing the errors,now on both sims.. : Apr 30 01:20:32 D420 NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) scheduled... Apr 30 01:20:32 D420 NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) started... Apr 30 01:20:32 D420 NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) complete. Apr 30 01:20:32 D420 NetworkManager: WARN check_pin_done(): PIN checking failed Apr 30 01:20:32 D420 NetworkManager: info Marking connection 'Auto GSM network connection' invalid. Apr 30 01:20:32 D420 NetworkManager: info Activation (ttyUSB0) failed. Apr 30 01:20:32 D420 NetworkManager: info Deactivating device ttyUSB0. Have confirmed that there is no pin on the vodafone card. Anyone any ideas? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
FC8 Pin error
Here's another question around the same subject... I changed contracts today on my data tarif, from T-Mobile to Vodafone. Tried the new sim in my D420 with Novatel minipci 5520, and seeing messages in the sys log saying: Apr 28 16:48:26 D420 NetworkManager: WARN check_pin_done(): PIN checking failed ?Now it only does this for the new sim, which doesn't have any pin enabled... Not sure if anyone was able to look into this, but just tried again using the latest NM: [EMAIL PROTECTED] ~]# rpm -qa | grep Network NetworkManager-devel-0.7.0-0.9.2.svn3566.fc8 NetworkManager-0.7.0-0.9.2.svn3566.fc8 NetworkManager-glib-devel-0.7.0-0.9.2.svn3566.fc8 NetworkManager-debuginfo-0.7.0-0.9.2.svn3566.fc8 NetworkManager-gnome-0.7.0-0.9.2.svn3566.fc8 NetworkManager-glib-0.7.0-0.9.2.svn3566.fc8 and still seeing the errors,now on both sims.. : Apr 30 01:20:32 D420 NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) scheduled... Apr 30 01:20:32 D420 NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) started... Apr 30 01:20:32 D420 NetworkManager: info Activation (ttyUSB0) Stage 1 of 5 (Device Prepare) complete. Apr 30 01:20:32 D420 NetworkManager: WARN check_pin_done(): PIN checking failed Apr 30 01:20:32 D420 NetworkManager: info Marking connection 'Auto GSM network connection' invalid. Apr 30 01:20:32 D420 NetworkManager: info Activation (ttyUSB0) failed. Apr 30 01:20:32 D420 NetworkManager: info Deactivating device ttyUSB0. Have confirmed that there is no pin on the vodafone card. Anyone any ideas? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: FC8
Yes, that's really scary, since you are not knowing which provider it is going to use. Well, you'll know once you get the bill ;-) Agreed, I think if it is going to connect, it's an absolute nessasity to tell you where it is connected. The card normally just uses the APN that's already stored in the SIM profile. Mine has 3 setup, so guess it is using the default, i.e. *99#? but as previously mentioned a feautre is on the way to enable which one you setup, a 'hot swap' option would be good, as I often flick between the 'generic' and 'vpn' apn that t-mobile uk offer. But what i'd like to know: how did you enter the PIN for your SIM card? I was not able to connect until i entered the PIN first with umtsmon or comgt. I didn't, I dont have a pin on my sim =P ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC8
On Mon, Apr 28, 2008 at 11:38 AM, Stefan Seyfried [EMAIL PROTECTED] wrote: I think that by just using the bits that are readily available, a much better user experience would be possible today. Sigh, I'm getting tired of hearing use umtsmon in every thread that has a word 3g or umts in it. Until umtsmon works with CDMA (Dan has explained it multiple times already), uses HAL for device discovery (opening random files in /proc and /sys is so last century), and most importantly, implements a DBus interface to control and receive status changes, NetworkManager simply can not use it. Not depending on Qt would certainly be a bonus too for a non-gui backend. So if you're interested in implementing these changes, feel free to ask for the details what exactly would be needed. Or if you just want to advertise umtsmon, please do it elsewhere. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC8
Umtsmon deliberately does not use HAL, since it is meant as a temporary solution until NM is ready, and it is intended to be usable on a little bit older systems that might not have the latest HAL. Umtsmon is not intended to be a backend for anything, and it would be pretty hard to hack it into that. Ah, sorry, I misunderstood you. Again: i was objecting the we cannot do this because the evil card maufacturers don't provide specs, which is the answer to every inquiry about proper 3G support and is, IMVHO plain FUD. It is possible. It has been done. I guess the truth is somewhere in the middle. The main reason why NM support for mobile devices is lacking is that it's almost good enough for now (0.7 release) (the PIN entering you mentioned is a small bug and can be easily fixed). Some other parts of NM aren't. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: FC8
Here's another question around the same subject... I changed contracts today on my data tarif, from T-Mobile to Vodafone. Tried the new sim in my D420 with Novatel minipci 5520, and seeing messages in the sys log saying: Apr 28 16:48:26 D420 NetworkManager: WARN check_pin_done(): PIN checking failed Now it only does this for the new sim, which doesn't have any pin enabled... ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC8
Into the fray here :-) Lets be clear, we are trying to make generalizations between two different technologies. UMTS is significantly different from EV-DO at all levels be it network, hardware, at command sets, etc. I don't believe you need the APN except in certain circumstances like roaming or other less-common configurations. We've got somebody working on a mobile wizard that should be able to select the right APN for you though if you need it. Different APNs often mean different billing schemes - for my no-limit flat data plan i need a different APN than for the normal, data volume charged data plans. Guess what APN was stored in the SIM when i got it... Enabling APN in the GSM world is important - it allows carriers to differentiate service capabilities, billing rates, and essentially allows them to group or classify service offerings. There is no guarantee the default profile or APN will be the one that should be used. EV-DO doesn't quite have this concept, hence perhaps the importance is not so obvious. Was just wondering if it should show the network name, i.e. T-Mobile? and is there a way to get it to show the signal strength? Yeah, both of these would be nice things to have. Unfortunately, some of that is blocked on the card vendors themselves becoming a bit more open. Most cards do not allow you to retrieve information about the connection while you're connected, unless you use a proprietary protocol that you must license from the vendor. 1) In Asia/Europe where there are large numbers of carriers competeing for your business, its pretty critical to be able to identify and select the appropriate carrier. 2) Network and signal should be available from the single AT port devices before a PPP connection is established... which would be the critical stage to look at these parameters. Both UMTS and EVDO cards should be able to do this - albient using different AT commands (IS-707 for EV-DO TS 127 007 for UMTS). Please quantify most cards. From the ~10 cards i have, only one, the Novatel X870 which only has one usable port, has this problem (but you can still select the provider and check signal strength before connecting). All other cards (Option, Sierra Wireless, Huawei) have two usable ports and you can use one of them to query for network data while being connected. Yes, you can do this on some cards. I've never said this was impossible for all cards. I just said it was impossible for huge numbers of common cards, many of which are CDMA, and many of which are GSM. Crass generalization here - from my own knowledge of the industry - not from comments posted here: 1) Most (All?) EV-DO cards do not have a second AT command port (Market factors perhaps?). 2) Most UMTS cards built within the last 2 years have a second AT command port 3) All cards older than 2 or so years have a single AT command port 4) Some UMTS cards also support GSM 07.01 multiplexing, allowing multiple ttys on a single USB endpoint. For the record: MC727 - EV-DO S620 - EV-DO AC595U - EV-DO AC580 - EV-DO AC860 - Older UMTS PC5750 - EV-DO KPC680 - EV-DO Thus I can see the difference in perception. My point is that lots of people have cards that don't allow this functionality under Linux yet. If most cards used AT commands, I'd add support tomorrow. That would be awesome. I think the split rather runs - Lots of people with EV-DO cards or older UMTS cards which cant support multiple AT ports, and another lots of people with relatively new UMTS cards which do support multiple AT ports... both are big groups, both are for the most part georaphically seperated. don't, we need to understand the entire field; what cards do? how do they support it? what cards don't? how can we easily identify cards that do and cards that do not? If a card does, are there variations in the commands and responses? This is where the umtsmon knowledge can be leveraged - there is alot of experience dealing with the tricks of the various cards to get them going sucessfully. The way this support gets into NetworkManager is going to be the following: 1) Add a property in HAL to tag the secondary port that can be used for communication, if it exists 2) Tag secondary ports of cards known to support AT commands with the correct modem.command_sets properties, and then add the property from (1) so we know they are a secondary port 3) Recognize secondary ports in NM, and for those cards that support them, provide signal strength and connection speed status to the user Sounds like a good plan to me - note secondary ports could be marked by what they support - be it AT commands or some proprietary protocol :) Cheers, Phil ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC8
On Mon, 2008-04-28 at 12:56 -0700, [EMAIL PROTECTED] wrote: Into the fray here :-) Lets be clear, we are trying to make generalizations between two different technologies. UMTS is significantly different from EV-DO at all levels be it network, hardware, at command sets, etc. Definitely. Though as our focus is on the user, hopefully no users have to care that we've had this discussion. It needs to just work for them, irregardless of the technology their particular provider or card uses. I don't believe you need the APN except in certain circumstances like roaming or other less-common configurations. We've got somebody working on a mobile wizard that should be able to select the right APN for you though if you need it. Different APNs often mean different billing schemes - for my no-limit flat data plan i need a different APN than for the normal, data volume charged data plans. Guess what APN was stored in the SIM when i got it... Enabling APN in the GSM world is important - it allows carriers to differentiate service capabilities, billing rates, and essentially allows them to group or classify service offerings. There is no guarantee the default profile or APN will be the one that should be used. EV-DO doesn't quite have this concept, hence perhaps the importance is not so obvious. Right. No argument there. APN is a heavily used GSM feature, and obviously its one NM must support and must support well. Was just wondering if it should show the network name, i.e. T-Mobile? and is there a way to get it to show the signal strength? Yeah, both of these would be nice things to have. Unfortunately, some of that is blocked on the card vendors themselves becoming a bit more open. Most cards do not allow you to retrieve information about the connection while you're connected, unless you use a proprietary protocol that you must license from the vendor. 1) In Asia/Europe where there are large numbers of carriers competeing for your business, its pretty critical to be able to identify and select the appropriate carrier. Of course; this has to happen no matter where you are. It's got to happen even in the US when you roam, since no carrier has 100% nationwide coverage. 2) Network and signal should be available from the single AT port devices before a PPP connection is established... which would be the critical stage to look at these parameters. Both UMTS and EVDO cards should be able to do this - albient using different AT commands (IS-707 for EV-DO TS 127 007 for UMTS). Correct; we certainly can show signal strength before we connect, and we can and should check whether the card is actually locked on a tower before we allow the device to be activated. Please quantify most cards. From the ~10 cards i have, only one, the Novatel X870 which only has one usable port, has this problem (but you can still select the provider and check signal strength before connecting). All other cards (Option, Sierra Wireless, Huawei) have two usable ports and you can use one of them to query for network data while being connected. Yes, you can do this on some cards. I've never said this was impossible for all cards. I just said it was impossible for huge numbers of common cards, many of which are CDMA, and many of which are GSM. Crass generalization here - from my own knowledge of the industry - not from comments posted here: 1) Most (All?) EV-DO cards do not have a second AT command port (Market factors perhaps?). Correct. 2) Most UMTS cards built within the last 2 years have a second AT command port Right. 3) All cards older than 2 or so years have a single AT command port Seems to be the case from what I've seen. 4) Some UMTS cards also support GSM 07.01 multiplexing, allowing multiple ttys on a single USB endpoint. For the record: MC727 - EV-DO S620 - EV-DO AC595U - EV-DO AC580 - EV-DO AC860 - Older UMTS PC5750 - EV-DO KPC680 - EV-DO Thus I can see the difference in perception. Though I do have access to an MC8775 and an AC880, which supposedly do support AT commands on the secondary interface. My point is simply that a huge number of people in the US, whether they use GSM _or_ CDMA cellular providers, don't necessarily have the capability of signal strength while connected. My point is that lots of people have cards that don't allow this functionality under Linux yet. If most cards used AT commands, I'd add support tomorrow. That would be awesome. I think the split rather runs - Lots of people with EV-DO cards or older UMTS cards which cant support multiple AT ports, and another lots of people with relatively new UMTS cards which do support multiple AT ports... both are big groups, both are for the most part georaphically seperated. don't, we need to understand the entire field; what cards do? how do they support it? what cards don't? how can we
NetworkManager-0.7.0-0.6.7.svn3614.fc8 aborting on suspend/resume?
Hello, NM 0.7.0-0.6.7.svn3614.fc8 from Koji seems to be crashing on me through a suspend/resume cycle... seen on two different machines using iwl4965 and b43 drivers. NetworkManager: info (wlan0): device state change: 8 - 3 NetworkManager: info Deactivating device wlan0. Nothing to flush. Nothing to flush. NetworkManager: nm_act_request_get_connection: assertion `NM_IS_ACT_REQUEST (req)' failed NetworkManager: WARN remove_network_cb(): Couldn't remove network from supplicant interface: The requested network does not exist.. NetworkManager: WARN remove_network_cb(): Couldn't remove network from supplicant interface: The requested network does not exist.. NetworkManager: info Waking up from sleep. NetworkManager: info (eth0): now unmanaged NetworkManager: info (eth0): device state change: 2 - 1 NetworkManager: info eth0: Device is fully-supported using driver '8139too'. NetworkManager: info Found new Ethernet device 'eth0'. NetworkManager: info (eth0): exported as /org/freedesktop/Hal/devices/net_00_02_3f_68_15_45 A handler is already registered for the path starting with path[0] = org NetworkManager: Failed to register GObject with DBusConnection ** (process:2453): WARNING (recursed) **: WARN nm_signal_handler(): Caught signal 6. Generating backtrace... aborting... Aborted Thanks, James. -- The Holy ettlz [EMAIL PROTECTED] PGP key ID: 03F94B5D --- 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: FC8
On Sat, 2008-04-26 at 09:49 +0100, Luke Sheldrick wrote: Hi all, Have just updated via yum update my fc8 laptop using the testing repos. It's updated my network manager, I believe it will be the same as the new fc9? Not quite; what's in updates-testing usually lags somewhat behind rawhide. I usually try to build the latest NM snapshot into Koji for F8 at least once a week though, just to keep F8 up to date with the latest progress. Anyways it has detected my inbuilt 3g modem in my Dell D420, and amazingly just connected... without the need to enter the APN or anything else? I don't believe you need the APN except in certain circumstances like roaming or other less-common configurations. We've got somebody working on a mobile wizard that should be able to select the right APN for you though if you need it. Was just wondering if it should show the network name, i.e. T-Mobile? and is there a way to get it to show the signal strength? Yeah, both of these would be nice things to have. Unfortunately, some of that is blocked on the card vendors themselves becoming a bit more open. Most cards do not allow you to retrieve information about the connection while you're connected, unless you use a proprietary protocol that you must license from the vendor. We're trying to pry some bits of those open, but it may take a while. There are a couple avenues though. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
FC8
Hi all, Have just updated via yum update my fc8 laptop using the testing repos. It's updated my network manager, I believe it will be the same as the new fc9? Anyways it has detected my inbuilt 3g modem in my Dell D420, and amazingly just connected... without the need to enter the APN or anything else? Was just wondering if it should show the network name, i.e. T-Mobile? and is there a way to get it to show the signal strength? Thx ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2.6.24.3-12.fc8 kernel causes NM to fail to connect, 2.6.23.15-137.fc8 works perfectly
On Sun, 2008-03-16 at 00:09 +, Brian Morrison wrote: On Sat, 8 Mar 2008 17:50:59 + Brian Morrison [EMAIL PROTECTED] wrote: On Sat, 8 Mar 2008 17:44:42 + Brian Morrison [EMAIL PROTECTED] wrote: If someone would like to tell me what sort of debugging I can do, I'll happily do so and post the results here. Should have added, it's an Intel 3945ABG card using the iwl3945 drivers. I don't think they or NM were updated in this batch of updateschecks...no, only NM-openvpn which I'm not using just now. So, looks like the kernel is the culprit although it might be that the new kernel wireless fixes are correct and NM was working around something in the previous kernel. I've now had some time to generate some logs, basically grepping for NetworkManager in /var/log/messages, which I'm going to post here. First of all a good log, using the 2.6.23.15-137 kernel: Mar 15 23:21:09 fangio NetworkManager: info starting... Mar 15 23:21:09 fangio NetworkManager: info Found radio killswitch /org/freedesktop/Hal/devices/ipw_wlan_switch Mar 15 23:21:09 fangio NetworkManager: info eth0: Device is fully-supported using driver 'sky2'. Mar 15 23:21:09 fangio NetworkManager: info Now managing wired Ethernet (802.3) device 'eth0'. Mar 15 23:21:09 fangio NetworkManager: info Bringing up device eth0 Mar 15 23:21:09 fangio NetworkManager: info Deactivating device eth0. Mar 15 23:21:09 fangio NetworkManager: info (eth0): exporting device as /org/freedesktop/Hal/devices/net_00_e0_b8_c5_e6_f4 Mar 15 23:21:09 fangio NetworkManager: info wlan0: Device is fully-supported using driver 'iwl3945'. Mar 15 23:21:09 fangio NetworkManager: info wlan0: driver supports SSID scans (scan_capa 0x01). Mar 15 23:21:09 fangio NetworkManager: info Now managing wireless (802.11) device 'wlan0'. Mar 15 23:21:09 fangio NetworkManager: info Bringing up device wlan0 Mar 15 23:21:09 fangio NetworkManager: info Deactivating device wlan0. Mar 15 23:21:09 fangio NetworkManager: info (wlan0): exporting device as /org/freedesktop/Hal/devices/net_00_19_d2_83_aa_bd Mar 15 23:21:15 fangio NetworkManager: info Trying to start the supplicant... Mar 15 23:21:15 fangio NetworkManager: info (eth0) supplicant interface is now in state 1 (from 0). Mar 15 23:21:15 fangio NetworkManager: info (wlan0) supplicant manager is now in state 1 (from 0). Mar 15 23:21:15 fangio NetworkManager: info (eth0) supplicant interface is now in state 2 (from 1). Mar 15 23:21:15 fangio NetworkManager: info (wlan0) supplicant interface is now in state 2 (from 1). Mar 15 23:22:58 fangio NetworkManager: info SWITCH: no current connection, found better connection 'Auto f3nr1r (wlan0)'. Mar 15 23:22:58 fangio NetworkManager: info Activating device wlan0 Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0/wireless): access point 'Auto f3nr1r' has security, but secrets are required. Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Mar 15 23:23:08 fangio NetworkManager: Missing or invalid key management Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0/wireless): connection 'Auto f3nr1r' has security, and secrets exist. No new secrets needed. Mar 15 23:23:08 fangio NetworkManager: info Config: added 'ssid' value 'f3nr1r' Mar 15 23:23:08 fangio NetworkManager: info Config: added 'key_mgmt' value 'WPA-PSK' Mar 15 23:23:08 fangio NetworkManager: info Config: added 'psk' value 'omitted' Mar 15 23:23:08 fangio NetworkManager: info Config: added 'proto' value 'WPA RSN' Mar 15 23:23:08 fangio NetworkManager: info Config: added 'pairwise' value 'TKIP CCMP' Mar 15 23:23:08 fangio NetworkManager: info Config: added 'group' value 'WEP40 WEP104 TKIP CCMP' Mar 15 23:23:08 fangio NetworkManager: info
Re: 2.6.24.3-12.fc8 kernel causes NM to fail to connect, 2.6.23.15-137.fc8 works perfectly
On Sat, 8 Mar 2008 17:50:59 + Brian Morrison [EMAIL PROTECTED] wrote: On Sat, 8 Mar 2008 17:44:42 + Brian Morrison [EMAIL PROTECTED] wrote: If someone would like to tell me what sort of debugging I can do, I'll happily do so and post the results here. Should have added, it's an Intel 3945ABG card using the iwl3945 drivers. I don't think they or NM were updated in this batch of updateschecks...no, only NM-openvpn which I'm not using just now. So, looks like the kernel is the culprit although it might be that the new kernel wireless fixes are correct and NM was working around something in the previous kernel. I've now had some time to generate some logs, basically grepping for NetworkManager in /var/log/messages, which I'm going to post here. First of all a good log, using the 2.6.23.15-137 kernel: Mar 15 23:21:09 fangio NetworkManager: info starting... Mar 15 23:21:09 fangio NetworkManager: info Found radio killswitch /org/freedesktop/Hal/devices/ipw_wlan_switch Mar 15 23:21:09 fangio NetworkManager: info eth0: Device is fully-supported using driver 'sky2'. Mar 15 23:21:09 fangio NetworkManager: info Now managing wired Ethernet (802.3) device 'eth0'. Mar 15 23:21:09 fangio NetworkManager: info Bringing up device eth0 Mar 15 23:21:09 fangio NetworkManager: info Deactivating device eth0. Mar 15 23:21:09 fangio NetworkManager: info (eth0): exporting device as /org/freedesktop/Hal/devices/net_00_e0_b8_c5_e6_f4 Mar 15 23:21:09 fangio NetworkManager: info wlan0: Device is fully-supported using driver 'iwl3945'. Mar 15 23:21:09 fangio NetworkManager: info wlan0: driver supports SSID scans (scan_capa 0x01). Mar 15 23:21:09 fangio NetworkManager: info Now managing wireless (802.11) device 'wlan0'. Mar 15 23:21:09 fangio NetworkManager: info Bringing up device wlan0 Mar 15 23:21:09 fangio NetworkManager: info Deactivating device wlan0. Mar 15 23:21:09 fangio NetworkManager: info (wlan0): exporting device as /org/freedesktop/Hal/devices/net_00_19_d2_83_aa_bd Mar 15 23:21:15 fangio NetworkManager: info Trying to start the supplicant... Mar 15 23:21:15 fangio NetworkManager: info (eth0) supplicant interface is now in state 1 (from 0). Mar 15 23:21:15 fangio NetworkManager: info (wlan0) supplicant manager is now in state 1 (from 0). Mar 15 23:21:15 fangio NetworkManager: info (eth0) supplicant interface is now in state 2 (from 1). Mar 15 23:21:15 fangio NetworkManager: info (wlan0) supplicant interface is now in state 2 (from 1). Mar 15 23:22:58 fangio NetworkManager: info SWITCH: no current connection, found better connection 'Auto f3nr1r (wlan0)'. Mar 15 23:22:58 fangio NetworkManager: info Activating device wlan0 Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0/wireless): access point 'Auto f3nr1r' has security, but secrets are required. Mar 15 23:22:58 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Mar 15 23:23:08 fangio NetworkManager: Missing or invalid key management Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0/wireless): connection 'Auto f3nr1r' has security, and secrets exist. No new secrets needed. Mar 15 23:23:08 fangio NetworkManager: info Config: added 'ssid' value 'f3nr1r' Mar 15 23:23:08 fangio NetworkManager: info Config: added 'key_mgmt' value 'WPA-PSK' Mar 15 23:23:08 fangio NetworkManager: info Config: added 'psk' value 'omitted' Mar 15 23:23:08 fangio NetworkManager: info Config: added 'proto' value 'WPA RSN' Mar 15 23:23:08 fangio NetworkManager: info Config: added 'pairwise' value 'TKIP CCMP' Mar 15 23:23:08 fangio NetworkManager: info Config: added 'group' value 'WEP40 WEP104 TKIP CCMP' Mar 15 23:23:08 fangio NetworkManager: info Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Mar 15 23:23:08 fangio NetworkManager: info Config: set interface ap_scan to 1 Mar 15
Re: 2.6.24.3-12.fc8 kernel causes NM to fail to connect, 2.6.23.15-137.fc8 works perfectly
Some notes on F8 kernels + iwl3945 + NM http://www.ces.clemson.edu/linux/f8-nm-iwl3945-B.shtml -- Bill Moss Alumni Distinguished Professor Mathematical Sciences Clemson University ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
2.6.24.3-12.fc8 kernel causes NM to fail to connect, 2.6.23.15-137.fc8 works perfectly
write - md/raid5: fix data corruption in some failure cases - serial: add IDs for some new Wacom tablets (#352811) * Tue Nov 6 2007 David Airlie [EMAIL PROTECTED] 2.6.23.1-44 - Fix bug 228414 - X hangs at startup with Radeon X800 GTO PCIe with DRI * Sat Nov 3 2007 David Woodhouse [EMAIL PROTECTED] 2.6.23.1-43 - Apply PS3 EHCI workaround to make rebooting work when hci_usb is loaded References: [ 1 ] Bug #433262 - RTC disabled in recent 2.6.24 builds for fc8 rawhide https://bugzilla.redhat.com/show_bug.cgi?id=433262 If I do /sbin/iwlist wlan0 scanning I can see both my APs showing the correct frequencies, encryption capbilities, SSIDs and MAC addresses, it's just that the connection never activates and the right hand green dot on the icon never occurs, it falls back to repeatedly asking for the WPA key even though gnome-keyring has it. Reverting to the 2.6.23.15-137 kernel makes it work instantly again. If someone would like to tell me what sort of debugging I can do, I'll happily do so and post the results here. Fun this wireless lark eh? -- Brian Morrison bdm at fenrir dot org dot uk Arguing with an engineer is like wrestling with a pig in the mud; after a while you realize you are muddy and the pig is enjoying it. GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2.6.24.3-12.fc8 kernel causes NM to fail to connect, 2.6.23.15-137.fc8 works perfectly
On Sat, 8 Mar 2008 17:44:42 + Brian Morrison [EMAIL PROTECTED] wrote: If someone would like to tell me what sort of debugging I can do, I'll happily do so and post the results here. Should have added, it's an Intel 3945ABG card using the iwl3945 drivers. I don't think they or NM were updated in this batch of updateschecks...no, only NM-openvpn which I'm not using just now. So, looks like the kernel is the culprit although it might be that the new kernel wireless fixes are correct and NM was working around something in the previous kernel. -- Brian Morrison bdm at fenrir dot org dot uk Arguing with an engineer is like wrestling with a pig in the mud; after a while you realize you are muddy and the pig is enjoying it. GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2.6.24.3-12.fc8 kernel causes NM to fail to connect, 2.6.23.15-137.fc8 works perfectly
On 08/03/2008, Brian Morrison [EMAIL PROTECTED] wrote: Should have added, it's an Intel 3945ABG card using the iwl3945 drivers. I don't think they or NM were updated in this batch of updateschecks...no, only NM-openvpn which I'm not using just now. So, looks like the kernel is the culprit although it might be that the new kernel wireless fixes are correct and NM was working around something in the previous kernel. I've also been having lots of problems with my 3945 using the iwl3945 ever since I bought a new laptop. Can you please see if the issue I reported at [1] is similar to yours and add a comment there in that case? Thanks, Rui [1] https://bugzilla.redhat.com/show_bug.cgi?id=428591 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2.6.24.3-12.fc8 kernel causes NM to fail to connect, 2.6.23.15-137.fc8 works perfectly
On Sat, 8 Mar 2008 22:49:25 + Rui Tiago Cação Matos [EMAIL PROTECTED] wrote: On 08/03/2008, Brian Morrison [EMAIL PROTECTED] wrote: Should have added, it's an Intel 3945ABG card using the iwl3945 drivers. I don't think they or NM were updated in this batch of updateschecks...no, only NM-openvpn which I'm not using just now. So, looks like the kernel is the culprit although it might be that the new kernel wireless fixes are correct and NM was working around something in the previous kernel. I've also been having lots of problems with my 3945 using the iwl3945 ever since I bought a new laptop. Can you please see if the issue I reported at [1] is similar to yours and add a comment there in that case? Thanks, Rui [1] https://bugzilla.redhat.com/show_bug.cgi?id=428591 Well, whatever it is, I have not seen any problems before now, it's only on this new 2.6.24.3-12 kernel that I see problems at all, before now it's just worked without problems. Since there are lots of wireless changes in the kernel changelog I suspect that one of them is the culprit. -- Brian Morrison bdm at fenrir dot org dot uk Arguing with an engineer is like wrestling with a pig in the mud; after a while you realize you are muddy and the pig is enjoying it. GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
nm-applet 0.7.0-0.6.7.svn3302.fc8 crash caused by bad auth?
On Wed, 2008-02-27 at 21:36 -0500, Dan Williams wrote: Did you downgrade _all_ the NM RPMs (nm, nm-gnome, nm-glib, etc) and then restart the machine to ensure a clean bootup? Worked OK again after a clean bootup. ;) As for nm-applet crashing, I've discovered some more. I power-cycled the WAP concerned and it now connects OK. I then killed the remote RADIUS server. As expected, it just kept prompting for secrets and fell back to wired when I pressed escape. I then power-cycled the WAP, still no RADIUS. I also restarted NetworkManager, and chose the misbehaving network. Again, it prompted me for the secrets. I filled these in. It failed to connect (good, no RADIUS). This time, I pressed escape and let it connect to wired. Then I chose the wireless network again --- and nm-applet terminated abnormally. To get it working again, I restarted NetworkManager and the WAP. So as far as I can see, there's some yet-to-be-understood state for a network (perhaps resulting from failed WPA/EAP-TLS auth?) which upsets nm-applet... James -- The Holy ettlz [EMAIL PROTECTED] PGP key ID: 03F94B5D --- 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
NM 0.7.0-0.6.7.svn3302.fc8 broken with dbus-glib 0.73-6.fc8?
Hello, Having problems with nm-applet 0.7.0-0.6.7.svn3302.fc8. If I try to connec to my usual (WPA) network, I get this: ** (nm-applet:23750): WARNING **: Invalid connection given. ** (nm-applet:23750): WARNING **: WARN applet_menu_item_activate_helper(): Invalid connection; asking for more information. (nm-applet:23750): Gtk-CRITICAL **: gtk_list_store_get_value: assertion `VALID_ITER (iter, list_store)' failed (nm-applet:23750): GLib-GObject-WARNING **: gtype.c:3339: type id `0' is invalid (nm-applet:23750): GLib-GObject-WARNING **: can't peek value table for type `invalid' which is not currently referenced and then it quits on signal 15, Bug Buddy kicks in, and there's a stack dump. The only thing I can think of that could've caused this is an update to dbus-glib-0.73-6.fc8. However I'm not convinced of this since downgrading doesn't help. The only other possible relevant packages upgraded then were pam-0.99.8.1-17.1.fc8.i386 and libnetfilter_conntrack-0.0.82-1.fc8.i386. [As a side note, I tried downgrading to NM 0.7.0-0.6.7.svn3235.fc8, but for some reason now the daemon just segfaults. Don't know what caused that, either.] Many thanks, James. -- The Holy ettlz [EMAIL PROTECTED] PGP key ID: 03F94B5D --- 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: NM 0.7.0-0.6.7.svn3302.fc8 broken with dbus-glib 0.73-6.fc8?
On Wed, 2008-02-27 at 23:14 +, The Holy ettlz wrote: Hello, Having problems with nm-applet 0.7.0-0.6.7.svn3302.fc8. If I try to connec to my usual (WPA) network, I get this: ** (nm-applet:23750): WARNING **: Invalid connection given. ** (nm-applet:23750): WARNING **: WARN applet_menu_item_activate_helper(): Invalid connection; asking for more information. (nm-applet:23750): Gtk-CRITICAL **: gtk_list_store_get_value: assertion `VALID_ITER (iter, list_store)' failed (nm-applet:23750): GLib-GObject-WARNING **: gtype.c:3339: type id `0' is invalid (nm-applet:23750): GLib-GObject-WARNING **: can't peek value table for type `invalid' which is not currently referenced and then it quits on signal 15, Bug Buddy kicks in, and there's a stack dump. The only thing I can think of that could've caused this is an update to dbus-glib-0.73-6.fc8. However I'm not convinced of this since downgrading doesn't help. The only other possible relevant packages upgraded then were pam-0.99.8.1-17.1.fc8.i386 and libnetfilter_conntrack-0.0.82-1.fc8.i386. Which selinux-policy-targeted RPM version? There was one that was bogus one that only got to updates-testing but no further. As a test point; I'm running all the 3302 RPMs, dbus-glib-0.73-6.fc8, kernel 2.6.23.15-137, and permissive SELinux with targeted policy 3.0.8-84.fc8. Haven't had an issue here. [As a side note, I tried downgrading to NM 0.7.0-0.6.7.svn3235.fc8, but for some reason now the daemon just segfaults. Don't know what caused that, either.] Did you downgrade _all_ the NM RPMs (nm, nm-gnome, nm-glib, etc) and then restart the machine to ensure a clean bootup? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.7.0-0.6.7.svn3302.fc8
On Sun, 2008-02-24 at 00:57 +, The Holy ettlz wrote: Hello, I'm using the current Fedora 8 NetworkManager build from Koji (0.7.0-0.6.7.svn3302.fc8) and seeing some issues with WPA2. I just got a new router/access point that's configured for WPA2/EAP-TLS, alongside my old access point with WPA/EAP-TLS. Both connect to the same RADIUS server. The WPA network works fine, but the new WPA2 set-up seems to only ever be able to connect just *once*. This first connection will work fine. If I try to connect again, it fails and prompts for the certificate information again. To get it to work, I have to stop NetworkManager and nm-applet, ifconfig the interface down, and start them up again. Note in the logs that eth1 never gets beyond stage 4 with the second go. I've attached some logs (adjusted for privacy!) from nm-applet and NetworkManager. I also see the following from both the applet and manager: So it looks like the issue is deeper and we'll need to know what wpa_supplicant is doing. Can you add a -ddd to the end of the Exec line in /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service and get the connection to fail like that again, then send me the output of /var/log/wpa_supplicant.log? That should shed some light on why the supplicant isn't making the connection. Thanks, Dan WARNING **: WARN list_connections_cb(): Couldn't retrieve system connections: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.. Setting SELinux to Permissive doesn't help. Thanks, James ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM 0.7.0-0.6.7.svn3302.fc8
Hello, I'm using the current Fedora 8 NetworkManager build from Koji (0.7.0-0.6.7.svn3302.fc8) and seeing some issues with WPA2. I just got a new router/access point that's configured for WPA2/EAP-TLS, alongside my old access point with WPA/EAP-TLS. Both connect to the same RADIUS server. The WPA network works fine, but the new WPA2 set-up seems to only ever be able to connect just *once*. This first connection will work fine. If I try to connect again, it fails and prompts for the certificate information again. To get it to work, I have to stop NetworkManager and nm-applet, ifconfig the interface down, and start them up again. Note in the logs that eth1 never gets beyond stage 4 with the second go. I've attached some logs (adjusted for privacy!) from nm-applet and NetworkManager. I also see the following from both the applet and manager: WARNING **: WARN list_connections_cb(): Couldn't retrieve system connections: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.. Setting SELinux to Permissive doesn't help. Thanks, James -- The Holy ettlz [EMAIL PROTECTED] PGP key ID: 03F94B5D --- ** (nm-applet:19896): WARNING **: Settings invalid. ** (nm-applet:19896): WARNING **: Settings invalid. ** (nm-applet:19896): WARNING **: Settings invalid. ** (nm-applet:19896): WARNING **: Settings invalid. ** (nm-applet:19896): WARNING **: Settings invalid. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid or missing ssid ** (nm-applet:19896): WARNING **: Invalid connection read from GConf at /system/networking/connections/2. ** (nm-applet:19896): WARNING **: Invalid
Re: NM dont work in fc8 + madwifi
On Sun, 2007-12-23 at 16:20 -0200, Juliano Rodrigues wrote: Hello, I compiled ath_pci version svn r3065. yum madwifi rpms drivers dont work in an fresh install of fc8 with a AR5418 (Generic Macbook Hardware) (after fc8 fresh install I did 'yum update' at all) Now if I do 'ifup ath0' I have my internet access 100% stable and OK. Can you try using the ath5k driver that comes in the F8 kernels? madwifi is usually tempermental when used with wpa_supplicant and the standard WEXT driver. If ath5k doesn't work for you, let me know. Dan NM output: NetworkManager: info eth0: Device is fully-supported using driver 'sky2'. NetworkManager: info (eth0): exporting device as /org/freedesktop/Hal/devices/net_00_1b_63_32_fb_32 NetworkManager: info Now managing wired Ethernet (802.3) device 'eth0'. NetworkManager: info Bringing up device eth0 NetworkManager: info Deactivating device eth0. NetworkManager: info ath0: Device is fully-supported using driver 'ath_pci'. NetworkManager: info (ath0): exporting device as /org/freedesktop/Hal/devices/net_00_1c_b3_be_9c_2d_0 NetworkManager: info Now managing wireless (802.11) device 'ath0'. NetworkManager: info Bringing up device ath0 NetworkManager: info Deactivating device ath0. NetworkManager: info (eth0) supplicant interface is now in state 2 (from 1). NetworkManager: info (ath0) supplicant interface is now in state 2 (from 1). NetworkManager: info SWITCH: no current connection, found better connection 'Auto Emilio (ath0)'. NetworkManager: info Activating device ath0 NetworkManager: info Activation (ath0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager: info Activation (ath0) Stage 1 of 5 (Device Prepare) started... NetworkManager: info Activation (ath0) Stage 2 of 5 (Device Configure) scheduled... NetworkManager: info Activation (ath0) Stage 1 of 5 (Device Prepare) complete. NetworkManager: info Activation (ath0) Stage 2 of 5 (Device Configure) starting... NetworkManager: info Activation (ath0/wireless): connection 'Auto Emilio' requires no security. No secrets needed. NetworkManager: info Config: added 'ssid' value 'Emilio' NetworkManager: info Config: added 'key_mgmt' value 'NONE' NetworkManager: info Activation (ath0) Stage 2 of 5 (Device Configure) complete. NetworkManager: info Config: set interface ap_scan to 1 NetworkManager: info (ath0) Supplicant interface state change: 0 - 2 NetworkManager: info (ath0) Supplicant interface state change: 2 - 3 NetworkManager: info (ath0) Supplicant interface state change: 3 - 0 NetworkManager: info (ath0) Supplicant interface state change: 0 - 2 NetworkManager: info (ath0) Supplicant interface state change: 2 - 3 NetworkManager: info Activation (ath0/wireless): association took too long, failing activation. NetworkManager: info Activation (ath0) failed for access point (Emilio) NetworkManager: info Marking connection 'Auto Emilio' invalid. NetworkManager: info Activation (ath0) failed. Can anyone helpme ? Thanks, Juliano. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM dont work in fc8 + madwifi
Hello, I compiled ath_pci version svn r3065. yum madwifi rpms drivers dont work in an fresh install of fc8 with a AR5418 (Generic Macbook Hardware) (after fc8 fresh install I did 'yum update' at all) Now if I do 'ifup ath0' I have my internet access 100% stable and OK. NM output: NetworkManager: info eth0: Device is fully-supported using driver 'sky2'. NetworkManager: info (eth0): exporting device as /org/freedesktop/Hal/devices/net_00_1b_63_32_fb_32 NetworkManager: info Now managing wired Ethernet (802.3) device 'eth0'. NetworkManager: info Bringing up device eth0 NetworkManager: info Deactivating device eth0. NetworkManager: info ath0: Device is fully-supported using driver 'ath_pci'. NetworkManager: info (ath0): exporting device as /org/freedesktop/Hal/devices/net_00_1c_b3_be_9c_2d_0 NetworkManager: info Now managing wireless (802.11) device 'ath0'. NetworkManager: info Bringing up device ath0 NetworkManager: info Deactivating device ath0. NetworkManager: info (eth0) supplicant interface is now in state 2 (from 1). NetworkManager: info (ath0) supplicant interface is now in state 2 (from 1). NetworkManager: info SWITCH: no current connection, found better connection 'Auto Emilio (ath0)'. NetworkManager: info Activating device ath0 NetworkManager: info Activation (ath0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager: info Activation (ath0) Stage 1 of 5 (Device Prepare) started... NetworkManager: info Activation (ath0) Stage 2 of 5 (Device Configure) scheduled... NetworkManager: info Activation (ath0) Stage 1 of 5 (Device Prepare) complete. NetworkManager: info Activation (ath0) Stage 2 of 5 (Device Configure) starting... NetworkManager: info Activation (ath0/wireless): connection 'Auto Emilio' requires no security. No secrets needed. NetworkManager: info Config: added 'ssid' value 'Emilio' NetworkManager: info Config: added 'key_mgmt' value 'NONE' NetworkManager: info Activation (ath0) Stage 2 of 5 (Device Configure) complete. NetworkManager: info Config: set interface ap_scan to 1 NetworkManager: info (ath0) Supplicant interface state change: 0 - 2 NetworkManager: info (ath0) Supplicant interface state change: 2 - 3 NetworkManager: info (ath0) Supplicant interface state change: 3 - 0 NetworkManager: info (ath0) Supplicant interface state change: 0 - 2 NetworkManager: info (ath0) Supplicant interface state change: 2 - 3 NetworkManager: info Activation (ath0/wireless): association took too long, failing activation. NetworkManager: info Activation (ath0) failed for access point (Emilio) NetworkManager: info Marking connection 'Auto Emilio' invalid. NetworkManager: info Activation (ath0) failed. Can anyone helpme ? Thanks, Juliano. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
FC8 / NM0.7
Not sure if the devs want any feedback on the 0.7 code from latest Fedora 8 yet? Appreciate it's still work in progress, but on the off chance you do... ;) - OpenVPN configuration dialog crashes when entering text - WPA2 dialog doesn't enable connect button correctly Other than that, 0.7 is working well enough here. Thanks! NetworkManager-gnome-0.7.0-0.5.svn3030.fc8 NetworkManager-openvpn-0.7.0-2.svn3047.fc8 NetworkManager-glib-0.7.0-0.5.svn3030.fc8 NetworkManager-0.7.0-0.5.svn3030.fc8 Regards, Jon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
