[PLUG] Understanding Networking Components

Mike Connors mconnors1 at gmail.com
Mon Apr 2 21:33:59 UTC 2012


>
> > But if the first ip packets from Rich's computer go out eth0, they will
> > never make in to the WAP DHSP server and be redirected to the captive
> > portal. It's possible, depending on how the captive portal works and how
> > it's configured that a call to an internal DNS server doesn't need to
> > happen.
>
> However, the wlan0 interface IS getting a response from the DHCP server,
> or it would not have an IP address.
>
> Nothing would be going out eth0, since it's not connected to anything,
> and, as per Rich's message, it's not in a running state. As I recall, the
> IPs Rich reported are in two different subnets, so, in theory, the IP stack
> should try both routes, if there are two routes in the routing table.
>
> Rich has also stated the host name (not the IP address) of the captive
> portal T&C page. This would require at least one call to some DNS server,
> to give the network stack someplace to go.
>
> My theory is that something is not setting the resolv.conf properly. This
> could be caused by a race condition. As I recall, Rich has a resolv.conf
> that gets swapped in by rc.local. If the network finishes configuring prior
> to rc.local running, then it's possible that rc.local is overwriting the
> DHCP configured resolv.conf. Then, once DNS is broken, everything appears
> broken.
>
>
Yes, the DHCP client, which sends out a DHCP broadcast on the WLAN is
getting a DHCP response back in wlan0. But, if it's in fact a captive
portal, then Rich's laptop will have an ip addr on a quarantined subnet
that is managed by the dhcp server. He would need to then have ip
connectivity back out through wlan0 to the wap/dhcp server to be redirected
to the captive portal page.

But I think the strongest clue that it's most likely an ip connectivity
issue is the fact that he can't ping the default gateway, which is probably
the WAP, dhcp server, router, captive portal all in one. This tells me his
laptop is isolated from the network.

Routing is done based on the routing entries in the routing table. The
routing algorithm doesn't take into account whether the interface is
connected. If there's an route entry defined in the routing table for a
disconnected interface the routing table manager will use it in it's
routing decision for a locally connected network. Dynamic, higher-end
routing protocols not withstanding.

"In theory, the IP stack should try both routes, if there are two routes in
the routing table."

Routing works by way of longest match, meaning the most specific route. If
there's no specific route defined for the dest ip addr, then packets are
routed out via the default gateway. If you have 2 default gateways, one
will take precedence.

The only time that theory is true, is if it's a broadcast message, such as
DHCP, where the packets are broadcasted out all the interfaces. The point
of a router and routing protocols is to have some intelligence around which
packets get routed out which interfaces. Otherwise, we'd just build the
internet by connecting a bunch of hubs together and have one big LAN.



More information about the PLUG mailing list