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. 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? Dan > 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 > _______________________________________________ > networkmanager-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/networkmanager-list _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
