Re: ifcfg-rh and wpa_supplicant
On Sat, 2012-05-19 at 06:17 +0200, Oncaphillis wrote: On 05/19/2012 03:43 AM, Dan Williams wrote: On Fri, 2012-05-18 at 23:39 +0200, Oncaphillis wrote: On 05/18/2012 11:23 PM, Dan Williams wrote: On Thu, 2012-05-17 at 09:58 +0200, Oncaphillis wrote: Hi, I'm using Fedora16 and I'm trying to set up NetworkManager to connect to a wlan on startup via /etc/sysconfig/network-scrip/ifcfg-wlan0 or /etc/sysconfig/network-scrip/ifcfg-ESSID. It seems the settings in /etc/sysconfig/wpa_supplicant are ignored if wpa_supplicant is managed by the NetworkManager,but I don't see any option to pass the -Ddriver option to wpa_supplicant. Correct, the settings in /etc/sysconfig/wpa_supplicant can be harmful when NetworkManager is used, because NetworkManager figures out whether to use the wext, nl80211, or wired driver as appropriate. What's the reason you want to use a specific supplicant driver? Dan Simply the observation that wpa_supplicant fails to associate when not using -Dwext What wifi kernel driver? snip 04:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PC Subsystem: Device 1a3b:1067 Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at febf (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 2 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [90] MSI-X: Enable- Count=1 Masked- Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: ath9k Kernel modules: ath9k That device is driven by the ath9k driver, which is one of the better-supported mac80211 chipsets, so it should certainly work with nl80211. If it's not working, then we need to get some supplicant and kernel debugging information to see what's wrong in the driver. What kernel version do you have? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ifcfg-rh and wpa_supplicant
On 05/21/2012 05:42 PM, Dan Williams wrote: That device is driven by the ath9k driver, which is one of the better-supported mac80211 chipsets, so it should certainly work with nl80211. If it's not working, then we need to get some supplicant and kernel debugging information to see what's wrong in the driver. What kernel version do you have? Dan Right now I've switched back to a fedora 13 with a self compiled kernel 3.2.13. The wpa_supplicant gets started by /etc/init.d/wpa_supplicant abd definitely uses the -Dwext option. The target I'm aiming for is Fedora16 with kernel 3.3.5-2 but I currently can't use it since wifi does not work Thanks O. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ifcfg-rh and wpa_supplicant
On Mon, 2012-05-21 at 18:31 +0200, Oncaphillis wrote: On 05/21/2012 05:42 PM, Dan Williams wrote: That device is driven by the ath9k driver, which is one of the better-supported mac80211 chipsets, so it should certainly work with nl80211. If it's not working, then we need to get some supplicant and kernel debugging information to see what's wrong in the driver. What kernel version do you have? Dan Right now I've switched back to a fedora 13 with a self compiled kernel 3.2.13. The wpa_supplicant gets started by /etc/init.d/wpa_supplicant abd definitely uses the -Dwext option. The target I'm aiming for is Fedora16 with kernel 3.3.5-2 but I currently can't use it since wifi does not work Right, so we need to figure out why wifi isn't working on F16. It should work, and it should work well with nl80211. WEXT is deprecated and will be removed from upstream kernels in the future. ath9k is actively developed upstream and any issues are usually fixed pretty quickly. Are there any interesting messages in 'dmesg' output for your wifi card? Is your access point 802.11n-enabled? Is it using 40MHz wide channels? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v2] Re: Change the state of iface from disconnected to connected using nmcli
On Thu, 2012-05-17 at 17:25 +0200, Jirka Klimes wrote: On Wednesday 16 of May 2012 18:02:12 Dan Williams wrote: On Mon, 2012-05-14 at 17:36 +0200, Jirka Klimes wrote: On Thursday 22 of March 2012 11:10:56 Dan Williams wrote: On Sun, 2012-03-18 at 23:43 +0530, Abhijeet Rastogi wrote: Hi, This is my first post here. I have tried googling and looking at the manpage but no help. We can use $nmcli dev disconnect iface eth0 to change the state of eth0 to disconnect. Is there a command to change it's state back to connected? I tried looking at the manpage I can't seem to find any option for that. At the moment, you need to tell NM to reconnect to something, eg 'nmcli con up uuid uuid'. Disconnect places the device into manual mode which requires user action to return to automatic mode. I suppose we can add an 'autoconnect' property to each device, which Disconnect() would set to false, but which could be changed via the D-Bus properties interface (authenticated of course) back to TRUE. This property would follow the internal 'autoconnect_inhibit' device member variable and the NMPolicy would listen for changes to this variable and retrigger an auto connection check if it changes back to TRUE. Patches accepted for that. Dan Attached are patches adding 'Autoconnect' property to NMDevice for core NM and libnm-glib as well. For the API docs, I'd say: If TRUE, indicates the device is allowed to autoconnect. If FALSE, manual intervention is required before the device will automatically connect to a known network, such as activating a connection using the device, or setting this property to TRUE. Changed the text in xml. There's a redundant NM_DEVICE_GET_PRIVATE() in nm_device_get_autoconnect(). Removed. The other thing we need to do is authenticate the property write call, which we've got some code for in nm-manager.c::prop_filter(). It's going to get a bit complicated since that function only works on the manager object, so we'll have to have something that's a bit more involved than just strcmp(propiface, NM_DBUS_IFACE). That said, it shouldn't be too bad. We basically want to enforce the same permissions as manager_device_disconnect_request() does. After some tries it seems to me that the easiest way is to tweak the prop_filter() and use it. I have added a check for .Device interface and find the right NMDevice object according to object path extracted from the D-Bus message. NM_AUTH_PERMISSION_NETWORK_CONTROL permission is used. Does it look right? I'm sending authorization changes as a separate patch, so that it is easier to see what changed. The changes were made to the previous core patch. libnm-glib didn't change. The rest of it looks good! Dan And while we're at it, to reduce confusion, we should just rename autoconnect_inhibit to autoconnect. Something like the attached patch applied on top of yours? Changed to autoconnect variable. One last thing with the permissions code; if we can't find the device when we're about to call g_object_set(), we should return NM_MANAGER_ERROR_UNKNOWN_DEVICE. Other than that they both look good. THanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ifcfg-rh and wpa_supplicant
On 05/21/2012 07:02 PM, Dan Williams wrote: Right, so we need to figure out why wifi isn't working on F16. It should work, and it should work well with nl80211. WEXT is deprecated and will be removed from upstream kernels in the future. ath9k is actively developed upstream and any issues are usually fixed pretty quickly. Are there any interesting messages in 'dmesg' output for your wifi card? Is your access point 802.11n-enabled? Is it using 40MHz wide channels? Dan Don't know how to figure out the 40MHz issue. (A) Here comes the dmesg part around ath9k initialization in Fedora12/Linux 3.2.13 snip ath9k :04:00.0: PCI INT A - Link[LN3A] - GSI 18 (level, low) - IRQ 18 ath9k :04:00.0: setting latency timer to 64 ... ... ath: EEPROM regdomain: 0x60 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x60 ... ... ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control' Registered led device: ath9k-phy0 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xff56, irq=18 /snip and the iwconfig stuff: snip wlan0 IEEE 802.11bgn ESSID:oncaphillis Mode:Managed Frequency:2.442 GHz Access Point: 00:25:9C:D0:04:FB Bit Rate=54 Mb/s Tx-Power=16 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=45/70 Signal level=-65 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:90 Missed beacon:0 /snip (B) The same stuff for Fedora16/Linux 3.3.6 snip [8.398499] ath: EEPROM regdomain: 0x60 [8.398507] ath: EEPROM indicates we should expect a direct regpair map [8.398517] ath: Country alpha2 being used: 00 [8.398523] ath: Regpair used: 0x60 [8.422729] ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control' [8.423924] Registered led device: ath9k-phy0 [ 12.209542] wlan0: authenticate with 00:25:9c:d0:04:fb (try 1) [ 12.211621] wlan0: authenticated [ 12.211720] wlan0: associate with 00:25:9c:d0:04:fb (try 1) [ 12.214487] wlan0: RX AssocResp from 00:25:9c:d0:04:fb (capab=0x411 status=0 aid=2) [ 12.214500] wlan0: associated [ 12.214512] wlan0: moving STA 00:25:9c:d0:04:fb to state 1 [ 12.214520] wlan0: moving STA 00:25:9c:d0:04:fb to state 2 [ 12.214529] wlan0: moving STA 00:25:9c:d0:04:fb to state 3 [ 12.215576] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready /snip snip wlan0 IEEE 802.11bgn ESSID:oncaphillis Mode:Managed Frequency:2.442 GHz Access Point: 00:25:9C:D0:04:FB Bit Rate=54 Mb/s Tx-Power=16 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=57/70 Signal level=-53 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:54 Missed beacon:0 /snip This however after I switched back to the old network/wpa_supplicant scripts. O. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
