malloc_type M_IFADDR and freed with malloc_type M_DEVBUF. This
causes a panic(9) in DIAGNOSTIC kernels. Add malloc_type M_IFMEDIA
and use it for both malloc'ing and free'ing ifmedia_entrys.
When the ethernet interface of a pppoe pseudo-interface detaches, remove
the association and mark the pppoe interface down.
This should fix PR kern/28375.
<net/if_dl.h> defines struct sockaddr_dl. On the line defining member
"sdl_family" (which overlaps "sa_family" in struct sockaddr), the
comment says AF_DLI.
But,
1) AF_DLI is said to be a DEC Direct data link interface
(sys/socket.h)
2) The kernel actually sends sockaddr_dl structs with AF_LINK.
Quiting Tom: The problem is the special case of an RTM_GET message
that wants interface information included in the response, and
therefore include the RTA_IFA or RTA_IFP (or both) flags in the
bitmask that says what addresses are supplied in the message. For
the RTM_GET message, it doesn't make sense to supply addresses
other than the one you're asking about, so those two other bits
are, in that specific case, overloaded with this meaning.
There is code in sys/net/rtsock.c to handle the case, but at some
time, extra sanity checking of the received message was added, that
failed to take this possibility into account.
The patch, is needed for the Asterisk software PBX to work properly
when it has multiple interfaces active: it needs to ask the kernel
for the IP address of the interface that will be used to communicate
with a given host.
1.) There is objection against this change by at least one developer.
2.) These changes cause repeatable system lockups and crashes for
at least four people.
received packets in csum_flags in the packet header. Packets that are
forwarded over the bridge need to have csum_flags cleared before being
put on the output queue. Do so in bridge_enqueue().
Discussed with Jason Thorpe.
Fixes PR kern/27007 and the first part of PR kern/21831.
This prevent a variety of fun panics, and therefore fixes PR 12932, PR 17561,
and PR 18376...
XXX
...however this is most definitely a hack. The real problem here is that there
is no callback to notify a "client" interface like vlan when a "parent"
interface's status changes, and therefore the vlan interface is always
IFF_RUNNING. This allows packets to be queued on vlan interface at any time.
We can't simply leave the packets on the vlan interface, either, because there
is no callback to dequeue them. And last, since it's always IFF_RUNNING, if
we just *toss* the packets, we lose gratuitous ARPs and DAD packets.
"This needs work," but at least it no longer bleeds.
the functionality of M_PREPEND, but with a bug: m_pkthdr.len was
not updated in pppoutput as it is in M_PREPEND.
Also, replace the loop that measures the length of the mbuf chain
with a call to m_length.
This fixes a PR from an anonymous bug reporter. Thank you, anonymous
bug reporter. Thanks, Itojun, for bringing the anonymous bug report
to my attention.
for consistency with M_FREE() and m_freem(). Affected files:
sys/mbuf.h
kern/uipc_socket2.c
kern/uipc_mbuf.c
net/if_ethersubr.c
netatalk/ddp_input.c
nfs/nfs_socket.c
