Re: Possibility to determine state of a connection

2013-02-13 Thread Martin Steuer

Am 13.02.2013 01:17, schrieb Dan Williams:

On Tue, 2013-02-12 at 21:18 +0100, Martin Steuer wrote:

I started using NetworkManager on a fresh installation of mine and
noticed a problem regarding PPPoE connections: When establishing a PPPoE
connection via ethernet an existing IP connection is disconnected. Thus
loosing IP connectivity on the local network.


This has been an issue for a long time in NM, and it needs to be
addressed in a more complete manner.  Basically, we need to run both the
original eth connection and the PPPoE one in parallel.  In reality, this
looks a lot like a VPN, and perhaps we should treat it as such.  Or,
really, it's just a tunnel like a VPN is a tunnel, and we should have a
more generic framework for handling tunnel interfaces.



Thats what I was thinking, VPN seems simliar in nature.


That would imply a change in behavior of NM as D-Bus clients would see
it, so perhaps this would have to wait a bit until we support multiple
VPN connections.  Which is something I'm happy to provide some guidance
on if anyone wants to work on it?



I'd be willing to invest some time, how involved would that be?


Dan



Martin
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Possibility to determine state of a connection

2013-02-12 Thread Martin Steuer
I started using NetworkManager on a fresh installation of mine and 
noticed a problem regarding PPPoE connections: When establishing a PPPoE 
connection via ethernet an existing IP connection is disconnected. Thus 
loosing IP connectivity on the local network.


This is obviously not necessary as these two connections can perfectly 
co-exist on a single device, both communicating via ethernet frames on 
the wire. While all hosts on the LAN are reachible via IP a machine may 
additionally create a connection with the DSL access concentrator thus 
providing internet connectivity.


At first I thought the observed behaviour might be a configuration 
problem on my end, but after further investigation I realized that this 
seems to be the standard behaviour of NetworkManager. A quick search on 
the net revealed that some, albeit not many, people had same problems.


Find attached a very simple but incomplete patch. As it currently is, it 
will not be really useful. While I can create a PPPoE session this way 
without interfering with an existing LAN connection on the same device 
it has issues when one tries to reconnect the PPPoE session while it is 
already established. This will result in a pppd which eventually fails 
after a timeout.


I do have the impression that it is not possible to check the state of
a connection. Instead, only a device does have a connection state, and I 
find this to be very limiting.

This forces the current implementation right at the point of my patch:
Even if a requested connection is already established, that one will be 
shut down, just to be brought back up again and it also makes it harder 
for connections to share a device.
If there was the possibility to check if a certain connection is already 
in place my patch could be made to work, and unneccessary reconnects 
could be avoided.


I do understand that the concept of connections is not bound to a 
certain device, this makes it even more important for the state 
information to be associated with a connection and not a device.


Is it correct that there is no connection state associated with a 
connection?

Would there be another way to achieve what I am after?

Thanks for your help!
Martin
diff --git a/src/nm-manager.c b/src/nm-manager.c
index 3dc60d8..25d74fc 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -2432,7 +2432,8 @@ internal_activate_device (NMManager *manager,
 		return NULL;
 
 	/* Tear down any existing connection */
-	if (nm_device_get_act_request (device)) {
+	if (nm_device_get_act_request (device) &&
+!nm_connection_is_type (connection, "pppoe")) {
 		nm_log_info (LOGD_DEVICE, "(%s): disconnecting for new activation request.",
 		 nm_device_get_iface (device));
 		nm_device_state_changed (device,
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list