Bruce M. Simpson
bms at incunabulum.net
Mon May 21 10:33:32 UTC 2007
Ozgur Ozdemircili wrote:
> I have a network of 10.10.10.0 and the gw is at 10.10.10.1. GW is
> giving out ip with DHCP. If the client pc is configured with DHCP they
> can get the ip from the server and go out to internet easily. But if
> the client has* static Ip configured*, for example 192.168.0.2 with gw
> 192.168.0.1, they cannot find the GW and cannot go out. I need the
> clients to be able to find the gw and *go out to internet without
> changing their ip configurations.
> I have searched for technology behind this and it seems like IPPNP is
> the solution. This technology is implemented in most of the hotspot
> gateways (nomadix, dlink etc)
This sounds like another buzzword that the vendors just made up when
everyone with a clue wasn't looking. Someone's created a Sourceforge
project for it which is still empty, and search engine matches find many
vendors describing this feature as 'unique'. The way it has been
verbally beaten on Linux related lists is something I can't disagree
The short answer is that this appears to be some kind of MAC based
gateway protocol; basically, an 'internet access device' (stub router
for home/small office) will forward any traffic it sees for a subnet
which it isn't configured with, by spoofing ARP traffic so as to make it
appear as though it is on that subnet.
This sounds like a configuration nightmare to implement correctly, and
goodness help you if you have more than one of these things connected to
the same network. Whilst it probably can be done in the network stack, I
speculate it couldn't be turned on at the same time as a number of other
features such as Proxy ARP, or CARP, and may have problems scaling to
more than a two-armed router (that is, 1 WAN uplink, and 1 Ethernet
interface running this stuff). It also seems to rely on a few
assumptions (subnet is a /24, and 0 is the subnetwork address). I think
it also assumes that the network is 802.1x or MAC address ACL
authenticated, and that clients are directly attached to the Layer 2
domain to which the interface which runs the quirk is attached.
I see no IETF standard for this quirk, and it doesn't seem to have been
as well thought out as the Zeroconf proposals.
So whilst it may seem like a quick fix, it would have to be implemented,
and the easiest thing for FreeBSD users to do in this situation is
probably just to configure a separate network alias on their internal
LAN interface -- something which is obviously more difficult to do with
the kind of device the quirk is intended for.
Now that I think on it, if IPv4 addresses are scoped, it might be
possible to implement a knob which says "All IPv4 addresses learned on
*this* interface have local scope", which in turn implies a 1:M NAT. It
relies of course on the NAT module e.g. pf being able to join the dots
and notice that an IP address outside of a configured subnet is being
used on that interface, however, it would stop the forwarding code doing
the wrong thing and forwarding the datagram back out the WAN interface
again after pf has demuxed the inbound datagram there.
To implement this feature properly requires that the forwarding code is
changed to allow it. The changes required are similar to those needed
for doing unnumbered IP. An interim solution could probably be
implemented in userland using bpf which would stash the appropriate
firewall rules to rewrite the outgoing traffic i.e. make the FreeBSD
router appear on the subnet which the client thinks it's on.
More information about the freebsd-net