summaryrefslogtreecommitdiffstats
path: root/sys/netinet
Commit message (Collapse)AuthorAgeFilesLines
* Permit ARP to proceed for IPv4 host routes for which the gateway is thezec2011-07-081-2/+12
| | | | | | | | | same as the host address. This already works fine for INET6 and ND6. While here, remove two function pointers from struct lltable which are only initialized but never used. MFC after: 3 days
* Add again the checking for log_arp_permanent_modify that was by accidentae2011-07-071-5/+7
| | | | | | | removed in the r186119. PR: kern/154831 MFC after: 1 week
* Remove the TCP_SORECEIVE_STREAM compile time option. The use ofandre2011-07-071-4/+2
| | | | | | | soreceive_stream() for TCP still has to be enabled with the loader tuneable net.inet.tcp.soreceive_stream. Suggested by: trociny and others
* Remove #ifdef notyet code dating back to 4.3BSD Net/2 (and possibly earlier).cperciva2011-07-051-18/+1
| | | | | | | | I think the benefit of making the code cleaner and easier to understand outweighs the humour of leaving this intact (or possibly changing it to #ifdef not_yet_and_probably_never). MFC after: 2 weeks
* Don't allow lro->len to exceed 65535, as this will result in overflowcperciva2011-07-051-0/+8
| | | | | | | | | | | when len is inserted back into the synthetic IP packet and cause a multiple of 2^16 bytes of TCP "packet loss". This improves Linux->FreeBSD netperf bandwidth by a factor of 300 in testing on Amazon EC2. Reviewed by: jfv MFC after: 2 weeks
* - General grammar and mdoc(7) fixes. [1] [2]gjb2011-07-041-65/+66
| | | | | | | | | | - While here, remove a paragraph about userspace operation that has been outdated for some time. [2] PR: 158623 Submitted by: Ben Kudak (kaduk % mit!edu) [1] Reviewed by: glebius [2] MFC after: 1 week
* pf(4) tags now store the state key but tcp_respond tries to reuse a mbuf as ↵eri2011-07-041-0/+1
| | | | | | | | | an optimization. This makes pf find the wrong state and cause errors reported with state mismatches. Clear the cached state link on the pf(4) tag to avoid the state mismatches. Approved by: bz
* ARP code reuses mbuf from ARP request to make a reply, but it does notae2011-07-041-0/+1
| | | | | | | | | | reset rcvif to NULL. Since rcvif is not NULL, ipfw(4) supposes that ARP replies were received on specified interface. Reset rcvif to NULL for ARP replies to fix this issue. PR: kern/131817 Reviewed by: glebius MFC after: 1 month
* Add the missing sca_keylength field to the sctp_authkey structure,tuexen2011-06-302-1/+12
| | | | | | which is used the the SCTP_AUTH_KEY socket option. MFC after: 1 month.
* Add new rule actions "call" and "return" to ipfw. They makeae2011-06-295-0/+134
| | | | | | | | | | | | | possible to organize subroutines with rules. The "call" action saves the current rule number in the internal stack and rules processing continues from the first rule with specified number (similar to skipto action). If later a rule with "return" action is encountered, the processing returns to the first rule with number of "call" rule saved in the stack plus one or higher. Submitted by: Vadim Goncharov Discussed by: ipfw@, luigi@
* Update packet filter (pf) code to OpenBSD 4.5.bz2011-06-284-4/+7
| | | | | | | | You need to update userland (world and ports) tools to be in sync with the kernel. Submitted by: mlaier Submitted by: eri
* Add support for SCTP_PR_SCTP_NONE which I misded to add.tuexen2011-06-271-1/+2
| | | | | | This constant is defined in the socket API ID. MFC after: 2 months.
* Add possibility to pass IPv6 packets to a divert(4) socket.glebius2011-06-272-57/+130
| | | | Submitted by: sem
* Export AddLink() function from libalias. It can be used when customae2011-06-224-39/+127
| | | | | | | | | | | alias address needs to be specified. Add inbound handler to the alias_ftp module. It helps handle active FTP transfer mode for the case with external clients and FTP server behind NAT. Fix passive FTP transfer case for server behind NAT using redirect with external IP address different from NAT ip address. PR: kern/157957 Submitted by: Alexander V. Chernikov
* Document PKT_ALIAS_SKIP_GLOBAL option.ae2011-06-221-1/+11
| | | | Submitted by: Alexander V. Chernikov
* Do not use SET_HOST_IPLEN() macro for IPv6 packets.ae2011-06-212-3/+3
| | | | | PR: kern/157239 MFC after: 2 weeks
* Fix a KASSERT from r212803 to check the correct length also in case ofbz2011-06-201-1/+8
| | | | | | | | IPsec being compiled in and used. Improve reporting by adding the length fields to the panic message, so that we would have some immediate debugging hints. Discussed with: jhb
* Remove a these days incorrect comment left from before new-arp.bz2011-06-181-1/+1
| | | | MFC after: 1 week
* Add SCTP_DEFAULT_PRINFO socket option.tuexen2011-06-163-0/+81
| | | | | | | Fix the SCTP_DEFAULT_SNDINFO socket option: Don't clear the PR SCTP policy when setting sinfo_flags. MFC after: 1 month.
* * Fix the handling of addresses in sctp_sendv().tuexen2011-06-161-0/+1
| | | | | | | * Add support for SCTP_SENDV_NOINFO. * Improve the error handling of sctp_sendv() and sctp_recv(). MFC after: 1 month
* Add support for the newly added SCTP API.tuexen2011-06-1510-611/+1656
| | | | | | | | | | | | | In particular add support for: * SCTP_SNDINFO, SCTP_PRINFO, SCTP_AUTHINFO, SCTP_DSTADDRV4, and SCTP_DSTADDRV6 cmsgs. * SCTP_NXTINFO and SCTP_RCVINFO cmgs. * SCTP_EVENT, SCTP_RECVRCVINFO, SCTP_RECVNXTINFO and SCTP_DEFAULT_SNDINFO socket option. * Special association ids (SCTP_FUTURE_ASSOC, ...) * sctp_recvv() and sctp_sendv() functions. MFC after: 1 month.
* Implement "global" mode for ipfw nat. It is similar to natd(8)ae2011-06-143-8/+54
| | | | | | | | | | | | | | | | "globalport" option for multiple NAT instances. If ipfw rule contains "global" keyword instead of nat_number, then for each outgoing packet ipfw_nat looks up translation state in all configured nat instances. If an entry is found, packet aliased according to that entry, otherwise packet is passed unchanged. User can specify "skip_global" option in NAT configuration to exclude an instance from the lookup in global mode. PR: kern/157867 Submitted by: Alexander V. Chernikov (previous version) Tested by: Eugene Grosbein
* Sort alias mode flags in the increasing order.ae2011-06-141-11/+11
|
* Add IPv6 support to the ipfw uid/gid check. Pass an ip_fw_args structureae2011-06-141-37/+53
| | | | | | | | | | | | to the check_uidgid() function, since it contains all needed arguments and also pointer to mbuf and now it is possible use in_pcblookup_mbuf() function. Since i can not test it for the non-FreeBSD case, i keep this ifdef unchanged. Tested by: Alexander V. Chernikov MFC after: 3 weeks
* Advance the advertised window (rcv_adv) to the currently received datajhb2011-06-131-1/+1
| | | | | | | | | | | | | | (rcv_nxt) if we advertising a zero window. This can be true when ACK'ing a window probe whose one byte payload was accepted rather than dropped because the socket's receive buffer was not completely full, but the remaining space was smaller than the window scale. This ensures that window probe ACKs satisfy the assumption made in r221346 and closes a window where rcv_nxt could be greater than rcv_adv. Tested by: trasz, pho, trociny Reviewed by: silby MFC after: 1 week
* Correct comments and debug logging in ipsec to better match reality.bz2011-06-082-2/+2
| | | | MFC after: 3 days
* Fix indentation.ae2011-06-071-4/+4
|
* Make a behaviour of the libalias based in-kernel NAT a bit closer toae2011-06-071-6/+16
| | | | | | | | | | | how natd(8) does work. natd(8) drops packets only when libalias returns PKT_ALIAS_IGNORED and "deny_incoming" option is set, but ipfw_nat always did drop packets that were not aliased, even if they should not be aliased and just are going through. PR: kern/122109, kern/129093, kern/157379 Submitted by: Alexander V. Chernikov (previous version) MFC after: 1 month
* Unbreak kernels with non-default PCBGROUP included but no WITNESS.bz2011-06-061-0/+1
| | | | | | | | Rather than including lock.h in in_pcbgroup.c in right order, fix it for all consumers of in_pcb.h by further header file pollution under #ifdef KERNEL. Reported by: Pan Tsu (inyaoo gmail.com)
* Implement a CPU-affine TCP and UDP connection lookup data structure,rwatson2011-06-069-13/+784
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | struct inpcbgroup. pcbgroups, or "connection groups", supplement the existing inpcbinfo connection hash table, which when pcbgroups are enabled, might now be thought of more usefully as a per-protocol 4-tuple reservation table. Connections are assigned to connection groups base on a hash of their 4-tuple; wildcard sockets require special handling, and are members of all connection groups. During a connection lookup, a per-connection group lock is employed rather than the global pcbinfo lock. By aligning connection groups with input path processing, connection groups take on an effective CPU affinity, especially when aligned with RSS work placement (see a forthcoming commit for details). This eliminates cache line migration associated with global, protocol-layer data structures in steady state TCP and UDP processing (with the exception of protocol-layer statistics; further commit to follow). Elements of this approach were inspired by Willman, Rixner, and Cox's 2006 USENIX paper, "An Evaluation of Network Stack Parallelization Strategies in Modern Operating Systems". However, there are also significant differences: we maintain the inpcb lock, rather than using the connection group lock for per-connection state. Likewise, the focus of this implementation is alignment with NIC packet distribution strategies such as RSS, rather than pure software strategies. Despite that focus, software distribution is supported through the parallel netisr implementation, and works well in configurations where the number of hardware threads is greater than the number of NIC input queues, such as in the RMI XLR threaded MIPS architecture. Another important difference is the continued maintenance of existing hash tables as "reservation tables" -- these are useful both to distinguish the resource allocation aspect of protocol name management and the more common-case lookup aspect. In configurations where connection tables are aligned with hardware hashes, it is desirable to use the traditional lookup tables for loopback or encapsulated traffic rather than take the expense of hardware hashes that are hard to implement efficiently in software (such as RSS Toeplitz). Connection group support is enabled by compiling "options PCBGROUP" into your kernel configuration; for the time being, this is an experimental feature, and hence is not enabled by default. Subject to the limited MFCability of change dependencies in inpcb, and its change to the inpcbinfo init function signature, this change in principle could be merged to FreeBSD 8.x. Reviewed by: bz Sponsored by: Juniper Networks, Inc.
* Do not return EINVAL when user does `ipfw set N flush` on an empty set.ae2011-06-061-3/+4
| | | | MFC after: 2 weeks
* - Implement RDNSS and DNSSL options (RFC 6106, IPv6 Router Advertisementhrs2011-06-061-2/+19
| | | | | | | | | | | | | | | | | | | | | Options for DNS Configuration) into rtadvd(8) and rtsold(8). DNS information received by rtsold(8) will go to resolv.conf(5) by resolvconf(8) script. This is based on work by J.R. Oldroyd (kern/156259) but revised extensively[1]. - rtadvd(8) now supports "noifprefix" to disable gathering on-link prefixes from interfaces when no "addr" is specified[2]. An entry in rtadvd.conf with "noifprefix" + no "addr" generates an RA message with no prefix information option. - rtadvd(8) now supports RTM_IFANNOUNCE message to fix crashes when an interface is added or removed. - Correct bogus ND_OPT_ROUTE_INFO value to one in RFC 4191. Reviewed by: bz[1] PR: kern/156259 [1] PR: bin/152458 [2]
* Add _mbuf() variants of various inpcb-related interfaces, including lookup,rwatson2011-06-045-16/+55
| | | | | | | | | | | | | | | | | | hash install, etc. For now, these are arguments are unused, but as we add RSS support, we will want to use hashes extracted from mbufs, rather than manually calculated hashes of header fields, due to the expensive of the software version of Toeplitz (and similar hashes). Add notes that it would be nice to be able to pass mbufs into lookup routines in pf(4), optimising firewall lookup in the same way, but the code structure there doesn't facilitate that currently. (In principle there is no reason this couldn't be MFCed -- the change extends rather than modifies the KBI. However, it won't be useful without other previous possibly less MFCable changes.) Reviewed by: bz Sponsored by: Juniper Networks, Inc.
* IP divert sockets use their inpcbinfo for port reservation, although notrwatson2011-06-041-0/+2
| | | | | | | | | | | | | | | | | | | for lookup. I missed its call to in_pcbbind() when preparing previous patches, which would lead to a lock assertion failure (although problem not an actual race condition due to global pcbinfo locks providing required synchronisation -- in this particular case only). This change adds the missing locking of the pcbhash lock. (Existing comments in the ipdivert code question the need for using the global hash to manage the namespace, as really it's a simple port namespace and not an address/port namespace. Also, although in_pcbbind is used to manage reservations, the hash tables aren't used for lookup. It might be a good idea to make them use hashed lookup, or to use a different reservation scheme.) Reviewed by: bz Reported by: Kristof Provost <kristof at sigsegv.be> Sponsored by: Juniper Networks
* Do not leak the pcbinfohash lock in the case where in6_pcbladdr() returnsrwatson2011-06-021-1/+1
| | | | | | | an error during TCP connect(2) on an IPv6 socket. Submitted by: bz Sponsored by: Juniper Networks, Inc.
* O_FORWARD_IP is only action which depends from the result of lookup ofae2011-06-011-1/+2
| | | | | | | | | | | | | | | | | | | | | dynamic rules. We are doing forwarding in the following cases: o For the simple ipfw fwd rule, e.g. fwd 10.0.0.1 ip from any to any out xmit em0 fwd 127.0.0.1,3128 tcp from any to any 80 in recv em1 o For the dynamic fwd rule, e.g. fwd 192.168.0.1 tcp from any to 10.0.0.3 3333 setup keep-state When this rule triggers it creates a dynamic rule, but this dynamic rule should forward packets only in forward direction. o And the last case that does not work before - simple fwd rule which triggers when some dynamic rule is already executed. PR: kern/147720, kern/150798 MFC after: 1 month
* Hide some debug messages under debug macro.ae2011-06-011-5/+5
| | | | MFC after: 1 week
* Hide useless warning under debug macro.ae2011-06-011-1/+2
| | | | | PR: kern/69963 MFC after: 1 week
* Unbreak NOINET kernels after r222488.bz2011-05-301-2/+2
| | | | | | | Reviewed by: rwatson Sponsored by: The FreeBSD Foundation Sponsored by: iXsystems! Pointy hat: to myself for missing this during review?
* Decompose the current single inpcbinfo lock into two locks:rwatson2011-05-3012-369/+424
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - The existing ipi_lock continues to protect the global inpcb list and inpcb counter. This lock is now relegated to a small number of allocation and free operations, and occasional operations that walk all connections (including, awkwardly, certain UDP multicast receive operations -- something to revisit). - A new ipi_hash_lock protects the two inpcbinfo hash tables for looking up connections and bound sockets, manipulated using new INP_HASH_*() macros. This lock, combined with inpcb locks, protects the 4-tuple address space. Unlike the current ipi_lock, ipi_hash_lock follows the individual inpcb connection locks, so may be acquired while manipulating a connection on which a lock is already held, avoiding the need to acquire the inpcbinfo lock preemptively when a binding change might later be required. As a result, however, lookup operations necessarily go through a reference acquire while holding the lookup lock, later acquiring an inpcb lock -- if required. A new function in_pcblookup() looks up connections, and accepts flags indicating how to return the inpcb. Due to lock order changes, callers no longer need acquire locks before performing a lookup: the lookup routine will acquire the ipi_hash_lock as needed. In the future, it will also be able to use alternative lookup and locking strategies transparently to callers, such as pcbgroup lookup. New lookup flags are, supplementing the existing INPLOOKUP_WILDCARD flag: INPLOOKUP_RLOCKPCB - Acquire a read lock on the returned inpcb INPLOOKUP_WLOCKPCB - Acquire a write lock on the returned inpcb Callers must pass exactly one of these flags (for the time being). Some notes: - All protocols are updated to work within the new regime; especially, TCP, UDPv4, and UDPv6. pcbinfo ipi_lock acquisitions are largely eliminated, and global hash lock hold times are dramatically reduced compared to previous locking. - The TCP syncache still relies on the pcbinfo lock, something that we may want to revisit. - Support for reverting to the FreeBSD 7.x locking strategy in TCP input is no longer available -- hash lookup locks are now held only very briefly during inpcb lookup, rather than for potentially extended periods. However, the pcbinfo ipi_lock will still be acquired if a connection state might change such that a connection is added or removed. - Raw IP sockets continue to use the pcbinfo ipi_lock for protection, due to maintaining their own hash tables. - The interface in6_pcblookup_hash_locked() is maintained, which allows callers to acquire hash locks and perform one or more lookups atomically with 4-tuple allocation: this is required only for TCPv6, as there is no in6_pcbconnect_setup(), which there should be. - UDPv6 locking remains significantly more conservative than UDPv4 locking, which relates to source address selection. This needs attention, as it likely significantly reduces parallelism in this code for multithreaded socket use (such as in BIND). - In the UDPv4 and UDPv6 multicast cases, we need to revisit locking somewhat, as they relied on ipi_lock to stablise 4-tuple matches, which is no longer sufficient. A second check once the inpcb lock is held should do the trick, keeping the general case from requiring the inpcb lock for every inpcb visited. - This work reminds us that we need to revisit locking of the v4/v6 flags, which may be accessed lock-free both before and after this change. - Right now, a single lock name is used for the pcbhash lock -- this is undesirable, and probably another argument is required to take care of this (or a char array name field in the pcbinfo?). This is not an MFC candidate for 8.x due to its impact on lookup and locking semantics. It's possible some of these issues could be worked around with compatibility wrappers, if necessary. Reviewed by: bz Sponsored by: Juniper Networks, Inc.
* Wrap long line.ae2011-05-301-1/+2
| | | | MFC after: 2 weeks
* Add tablearg support for ipfw setfib.ae2011-05-302-4/+11
| | | | | PR: kern/156410 MFC after: 2 weeks
* Get rid of unused functions.tuexen2011-05-294-127/+0
| | | | MFC after: 1 week.
* Supply the LLE_STATIC flag bit to in_ifscurb() when scrubbing interfaceqingli2011-05-291-8/+17
| | | | | | | | address so that proper clean up will take place in the routing code. This patch fixes the bootp panic on startup problem. Also, added more error handling and logging code in function in_scrubprefix(). MFC after: 5 days
* Add FEATURE() definitions for IPv4 and IPv6 so that we can usebz2011-05-251-0/+2
| | | | | | | | | | feature_present(3) to dynamically decide whether to use one or the other family. Reviewed by: gnn Sponsored by: The FreeBSD Foundation Sponsored by: iXsystems MFC after: 10 days
* An inpcb lock is no longer required in in_pcbref() since the move torwatson2011-05-241-2/+0
| | | | | | | refcount(9). MFC after: 3 weeks Sponsored by: Juniper Networks, Inc.
* Continue to refine inpcb reference counting and locking, in preparation forrwatson2011-05-232-63/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reworking of inpcbinfo locking: (1) Convert inpcb reference counting from manually manipulated integers to the refcount(9) KPI. This allows the refcount to be managed atomically with an inpcb read lock rather than write lock, or even with no inpcb lock at all. As a result, in_pcbref() also no longer requires an inpcb lock, so can be performed solely using the lock used to look up an inpcb. (2) Shift more inpcb freeing activity from the in_pcbrele() context (via in_pcbfree_internal) to the explicit in_pcbfree() context. This means that the inpcb refcount is increasingly used only to maintain memory stability, not actually defer the clean up of inpcb protocol parts. This is desirable as many of those protocol parts required the pcbinfo lock, which we'd like not to acquire in in_pcbrele() contexts. Document this in comments better. (3) Introduce new read-locked and write-locked in_pcbrele() variations, in_pcbrele_rlocked() and in_pcbrele_wlocked(), which allow the inpcb to be properly unlocked as needed. in_pcbrele() is a wrapper around the latter, and should probably go away at some point. This makes it easier to use this weak reference model when holding only a read lock, as will happen in the future. This may well be safe to MFC, but some more KBI analysis is required. Reviewed by: bz MFC after: 3 weeks Sponsored by: Juniper Networks, Inc.
* Move from passing a wildcard boolean to a general set up lookup flags intorwatson2011-05-231-12/+18
| | | | | | | | | | | | | in_pcb_lport(), in_pcblookup_local(), and in_pcblookup_hash(), and similarly for IPv6 functions. In the future, we would like to support other flags relating to locking strategy. This change doesn't appear to modify the KBI in practice, as callers already passed in INPLOOKUP_WILDCARD rather than a simple boolean. MFC after: 3 weeks Reviewed by: bz Sponsored by: Juniper Networks, Inc.
* A number of quite incremental refinements to struct inpcbinfo's definition:rwatson2011-05-231-20/+41
| | | | | | | | | | | | | | (1) Add a locking guide for inpcbinfo. (2) Annotate inpcbinfo fields with synchronisation information; not all annotations are 100% satisfactory. (3) Reorder inpcbinfo fields so that the lock is at the head of the structure, and close to fields it protects. (4) Sort fields that will eventually be hashlock/pcbgroup-related together even though they remain locked by ipi_lock for now. Reviewed by: bz Sponsored by: Juniper Networks X-MFC after: KBI analysis required
* The statically configured (permanent) ARP entries are removed when anqingli2011-05-203-18/+33
| | | | | | | | | | interface is brought down, even though the interface address is still valid. This patch maintains the permanent ARP entries as long as the interface address (having the same prefix as that of the ARP entries) is valid. Reviewed by: delphij MFC after: 5 days
OpenPOWER on IntegriCloud