mirror of
https://libwebsockets.org/repo/libwebsockets
synced 2024-12-12 08:47:25 +00:00
643a001ed8
This creates a role for RFC3549 Netlink monitoring. If the OS supports it (currently, linux) then each pt creates a wsi with the netlink role and dumps the current routing table at pt init. It then maintains a cache of the routing table in each pt. Upon routing table changes an SMD message is issued as an event, and Captive Portal Detection is triggered. All of the pt's current connections are reassessed for routability under the changed routing table, those that no longer have a valid route or gateway are closed.
52 lines
2.0 KiB
Markdown
52 lines
2.0 KiB
Markdown
# Lws routing
|
|
|
|
lws is mainly built around POSIX sockets and operates from the
|
|
information available from those. But in some cases, it needs to go
|
|
a step further and monitor and understand the device routing table.
|
|
|
|
## Recognizing loss of routability
|
|
|
|
On mobile devices, switching between interfaces and losing / regaining
|
|
connections quickly is a given. But POSIX sockets do not act like
|
|
that, the socket remains connected until something times it out if it
|
|
no longer has a route to its peer, and the tcp timeouts can be in the
|
|
order of minutes.
|
|
|
|
In order to do better, lws must monitor and understand how the routing
|
|
table relates to existing connections, dynamically.
|
|
|
|
## Linux: netlink
|
|
|
|
For linux-based devices you can build in netlink-based route monitoring
|
|
with `-DLWS_WITH_NETLINK=1`, lws aquires a copy of the routing table
|
|
when the context / pt starts up and modifies it according to netlink
|
|
messages from then on.
|
|
|
|
On Linux routing table events do not take much care about backing out
|
|
changes made on interface up by, eg, NetworkManager. So lws also
|
|
monitors for link / interface down to remove the related routes.
|
|
|
|
## Actions in lws based on routing table
|
|
|
|
Both server and client connections now store their peer sockaddr in the
|
|
wsi, and when the routing table changes, all active wsi on a pt are
|
|
checked against the routing table to confirm the peer is still
|
|
routable.
|
|
|
|
For example if there is no net route matching the peer and no gateway,
|
|
the connection is invalidated and closed. Similarly, if we are
|
|
removing the highest priority gateway route, all connections to a peer
|
|
without a net route match are invalidated. However connections with
|
|
an unaffected matching net route like 127.0.0.0/8 are left alone.
|
|
|
|
## Intergration to other subsystems
|
|
|
|
If SMD is built in, on any route change a NETWORK message
|
|
`{"rt":"add|del"}` is issued.
|
|
|
|
If SMD is built in, on any route change involving a gateway, a NETWORK
|
|
message `{"trigger":"cpdcheck", "src":"gw-change"}` is issued. If
|
|
Captive Portal Detection is built in, this will cause a new captive
|
|
portal detection sequence.
|
|
|