- consider non-primary (2nd and beyond) IPv4 address as "local", and prevent
outgoing ARP.
- for routing entries generated by ARP, make sure to set rt->rt_ifa equal to
rt_key, to help IPv4 source address selection for traffic to myself.
PR 13311.
caveats/TODOs:
- interface routes ("connected routes" in cisco terminlogy) is tied with the
primary (1st) IPv4 address on the interface. should be fixed with updates
to rt_ifinit().
- source address selection for offlink locations. 1st address tend to be used
with the current code
(you can configure it right by setting rt->rt_ifa accordingly).
network interfaces. This works by pre-computing the pseudo-header
checksum and caching it, delaying the actual checksum to ip_output()
if the hardware cannot perform the sum for us. In-bound checksums
can either be fully-checked by hardware, or summed up for final
verification by software. This method was modeled after how this
is done in FreeBSD, although the code is significantly different in
most places.
We don't delay checksums for IPv6/TCP, but we do take advantage of the
cached pseudo-header checksum.
Note: hardware-assisted checksumming defaults to "off". It is
enabled with ifconfig(8). See the manual page for details.
Implement hardware-assisted checksumming on the DP83820 Gigabit Ethernet,
3c90xB/3c90xC 10/100 Ethernet, and Alteon Tigon/Tigon2 Gigabit Ethernet.
There is no place in the source where this bit could ever be set (or I'm
to blind to find it).
This fixes PR 12671.
If someone thinks this is the wrong solution, please make sure to (a) reopen
the PR and (b) explain to me how the tested bits would ever get set. I'll
be glad to then look further for the real cause (i.e. the flags not getting
set in the case described in the PR).
(reported by: grendel@heorot.stanford.edu (Ted U)
- Don't cast malloc/realloc/calloc return values because they hide LP64 bugs.
- Don't destroy the whole array when realloc fails
- Use calloc in all cases (malloc was used inconsistently).
- Avoid duplicating code.
Reviewed by: ross
"lots of fragmented packets" DoS attack.
the current default value is derived from ipv6 counterpart, which is
a magical value "200". it should be enough for normal systems, not sure
if it is enough when you take hundreds of thousands of tcp connections on
your system. if you have proposal for a better value with concrete reasons,
let me know.
ISS attacks (which we already fend off quite well).
1. First-cut implementation of RFC1948, Steve Bellovin's cryptographic
hash method of generating TCP ISS values. Note, this code is experimental
and disabled by default (experimental enough that I don't export the
variable via sysctl yet, either). There are a couple of issues I'd
like to discuss with Steve, so this code should only be used by people
who really know what they're doing.
2. Per a recent thread on Bugtraq, it's possible to determine a system's
uptime by snooping the RFC1323 TCP timestamp options sent by a host; in
4.4BSD, timestamps are created by incrementing the tcp_now variable
at 2 Hz; there's even a company out there that uses this to determine
web server uptime. According to Newsham's paper "The Problem With
Random Increments", while NetBSD's TCP ISS generation method is much
better than the "random increment" method used by FreeBSD and OpenBSD,
it is still theoretically possible to mount an attack against NetBSD's
method if the attacker knows how many times the tcp_iss_seq variable
has been incremented. By not leaking uptime information, we can make
that much harder to determine. So, we avoid the leak by giving each
TCP connection a timebase of 0.
enami