when ip header and tcp header are not adjacent to each other
(i.e. when ip6 options are attached).
To test this, try
telnet @::1@::1 port
toward a port without responding server. Prior to the fix, the kernel will
generate broken RST packet.
for the protocol in the specified packet.
Fix statistic gathering to not make bogus increments of ips_delivered and
ips_noproto for cases where rip_input() is called by a protocol handler
(such as icmp_input or igmp_input) which has already processed the packet.
(Sorry for a big commit, I can't separate this into several pieces...)
Pls check sys/netinet6/TODO and sys/netinet6/IMPLEMENTATION for details.
- sys/kern: do not assume single mbuf, accept chained mbuf on passing
data from userland to kernel (or other way round).
- "midway" ATM card: ATM PVC pseudo device support, like those done in ALTQ
package (ftp://ftp.csl.sony.co.jp/pub/kjc/).
- sys/netinet/tcp*: IPv4/v6 dual stack tcp support.
- sys/netinet/{ip6,icmp6}.h, sys/net/pfkeyv2.h: IETF document assumes those
file to be there so we patch it up.
- sys/netinet: IPsec additions are here and there.
- sys/netinet6/*: most of IPv6 code sits here.
- sys/netkey: IPsec key management code
- dev/pci/pcidevs: regen
In my understanding no code here is subject to export control so it
should be safe.
address zero of each net/subnet is a broadcast address.
(The default value is nonzero, which preserves the current behavior).
This can be set using sysctl; the boot-time default can also be
configured using the HOSTZEROBROADCAST kernel config option.
While we're here, defopt HOSTZEROBROADCAST and SUBNETSARELOCAL
after various m_adj()s have been done. Kludge around this with a cheesy
macro that knows where the drivers put the mac header in the first mbuf.
XXX There should be a better way to do this.
where one side can think a connection exists, where the other side thinks
the connection was never established.
The original problem was first reported by Ty Sarna in PR #5909. The
original fix I made to the code didn't cover all cases. The problem this
fix addresses was reported by Christoph Badura via private e-mail.
Many thanks to Bill Sommerfeld for helping me to test this code, and
for finding a subtle bug.
remote of the tunnel can be found.
XXX If you manually mark the interface as "UP" and set the MTU later
XXX sending a packet will still cause a kernel panic.
passing SIOCSIFADDR/SIOIFDSTADDR, but by passing the addresses in
the appropriate structs.
One of the mysteries of ifconfig IMHO...
Should fix kern/6899.
and netinet, currently only tested under netinet.
Disabled by default, enabled by compiling the kernel with option
IFA_STATS. Enabling this feature seems to make the ip_output function
take 13% longer than before, which should be OK for people that need
this feature.
same uid or by root.
This code is from FreeBSD. (Whilst it was originally obtained from OpenBSD,
FreeBSD fixed it to work with multicast. To quote the commit message:
- Don't bother checking for conflicting sockets if we're binding to a
multicast address.
- Don't return an error if we're binding to INADDR_ANY, the conflicting
socket is bound to INADDR_ANY, and the conflicting socket has
SO_REUSEPORT set.
)
- Don't use tcp_respond(), instead create the tcp/ip header from scratch,
and send it ourself.
- Reuse the mbuf that carried the SYN, or allocate one if that is not
available.
- Cache the route we look up to do the Path MTU Discovery check, and
transfer the reference to that route to the inpcb when the connection
completes.
* Macro'ize a small, but often repeated code fragment.
SYN,ACK packets during Path MTU Discovery. Fix tcp_respond() to do the
appropriate route lookup and set DF as appropriate.
Also, fixup similar code in tcp_output() to relookup the route if it
is down.
ipip_input(), and returns non-zero if mrt_ipip_input() handled the
packet.
XXX Eventually, the multicast code should probably use regular IP-IP
XXX `interfaces', but mrouted knows about the VIF table, etc.
up the interface to ip_mroute.c somewhat, and properly separates IP-IP
from GRE. (They are similar, but they are different protocols, and should
not be implemented in the same place.)
where the user issued a write with a length greater than MLEN but less
than MINCLSIZE, thus causing two mbufs to be used. The loop in sosend()
would then call PRU_SEND twice, causing TCP to transmit 2 packets when
it could have transmitted one.
Suggested by Justin Walker <justin@apple.com> on the freebsd-net
mailing list.
((so->so_proto->pr_flags & PR_CONNREQUIRED) == 0 ||
(so->so_options & SO_ACCEPTCONN) == 0)
since the latter is always true, so the former test in unnecessary.
from `TCP/IP Illustrated, Volume 2', W. Richard Stevens, p 730.
itojun