Re: NetworkManager-0.6.5 for FC6?
have you tryed with a newer wpa_supplicant too? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and applet 0.6.5 Released
On 4/20/07, Christopher Aillon <[EMAIL PROTECTED]> wrote: Hey all, It's been a while since we've had NM releases and after talking with Dan, I just made a release of 0.6.5 based on the 0.6 branch. Downloads are available at: http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.6/ http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.6/ Thanks to all who contributed to this release! what about this issues? http://mail.gnome.org/archives/networkmanager-list/2007-April/msg00101.html ___ 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
Re: networkmanager blocks suspend to disk?
On 4/9/07, Dan Williams <[EMAIL PROTECTED]> wrote: On Mon, 2007-04-09 at 16:28 +0200, dragoran dragoran wrote: > > > On 4/9/07, Dan Williams <[EMAIL PROTECTED]> wrote: > On Mon, 2007-04-09 at 11:26 +0200, dragoran wrote: > > I tryed suspend to disk on my laptop and it fails with > "strange > > networkmanager not stopped" and goes back to X. > > If I stop the networkmanager service It works. > > I use FC6 x86_64, loaded networkdrivers: r8169,ipw3945 > > any more info I can provide? > > known bug? > > No, it works for the cards I've tried, including ipw2200 and > ipw2100. > Can you try a suspend and then grab the output > of /var/log/messages? > You should see this in your logs: "Going to sleep.". > > I have attached the relevant part of /var/log/messages > > > Are you running gnome-power-manager or another power > management daemon? > NM doesn't put itself to sleep, but is told by > gnome-power-manager (or > another PM daemon) to go to sleep and to wake up. > > yes I use gnome-power-manager Interesting; you're suspending in the middle of a connection attempt, which should probably terminate the connection attempt. However, I don't see the "Going to sleep" message at all, which leads me to suspect that something is missing between gpm and NM. I did tis while I was connected to the wired network and with wireless off via killswitch. so who is broken? nm or gpm or both? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: networkmanager blocks suspend to disk?
On 4/9/07, Dan Williams <[EMAIL PROTECTED]> wrote: On Mon, 2007-04-09 at 11:26 +0200, dragoran wrote: > I tryed suspend to disk on my laptop and it fails with "strange > networkmanager not stopped" and goes back to X. > If I stop the networkmanager service It works. > I use FC6 x86_64, loaded networkdrivers: r8169,ipw3945 > any more info I can provide? > known bug? No, it works for the cards I've tried, including ipw2200 and ipw2100. Can you try a suspend and then grab the output of /var/log/messages? You should see this in your logs: "Going to sleep.". I have attached the relevant part of /var/log/messages Are you running gnome-power-manager or another power management daemon? NM doesn't put itself to sleep, but is told by gnome-power-manager (or another PM daemon) to go to sleep and to wake up. yes I use gnome-power-manager Dan Apr 9 16:23:46 localhost kernel: Disabling non-boot CPUs ... Apr 9 16:23:46 localhost kernel: kvm: disabling virtualization on CPU1 Apr 9 16:23:46 localhost kernel: Breaking affinity for irq 1 Apr 9 16:23:46 localhost kernel: Breaking affinity for irq 12 Apr 9 16:23:46 localhost kernel: Breaking affinity for irq 16 Apr 9 16:23:46 localhost kernel: Breaking affinity for irq 17 Apr 9 16:23:46 localhost kernel: Breaking affinity for irq 19 Apr 9 16:23:46 localhost kernel: Breaking affinity for irq 2300 Apr 9 16:23:46 localhost kernel: CPU 1 is now offline Apr 9 16:23:46 localhost kernel: SMP alternatives: switching to UP code Apr 9 16:23:46 localhost NetworkManager: nm_device_802_11_wireless_get_mode (): error getting card mode on eth1: No such device Apr 9 16:24:06 localhost restorecond: Read error (Interrupted system call) Apr 9 16:24:06 localhost kernel: CPU1 is down Apr 9 16:24:06 localhost kernel: Stopping tasks ... Apr 9 16:24:06 localhost kernel: Stopping user space processes timed out after 20 seconds (1 tasks refusing to freeze): Apr 9 16:24:06 localhost kernel: NetworkManager Apr 9 16:24:06 localhost kernel: Restarting tasks ... <4> Strange, khubd not stopped Apr 9 16:24:06 localhost kernel: Strange, kseriod not stopped Apr 9 16:24:06 localhost kernel: Strange, pdflush not stopped Apr 9 16:24:06 localhost kernel: Strange, pdflush not stopped Apr 9 16:24:06 localhost kernel: Strange, kswapd0 not stopped Apr 9 16:24:06 localhost kernel: Strange, pccardd not stopped Apr 9 16:24:06 localhost kernel: Strange, kjournald not stopped Apr 9 16:24:06 localhost kernel: Strange, kauditd not stopped Apr 9 16:24:06 localhost kernel: Strange, kjournald not stopped Apr 9 16:24:06 localhost kernel: Strange, khelper not stopped Apr 9 16:24:11 localhost kernel: Strange, NetworkManager not stopped Apr 9 16:24:11 localhost kernel: ipw3945: Radio Frequency Kill Switch is On: Apr 9 16:24:11 localhost kernel: Kill switch must be turned off for wireless networking to work. Apr 9 16:24:11 localhost kernel: done. Apr 9 16:24:11 localhost kernel: Enabling non-boot CPUs ... Apr 9 16:24:11 localhost kernel: SMP alternatives: switching to SMP code Apr 9 16:24:11 localhost kernel: Booting processor 1/2 APIC 0x1 Apr 9 16:24:11 localhost gnome-power-manager: (linux) Wecke Computer auf Apr 9 16:24:11 localhost kernel: Not responding. Apr 9 16:24:11 localhost NetworkManager: Waking up from sleep. Apr 9 16:24:11 localhost kernel: Inquiring remote APIC #1... Apr 9 16:24:11 localhost NetworkManager: Deactivating device eth0. Apr 9 16:24:11 localhost kernel: ... APIC #1 ID: failed Apr 9 16:24:12 localhost kernel: ... APIC #1 VERSION: failed Apr 9 16:24:12 localhost kernel: ... APIC #1 SPIV: failed Apr 9 16:24:12 localhost kernel: kvm: disabling virtualization on CPU1 Apr 9 16:24:12 localhost kernel: r8169: eth0: link up Apr 9 16:24:12 localhost NetworkManager: eth0: Device is fully-supported using driver 'r8169'. Apr 9 16:24:12 localhost NetworkManager: nm_device_init(): waiting for device's worker thread to start Apr 9 16:24:12 localhost NetworkManager: nm_device_init(): device's worker thread started, continuing. Apr 9 16:24:12 localhost NetworkManager: Now managing wired Ethernet (802.3) device 'eth0'. Apr 9 16:24:12 localhost NetworkManager: Deactivating device eth0. Apr 9 16:24:12 localhost NetworkManager: Will activate wired connection 'eth0' because it now has a link. Apr 9 16:24:12 localhost NetworkManager: SWITCH: no current connection, found better connection 'eth0'. Apr 9 16:24:12 localhost NetworkManager: Will activate connection 'eth0'. Apr 9 16:24:12 localhost NetworkManager: Device eth0 activation scheduled... Apr 9 16:24:12 localhost NetworkManager: Activation (eth0) started... Apr 9 16:24:12 localhost NetworkManager: Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... Apr 9 16:24:12 localhost NetworkManager: Activation (eth0) Stage 1 of 5 (Device Prepare) started... Apr 9 16:24:12 localhost NetworkManager: Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Re: Roadmap to 0.7
On 4/7/07, Dan Williams <[EMAIL PROTECTED]> wrote: On Thu, 2007-04-05 at 12:48 +0200, Giovanni Lovato wrote: > Hi all! > I can't find a roadmap of this project and I'm wondering if exists a > release date for NetworkManager 0.7, in which I hope there will be > system-wide configuration and multiple active network support! There's a "NetworkManagerToDo" page on live.gnome.org that gives the planned list of features for 0.7. http://live.gnome.org/NetworkManagerToDo static ip adresses not on the list? or are they already supported in trunk? Dan ___ 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
Re: networkmanager fails to associate (ipw3945)
On 2/10/07, Dan Williams <[EMAIL PROTECTED]> wrote: On Sat, 2007-02-10 at 16:46 +, Volker Braun wrote: > In dragoran's wpa_supplicant log there is this suspicious entry somewhere > at the beginning: > > Wireless event: new AP: 00:00:00:00:00:00 > Added BSSID 00:00:00:00:00:00 into blacklist > State: ASSOCIATING -> DISCONNECTED > > driver bug? wpa_supplicant bug? I don't see the reason for why > wpa_supplicant disconnects, but it does. Of course, it immediately tries > again and succeeeds. This is a driver bug. The driver lost association to the AP, or the AP told the driver to disconnect itself by sending a disassociation or deauthentication frame, or a driver/firmware timer expired, or something like that. It's essentially the card saying "I can't connect" or "I lost the connection", and there's not much that NM or wpa_supplicant can realistically do about it. > But NetworkManager then ticks differently. The supplicant_timeout_cb() had > 20 seconds to complete, but now it has only 8 seconds for the > link_timeout_cb. > > Feb 8 13:48:49 localhost NetworkManager:SUP: sending command 'ENABLE_NETWORK 0' > Feb 8 13:48:49 localhost NetworkManager:SUP: response was 'OK' > Feb 8 13:48:49 localhost NetworkManager:Activation (eth1) Stage 2 of 5 (Device Configure) complete. > Feb 8 13:48:57 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready > > Comment: doesn't that mean that the link is up now? Not really; that's the driver calling netif_carrier_on(), which doesn't really mean anything for wireless interfaces. Does it mean that the card associated? Or does it mean that the card has authenticated? Or does it mean the card can actually pass frames to the AP? Or does it mean that you can actually send traffic _beyond_ the AP? netlink carrier detect is essentially useless on wireless links, and nobody (neither NM nor wpa_supplicant) uses wireless carrier notifications for anything because of that. All drivers do netif_carrier_* differently anyway, partially because its useless. sometimes when this happens the gnome-netstatus -applet shows that the card is associated but nm disconnects it again and ask for a password. Feb 8 13:48:59 localhost avahi-daemon[2565]: New relevant interface eth1.IPv6 for mDNS. > Feb 8 13:48:59 localhost avahi-daemon[2565]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::218:deff:fe05:f79e. > Feb 8 13:48:59 localhost avahi-daemon[2565]: Registering new address record for fe80::218:deff:fe05:f79e on eth1. > > Comment: it is now 11 seconds past the start of the supplicant_timeout, > usually we wouldn't give up yet. > > Feb 8 13:49:00 localhost NetworkManager:Activation (eth1/wireless): disconnected during association, asking for new key. > Feb 8 13:49:00 localhost NetworkManager:Activation (eth1) New wireless user key requested for network 'mynet'. > > I think the heuristic DISCONNECT => need new password is wrong. We should > at least try a few times. Either wait until we have a fixed number of > disconnects, or wait until the end of the supplicant timeout even if there > are initial disconnects. This is a really complicated issue. It depends on what disconnect means during the association attempt. During 802.1x handshakes, it's certainly possible that we have associated and authed to the access point, but if our credentials are wrong, the RADIUS server may have kicked us off, and wpa_supplicant returns a DISCONNECT event. There was a patch a while ago that normalized the 'new key' requests. It seemed to make sense at the time. Before we change it, I'd urge a review of what exactly it means when wpa_supplicant sends the disconnect event during an association for the different auth methods (including WEP shared key/open system). NetworkManager should probably be trying a little harder before giving up, but definitely not by increasing timeouts. Remember that on WEP Open System connections, you _never_ know if your WEP key is wrong until 45 seconds later when DHCP times out. Trying again would be a connect time of 1:30, and that's just wrong. WPA is a lot better here because there are hard failures when your credentials or keys are wrong, and we should take advantage of that. so whats the solution now? anything that I could test/provide to help here? or is nm useless on this kind of setup? is it possible to make the timeout a gconf-key for each connection? Dan ___ 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
Re: networkmanager fails to associate (ipw3945)
it does I created a file wpax.txt with the contents you posted (only changed
passphrase) and did
wpa_supplicant -D wext -i eth1 -c wpax.txt -dd (to enable debug output to)
and it connects just fine.
I attached the output.
On 2/8/07, Dan Williams <[EMAIL PROTECTED]> wrote:
On Thu, 2007-02-08 at 13:53 +0100, dragoran wrote:
> Dan Williams wrote:
> > On Thu, 2007-02-08 at 10:29 +0100, dragoran wrote:
> >
> >> I recompiled ieee and ipw3945 and it now works with wpa_supplicant
> >> without any problems (using the wext driver).
> >> but nm keeps asking me for the passphrase and never connects.
> >>
> >
> > Hmm; can you get some logs of NM during the connection attempt? They
> > should get dumped to /var/log/messages. Basically, it may be the case
> > that NM isn't passing the same options to wpa_supplicant as your
> > testcase is using, but we don't know what those options are.
> >
> >
> nm output to syslog is attached (note: ignore selinux messages I did run
> setenforce 0 before doing this test)
Does this wpa_supplicant config file work for you?
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
ap_scan=1
network={
ssid="mynet"
proto=WPA
key_mgmt=WPA-PSK
scan_ssid=1
pairwise=TKIP
group=TKIP
psk=""
}
If not, we need to figure out why that doesn't work. The config above
is essentially what NM is pushing to wpa_supplicant.
Dan
wpa_supplicant -D wext -i eth1 -c wpax.txt -dd
Initializing interface 'eth1' conf 'wpax.txt' driver 'wext' ctrl_interface 'N/A'
Configuration file 'wpax.txt' -> '/home/linux/wpax.txt'
Reading configuration file '/home/linux/wpax.txt'
ctrl_interface='/var/run/wpa_supplicant'
ctrl_interface_group=10 (from group name 'wheel')
ap_scan=1
Line: 6 - start of a new network block
ssid - hexdump_ascii(len=5):
6d 79 6e 65 74mynet
proto: 0x1
key_mgmt: 0x2
scan_ssid=1 (0x1)
pairwise: 0x8
group: 0x8
PSK (ASCII passphrase) - hexdump_ascii(len=9): [REMOVED]
PSK (from passphrase) - hexdump(len=32): [REMOVED]
Priority group 0
id=0 ssid='mynet'
Initializing interface (2) 'eth1'
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
SIOCGIWRANGE: WE(compiled)=21 WE(source)=16 enc_capa=0xf
capabilities: key_mgmt 0xf enc 0xf
Own MAC address: 00:18:de:05:f7:9e
wpa_driver_wext_set_wpa
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_countermeasures
wpa_driver_wext_set_drop_unencrypted
Setting scan request: 0 sec 10 usec
Added interface eth1
Wireless event: cmd=0x8b06 len=12
RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
State: DISCONNECTED -> SCANNING
Starting AP scan (specific SSID)
Scan SSID - hexdump_ascii(len=5):
6d 79 6e 65 74mynet
Scan timeout - try to get results
Received 345 bytes of scan results (1 BSSes)
Scan results: 1
Selecting BSS from priority group 0
0: 00:0d:0b:c3:bd:c9 ssid='mynet' wpa_ie_len=24 rsn_ie_len=22 caps=0x11
selected based on WPA IE
Trying to associate with 00:0d:0b:c3:bd:c9 (SSID='mynet' freq=0 MHz)
Cancelling scan request
WPA: clearing own WPA/RSN IE
Automatic auth_alg selection: 0x1
WPA: using IEEE 802.11i/D3.0
WPA: Selected cipher suites: group 8 pairwise 8 key_mgmt 2
WPA: set AP WPA IE - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02
WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 02 01 00 00 0f ac 02 01 00 00 0f ac 02 0c 00
WPA: using GTK TKIP
WPA: using PTK TKIP
WPA: using KEY_MGMT WPA-PSK
WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02
No keys have been configured - skip key clearing
wpa_driver_wext_set_drop_unencrypted
State: SCANNING -> ASSOCIATING
wpa_driver_wext_associate
Setting authentication timeout: 15 sec 0 usec
EAPOL: External notification - EAP success=0
EAPOL: External notification - EAP fail=0
EAPOL: External notification - portControl=Auto
RSN: Ignored PMKID candidate without preauth flag
Wireless event: cmd=0x8b06 len=12
Wireless event: cmd=0x8b15 len=24
Wireless event: new AP: 00:00:00:00:00:00
Added BSSID 00:00:00:00:00:00 into blacklist
State: ASSOCIATING -> DISCONNECTED
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
EAPOL: External notification - EAP success=0
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: al
