My DSL connection, using a modem in "bridge" mode and pppoe(4), suffers
from disconnections every few (5 or so) days. The following message is
printed in the syslog:
pppoe0: LCP keepalive timeout
which indicates that several Echo-Requests were not followed by replies,
so the kernel considers the connection to be dead and tries to
reestablish the PPP session. Perhaps this could be fixed by the ISP, or
perhaps it comes from the modem, and perhaps it could be fixed by
increasing either MAXALIVECNT or the sec parameter in the relevant
timeout_add_sec(9) call in src/sys/net/if_spppsubr.c (currently these
are hard-coded but it would be nice to make these parameters accessible
through ifconfig(8): see the "bugs" section in sppp(4)).
The disconnection itself is not the problem that I want to discuss right
now. sppp(4) manages to reconnect (sometimes it takes a few minutes,
presumably because the other end is not happy that the previous
connection was not properly terminated), and so as long as the
reconnections are not too frequent it is not too big of an issue. My
main problem is that the default IPv6 route, configured by adding
!/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0
to /etc/hostname.pppoe0 as suggested by the manual, does not survive the
reconnection (to be precise, all IPv6 addresses are purged when the new
IPv6CP dance succeeds, and so the routes are purged as well). This is
surprising because the default IPv4 route does survive the reconnection
(route -n monitor tells me that some magic happens with the "special"
addresses 0.0.0.0 and 0.0.0.1). Of course running the above route
command reinstates the default IPv6 route, but this has to be done
manually.
Is this problem known? Is it the case for all sppp(4) connections (with
IPv6 enabled of course), or even for all similar point-to-point
interfaces? If your connection is reliable, you can simply unplug the
phone line for about 30 seconds to try to reproduce this issue. A
detail that can make my case somewhat particular: for some reason none
of the DHCPv6 clients in ports worked for me (even if I temporarily
disable the firewall, my "solicit" remain unanswered) but since my ISP
informed me of my prefix, I could simply configure the "local" interface
of the router with a static IPv6 address, and similarly for rad(8).
Fortunately my ISP is routing the IPv6 packets on my line even without
prefix delegation.
I considered the following possible solutions.
1) The kernel could have a way of remembering the default IPv6 route
that was added, like for IPv4. I don't know what kind of complication
to the routing code that would entail.
2) I considered using ifstated(8) to add the default route anytime
pppoe0 comes up, but this does not seem to be the right event: if I
understand correctly, the interface is marked as "up" when the PPP dance
succeeds, before any one of the NCP dances succeeds. One could have a
little nap between the "up" event and the addition of the default IPv6
route, but that does not seem right. One could add more interface
events to ifstated(8), but perhaps that is too complicated for this
particular tool?
3) As a temporary measure, I wrote a small program (with a lot of
copy-paste from the source of ifstated(8) and route(8), see attachment)
that waits for the addition of new route with destination fe80::%pppoe0,
and subsequently adds the sought default route. It worked at least
once, so I am hopeful that it will work always. I have no doubt that it
could be improved (for starters, the name of the interface could be
passed as argument).
PS: although the route(4) man page was really useful to understand how
to talk to the kernel, it does not give all the details to do so (e.g.
alignment on "long" for the sockaddrs, the way scope ids are embedded in
link-local addresses, and which fields in the sockaddrs are actually
used by the kernel). That is not really preventing anyone to interact
with the kernel because there are many examples of code in base
(sys/net/rtsock.c, sbin/route/*.c, ...), but I thought I would point it
out just in case the goal is to have the route(4) man page be
self-contained.
No comments:
Post a Comment