Re: new ip settings method acceptibility

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? I do agree
that it is a corner case, which is why I'm asking now. 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

>> connection method, but it's a little different. It will be called
>> "forwarded" or "proxied". It is used for connecting to a network on
>> behalf of another host.
> 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).

>> It's how I make my cellular wireless router
>> work in situations where I need to offer the wireless connection as
>> if
>> it was just a normal Ethernet 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, which is very common.

>> The setup involves connecting to a network normally, but not adding
>> the acquired (via PPP, DHCP, etc) address to the interface
> 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.

>> Additionally, an SNAT target
>> is added to the nat table's POSTROUTING chain so that this middle
>> device can also use the connection.
> 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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]