Re: Doesn't reconnect to wifi after resuming from suspend
poma wrote: On 06.02.2015 18:42, Ferry Toth wrote: poma wrote: On 05.02.2015 22:00, Ferry Toth wrote: poma wrote: On 05.02.2015 20:12, Ferry Toth wrote: Would that be after a certain kernel? But I used 14.04 with kernel 3.17 (no problem) and 14.10 with 3.17 (and now 3.18) See if it can help https://wireless.wiki.kernel.org/en/users/drivers/ath9k/bugs Thanks by I don't find my case there. /etc/systemd/system/ath9k-reload.service [Unit] Description=Reload Atheros 802.11n wireless LAN cards driver After=hibernate.target suspend.target hybrid-sleep.target [Service] Type=oneshot ExecStart=/usr/sbin/modprobe -r ath9k ExecStart=/usr/sbin/modprobe ath9k [Install] WantedBy=hibernate.target suspend.target hybrid-sleep.target # systemctl enable ath9k-reload.service # systemctl suspend RESUME # systemctl hibernate THAW # systemctl hybrid-sleep RESUME||THAW Does it work? Actually no, it doesn't. I already suspected that as I tried other similar (non-systemd) scripts that restart stuff on resume. With this script, it doesn't even autoreconnect on boot (which did work before). After=hibernate.target suspend.target hybrid-sleep.target As you can read, in the mechanism of ath9k-reload.service, it by any means should not affect the Soft-Off/boot, but only Suspend-to-Disk/thaw and/or Suspend-to-RAM/resume. I am starting to believe that after the drivers go up, an event scan is started, and the ath9k incorrectly reports that it is done (but might not be, as I have 2.4G and 5G and am trying to reconnect to the 5G). Just restarting drivers won't fix this (if it is indeed so). I need a delay after resume and scan, and before the autoconnect starts. BTW when I do: lsmod | grep ath ath9k 162133 0 ath9k_common 25638 1 ath9k ath9k_hw 460416 2 ath9k_common,ath9k ath29397 3 ath9k_common,ath9k,ath9k_hw mac80211 697212 1 ath9k ath3k 13381 0 cfg80211 520257 4 ath,ath9k_common,ath9k,mac80211 bluetooth 486890 7 bnep,ath3k,btusb,rfcomm Rather than speculate, try to contact and consult with folks at http://linuxwireless.sipsolutions.net/en/users/Drivers/ath9k/#Mailing_list http://vger.kernel.org/vger-lists.html#linux-wireless Good luck Actually I'm not speculating, but hypothesizing. I tried manually connecting, but then as fast as possible after resume and I get the same problem as with autoconnect. So apparently, manual connect is working good, when attempted 5 sec or after resume. This leads me to believe that 'something is busy' without networkmanager knowing it. A network scan is what comes to mind. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Doesn't reconnect to wifi after resuming from suspend
poma wrote: On 05.02.2015 22:00, Ferry Toth wrote: poma wrote: On 05.02.2015 20:12, Ferry Toth wrote: Would that be after a certain kernel? But I used 14.04 with kernel 3.17 (no problem) and 14.10 with 3.17 (and now 3.18) See if it can help https://wireless.wiki.kernel.org/en/users/drivers/ath9k/bugs Thanks by I don't find my case there. /etc/systemd/system/ath9k-reload.service [Unit] Description=Reload Atheros 802.11n wireless LAN cards driver After=hibernate.target suspend.target hybrid-sleep.target [Service] Type=oneshot ExecStart=/usr/sbin/modprobe -r ath9k ExecStart=/usr/sbin/modprobe ath9k [Install] WantedBy=hibernate.target suspend.target hybrid-sleep.target # systemctl enable ath9k-reload.service # systemctl suspend RESUME # systemctl hibernate THAW # systemctl hybrid-sleep RESUME||THAW Does it work? Actually no, it doesn't. I already suspected that as I tried other similar (non-systemd) scripts that restart stuff on resume. With this script, it doesn't even autoreconnect on boot (which did work before). I am starting to believe that after the drivers go up, an event scan is started, and the ath9k incorrectly reports that it is done (but might not be, as I have 2.4G and 5G and am trying to reconnect to the 5G). Just restarting drivers won't fix this (if it is indeed so). I need a delay after resume and scan, and before the autoconnect starts. BTW when I do: lsmod | grep ath ath9k 162133 0 ath9k_common 25638 1 ath9k ath9k_hw 460416 2 ath9k_common,ath9k ath29397 3 ath9k_common,ath9k,ath9k_hw mac80211 697212 1 ath9k ath3k 13381 0 cfg80211 520257 4 ath,ath9k_common,ath9k,mac80211 bluetooth 486890 7 bnep,ath3k,btusb,rfcomm ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Doesn't reconnect to wifi after resuming from suspend
poma wrote: On 05.02.2015 20:12, Ferry Toth wrote: Would that be after a certain kernel? But I used 14.04 with kernel 3.17 (no problem) and 14.10 with 3.17 (and now 3.18) See if it can help https://wireless.wiki.kernel.org/en/users/drivers/ath9k/bugs Thanks by I don't find my case there. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Doesn't reconnect to wifi after resuming from suspend
Dan Williams wrote: On Tue, 2015-02-03 at 23:15 +0100, Ferry Toth wrote: On my home wifi network I have 1 2.4GHz and 1 5GHz AP (is actually 1 fritz box). With one machine (chromebook running kubuntu 14.10 and AR9462 abgn wifi) When automatically reconnecting to 5GHz after resume half of the time the connection fails and retries indefinitely. It seems to fail more when moving the laptop to another location in house while it sleeps (so the list of visible networks actually changes). When this happens it is almost impossible to reconnect manually. (what works sometimes is disconnecting the connection that is building, disable the wifi, enable again, wait a bit then manually connect to the other (2.4GHz) AP) Strangely: disabling autoconnect on resume and then manually connecting always works. Other strange thing: Another machine (NUC with intel wifi and same kubuntu 14.10) always works. To me, it seems to be some interference between rescanning and connecting. I have no idea what is the difference in the state machine when autoconnecting vs. manual. I've provided log's on bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=726121 I updated the bug with some thoughts after looking at the logs. It looks to me like the issues are exclusively driver and/or supplicant problems. In the failed automatic log, the access point and the device don't agree on state, so the access point rejects the device. That starts a reconnect attempt which then apparently fails at the driver level because the AP never responds to teh driver's association attempts. Later on, the supplicant enters the scanning state but has to time that out because the driver never notifies the supplicant that the scan has finished. Even later, the supplicant screws up by trying to associate with 00:00:00:00:00:00 and then it simply falls over. One thing you could do is try to set up a resume-time script that just does 'rmmod ath9k; modprobe ath9k' and see if that fixes most of your issues; if so then it's usually an indication of driver bugs. Given that iwlwifi works fine on the machine, I think the issues are specific to the ath9k driver, and not the mac80211 stack (which iwlwifi also uses). Dan I did a quick test: 1 - close the lid (suspend) 2 - open the lid (resume) 3 - login as quickly as possible ( 2sec) 4 - manually connect the wifi (1sec) The connection then fails the same as with auto reconnect. So it looks as if the autoreconnect fails because it starts too early after resume. Might it be that it starts connecting too early because it thinks the scan is completed although it really is not? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Doesn't reconnect to wifi after resuming from suspend
Dan Williams wrote: On Tue, 2015-02-03 at 23:15 +0100, Ferry Toth wrote: On my home wifi network I have 1 2.4GHz and 1 5GHz AP (is actually 1 fritz box). With one machine (chromebook running kubuntu 14.10 and AR9462 abgn wifi) When automatically reconnecting to 5GHz after resume half of the time the connection fails and retries indefinitely. It seems to fail more when moving the laptop to another location in house while it sleeps (so the list of visible networks actually changes). When this happens it is almost impossible to reconnect manually. (what works sometimes is disconnecting the connection that is building, disable the wifi, enable again, wait a bit then manually connect to the other (2.4GHz) AP) Strangely: disabling autoconnect on resume and then manually connecting always works. Other strange thing: Another machine (NUC with intel wifi and same kubuntu 14.10) always works. To me, it seems to be some interference between rescanning and connecting. I have no idea what is the difference in the state machine when autoconnecting vs. manual. I've provided log's on bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=726121 I updated the bug with some thoughts after looking at the logs. It looks to me like the issues are exclusively driver and/or supplicant problems. In the failed automatic log, the access point and the device don't agree on state, so the access point rejects the device. That starts a reconnect attempt which then apparently fails at the driver level because the AP never responds to teh driver's association attempts. Later on, the supplicant enters the scanning state but has to time that out because the driver never notifies the supplicant that the scan has finished. Even later, the supplicant screws up by trying to associate with 00:00:00:00:00:00 and then it simply falls over. One thing you could do is try to set up a resume-time script that just does 'rmmod ath9k; modprobe ath9k' and see if that fixes most of your issues; if so then it's usually an indication of driver bugs. Given that iwlwifi works fine on the machine, I think the issues are specific to the ath9k driver, and not the mac80211 stack (which iwlwifi also uses). Dan Thanks Dan, Yes I already tried al that before reporting the bug. That's what some report (google) worked for them. First I thought it worked for me too. But alas, after these wakeup scripts automaically reconnect works sometimes, sometimes not, same as now, I agree it must have something to do with the driver, as the Intel always works. AND the same network manager (in Kubuntu 14.04) worked well, while in 14.10 not. To me it seems in 14.04 it also connected faster, so fast that when I opened the lid and passed the screen saver password I would be already connected ( 3 sec). OTOH NM state machine seems to get confused and does not recover. While when manually connect it always works. So it seems the code path on autoreconnect is different, or there is a bug in the state machine that only pops up immediately after resume. But you have a point: could it be the ath9k never notifies that the scan is ready? Would that be after a certain kernel? But I used 14.04 with kernel 3.17 (no problem) and 14.10 with 3.17 (and now 3.18) ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Doesn't reconnect to wifi after resuming from suspend
On my home wifi network I have 1 2.4GHz and 1 5GHz AP (is actually 1 fritz box). With one machine (chromebook running kubuntu 14.10 and AR9462 abgn wifi) When automatically reconnecting to 5GHz after resume half of the time the connection fails and retries indefinitely. It seems to fail more when moving the laptop to another location in house while it sleeps (so the list of visible networks actually changes). When this happens it is almost impossible to reconnect manually. (what works sometimes is disconnecting the connection that is building, disable the wifi, enable again, wait a bit then manually connect to the other (2.4GHz) AP) Strangely: disabling autoconnect on resume and then manually connecting always works. Other strange thing: Another machine (NUC with intel wifi and same kubuntu 14.10) always works. To me, it seems to be some interference between rescanning and connecting. I have no idea what is the difference in the state machine when autoconnecting vs. manual. I've provided log's on bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=726121 Any suggestions are highly appreciated. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: GSM modem via Bluetooth?
Op woensdag 24-11-2010 om 09:06 uur [tijdzone +0300], schreef Andrey
Borzenkov:
On Wed, Nov 24, 2010 at 6:55 AM, Dan Williams d...@redhat.com wrote:
On Sat, 2010-11-20 at 23:28 +0300, Andrey Borzenkov wrote:
On Sat, Nov 20, 2010 at 1:24 AM, Dan Williams d...@redhat.com wrote:
On Thu, 2010-11-04 at 15:33 +0300, Andrey Borzenkov wrote:
I have Nokia E51 and am using KDE with bluedevil; Modemmanager 0.4 and
NM 0.8.2-rc1. I can browse phone and transfer files, but modemmanager
does not display any available device when BT is activated. Is it
supposed to work at all and if yes, what is requires to get it
working? Pointers to documentation is appreciated. Thank you!
Getting this working first requires adding a connection for the
device, since we can't scan for it. Once the connection is added and
known to NM, it'll show up in the menu and you can choose it. While it
doesn't help you immediately with bluedevil, this is how we did the
gnome side of things:
http://blogs.gnome.org/dcbw/2009/07/10/unwire-with-networkmanager/
Yes, I know this but it does not really help to make it running using
Bordmittel.
OK, I have phone that exports DUN:
{pts/1}% sdptool search DUN
Inquiring ...
Searching for DUN on 00:24:03:BE:1A:29 ...
Service Name: Dial-Up Networking
Service RecHandle: 0x100c5
Service Class ID List:
Dialup Networking (0x1103)
Protocol Descriptor List:
L2CAP (0x0100)
RFCOMM (0x0003)
Channel: 4
Language Base Attr List:
code_ISO639: 0x454e
encoding:0x6a
base_offset: 0x100
Profile Descriptor List:
Dialup Networking (0x1103)
Version: 0x0100
As I understand, I need serial port that is used by ModemManager. I
now create serial port for the phone:
{pts/0}% sudo rfcomm bind 00:24:03:BE:1A:29 4
{pts/0}% ll /dev/rfcomm0
crw-rw 1 root dialout 216, 0 Ноя 20 23:22 /dev/rfcomm0
But this port is ignored by ModemManager:
{pts/0}% dbus-send --print-reply --system
--dest=org.freedesktop.ModemManager /org/freedesktop/ModemManager
org.freedesktop.ModemManager.EnumerateDevices
method return sender=:1.10 - dest=:1.315 reply_serial=2
array [
]
So what is missing in this case? Thank you!
You don't actually need to create the rfcomm port yourself. NM will
create that on-the-fly when starting up DUN for the device. Since we
cannot scan for devices with Bluetooth (takes way too long and
interrupts existing connections) NM requires that a 'connection' already
be defined for a phone before you can use it; that connection stores
various config we want to know before connecting (like the BT address!).
Yes, that was the missing bit; it is not documented anywhere clear
that such connection is required.
Here's how it works for GNOME desktops:
And for those who do not use Gnome?
I have the same problem. How do I get a connection in Kubuntu?
Installing gnome-bluetooth and following Dan's blog I don't get the
'Access the Internet using your mobile phone' checkbox.
What now?
Ferry
Anyway, I had to use rfcomm connect, not rfcomm bind; rfcomm
connect creates BT connection to phone that is happily recognized by
MM now and exported for NM use. But now NM was ignoring it :)
For testing I commented out the bits
/* If it was a Bluetooth modem and no bluetooth device claimed
it, ignore
* it. The rfcomm port (and thus the modem) gets created
automatically
* by the Bluetooth code during the connection process.
*/
if (driver !strcmp (driver, bluetooth)) {
nm_log_info (LOGD_MB, ignoring modem '%s' (no
associated Bluetooth device), ip_iface);
return;
}
and was able to finally connect without any obvious problems.
What is the reason for this ignorance :) ? If I understand
correctly, we are ignoring rfcomm because we are going to create it
ourselves. But by this logic if there is no pre-existing connection,
we will *not* create any rcomm in the first place. And if any
connection was defined for it, it would have claimed device before and
we would not reach this place at all. So if we are here, we see serial
connection to BT modem ready for us; why not let user to just use it?
___
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: NM-vpn no vpn secrets
Yes, the X.509 Certificates method is used. The Certificate requires a key, the Key file has no password. The results is that about once in 5 tries the connection gets established, possibly depending on the time between retries. The workaround just switches to X.509 with password, changes no other settings, and I fill in a bogus username and password as Anton suggests. Now the connection always is established in one try. --- Ferry Toth Oranjeplantage 34 2611 TK Delft Nederland Tel: +31(15)2133191 On wo, 2010-01-20 at 15:05 -0800, Dan Williams wrote: On Wed, 2010-01-20 at 23:36 +0100, Ferry Toth wrote: Dan, Yes I deleted that. What was before were the messages that you get when successfully establishing a VPN connection. SIGTERM[hard,] happens because I manually close the vpn at that point. I assumed those log before were not that interesting. BTW Anton Lindström found a work around the problem Anton Lindström wrote on 2009-12-04: #97 (https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/453807), transcription follows: Just want to comment that I have found a workaround for network-manager-openvpn: Instead of selecting authentication type Certificate (TLS) (I'm translating this to English so it might not be exactly the same) I select Password with certificate (TLS). Then I fill in a bogus username and password. Ok, I assume that you are using a TLS connection and the private key is *not* protected iwth a password? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM-vpn no vpn secrets
Dan, Yes I deleted that. What was before were the messages that you get when successfully establishing a VPN connection. SIGTERM[hard,] happens because I manually close the vpn at that point. I assumed those log before were not that interesting. BTW Anton Lindström found a work around the problem Anton Lindström wrote on 2009-12-04: #97 (https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/453807), transcription follows: Just want to comment that I have found a workaround for network-manager-openvpn: Instead of selecting authentication type Certificate (TLS) (I'm translating this to English so it might not be exactly the same) I select Password with certificate (TLS). Then I fill in a bogus username and password. This works for me for now. --- Ferry Toth Oranjeplantage 35 2611 TK Delft Nederland Tel: +31(15)2133191 -Oorspronkelijke bericht- Van: Dan Williams d...@redhat.com Aan: Ferry Toth ft...@telfort.nl Cc: networkmanager-list@gnome.org Onderwerp: Re: NM-vpn no vpn secrets Datum: Wed, 20 Jan 2010 13:00:04 -0800 On Fri, 2009-12-18 at 09:09 +0100, Ferry Toth wrote: Hello Dan Doing as you told (killing and starting the service as sudo) i have the following results: The error message from nm-applet is that the vpn-service can not b e started. When this happens there are no messages in the terminal. When I retry this a few times then hundreds of messages appear and the vpn connection is setup normally. I think this will not be to interresting. Finally closing vpn and then try to reopen gives the following: Fri Dec 18 09:04:09 2009 us=69544 SIGTERM[hard,] received, process exiting Fri Dec 18 09:04:09 2009 us=70616 PKCS#11: pkcs11_terminate - entered Fri Dec 18 09:04:09 2009 us=70716 PKCS#11: pkcs11h_terminate entry Fri Dec 18 09:04:09 2009 us=70758 PKCS#11: Removing providers Fri Dec 18 09:04:09 2009 us=70795 PKCS#11: Releasing sessions Fri Dec 18 09:04:09 2009 us=70829 PKCS#11: Terminating slotevent Fri Dec 18 09:04:09 2009 us=70864 PKCS#11: _pkcs11h_slotevent_terminate entry Fri Dec 18 09:04:09 2009 us=70899 PKCS#11: _pkcs11h_slotevent_terminate return Fri Dec 18 09:04:09 2009 us=70933 PKCS#11: Marking as uninitialized Fri Dec 18 09:04:09 2009 us=70983 PKCS#11: pkcs11_terminate - return ** Message: info Connect timer expired, disconnecting. Do you get anything from openvpn *before* the SIGTERM[hard,] bits? We're more interested in what happens before that. Dan ** (process:20896): WARNING **: WARN connect_timer_expired(): Disconnect failed: Could not process the request because no VPN connection was active. ** Message: info Connect timer expired, disconnecting. Op donderdag 17-12-2009 om 14:54 uur [tijdzone -0800], schreef Dan Williams: /usr/lib/network-manager-openvpn/nm-openvpn-service ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM-vpn no vpn secrets
Hello Dan Doing as you told (killing and starting the service as sudo) i have the following results: The error message from nm-applet is that the vpn-service can not b e started. When this happens there are no messages in the terminal. When I retry this a few times then hundreds of messages appear and the vpn connection is setup normally. I think this will not be to interresting. Finally closing vpn and then try to reopen gives the following: Fri Dec 18 09:04:09 2009 us=69544 SIGTERM[hard,] received, process exiting Fri Dec 18 09:04:09 2009 us=70616 PKCS#11: pkcs11_terminate - entered Fri Dec 18 09:04:09 2009 us=70716 PKCS#11: pkcs11h_terminate entry Fri Dec 18 09:04:09 2009 us=70758 PKCS#11: Removing providers Fri Dec 18 09:04:09 2009 us=70795 PKCS#11: Releasing sessions Fri Dec 18 09:04:09 2009 us=70829 PKCS#11: Terminating slotevent Fri Dec 18 09:04:09 2009 us=70864 PKCS#11: _pkcs11h_slotevent_terminate entry Fri Dec 18 09:04:09 2009 us=70899 PKCS#11: _pkcs11h_slotevent_terminate return Fri Dec 18 09:04:09 2009 us=70933 PKCS#11: Marking as uninitialized Fri Dec 18 09:04:09 2009 us=70983 PKCS#11: pkcs11_terminate - return ** Message: info Connect timer expired, disconnecting. ** (process:20896): WARNING **: WARN connect_timer_expired(): Disconnect failed: Could not process the request because no VPN connection was active. ** Message: info Connect timer expired, disconnecting. Op donderdag 17-12-2009 om 14:54 uur [tijdzone -0800], schreef Dan Williams: /usr/lib/network-manager-openvpn/nm-openvpn-service ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM-vpn no vpn secrets
I am on Karmic. Actually if a try multiple times to connect after 3 attempts (or so) it will connect. Tried the suggestion below, but Karmic also does not use libexec. I have no idea how to start up the service on Karmic. Any suggestions? Ferry Op woensdag 16-12-2009 om 17:27 uur [tijdzone -0800], schreef Dan Williams: On Sun, 2009-12-06 at 22:55 +0100, Ferry Toth wrote: I confirm this issue. However in my sometimes NM connects to the vpn (openvpn) without problems and sometimes is doesn't. This does not depend on the openvpn server as other machines work fine,as well a previous version of nm-applet. I my case I have a CA cert, a certificate and a key cert (which does not need a password). It may be a problem with the state machine of the networkwork manager? If you want more information about the problem, you can (as root): 1) killall -TERM nm-openvpn-service 2) OPENVPN_DEBUG=1 /usr/libexec/nm-openvpn-service (or wherever it's at on your system, Debian doesn't use libexec) and then try to connect. It'll spew out a load of debugging information which is necessary to figure out what's going wrong. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM-vpn no vpn secrets
I confirm this issue. However in my sometimes NM connects to the vpn (openvpn) without problems and sometimes is doesn't. This does not depend on the openvpn server as other machines work fine,as well a previous version of nm-applet. I my case I have a CA cert, a certificate and a key cert (which does not need a password). It may be a problem with the state machine of the networkwork manager? -- Ferry Toth -Oorspronkelijke bericht- Van: Dan Williams d...@redhat.com Aan: Alexander Sack a...@ubuntu.com Cc: Neal Becker ndbeck...@gmail.com, networkmanager-list@gnome.org Onderwerp: Re: NM-vpn no vpn secrets Datum: Fri, 04 Dec 2009 12:24:13 -0800 Nieuwsgroepen: gmane.linux.network.networkmanager.devel On Thu, 2009-12-03 at 12:34 +0100, Alexander Sack wrote: On Wed, Dec 02, 2009 at 07:17:46PM -0500, Neal Becker wrote: On Wednesday 02 December 2009, Dan Williams wrote: What appears to be the issue here is that you haven't set any secrets in the connection editor the VPN. That means passwords, shared keys, etc. Or that the secrets didn't pass validation. When you open the connection editor, are your passwords still there? If you're not entering any, are you asked for a password when you connect? Dan I entered the certificates. Same as I use to start openvpn manually. No password is needed, and none is entered into 'Private key password' field (if that's what you mean). I don't know if it's a permission issue. The private key can only be read as root (but of course, that's normal). I remember that there was a bug about not being able to configure VPNs that have no password. maybe thats the case here? Maybe just an overly strict settings verify? NetworkManager in general does not support unencrypted private keys because these configurations are not secure. You'll want to encrypt your private key using openssl and provide a private key password. Your private key password is stored securely in the keyring. I've recently added some UI to nm-applet/nm-connection-editor that warn you if the private key is not encrypted, and we should probably add that same UI to nm-openvpn. In any case, nm-openvpn should not enable the Apply button unless a private key is entered, which doesn't seem to be the case. I'll fix that. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network manager and GSM IrDA connection
I have Ubuntu Karmic which comes with 0.8. The serial port driver is ks_959 (Kingsun dongle). The driver loads automatically, then I need to irattach and load ircomm_tty and sir stuff. I have seen that modprobing these drivers does not trigger modemmanager. However it the dongle is plugged in on boot modemmanager does start and starts to probe the ircomm port. This is the wrong one as the Kingsun only supports sir and not fir. And apparently the init.d scripts do a little extra so that modemmanager starts. But I'll try your suggestions and report back. Thanks, -- Ferry Toth -Oorspronkelijke bericht- Van: Dan Williams d...@redhat.com Aan: Ferry Toth ft...@telfort.nl Cc: networkmanager-list@gnome.org Onderwerp: Re: network manager and GSM IrDA connection Datum: Tue, 17 Nov 2009 14:04:10 -0800 On Thu, 2009-11-12 at 22:07 +0100, Ferry Toth wrote: I have a GSM with GPRS that connects using IrDA. I can setup a connection manually, but I need it to be done by network manager as that notifies my applications an internet connection is available. I can not find how to configure nm so that it is notified that irda is up, so that nm can start the pppd. What I am trying to achieve is let udev do the work for setting up the irda connection, but don't know how nm is triggered. Do I need to send a dbus message? NM 0.7 or 0.8? With NM 0.7, a callout helper is used to probe the device for its capabilities when the serial port shows up. But the prober is limited to known mobile broadband devices, and IrDA isn't one of them. You'll need to find out the driver for your irda serial port (it's probably ircomm_tty) and then add that to this line in /lib/udev/rules.d/77-nm-probe-modem-capabilities.rules : # Only probe known mobile broadband drivers DRIVERS==option|sierra|hso|cdc_acm|qcserial|moto-modem, GOTO=probe That will cause NM to probe the port for mobile broadband support when the port shows up, so make sure your phone is on and it's all connected and everything. For NM 0.8, ModemManager is used and it'll just probe every serial port at the moment (we'll fix that). Here, make sure it all works by stopping NM and modem-manager, then run modem-manager --debug and get the irda port set up and see if ModemManager find it. If not, we can try to debug from there. I'm not sure about natively supporting IrDA since that seems to be going out, but if the patches aren't huge it's probably a win. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
network manager and GSM IrDA connection
I have a GSM with GPRS that connects using IrDA. I can setup a connection manually, but I need it to be done by network manager as that notifies my applications an internet connection is available. I can not find how to configure nm so that it is notified that irda is up, so that nm can start the pppd. What I am trying to achieve is let udev do the work for setting up the irda connection, but don't know how nm is triggered. Do I need to send a dbus message? Or am I on the wrong path here. Thanks in advance, Ferry ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
