| Age | Commit message (Collapse) | Author |
|---|
|
this makes it more obvious that the bpf code should only read
packets, never modify them.
now possible because the paths that care about M_FILDROP set it
after calling bpf_mtap.
ok mpi@ visa@ deraadt@
|
|
ok mpi@
|
|
hint.
ok kettenis@, deraadt@
|
|
Use a new task that runs holding the KERNEL_LOCK to execute mp-unsafe
code. Our current goal is to progressively move input functions to the
unlocked task.
This gives a small performance boost confirmed by Hrvoje Popovski's
IPv4 forwarding measurement:
before: after:
send receive send receive
400kpps 400kpps 400kpps 400kpps
500kpps 500kpps 500kpps 500kpps
600kpps 600kpps 600kpps 600kpps
650kpps 650kpps 650kpps 640kpps
700kpps 700kpps 700kpps 700kpps
720kpps 640kpps 720kpps 710kpps
800kpps 640kpps 800kpps 650kpps
1.4Mpps 570kpps 1.4Mpps 590kpps
14Mpps 570kpps 14Mpps 590kpps
ok kettenis@, bluhm@, dlg@
|
|
Apparently nobody can hit this condition anymore or people do not
report bugs if their kernel do not panic.
ok dlg@, sashan@
|
|
callbacks return EAGAIN if they modify the routing table. While we're here,
simplify life for rtable_walk callers by moving the loop that restarts the
walk on EAGAIN into rtable_walk itself.
Flushing cloned routes on interface state changes becomes a bit more
inefficient, but this can be improved later.
ok mpi@ dlg@
|
|
bug introduced in r1.138.
Reported at https://twitter.com/DarkSoul4242/status/722365165262405633
(twitter is *NOT* the place to report bugs!) and in
https://marc.info/?l=openbsd-bugs&m=145988918010707&w=2,
pointed out by tb@
|
|
and pretending the output succeeded. Packets are still dropped!
Idea from jsg@ following same change to bridge(4). ok mpi@
|
|
Since the rtalloc(9) rewrite no route lookup is done in this function so
there's no need for a destination or a rtable ID.
|
|
no functional change
|
|
the recent vlan code sets the vlan interfaces mac address to the
parent interfaces mac address when it is brought up, and resets it
when the vlan interface is brought down.
now, if you set a mac address manually (eg, ifconfig vlanX lladdr
f0:0b:a7:ba:2b:00), vlan(4) ignores the parents mac address and
never resets its own.
to make this work, setting a custom lladdr on a vlan interface makes
the parent interface promisc so the packets wont be filtered by the
hardware interface.
setting the mac address to 00:00:00:00:00:00 resets this behavior
and makes the interface inherit the parents mac again.
issue reported by and fix tested by paul de weerd
|
|
The EBUSY hack imposes an order on the ifconfig commands issued
against the pppoe interface used to configure the sppp layer below.
To counter this we use the ENETRESET trick that other drivers use
to tell the pppoe layer that sppp has requested a stop/init reset
sequence to proceed which we oblige with in case pppoe is UP and
RUNNING.
Tested by semarie@ and Jan Schreiber <jes@posteo.de>, thanks!
|
|
theyre currently unused, so no functional change.
|
|
this makes it more clear to the casual reader that it refers to the
parent interface, which is consistently referred to as ifp0 in the
rest of the vlan (and carp) code.
this is a good idea from mpi@
|
|
configuration of the vlan parent interface and the vlan id should
come via the IFPARENT and VNETID ioctls now. the vlan specific
ioctls are still available via a compat layer, but that will go
away a bit further into this release cycle.
the parent interface may only be configured while the vlan is down.
the vnetid may be changed at runtime, but will generate link state
changes across that event.
the vlan is implicitily brought up when an address is assigned,
which brings it in line with all our other network drivers. the
legacy vlan ioctl still imply bringing the interface up because
that's what it used to do.
the code that brings vlans up and down is now simplified because
it no longer supports changing the parent at run time. most of that
code now adds state to the parent when bringing the vlan up, and
bringing the interface down just removes it in reverse.
these simplifications in turn make it possible for us to transmit
packets on vlan interfaces without holding the big lock, so its now
marked as MPSAFE.
ok jmatthew@ sthen@ mpi@
|
|
note that this uses max_linkhdr as the adjustment arg. this follows
what the ip stack does when generating packets as it provides space
for link headers (like ethernet headers) to be prepended on the new
packet.
ok henning@
|
|
node in /dev, that services all bpf consumers (up to 1024). Also,
disallow the usage of all but the first minor device, so accidental use
of another minor device will attract attention.
Cloning bpf offers some advantages:
- Users with high bpf usage won't have to clutter their /dev with device
nodes.
- A lot of programs in base use a pattern like this to acces bpf:
int fd, n = 0;
do {
(void)snprintf(device, sizeof device, "/dev/bpf%d", n++);
fd = open(device, mode);
} while (fd < 0 && errno == EBUSY);
Those can now be replaced by a simple open(), without loop.
ok mikeb
"right time in the cycle to try" deraadt
|
|
|
|
ok jmatthew@
|
|
Reported by and ok jmatthew@
|
|
it should not be used to output packets but we have to respect the ifp
driver API to some extend.
Prevent a panic found the hardway by espie@.
ok claudio@, mikeb@, jsg@, krw@
|
|
content and unlink the statekey.
This should allow us to find the reminding corner cases of packets
looped back in the stack.
ok dlg@
|
|
removal from mbuf.h. ok mpi@
|
|
|
|
ok guenther@
|
|
Static is a nop in _KERNEL, but is static in userland and therefore libpcap
|
|
other projects have already done this, and there's software (eg,
gopacket) which now expects it.
based on a discussion with jasper@ and canacar@
ok jasper@
|
|
the code was confusing around how it dealt with packets in mbufs
vs plain memory buffers with a lenght.
this renames bpf_filter to _bpf_filter, and changes it so the packet
memory is referred to by an opaque pointer, and callers have to
provide a set of operations to extra values from that opaque pointer.
bpf_filter is now provided as a wrapper around _bpf_filter. it
provides a set of operators that work on a straight buffer with a
lenght.
this also adds a bpf_mfilter function which takes an mbuf instead
of a buffer, and it provides explicit operations for extracting
values from mbufs.
if we want to use bpf filters against other data structures (usb
or scsi packets maybe?) we are able to provide functions for
extracting payloads from them and use _bpf_filter as is.
ok canacar@
|
|
eleven years, remove it.
Despite what the wildly outdated time(9) claims, there is no longer
globally visible "struct timeval mono_time" or "struct timeval time".
ok mpi@ sthen@ mikeb@
|
|
|
|
nothing uses them, and the implementation make incorrect assumptions
about mbufs within bpf processing that could lead to some weird
failures.
ok sthen@ deraadt@ mpi@
|
|
less code for the same effect, which is ETHER_ALIGNed packets.
ok mpi@
|
|
Since mpath is not enabled in RAMDISK, proxy ARP won't work there either.
ok bluhm@
|
|
ok mpi@ claudio@
|
|
ok mpi@
|
|
this is the second attempt to get it in, the first
attempt got backed out on Jan 31 2016
the change also contains fixes contributed by Stefan Kempf
in earlier iteration.
OK srhen@
|
|
|
|
ok mpi@ jmatthew@
|
|
From Florian Riehm, ok bluhm@
|
|
entries.
This is a noop with the radix routing table because rt_mask() is always
NULL for RTF_HOST entries, but it preserves the old behavior with ART.
With the ART routing table host entry always have a prefix length equals
to the length of the address.
Fix a regression reported by semarie@.
ok semarie@, bluhm@
|
|
ok yasuoka@
|
|
this gives us preallocated space at the start of the packet for
headers so later calls to M_PREPEND are far less likely to fail.
ok yasuoka@
|
|
|
|
the previous code had vlan_ether_purgemulti and vlan_ether_resetmulti,
both of which did too many things. purgemulti would try and remove
the multicast entries from the parent, and then free the local
copies of the addresses. resetmulti would try to remove the address
from the parent, and then optionally try to add them to a new parent.
resetmulti in particular makes the overall vlan config steps fairly
twisty.
the refactor offers vlan_multi_apply, and vlan_multi_free. multi_apply
simply adds or removes the multicast addresses from a parent
interface. it is now up to the config steps to call them appropriately
when configuring a parent or a new parent. vlan_multi_free only
deletes the memory associated with the vlans multicast addresses.
vlan_multi_apply is called when a parent is configured (ie, ifconfig
vlan0 up), or unconfigured (ifconfig vlan0 down or a detach of the
parent). vlan_multi_free is called when a vlan interface is destroyed
(ifconfig vlan0 destroy).
ok mpi@
|
|
detect this and bump ifq_congestion forward rather than claim the
system is congested for a long period of time.
ok mpi@ henning@ jmatthew@
|
|
ok mpi@
|
|
still no binary change.
|
|
the vlan interface is ifp, the vlans parent interface is ifp0, the new
interface parent is newifp0.
requested by mpi@
no binary change
|
|
|
|
previously mpw would walk around our interface hierarchy so it could
reinject vlan tags for packets that were received on a stack of
vlan interfaces. this got in the way of making vlan mpsafe, but is
also unecessary according to how i read RFC 4448 which describes
how mpls pseudowires should function.
the behaviour is now:
- in raw mode mpw(4) acts like a normal ethernet interface
it no longer injects a tag from a vlan interface that may be on the
same bridge as it, and it allows you to configure ip addresses on
the local interface and use them without panicking the kernel.
- in tagged mode it will only add tags from vlan interfaces on the
same bridge as it, but not any parent/child tags from interfaces
on top of that vlan. if the packet did not come from a vlan interface
on a bridge it will inject a tag for vlan 0.
this will also allow vlan to move forward.
ok mpi@ rzalamena@ claudio@
|
