summaryrefslogtreecommitdiffstats
path: root/sys/netinet
Commit message (Collapse)AuthorAgeFilesLines
* Document data structures and operation on dummynet so next timeluigi2001-01-171-42/+117
| | | | | I or someone else browse through this code I do not have a hard time understanding what is going on.
* Some dummynet patches that I forgot to commit last summer.luigi2001-01-162-34/+75
| | | | | | One of them fixes a potential panic when bridging is used and you run out of mbufs (though i have no idea if the bug has ever hit anyone).
* Prototype inet_ntoa_r and thereby silence a warning from GCC. The functionbmilekic2001-01-121-0/+1
| | | | is prototyped immediately under inet_ntoa, which is also from libkern.
* o Minor style(9)ism to make consistent with -STABLErwatson2001-01-091-1/+1
|
* o IPFW incorrectly handled filtering in the presence of previouslyrwatson2001-01-093-8/+18
| | | | | | | | | | | | | | | | | | | | reserved and now allocated TCP flags in incoming packets. This patch stops overloading those bits in the IP firewall rules, and moves colliding flags to a seperate field, ipflg. The IPFW userland management tool, ipfw(8), is updated to reflect this change. New TCP flags related to ECN are now included in tcp.h for reference, although we don't currently implement TCP+ECN. o To use this fix without completely rebuilding, it is sufficient to copy ip_fw.h and tcp.h into your appropriate include directory, then rebuild the ipfw kernel module, and ipfw tool, and install both. Note that a mismatch between module and userland tool will result in incorrect installation of firewall rules that may have unexpected effects. This is an MFC candidate, following shakedown. This bug does not appear to affect ipfilter. Reviewed by: security-officer, billf Reported by: Aragon Gouveia <aragon@phat.za.net>
* provide a sysctl 'net.link.ether.inet.log_arp_wrong_iface' to allow onealfred2001-01-061-0/+7
| | | | | | | | to supress logging when ARP replies arrive on the wrong interface: "/kernel: arp: 1.2.3.4 is on dc0 but got reply from 00:00:c5:79:d0:0c on dc1" the default is to log just to give notice about possibly incorrectly configured networks.
* Fix incorrect logic wouldn't disconnect incomming connections that had beenalfred2001-01-031-1/+1
| | | | | | disconnected because they were not full. Submitted by: David Filo
* include tcp header files to get the prototype for tcp_seq_vs_sessassar2000-12-271-0/+2
|
* Update the "icmp_admin_prohib_like_rst" code to check the tcp-window andphk2000-12-246-22/+144
| | | | | | | to be configurable with respect to acting only in SYN or in all TCP states. PR: 23665 Submitted by: Jesper Skriver <jesper@skriver.dk>
* * Rename M_WAIT mbuf subsystem flag to M_TRYWAIT.bmilekic2000-12-212-2/+2
| | | | | | | | | | | | | | | | | | This is because calls with M_WAIT (now M_TRYWAIT) may not wait forever when nothing is available for allocation, and may end up returning NULL. Hopefully we now communicate more of the right thing to developers and make it very clear that it's necessary to check whether calls with M_(TRY)WAIT also resulted in a failed allocation. M_TRYWAIT basically means "try harder, block if necessary, but don't necessarily wait forever." The time spent blocking is tunable with the kern.ipc.mbuf_wait sysctl. M_WAIT is now deprecated but still defined for the next little while. * Fix a typo in a comment in mbuf.h * Fix some code that was actually passing the mbuf subsystem's M_WAIT to malloc(). Made it pass M_WAITOK instead. If we were ever to redefine the value of the M_WAIT flag, this could have became a big problem.
* Use getmicrotime() instead of microtime() when timestamping ICMP packets,billf2000-12-161-1/+1
| | | | | | | the former is quicker and accurate enough for use here. Submitted by: Jason Slagle <raistlin@toledolink.com> (on IRC) Reviewed by: phk
* We currently does not react to ICMP administratively prohibitedphk2000-12-164-0/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | messages send by routers when they deny our traffic, this causes a timeout when trying to connect to TCP ports/services on a remote host, which is blocked by routers or firewalls. rfc1122 (Requirements for Internet Hosts) section 3.2.2.1 actually requi re that we treat such a message for a TCP session, that we treat it like if we had recieved a RST. quote begin. A Destination Unreachable message that is received MUST be reported to the transport layer. The transport layer SHOULD use the information appropriately; for example, see Sections 4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. quote end. I've written a small extension that implement this, it also create a sysctl "net.inet.tcp.icmp_admin_prohib_like_rst" to control if this new behaviour is activated. When it's activated (set to 1) we'll treat a ICMP administratively prohibited message (icmp type 3 code 9, 10 and 13) for a TCP sessions, as if we recived a TCP RST, but only if the TCP session is in SYN_SENT state. The reason for only reacting when in SYN_SENT state, is that this will solve the problem, and at the same time minimize the risk of this being abused. I suggest that we enable this new behaviour by default, but it would be a change of current behaviour, so if people prefer to leave it disabled by default, at least for now, this would be ok for me, the attached diff actually have the sysctl set to 0 by default. PR: 23086 Submitted by: Jesper Skriver <jesper@skriver.dk>
* Change the following:bmilekic2000-12-155-11/+43
| | | | | | | | | | | | | | | | 1. ICMP ECHO and TSTAMP replies are now rate limited. 2. RSTs generated due to packets sent to open and unopen ports are now limited by seperate counters. 3. Each rate limiting queue now has its own description, as follows: Limiting icmp unreach response from 439 to 200 packets per second Limiting closed port RST response from 283 to 200 packets per second Limiting open port RST response from 18724 to 200 packets per second Limiting icmp ping response from 211 to 200 packets per second Limiting icmp tstamp response from 394 to 200 packets per second Submitted by: Mike Silbersack <silby@silby.com>
* Convert more malloc+bzero to malloc+M_ZERO.dwmalone2000-12-087-30/+20
| | | | | Submitted by: josh@zipperup.org Submitted by: Robert Drehmel <robd@gmx.net>
* Staticize some malloc M_ instances.phk2000-12-081-1/+1
|
* Lock down the network interface queues. The queue mutex must be obtainedjlemon2000-11-254-26/+17
| | | | | | | | | | | | | | before adding/removing packets from the queue. Also, the if_obytes and if_omcasts fields should only be manipulated under protection of the mutex. IF_ENQUEUE, IF_PREPEND, and IF_DEQUEUE perform all necessary locking on the queue. An IF_LOCK macro is provided, as well as the old (mutex-less) versions of the macros in the form _IF_ENQUEUE, _IF_QFULL, for code which needs them, but their use is discouraged. Two new macros are introduced: IF_DRAIN() to drain a queue, and IF_HANDOFF, which takes care of locking/enqueue, and also statistics updating/start if necessary.
* Revert the last commit to the callout interface, and add a flag tojlemon2000-11-252-10/+10
| | | | | | | callout_init() indicating whether the callout is safe or not. Update the callers of callout_init() to reflect the new interface. Okayed by: Jake
* Fixup (hopefully) bridging + ipfw + dummynet together...bmilekic2000-11-231-5/+5
| | | | | | | | | | | | | | | | | | * Some dummynet code incorrectly handled a malloc()-allocated pseudo-mbuf header structure, called "pkt," and could consequently pollute the mbuf free list if it was ever passed to m_freem(). The fix involved passing not pkt, but essentially pkt->m_next (which is a real mbuf) to the mbuf utility routines. * Also, for dummynet, in bdg_forward(), made the code copy the ethernet header back into the mbuf (prepended) because the dummynet code that follows expects it to be there but it is, unfortunately for dummynet, passed to bdg_forward as a seperate argument. PRs: kern/19551 ; misc/21534 ; kern/23010 Submitted by: Thomas Moestl <tmoestl@gmx.net> Reviewed by: bmilekic Approved by: luigi
* mdoc(7) police: use the new feature of the An macro.ru2000-11-221-24/+14
|
* While I'm here, get rid of (now useless) MCLISREFERENCED and use MEXT_IS_REFbmilekic2000-11-111-6/+2
| | | | | | | | | instead. Also, fix a small set of "avail." If we're setting `avail,' we shouldn't be re-checking whether m_flags is M_EXT, because we know that it is, as if it wasn't, we would have already returned several lines above. Reviewed by: jlemon
* Fixed the security breach I introduced in rev 1.145.ru2000-11-071-3/+3
| | | | | | Disallow getsockopt(IP_FW_ADD) if securelevel >= 3. PR: 22600
* tp->snd_recover is part of the New Reno recovery algorithm, and shouldjlemon2000-11-042-2/+12
| | | | | | | | | | | | | only be checked if the system is currently performing New Reno style fast recovery. However, this value was being checked regardless of the NR state, with the end result being that the congestion window was never opened. Change the logic to check t_dupack instead; the only code path that allows it to be nonzero at this point is NewReno, so if it is nonzero, we are in fast recovery mode and should not touch the congestion window. Tested by: phk
* Fixed the bug I have introduced in icmp_error() in revision 1.44.ru2000-11-021-1/+1
| | | | | | The amount of data we copy from the original IP datagram into the ICMP message was computed incorrectly for IP packets with payload less than 8 bytes.
* Wrong checksum may have been computed for certain UDP packets.ru2000-11-011-1/+1
| | | | Reviewed by: jlemon
* Wrong checksum used for certain reassembled IP packets before diverting.ru2000-11-011-1/+4
|
* It's no longer true that "nobody uses ia beyond here"; it's nowjoe2000-11-011-1/+1
| | | | | | used to keep address based if_data statistics in. Submitted by: ru
* Do not waste a time saving a copy of IP header if we are certainlyru2000-10-311-1/+2
| | | | not going to send an ICMP error message (net.inet.udp.blackhole=1).
* Added boolean argument to link searching functions, indicatingru2000-10-307-107/+42
| | | | whether they should create a link if lookup has failed or not.
* A significant rewrite of PPTP aliasing code.ru2000-10-304-151/+265
| | | | | | | | | | | | | | PPTP links are no longer dropped by simple (and inappropriate in this case) "inactivity timeout" procedure, only when requested through the control connection. It is now possible to have multiple PPTP servers running behind NAT. Just redirect the incoming TCP traffic to port 1723, everything else is done transparently. Problems were reported and the fix was tested by: Michael Adler <Michael.Adler@compaq.com>, David Andersen <dga@lcs.mit.edu>
* Move suser() and suser_xxx() prototypes and a related #define fromphk2000-10-294-4/+0
| | | | | | | | | <sys/proc.h> to <sys/systm.h>. Correctly document the #includes needed in the manpage. Add one now needed #include of <sys/systm.h>. Remove the consequent 48 unused #includes of <sys/proc.h>.
* Remove unneeded #include <sys/proc.h> lines.phk2000-10-292-2/+0
|
* Fix conflicts creted by import.darrenr2000-10-298-41/+51
|
* Count per-address statistics for IP fragments.joe2000-10-291-2/+6
| | | | | Requested by: ru Obtained from: BSD/OS
* Include sys/param.h for `__FreeBSD_version' rather than the non-existentobrien2000-10-271-2/+2
| | | | | | osreldate.h. Submitted by: dougb
* Convert all users of fldoff() to offsetof(). fldoff() is badphk2000-10-276-11/+0
| | | | | | | | | | | | | | | | | | | | | | | because it only takes a struct tag which makes it impossible to use unions, typedefs etc. Define __offsetof() in <machine/ansi.h> Define offsetof() in terms of __offsetof() in <stddef.h> and <sys/types.h> Remove myriad of local offsetof() definitions. Remove includes of <stddef.h> in kernel code. NB: Kernelcode should *never* include from /usr/include ! Make <sys/queue.h> include <machine/ansi.h> to avoid polluting the API. Deprecate <struct.h> with a warning. The warning turns into an error on 01-12-2000 and the file gets removed entirely on 01-01-2001. Paritials reviews by: various. Significant brucifications by: bde
* Fetch the protocol header (TCP, UDP, ICMP) only from the first fragmentru2000-10-271-16/+11
| | | | | | | | of IP datagram. This fixes the problem when firewall denied fragmented packets whose last fragment was less than minimum protocol header size. Found by: Harti Brandt <brandt@fokus.gmd.de> PR: kern/22309
* RFC 791 says that IP_RF bit should always be zero, but nothingru2000-10-261-52/+29
| | | | | | | | in the code enforces this. So, do not check for and attempt a false reassembly if only IP_RF is set. Also, removed the dead code, since we no longer use dtom() on return from ip_reass().
* fix conflicts from rcsidsdarrenr2000-10-2614-178/+599
|
* Wrong header length used for certain reassembled IP packets.ru2000-10-261-2/+2
| | | | | | This was first fixed in rev 1.82 but then broken in rev 1.125. PR: 6177
* Close PR22152 and PR19511 -- correct the naming of a variableluigi2000-10-261-1/+1
|
* We now keep the ip_id field in network byte order all theru2000-10-251-0/+4
| | | | | | | time, so there is no need to make the distinction between ip_output() and ip_input() cases. Reviewed by: silence on freebsd-net
* be careful on mbuf overrun on ctlinput.itojun2000-10-232-2/+12
| | | | | short icmp6 packet may be able to panic the kernel. sync with kame.
* Save a few CPU cycles in IP fragmentation code.ru2000-10-201-3/+1
|
* Augment the 'ifaddr' structure with a 'struct if_data' to keepjoe2000-10-192-1/+13
| | | | | | | | | | | statistics on a per network address basis. Teach the IPv4 and IPv6 input/output routines to log packets/bytes against the network address connected to the flow. Teach netstat to display the per-address stats for IP protocols when 'netstat -i' is evoked, instead of displaying the per-interface stats.
* A failure to allocate memory for auxiliary TCP data is now fatal.ru2000-10-191-16/+15
| | | | | This fixes a null pointer dereference problem that is unlikely to happen in normal circumstances.
* If we do not byte-swap the ip_id in the first place, don't do it inru2000-10-181-0/+2
| | | | | the second. NetBSD (from where I've taken this originally) needs to fix this too.
* Backout my wrong attempt to fix the compilation warning in ip_input.cru2000-10-121-1/+1
| | | | | | | | | | and instead reapply the revision 1.49 of mbuf.h, i.e. Fixed regression of the type of the `header' member of struct pkthdr from `void *' to caddr_t in rev.1.51. This mainly caused an annoying warning for compiling ip_input.c. Requested by: bde
* Fix the compilation warning.ru2000-10-121-1/+1
|
* Allow for IP_FW_ADD to be used in getsockopt(2) incarnation asru2000-10-122-1/+4
| | | | | | | well, in which case return the rule number back into userland. PR: bin/18351 Reviewed by: archie, luigi
* Remove headers not needed.alfred2000-10-072-26/+0
| | | | Pointed out by: phk
OpenPOWER on IntegriCloud