to check if interface exists, as (1) if_index has different meaning
(2) ifindex2ifnet could become NULL when interface gets destroyed,
since when we have introduced dynamically-created interfaces. from kame
the tag before forwarding the packet, make sure the packet+tag is at least
68 bytes long.
This is necessary because our parent will only pad to 64 bytes (ETHER_MIN_LEN)
and some switches will not pad by themselves after deleting a tag.
Gone are the old kern_sysctl(), cpu_sysctl(), hw_sysctl(),
vfs_sysctl(), etc, routines, along with sysctl_int() et al. Now all
nodes are registered with the tree, and nodes can be added (or
removed) easily, and I/O to and from the tree is handled generically.
Since the nodes are registered with the tree, the mapping from name to
number (and back again) can now be discovered, instead of having to be
hard coded. Adding new nodes to the tree is likewise much simpler --
the new infrastructure handles almost all the work for simple types,
and just about anything else can be done with a small helper function.
All existing nodes are where they were before (numerically speaking),
so all existing consumers of sysctl information should notice no
difference.
PS - I'm sorry, but there's a distinct lack of documentation at the
moment. I'm working on sysctl(3/8/9) right now, and I promise to
watch out for buses.
mbuf chains which are recycled (e.g., ICMP reflection, loopback
interface). A consensus was reached that such recycled packets should
behave (more-or-less) the same way if a new chain had been allocated
and the contents copied to that chain.
Some packet tags may in future be marked as "persistent" (e.g., for
mandatory access controls) and should persist across such deletion.
NetBSD as yet hos no persistent tags, so m_tag_delete_nonpersistent()
just deletes all tags. This should not be relied upon.
The code was assuming that interface addresses are removed one-by-one.
With IPv6 and multicasts, removal of one address can remove other
addresses as side effect, which caused accesses of free()d memory.
sysctl. Add a protocol-independent sysctl handler to show the per-protocol
"struct ifq' statistics. Add IP(v4) specific call to the handler.
Other protocols can show their per-protocol input statistics by
allocating a sysclt node and calling sysctl_ifq() with their own struct ifq *.
As posted to tech-kern plus improvements/cleanup suggested by Andrew Brown.
some problem setting the media to the requested value (usually IFM_AUTO),
we now force the media selection to IFM_NONE.
This addresses PR/14029 ``panic("ifmedia_set") a little too brutal''
and may address to some degree PR/19504 and PR/23341.
* introduce fsetown(), fgetown(), fownsignal() - this sets/retrieves/signals
the owner of descriptor, according to appropriate sematics
of TIOCSPGRP/FIOSETOWN/SIOCSPGRP/TIOCGPGRP/FIOGETOWN/SIOCGPGRP ioctl; use
these routines instead of custom code where appropriate
* make every place handling TIOCSPGRP/TIOCGPGRP handle also FIOSETOWN/FIOGETOWN
properly, and remove the translation of FIO[SG]OWN to TIOC[SG]PGRP
in sys_ioctl() & sys_fcntl()
* also remove the socket-specific hack in sys_ioctl()/sys_fcntl() and
pass the ioctls down to soo_ioctl() as any other ioctl
change discussed on tech-kern@
filter or not. We only need to run the filter for bridge_forward() and
bridge_broadcast(). If we also run it for bridge_output(), we will run
the filter twice outbound per packet, so don't.
In bridge_ipf(), make sure we don't run m_cat() on a single mbuf chain
by checking to see (and remembering) if we need to m_split() the mbuf.
This fixes bridge + ipfilter on sparc.
Fixes PR kern/22063.
As long as we receive data from the peer, don't worry. When we have not
received anything within the "max_noreceive" period, we start sending LCP
echo requests and count them, until we receive an answer (or some data)
or the "maxalive" count of not answered echo requests is reached.
All this is checked at a global 10 seconds interval for all interfaces.
The "max_noreceive" period and the "maxalive" count are configurable per
interface.
and for regression-testing performance at various MTUs.
NB: route MTU may not track MTU changes, which may cause problems for
AF_ISO if loopback MTU is decreased. I've never seen problems with IP,
in various tests going back to around NetBSD 1.3.
itojun