[haiku-commits] Re: haiku: hrev49031 - src/kits/network/libnetapi headers/os/net
- From: Michael Lotz <mmlr@xxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 16 Apr 2015 23:03:16 +0200
On 13.04.2015 16:23, Axel Dörfler wrote:
Am 12.04.2015 um 18:50 schrieb mmlr@xxxxxxxx:
3b7b927dd01f: libbnetapi: Add BNetworkRoute to replace use of
route_entry.
Note that we currently only seem to have per interface default routes
and not an actual global default route. This was already the case
before
these changes and I did not further investigate what this means.
The only reason a route exists is to choose the interface the packet is
sent over. They are global in the sense that all routes are evaluated to
find the one we actually use. The only thing that is missing in our
stack yet is a balancing mechanism if you have two exactly equivalent
routes -- they should be chosen alternately in that case.
Well, the whole reason a route exists is to determine where a packet
should be routed through. That includes the interface, but foremost it
determines the router to be used.
Let's say you have a wired interface that is attached to a network with
different routers for different subnets and you have the address 10.0.0.100:
subnet gateway
0.0.0.0 10.0.0.1 <- default gateway A
10.1.0.0/16 10.0.0.11 <- gateway B
10.3.0.0/16 10.0.0.13 <- gateway C
So if you send a packet on this interface for the network 10.1.x.x it
will go through gateway B at 10.0.0.11, if you send a packet to the
network 10.3.x.x it goes through gateway C at 10.0.0.13. Anything else
on this interface goes through the default gateway A at 10.0.0.1.
Now if you also have a wireless interface that is connected to a
different network where you have the address 192.168.0.50 and different
routes:
subnet gateway
0.0.0.0 192.168.0.1 <- default gateway D
192.168.1.0/24 192.168.0.2 <- gateway E
So packets sent on this interface that match network 192.168.1.x are
sent to gateway E, anything else on this interface goes through the
default gateway of this interface, gateway D.
What is missing is a way to determine which of the two default gateways
is to be used by default. A default default gateway, a metric among the
gateways or a default interface or similar needs to exist.
One possibility is to just not set a default gateway on the second
interface. This causes everything that isn't matched to a more specific
route to go through the default gateway of the first interface.
This approach is rather inconvenient though, as the default gateway is
usually supplied through DHCP. Just ignoring it if you already have
another default gateway will let you become "disconnected" once the
interface with that gateway goes down (i.e. you disconnect the wired
interface and want to continue to use the wireless one, but its default
gateway from DHCP was ignored because it was received later). Also this
obviously breaks applications that attach to a specific interface if
that interface has no default gateway.
You could also set the gateway but not mark it with the default flag and
then update the default flag when interfaces change their status. This
works, but means you need to check the flags in addition to the mask.
For applications that are attached to a specific interface you would
also have to store the found possible gateway that didn't have the
default flag and then use it if you don't find another gateway with the
flag set.
Cleaner would be to have the default gateways on both interfaces and
then have a way to prioritize one interface over the other or one route
over the other. Attaching metrics to the routes like done in other
systems would work for that.
I don't think packets can just be spread across different routes. How
would that work with NAT? How would the router(s) know that these
packets belong to the same connection if they are coming from different
interfaces?
RouteList::Iterator iterator = domain->routes.GetIterator();
+ const size_t baseSize = IF_NAMESIZE + sizeof(route_entry);
Shouldn't that be kBaseSize then?
Indeed.
Regards,
Michael
Other related posts:
