Re: new ip settings method acceptibility

[Pavel Simerda <psimerda redhat com>]

> On Tue, Aug 14, 2012 at 9:11 AM, Pavel Simerda <psimerda redhat com>
> wrote:
> >> I'm considering adding a new method for ip settings and I'd like
> >> some
> >> input before I go write the whole thing. Primarily, I'm wondering
> >> if
> >> this feature would have any chance of being merged since it will
> >> have
> >> very few users. My method accomplishes a similar thing to the
> >> "shared"
> >
> > I'm afraid you would have better chance with options tweaking the
> > 'shared'
> > method if you need some tweaking at all. Misusing the 'method' for
> > corner
> > cases has little chance to be accepted.
> >
> 
> I disagree that this would be a misuse; care to elaborate?

Sure. Methods are for everyday use. You want to have standard automatic
connection? It's there. You want to have static configuration? There.
You want to act as a router instead? Use shared.

Method in NetworkManager is the basic mode of function. Tweaks for specific
use cases can be done with various options for tweaking the IP config. If
it's 'something like shared', it should probably be 'shared'.

> I do agree that it is a corner case, which is why I'm asking now.

Corner cases are best handled by tweaking the method with more options,
is it good enough for you?

> The reason I'm
> considering NetworkManager is because I was about to implement my own
> manager, but it replicated much of NM's functionality. Hopefully once
> people get a clear picture of what I'm trying to do and why I'm doing
> it, we can settle on an answer of whether this would be welcome or
> not.

My impression is that... if there is a good use case for that, it should
be possible to do it with keyfile configuration. Whether it gets to the
GUI and/or conf plugins would be the next question.

> > The 'shared' method is about providing network connectivity. I
> > don't understand
> > whether you are going to provide network connectivity or connect to
> > a network.
> 
> It's both. I am connecting to a cellular wireless network and
> providing that connectivty to another network (which is almost always
> a single device).

Method is bound to a connection, most connections are bound to a device,
this is not an exception. So we are talking about two connections here.

The 'shared' method applies to just one connection while using information
from the 'default routing' connection.

> > There is not such a big difference between wireless and ethernet
> > connections. Their IP configuration is managed the same way.
> >
> 
> It's a big difference when the wireless connection is PPP,

Then please treat my words as referring to wireless ethernet and
wired ethernet instead.

> > So you recieve a DHCP address and you won't use it as the interface
> > address? Why?
> >
> 
> A large number of my clients use custom APNs to get specific
> addresses
> to specific endpoints. They use my device because their equipment
> doesn't know how to use cellular cards; my device does the actual
> connection, then gives that address to the client. I cannot route
> packets to a host that has my IP address unless I use rediculous
> netfilter rules to trick the routing process.
> 
> >> a different address is added the to interface instead
> >
> > How is it determined?
> >
> 
> There is a default RFC 1918 address, but its configurable.
> 
> >> and the original
> >> address from the network is saved; dhcpd is configured to offer
> >> that
> >> single address on the other interfaces.
> >
> > Wouldn't bridging serve this purpose better?
> 
> PPP conections cannot be bridged with Ethernet.

Got it. We have a very special use case here. It's an embedded
device, a network equipment, that picks address by DHCP only to
forward it.

An end host (final DHCP client) wants to have connectivity. Therefore
it uses DHCP to get its address, prefix length and gateway (and DNS but
that's easy enough). Therefore your 'device' must reply to ARP requests
for gateway and must forward the packets (proxy_arp might work well for
this if you manage to forward the DHCP stuff). But you also want to
connect to internet services from the device parasiting on the end
host's IP address.

This is not a matter of adding another connection method, this sort of
configuration greatly affects configuration of two network connections
and requires very non-standard behavior.

NM doesn't currently fit well in black magic networking, OpenWRT used to
do slightly better. But if you can make this work well with NetworkManager,
it'll be a pleasant surprise for me.

For the first tests it might be helpful if NetworkManager can be tweaked
*not* to commit IP addresses to the interface. Your fake address and other
things could generally be done with dispatcher.d scripts. Many things can
be done with helper daemons and helper scripts.

It may happen that you will want to have your scenario working while we would
need a more generic solution (if one at all). Then we should find the best way
to let you use NM for whatever you want and only modify it in acceptable ways.

> > To me this looks much more complicated than it should be. What do
> > you
> > gain using this method instead of network sharing? (And also
> > instead
> > of bridging that is planned for NetworkManager?)
> 
> Network sharing does not give the downstream device the address that
> was intended for it.

It still seems to be rather complicated but now I at least understand the
use case. While I'm not convinced that we need another mode, and I'm not
convinced that we need a user-friendly way to set up your use case, I'll
be happy work out a way that makes NM usable for your use case at least with
some scripting and possibly an external tool.

Cheers,

Pavel