Re: ppp and "offline state"

[Christopher Lang <christopher lang acurana de>]

Hi,

> Then, in the network connections menu, an item "externally managed
> connection"...

as stated in a similar post on lwn, I would like to strongly second the below. 
There are some folks out there who are working on proprietary/corporate 
connection managers (incuding myself) and currently NM just locks them out 
and causes them a lot of trouble.

A few small features could easily rectify the situation and I do not think 
that externally managed connections would cause too much trouble for NM:

- dbus method(s) that allows to make NM aware of a custom connection and its 
status
- A dbus method that allows external applications to tell NM to leave a 
particular device/interface alone

I think that nobody is asking to change major NM workings, just the very 
minimum to allow custom connections to co-exist, and avoid these troublesome 
Firefox, Evolution, resolv.conf etc. etc. issues.

thanks for your patience,
Chris

http://www.acurana.de/


On Monday 07 September 2009 12:53:58 Pietro Battiston wrote:
> By looking at bugs filed and words spent in several different bug
> trackers and mailing lists, I fear NM developers may be quite allergic
> to the words forming the subject of this email, but though indeed the
> problem gathered a big attention, I didn't find any (reasonably recent)
> documented answer to the three questions I'm asking, so here ends the
> prologue:
>
>
> 1) the most clear answer I found to the claim:
>
> "NM doesn't support generic ppp, so I must connect with
> $APP_TO_HANDLE_PPP_CONNECTION and NM doesn't notice it, so
> $APP_USING_NETWORK doesn't connect, thinking I'm disconnected"
>
> is at [0] and basically says:
>
> "nobody is working on it, if somebody would like to, please step in".
>
> This was obviously an admissible position; is it still true, or did the
> creation of MobileManager change future hopes of generic (or at least
> bluetooth) ppp support in NM? I ask it because the name of the project
> seems to suggest it, though in presenting it at [1], Dan only talks
> about "All mobile broadbands", and the same does the README.
>
>
> 2) supposing that answer to 1) is "no, people connecting via a
> traditional modem or a mobile via bluetooth shouldn't just hope NM
> supporting them soon", then wouldn't it make sense to allow _setting_,
> instead than just _querying_, online/offline status via DBUS?
>
> This would allow, with few lines of code, tools like Gnome-PPP to say
> "hey, NM, we _are_ online"[2]
>
> Then, in the network connections menu, an item "externally managed
> connection" could also possibly show up and activate...
>
> I perfectly understand this is not something NM developers dream of,
> being not part of the standard infrastructure, but it would be of huge
> help to those who - like me and many people I know of (BTW, from
> personal experience I frankly doubt about the 98% Alexander's estimate
> in [0]) - need to connect via bluetooth/standard modems (it may be OT,
> but let me mention that this is one of the few things Windows/OS X
> softwares do nicely since many years and Linux Desktop doesn't).
>
> I (don't know NM internals and) suppose some things may not work as
> usually: for instance, I can imagine sharing a connection would be a
> problem, if NM doesn't control it... but _this_ is really a minor
> problem.
>
>
> 3) Why was PPP generic support dropped? Because it was broken/lacking
> manpower or just because mobile broadband support covered many of the
> use cases of it?
>
>
> thanks for your patience in answering(/providing me pointers if the
> questions are indeed answered elsewhere).
>
> Pietro Battiston
>
> [0]
> http://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/220497/
> [1]
> http://blogs.gnome.org/dcbw/2009/03/20/thats-when-i-reach-for-my-revolver/
> [2]
> They could also say "hey, NM, we are online thanks to the process with
> pid $pid, assume we are online as long as it is alive!", or "we are
> online thanks to card ppp*, assume we are online until it exists!"...
> but this is not _so_ necessary, since it would be easy, for the calling
> app, to spawn a separate monitoring process which finally would say
> "hey, NM, control back to you" at the end of the connection.