Age | Commit message (Collapse) | Author |
|
|
|
|
|
the new chain. This fixes a potential memory leak in ip_output().
Also simplify a bunch of "goto done".
OK kn@ mvs@
|
|
Without this modification, because of the volatile qualifier, the
compiler does not produce four `` = 0 '' assignments, but code
equivalent to:
*(volatile uint32_t *)INT_ST_MASK3 = 0;
*(volatile uint32_t *)INT_ST_MASK2 =
*(volatile uint32_t *)INT_ST_MASK3;
*(volatile uint32_t *)INT_ST_MASK1 =
*(volatile uint32_t *)INT_ST_MASK2;
*(volatile uint32_t *)INT_ST_MASK0 =
*(volatile uint32_t *)INT_ST_MASK1;
Anders Gavare reported to Miod Vallat, and he gave me a diff.
|
|
|
|
ipsec code is written, but is disabled, so the ipsec words here are
still commented out for now.
|
|
ok deraadt@ dlg@
|
|
i found the Transparent Network Security Policy Enforcement paper
by angelos and jason was useful for understanding the background
and why you'd want to do this.
the implementation is a little bit different to the bridge one
because i've tweaked the order that pf and ipsec processing happens,
depending on which direction the packet is going over the bridge.
bridge always runs ipsec processing before pf, no matter which
direction the packet is going. packets going into veb, pf runs first
and then ipsec input processing is allowed to happen. in the outgoing
direction ipsec happens first and then pf. pf runs before ipsec in
the inbound direction so pf can apply policy to ipsec encapsulated
packets before they hit pf. this allows you to apply policy to both
the encrypted and unencrypted packets in both directions.
the code is disabled for now. this is mostly because i want veb(4)
to have a good chance at operating outside the netlock, and i'm
pretty sure the ipsec stack isn't ready for that yet. the other
reason why it's disabled is getting a test setup is effort, but i
want to sleep.
|
|
ok mpi@
|
|
Reduce differences with NetBSD and prepare for `uobj' locking.
No functionnal change. ok chris@, kettenis@
|
|
|
|
using the ipv6 next protocol header probably doesnt work. it also
probably doesnt matter cos i'm not sure anyone uses this feature in
bridge. or maybe there isn't anyone who uses ipv6. both are plausible
options.
hahaha^Wok patrick@
|
|
|
|
|
|
|
|
minor changes.
|
|
|
|
The timecounter struct is large and I think it may change in the
future. Changing it later will be easier if we use C99-style
initialization for all timecounter structs. It also makes reading the
code a bit easier.
For reasons I cannot explain, switching to C99-style initialization
sometimes changes the hash of the resulting object file, even though
the resulting struct should be the same. So there is a binary change
here, but only sometimes. No behavior should change in either case.
I can't compile-test this everywhere but I have been staring at the
diff for days now and I'm relatively confident this will not break
compilation. Fingers crossed.
ok gnezdo@
|
|
im considering converting ethernet addresses into uint64_ts to make
comparisons (and masking) easier. im trialling it here, and it
doesn't seem like the worst.
|
|
ok jmatthew@
|
|
my intention is to replace bridge(4), but the way it works is
different enough from from bridge that a name change is justified
to distinguish them. it also makes it easier to commit it to the
tree and work on it in parallel to bridge, and allows a window of
migration.
the main difference between veb(4) and bridge(4) is how they use
interfaces as ports. veb takes over interfaces completely and only
uses them to receive and transmit ethernet packets. bridge also use
each interface as a port to the ethernet segment it's connected to,
but also tries to continue supporting the use of the interface as
a way to talk to the network stack on the local system. supporting
the use of interfaces for both external and local communication is
where most of my confusion with bridge comes from, both when i'm
trying to operate it and also understand the code. changing this
semantic is where most of the simplification in veb comes from
compared to bridge.
because veb takes over interfaces, the ethernet network set up on
a veb is isolated from the host network stack. by default veb does
not interact with pf or the ip (and mpls) stacks. to enable pf for
ip frames going over veb ports link1 on the veb interface must be
set. to have the stack interact with a veb network, vport interfaces
must be created and added as ports to a veb.
the vport interface driver is provided as part of veb, and is handled
specially by veb. veb usually prevents the use of ports by the stack
for sending an receiving packets, but that's why vports exist, so
veb has special handling for them.
veb already supports a lot of the other features that bridge has,
including bridge rules and protected domains, but i got tired of
working out of the tree and stopped implementing them. the main
outstanding features is better address table management, the
blocknonip flag on ports, transparent ipsec interception, and
spanning tree. i may not bother with spanning tree unless someone
tells me that they actually use it.
the core ethernet learning bridge functionality is provided by the
etherbridge code that was factored out of nvgre and bpe. veb is
already (a lot) faster than bridge, and is better prepared to operate
in parallel on multiple CPUs concurrently.
thanks to hrvoje popovski for testing some earlier versions of this.
discussed with many
ok patrick@ jmatthew@
|
|
|
|
and exit if ExitOnForwardFailure is set; bz3264
|
|
ok kettenis@ pirofti@
|
|
ok krw@
|
|
From miod@
|
|
|
|
functions. config_setpfkey() is always called with id PROC_IKEV2.
|
|
|
|
|
|
|
|
This allows us to reboot the machine.
ok patrick@
|
|
which requires kernel lock to be held.
ok mpi@
|
|
ok kettenis@
|
|
ok kettenis@
|
|
This mostly adjust the interrupt masking and status support since this
variant lacks the UINTM and UINTP registers.
ok patrick@
|
|
This allows us to do ber-type checking inside ober_scanf_elements, which
will allow for stricter ASN.1 parsing in the future.
Manpage feedback and OK claudio@, jmc@
OK claudio@
|
|
|
|
Ensure that the server announced TLSv1.3 (and nothing higher) in the
supported_versions extension. In that case, the legacy_version must
be TLSv1.2 according to RFC 8446, 4.1.3 and 4.2.1.
This commit also removes some unreachable code which is a remnant of
very early TLSv1.3 code from before the legacy fallback was introduced.
Simplify a few checks and adjust some comments nearby.
ok jsing
|
|
This consolidates the version handling code and will make upcoming changes
easier.
ok tb@
|
|
reassembly, reinsert the fragment into the lookup table with correct
index.
Reported-by: syzbot+d043455a5346f726f1c4@syzkaller.appspotmail.com
OK claudio@
|
|
|
|
|
|
ASN.1 verification.
OK claudio@
|
|
|
|
issue 2570.
|
|
around rather than freeing later, and add a config_files format variable
containing it. Suggested by kn@ a while back.
|
|
each time a tree is created is too expensive. Instead, convert them all
into callbacks and put them in a static table so they only allocate on
demand. The tree remains for the moment for extra (non-default)
variables added by for example copy mode or popups. Also reduce
expensive calls to localtime_r/strftime. GitHub issue 2253.
|
|
from Anindya Mukherjee.
|
|
default reboot interval of 1 sec. Gives the DHCP server a
fairer shot at replying before the timeout expires.
ok millert@
|