Re: suspend/deactivate devices in modem manager
Hi Dan
- Original Message -
From: Dan Williams d...@redhat.com
To: Mark Haack mark.ha...@werk55.de
Cc: networkmanager-list@gnome.org; Tambet Ingo tam...@gmail.com
Sent: Wednesday, January 20, 2010 10:17 PM
Subject: Re: suspend/deactivate devices in modem manager
On Mon, 2009-11-23 at 16:12 +0100, Mark Haack wrote:
Hi Dan
Hi Ingo
I'm looking for a way to disable particular devices in modem manager.
I.e.
(a) my application wants to handle a huwei device by it's own,
(b) without interupting the user for the configuration by the nm
applet, which means my app provides settings for it
As far I can see the device support is compiled into the mm as
plugins? Is there
a external, configuration (xml) file, which declares that product id +
vendor id belongs to a certain plugin.
The plugins each are responsible for detecting what devices they handle.
At this point it's a combination of driver name matching ('hso' for
example) and USB vid/pid matching. I generally stay away from
explicitly listing devices in udev rules files (like windows .INF files
always do) because that's a huge pain to maintain.
But given that most configurations are not going to have multiple mobile
broadband devices, perhaps your configurations don't want to run
ModemManager then?
Dan
you´re right. For my configuration I choose the following design.
I stop the networkmanager if app begins the operation and restart it after
all is done.
So in that case, there is no competition with each other. App can handles
all of its own, despite of all the wifi goodies in nm.
I would like to use more of nm, but there some missing crunch points
1. a modem manager fascade to use my own modem manager implementation
dynamically
2. or a plugin api for UI elements to customize it. (there is dbus okay, but
I cant stop annoying nm dialogs)
BR
Mark
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Augmenting mobile-broadband-provider-info
Hi - Original Message - From: Dan Williams d...@redhat.com To: Mark Haack mark.ha...@werk55.de Cc: Marcel Holtmann mar...@holtmann.org; Antti Kaijanmäki antti.kaijanm...@nomovok.com; networkmanager-list@gnome.org Sent: Wednesday, January 20, 2010 10:15 PM Subject: Re: Augmenting mobile-broadband-provider-info On Mon, 2009-11-23 at 12:15 +0100, Mark Haack wrote: Hi - Original Message - From: Marcel Holtmann mar...@holtmann.org To: Antti Kaijanmäki antti.kaijanm...@nomovok.com Cc: networkmanager-list@gnome.org Sent: Monday, November 23, 2009 10:30 AM Subject: Re: Augmenting mobile-broadband-provider-info Hi Antti, Do you mean the international dial code like +1 for the US, etc? We could do this. Yes, that's what I mean. At least in the case of the timezone db, I think there's better places to put that. I realize not all platforms use glibc, but I have to believe that even if you don't, there's going to be some timezone/locale information already on the system that it would be a shame to duplicate. Ok, I agree with that. Could we at least add countries and provider's that do not necessarily offer mobile broadband but just telephony? A mapping from MCC MNC to country and provider name can be helpful in various ways. Please pay attention to it, because country name by standards only fits 98% of the real world. I.E. you have this little isles near UK or think of Palestine Networks. Sometimes you also need extra geo information to display i.E. india with all of its regions. for quick reference I usually use http://www.numberingplans.com/?page=planssub=imsinr I agree. This would turn m-b-p-i into cellular-provider-info. When we are now talking about augmenting, I would like to make some proposals also. I would like to have optional network-name field added to gsm section. Virtual providers use same parent networks with same mcc/mnc pairs and there's no way telling them a part. Here's an example with two Finnish operators which both operate on DNA network: DNA: at+cops=0,2 at+cops? +COPS: 0,2,24412,2 GoMobile: at+cops=0,2 at+cops? +COPS: 0,2,24412,2 Fortunately each provider conveniently happens to claim they own the network they are operating in: DNA: at+cops=0,0 at+cops? +COPS: 0,0,dna,2 GoMobile: at+cops=0,0 at+cops? +COPS: 0,0,go.mobile,2 We can use this long alphabetical format of the network to identify the virtual providers from each other: provider nameDna/name gsm network-namedna/network-name network-id mcc=244 mnc=12/ apn value=internet dns217.78.192.22/dns dns217.78.192.78/dns /apn /gsm /provider provider nameGoMobile/name gsm network-namego.mobile/network-name network-id mcc=244 mnc=12/ apn value=internet.gomobile.fi dns217.78.192.22/dns dns217.78.192.78/dns /apn /gsm /provider This allows us to automatically select the correct provider. Any thoughts? you can't trust the network name string returned by AT+COPS since there are so many factors coming into play here. So first of all you have the names stored in the modem itself, then the names stored on the SIM card and then the potential updates over the network. Every hardware does different things to present the result of AT+COPS. And to make it even more complex, in case of roaming situations some devices actually to weird concat of home network and current network. To blow on the fire, in (if I remember right) i.e. US Cingular there is a technical roaming without actual charge, because the subnets belong to each other. Which means on technical level there is roaming, which is reported by +creg, but it is not the right business logic, which belongs to the user domain. T-Mobile US has completely free GPRS/EDGE roaming for their prepaid customers throughout the US, on a variety of providers. Like you say, the roaming logic is really in the billing systems and that's not something that's easy to track. ATT phones will also spoof the provider name shown on the phone and always show ATT even if you're roaming on some other provider. I guess it is still possible to track business logic. 1. We can identify SIM Card 2. Even if PLMN is spoofed it is ATT so we know it is free for prepaid customer anyway The main challenge is to put all the logic into code, db or whatever and maintenance of it would be very weird. BR Mark Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org
Re: http-proxy with Open-VPN
Darren Albers wrote: On Wed, Jan 20, 2010 at 6:04 PM, Dan Williams d...@redhat.com wrote: On Wed, 2010-01-20 at 23:41 +0100, Tomas Kovacik wrote: Dan Williams wrote: On Wed, 2009-12-16 at 21:23 -0500, Darren Albers wrote: Is there an option in GConf to set the Open-VPN plugin to use a proxy? Not yet... Need some proxy support in the UI first I think, though I'd probably take a patch adding the appropriate GConf bits for proxy assuming they're not too horrid. Dan reinventing a wheel? :) I sent patch couple month ago, for latest ubunttu 9.10: *https://launchpad.net/~nail-nodomain/+archive/ppa/+packages patch is debian/patches/01_http_proxy.diff, it's not applied directly in source, so you can use it if you want Bah, sorry. Any chance you can attach the patch to https://bugzilla.gnome.org/show_bug.cgi?id=440031 for me? Thanks, Dan Tomas, does your patch add a Gconf entry or is it in the GUI? If it is a GConf Entry what should that entry be? Thank you! both, if it's in gui it must be also in gconf, no? :) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: http-proxy with Open-VPN
Dan Williams wrote: On Wed, 2010-01-20 at 23:41 +0100, Tomas Kovacik wrote: Dan Williams wrote: On Wed, 2009-12-16 at 21:23 -0500, Darren Albers wrote: Is there an option in GConf to set the Open-VPN plugin to use a proxy? Not yet... Need some proxy support in the UI first I think, though I'd probably take a patch adding the appropriate GConf bits for proxy assuming they're not too horrid. Dan reinventing a wheel? :) I sent patch couple month ago, for latest ubunttu 9.10: *https://launchpad.net/~nail-nodomain/+archive/ppa/+packages patch is debian/patches/01_http_proxy.diff, it's not applied directly in source, so you can use it if you want Bah, sorry. Any chance you can attach the patch to https://bugzilla.gnome.org/show_bug.cgi?id=440031 for me? Thanks, Dan done. t. ___ 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: Problem to add a broadband connection on NetworkManagerUserSettings
Hi guys, I tried with SystemSettings before use UserSettings and really works, but when you create a connection with SystemSettings, it's marked as Available for all users, and when you use this kind of connection, you just can use once, the second time crashes the system, there is a lot of issues opened on launchpad about it, because of that I need to use UserSettings. Happens for broadband and DSL connections, may be to wireless too, it's not just about connections created with my own code, I tried with nm-applet, if you check available for all uses, don't works. If someone knows some workaround to get SystemSettings working, I can use it. Thanks guys for your help, and sorry again about the Legal message, it's not my faul, but I'll start use other email. Maxwell On Tue, 2010-01-19 at 16:45 +0100, Jirka Klimes wrote: On Wednesday 13 January 2010 16:33:27 Maxwell Chiareli Xandeco wrote: I'm using Ubuntu 9.10, with your code I don't get errors but a connection is not added, nothing happens when I call AddConnection method. I've investigated it a bit and found out that AddConnection is not supported via D-Bus due to security reasons. (src/gconf-helpers/nma-gconf-settings.c:add_connection() function) If you use SystemSettings service instead of UserSettings, the connection adding will work (just keyfile plugin). Jirka Legal Disclaimer: The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Augmenting mobile-broadband-provider-info
Am Mittwoch, den 20.01.2010, 16:02 -0600 schrieb Denis Kenzior: I've seen this happen on the Freerunner. Immediately after registering COPS returns Cingular, 5 minutes later it will return ATT. Yes, if the EONS tables are complete and not damaged (seen that a lot on various SIMs), it will transparently transform MCCMNC using this info. Ultimately the SIM is the one to trust here, not COPS or any other combination of COPS/CREG, etc. Much of the COPS/CREG information can be ultimately overridden by the contents of the SIM elementary files like EFspn, EFspdi, EFehplmn, EFehplmnpi, EFpnn, EFopl, etc. Of course various stacks / modems get this right in varying degrees of correctness. Right, still having a fallback in the database for modems which do not allow to use of any alphanumerical information would be much appreciated, i.e. do we agree that s/mobile-broadband-provider-info/mobile-provider-info/g would be feasible? -- :M: ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Augmenting mobile-broadband-provider-info
On Thu, 2010-01-21 at 17:59 +0100, Michael 'Mickey' Lauer wrote: Am Mittwoch, den 20.01.2010, 16:02 -0600 schrieb Denis Kenzior: I've seen this happen on the Freerunner. Immediately after registering COPS returns Cingular, 5 minutes later it will return ATT. Yes, if the EONS tables are complete and not damaged (seen that a lot on various SIMs), it will transparently transform MCCMNC using this info. Ultimately the SIM is the one to trust here, not COPS or any other combination of COPS/CREG, etc. Much of the COPS/CREG information can be ultimately overridden by the contents of the SIM elementary files like EFspn, EFspdi, EFehplmn, EFehplmnpi, EFpnn, EFopl, etc. Of course various stacks / modems get this right in varying degrees of correctness. Right, still having a fallback in the database for modems which do not allow to use of any alphanumerical information would be much appreciated, i.e. do we agree that s/mobile-broadband-provider-info/mobile-provider-info/g would be feasible? I don't mind adding more information like marking WAP APNs, per-APN proxies, SMS center, MMS, etc. We'll need to extend the schema but that's easy enough. WRT substituting provider names in COPS responses when the modem doesn't have the name, the best I think we can do is back-map the MCC/MNC to a list of providers, or query the SIM for more correct information. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem to add a broadband connection on NetworkManagerUserSettings
On Thu, 2010-01-21 at 10:15 -0200, Maxwell Chiareli Xandeco wrote: Hi guys, I tried with SystemSettings before use UserSettings and really works, but when you create a connection with SystemSettings, it's marked as Available for all users, and when you use this kind of connection, you just can use once, the second time crashes the system, there is a That's a bug then; I fixed one specific bug with nm-connection-editor caused by an older version of the polkit-gnome packages. We'd need more logs, pointers to logs, stacktraces, or Launchpad links to figure that out. It's probably a bug, and we need to figure out more details before we can fix it. lot of issues opened on launchpad about it, because of that I need to use UserSettings. That's somewhat unfortunate, because for a variety of security reasons programs themselves are not allowed to change network information via the D-Bus interface. You can however use GConf (see gconftool-2 --import) to do this if you really need to. Dan Happens for broadband and DSL connections, may be to wireless too, it's not just about connections created with my own code, I tried with nm-applet, if you check available for all uses, don't works. If someone knows some workaround to get SystemSettings working, I can use it. Thanks guys for your help, and sorry again about the Legal message, it's not my faul, but I'll start use other email. Maxwell On Tue, 2010-01-19 at 16:45 +0100, Jirka Klimes wrote: On Wednesday 13 January 2010 16:33:27 Maxwell Chiareli Xandeco wrote: I'm using Ubuntu 9.10, with your code I don't get errors but a connection is not added, nothing happens when I call AddConnection method. I've investigated it a bit and found out that AddConnection is not supported via D-Bus due to security reasons. (src/gconf-helpers/nma-gconf-settings.c:add_connection() function) If you use SystemSettings service instead of UserSettings, the connection adding will work (just keyfile plugin). Jirka Legal Disclaimer: The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message ___ 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
On Thu, 2010-01-21 at 10:26 +0100, Ferry Toth wrote: 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. Yeah, this is obviously sub-optimal for two reasons; (1) your private key is not encrypted and thus is vulnerable, and (2) the UI doesn't detect an unencrypted private key and handle it properly. Dan --- 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: suspend/deactivate devices in modem manager
On Thu, 2010-01-21 at 09:48 +0100, Mark Haack (werk55.de) wrote:
Hi Dan
- Original Message -
From: Dan Williams d...@redhat.com
To: Mark Haack mark.ha...@werk55.de
Cc: networkmanager-list@gnome.org; Tambet Ingo tam...@gmail.com
Sent: Wednesday, January 20, 2010 10:17 PM
Subject: Re: suspend/deactivate devices in modem manager
On Mon, 2009-11-23 at 16:12 +0100, Mark Haack wrote:
Hi Dan
Hi Ingo
I'm looking for a way to disable particular devices in modem manager.
I.e.
(a) my application wants to handle a huwei device by it's own,
(b) without interupting the user for the configuration by the nm
applet, which means my app provides settings for it
As far I can see the device support is compiled into the mm as
plugins? Is there
a external, configuration (xml) file, which declares that product id +
vendor id belongs to a certain plugin.
The plugins each are responsible for detecting what devices they handle.
At this point it's a combination of driver name matching ('hso' for
example) and USB vid/pid matching. I generally stay away from
explicitly listing devices in udev rules files (like windows .INF files
always do) because that's a huge pain to maintain.
But given that most configurations are not going to have multiple mobile
broadband devices, perhaps your configurations don't want to run
ModemManager then?
Dan
you´re right. For my configuration I choose the following design.
I stop the networkmanager if app begins the operation and restart it after
all is done.
So in that case, there is no competition with each other. App can handles
all of its own, despite of all the wifi goodies in nm.
I would like to use more of nm, but there some missing crunch points
1. a modem manager fascade to use my own modem manager implementation
dynamically
The ModemManager D-Bus API is specified and there's already alternative
implementations; you can certainly write your own service conforming to
the MM D-Bus API and NetworkManager will happily use it instead of
modem-manager itself.
2. or a plugin api for UI elements to customize it. (there is dbus okay, but
I cant stop annoying nm dialogs)
3. We can enhance ModemManager and the D-Bus API to provide the
functionality you require (within reason of course), which is my
preferred solution.
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH: passwordless TLS openvpn fails to connect with no VPN secrets
On Wed, 2010-01-20 at 21:26 -0300, Federico Heinz wrote: On 20/01/2010, Dan Williams wrote: On Mon, 2009-12-21 at 02:10 -0300, Federico Heinz wrote: The openVPN plugin for NetworkManager fails to connect to a passwordless TLS server, complaining of no VPN secrets. This happened because the code assumes that only static-key servers use no secrets, which isn't true. Only password and password+TLS require secrets. https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/453807 We'd need a bit more than that unfortunately. First, openvpn assumes that the TLS private key will have a password protecting it, in which case the patch isn't required. Indeed, this is true: if the key is password-protected, the connection succeeds. Second, if we do want to allow unencrypted private keys (a security hole) The security hole is relative, and it depends on the details of how the key is stored. A password does not provide much security beyond that of storing the file in an ecryptfs-encrypted directory, for instance. In any case, if you do decide that you don't want to enable non-encrypted keys, then at least the program should fail with a more informative message. The current No secrets message is hard to decypher for a normal user, something along the lines of Private key needs to be password-protected would be much more helpful. Better yet, the UI should not let the enter a plain text key in the dialog, instead of allowing such a misconfiguration and then refusing to use it. then we'd need code to verify that the private key the user has picked is indeed unencrypted before letting the UI enable the OK button. Any chance you'd be willing to work on that patch? Most of the code to do that is lying around since nm-applet needs to do the same thing for 802.1x TLS. I might, but first I'd hate to do the work to have it later rejected because the guardians of the project decided to do it differently (not accepting plaintext keys at all, for instance). If there is a clear decision about what the desired behaviour is, I'll look into it. Honestly I don't care. I'm fine with some code in the NM-openvpn UI to check the certificate file and determine if a private key password is required or not. I believe DER-format keys are always unencrypted (because they simply don't have the ability to specify the information necessary for decryption) but we can easily figure out of PEM format keys are encrypted or not by looking for the DEK-Info and Proc-Type tags in the OpenSSL header. We need remember to scan more than 10K or so of the file in case the private key is at the bottom of a bunch of certificates. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Re: NM forgets CA certificate
On Wed, 2010-01-20 at 12:35 -0500, Matthew Saltzman wrote: On Tue, 2010-01-19 at 22:12 -0800, Dan Williams wrote: On Wed, 2010-01-13 at 15:48 -0500, Matthew Saltzman wrote: I don't recall if I wrote before about this, but I don't think so. I've been thinking about it. I have a PEAP connection that requires a separate CA cert from the usual bundle. The first time I connect after a reboot, the connection always times out. When the configuration dialog pops up, it shows CA Any idea why it's timing out? Does /var/log/messages or wpa_supplicant debugging show anything interesting? I assume it times out because there's no cert--I get the same behavior if I have a bad cert instead. NM messages from this morning's failure, followed by correcting the cert, followed by success attached. If that's not enough, what steps do I follow to debug wpa_supplicant? Can you grab your ~/.xsession-errors right after you see this happening? I'd like to see if the applet spits out anything interesting. Dan certificate: (None). Opening the dialog allows me to select the cert Are all the other settings successfully preserved? Yes. Also, when I edit the security settings in the connection editor, the setting is already cleared, even though I haven't even disconnected. So it looks like it uses it, but never saves it. It does remember across suspend/relocate though. file and then the connection is fine (although the Wireless Security config window shows no cert), even across movements to another network and back, until the next boot or NM restart. What version of NM? $ rpm -q NetworkManager wpa_supplicant NetworkManager-0.7.997-2.git20091214.fc12.x86_64 wpa_supplicant-0.6.8-8.fc12.x86_64 $ uname -r 2.6.31.9-174.fc12.x86_64 Also, it seems that I should be able to use the cert as I got it from Entrust as a .cer or after conversion to a .der, but neither of those works for me (although it does work for others). I had to get someone to send me a .der that we knew worked, and I use that. You should be able to use it as a .cer actually; any chance you can reply with the contents of that certificate so I can find out why it's not recognized? Is it the case that it doesn't even show up in the file chooser? Actually, never mind about this part. It turns out that I had wrong instructions for where to get the cert. It's a standard Entrust end user 2048-bit. There used to be two on the site, and my instructions pointed at the wrong one. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout is too short for this college network
Hello Dan, thanks for your reply! There are various cases where the DHCP timeout is the amount of latency between NM timing out a legitimate failure and falling back to a working network. Ah, I was afraid it was something like this. That's unfortunate :( The cases where the DHCP latency is a problem are cases where we don't expect to get *any* OFFERs. So if we could figure out that some server sent an OFFER then we could extend the internal DHCP timeout in NetworkManager and hopefully handle your problem. From what I've seen, it looks like dhclient already does something similar. If I put timeout 45; in dhclient.conf and then run dhclient on a network where no DHCP servers are present (i.e. no OFFERs are received), then dhclient does indeed timeout in 45 seconds. However, as soon as it gets an OFFER, it seems that the 45 second countdown stops. dhclient then proceeds to try and get an ACK, and this process seems to be subject to a separate (hard coded?) timeout. If that fails, then dhclient returns to the DISCOVER stage and once again waits 45 seconds for an OFFER. So the good news is, dhclient is already setup so that it times out relatively quickly when DHCP servers are not present, and it's also willing to wait longer when dealing with lazy servers. The bad news is that this behavior is not well documented, and I don't know if there are any limits on how many times it will loop like this. If I were to hit a broken DHCP server that always sent OFFERs but never sent ACKs, it's possible that dhclient would never time out. But I'd argue that this would be a dhclient bug that may be worth fixing anyway. Any chance you'd like to poke around dhclient (including perhaps it's socket-based control interface?) and see if there's a way to get more information out of it? I skimmed the documentation about dhclient's OMAPI interface to see what controls are available. It doesn't look good. :( But I may yet be able to find something (undocumented?) that would help, if we do indeed go this route. Perhaps I'll read the dhclient source code, methinks that'll help :) Have a good one, Daniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
dbus-api examples
Hi is there any dbus-send api examples for Network manager for dial-up (pppd) to connect and disconnect. regards kiran ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
