The former two are no longer necessary as slstats is no more
and pppstats now uses an ioctl instead of rummaging through kmem.
The latter has nothign interesting for the userland, but uses
struct bintime that I'm about to hide under #ifdef _KERNEL.
A bunch of remaining <net/if_*.h> headers is pretty useless to the
userland too, but ... someone else's yag to shave...
- struct timeval time is gone
time.tv_sec -> time_second
- struct timeval mono_time is gone
mono_time.tv_sec -> time_uptime
- access to time via
{get,}{micro,nano,bin}time()
get* versions are fast but less precise
- support NTP nanokernel implementation (NTP API 4)
- further reading:
Timecounter Paper: http://phk.freebsd.dk/pubs/timecounter.pdf
NTP Nanokernel: http://www.eecis.udel.edu/~mills/ntp/html/kern.html
/sys/net/if_spppvar.h says:
"Lower layer drivers that are always ready to communicate
(like hardware HDLC) can shortcut pp_up from pp_tls,
and pp_down from pp_tlf."
When I follow those instructions, I get a kernel stack
overflow as soon as I open the HDLC device.
Here is the loop:
sppp_ioctl calls sppp_lcp_open
sppp_lcp_open calls sppp_open_event
sppp_open_event calls sppp_lcp_tls
sppp_lcp_tls calls pp_tls
pp_tls is the SHORTCUT to sppp_lcp_up
sppp_lcp_up calls spp_lcp_open
...and around we go until the stack overflows.
The fix is to reverse the order of the action (tls)
and the state change (from INITIAL to STARTING) in
sppp_open_event.
There is a similar loop during closing:
sppp_ioctl calls sppp_lcp_close
sppp_lcp_close calls sppp_close_event
spp_close_event calls sppp_lcp_tlf
sppp_lcp_tlf calls pp_tlf
pp_tlf is the SHORTCUT to sppp_lcp_down
sppp_lcp_down calls sppp_lcp_close
...and around we go until the stack overflows.
The fix is to reverse the order of the action (tlf)
and the state change (from STARTING to INITIAL) in
sppp_close_event.
Separately, while I was discovering this, I noticed
that pp_tlf was being called unconditionally rather
than first checking to see if it is NULL. pp_tlf
is a callout from sppp to the hdlc device driver.
Elsewhere in sppp, this is always checked for NULL
before calling it, and the comments in if_spppvar.h
imply that filling it in is optional.
From spppvar.h:
"These functions need to be filled in by the lower layer
(hardware) drivers if they request notification from the
PPP layer whether the link is actually required."
This clearly says that pp_tlf and pp_tls are optional
and so sppp must check before calling them.
that expect real addresses. explicitly KASSERT() that it is not
NULL in the kernel and just avoid using it userland.
(the kernel could be more defensive about this, but, until now it
would have just crashed anyway.)
The PR submitter and the PR handler were unable to test this code
using Teredo userland clients such as Miredo. However, the PR handler
dumped and analyzed some of the packets produced by Miredo and they
seemed fine.
(On a side note: I was unable to setup Teredo in Windows XP and the
problem seemed similar to what I currently see in NetBSD: lack of
replies from the Teredo relay).
- most of the kernel code will not care about the actual encoding of
scope zone IDs and won't touch "s6_addr16[1]" directly.
- similarly, most of the kernel code will not care about link-local
scoped addresses as a special case.
- scope boundary check will be stricter. For example, the current
*BSD code allows a packet with src=::1 and dst=(some global IPv6
address) to be sent outside of the node, if the application do:
s = socket(AF_INET6);
bind(s, "::1");
sendto(s, some_global_IPv6_addr);
This is clearly wrong, since ::1 is only meaningful within a single
node, but the current implementation of the *BSD kernel cannot
reject this attempt.
- and, while there, don't try to remove the ff02::/32 interface route
entry in in6_ifdetach() as it's already gone.
This also includes some level of support for the standard source
address selection algorithm defined in RFC3484, which will be
completed on in the future.
From the KAME project via JINMEI Tatuya.
Approved by core@.
Applied fix, similar to the one suggested in the PR. We use a counter to
limit the number of consecutive packets accepted from the fast queue. This
number can be set via ioctl, but this has not been implemented. Since there
are only 2 queues other proposed solutions such as ALTQ are overkill and
they have not been implemented in the past 7 years. Now LCP echos can be
used to detect that the line is up.
clients of bpf_filter(), like if_ppp, that are not limited by
bpf_maxbufsize. The same check is done at the run time, so there is no
problem created.
Noticed by Guy Harris in private email.
- Replace references to linesw[0] with a ttyldisc_default() function
that returns the default ("termios") line discipline.
- The linesw[] array is gone, replaced by a linked list.
- ttyldisc_add() and ttyldisc_remove() have been replaced by
ttyldisc_attach() and ttyldisc_detach().
- Things that provide line disciplines are now responsible for
registering those disciplines with the system. The linesw
structures are no longer declared in tty_conf.c
- Line disciplines are now refcounted; a lookup causes a reference to
be held. ttyldisc_release() releases the reference. Attempts to
detach an in-use line discipline result in EBUSY.
- Fix function signature lossage in if_sl.c, if_strip.c, and tty_tb.c
that was masked by the old tty_conf.c
- tty_init() is no longer necessary; delete it and its call from main().
yamt