summaryrefslogtreecommitdiffstats
path: root/sys/netinet
Commit message (Collapse)AuthorAgeFilesLines
* Temporary feature: Runtime tuneable tcp initial sequence numbersilby2001-07-088-6/+77
| | | | | | | | | | | | | | | | | | generation scheme. Users may now select between the currently used OpenBSD algorithm and the older random positive increment method. While the OpenBSD algorithm is more secure, it also breaks TIME_WAIT handling; this is causing trouble for an increasing number of folks. To switch between generation schemes, one sets the sysctl net.inet.tcp.tcp_seq_genscheme. 0 = random positive increments, 1 = the OpenBSD algorithm. 1 is still the default. Once a secure _and_ compatible algorithm is implemented, this sysctl will be removed. Reviewed by: jlemon Tested by: numerous subscribers of -net
* gif(4) and stf(4) modernization:brooks2001-07-023-52/+4
| | | | | | | | | | | - Remove gif dependencies from stf. - Make gif and stf into modules - Make gif cloneable. PR: kern/27983 Reviewed by: ru, ume Obtained from: NetBSD MFC after: 1 week
* While in there fixing a fragment logging bug, fix it so we logcjc2001-07-021-8/+11
| | | | | | | | | | | | | | | | | | fragments "right." Log fragment information tcpdump(8)-style, Jul 1 19:38:45 bubbles /boot/kernel/kernel: ipfw: 1000 Accept ICMP:8.0 192.168.64.60 192.168.64.20 in via ep0 (frag 53113:1480@0+) That is, instead of the old, ... Fragment = <offset/8> Do, ... (frag <IP ID>:<data len>@<offset>[+]) PR: kern/23446 Approved by: ru MFC after: 1 week
* Backout CSRG revision 7.22 to this file (if in_losing notices anru2001-06-291-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RTF_DYNAMIC route, it got freed twice). I am not sure what was the actual problem in 1992, but the current behavior is memory leak if PCB holds a reference to a dynamically created/modified routing table entry. (rt_refcnt>0 and we don't call rtfree().) My test bed was: 1. Set net.inet.tcp.msl to a low value (for test purposes), e.g., 5 seconds, to speed up the transition of TCP connection to a "closed" state. 2. Add a network route which causes ICMP redirect from the gateway. 3. ping(8) host H that matches this route; this creates RTF_DYNAMIC RTF_HOST route to H. (I was forced to use ICMP to cause gateway to generate ICMP host redirect, because gateway in question is a 4.2-STABLE system vulnerable to a problem that was fixed later in ip_icmp.c,v 1.39.2.6, and TCP packets with DF bit set were triggering this bug.) 4. telnet(1) to H 5. Block access to H with ipfw(8) 6. Send something in telnet(1) session; this causes EPERM, followed by an in_losing() call in a few seconds. 7. Delete ipfw(8) rule blocking access to H, and wait for TCP connection moving to a CLOSED state; PCB is freed. 8. Delete host route to H. 9. Watch with netstat(1) that `rttrash' increased. 10. Repeat steps 3-9, and watch `rttrash' increases. PR: kern/25421 MFC after: 2 weeks
* Fixed the brain-o in rev. 1.10: the logic check was reversed.ru2001-06-271-1/+1
| | | | Reported by: Bernd Fuerwitt <bf@fuerwitt.de>
* Bring in fix from NetBSD's revision 1.16:ru2001-06-261-1/+7
| | | | | | | Pass the correct destination address for the route-to-gateway case. PR: kern/10607 MFC after: 2 weeks
* Allow getcred sysctl to work in jailed root processes. Processes candwmalone2001-06-243-17/+35
| | | | | | | | only do getcred calls for sockets which were created in the same jail. This should allow the ident to work in a reasonable way within jails. PR: 28107 Approved by: des, rwatson
* Replace bzero() of struct ip with explicit zeroing of structure members,jlemon2001-06-232-4/+12
| | | | which is faster.
* Add netstat(1) knob to reset net.inet.{ip|icmp|tcp|udp|igmp}.stats.ru2001-06-236-6/+6
| | | | | | For example, ``netstat -s -p ip -z'' will show and reset IP stats. PR: bin/17338
* Eliminate the allocation of a tcp template structure for eachsilby2001-06-238-135/+122
| | | | | | | | | | | | connection. The information contained in a tcptemp can be reconstructed from a tcpcb when needed. Previously, tcp templates required the allocation of one mbuf per connection. On large systems, this change should free up a large number of mbufs. Reviewed by: bmilekic, jlemon, ru MFC after: 2 weeks
* - Renumber KAME local ICMP types and NDP options numberes beacaues theysumikawa2001-06-211-6/+8
| | | | | | | | | are duplicated by newly defined types/options in RFC3121 - We have no backward compatibility issue. There is no apps in our distribution which use the above types/options. Obtained from: KAME MFC after: 2 weeks
* made sure to use the correct sa_len for rtalloc().ume2001-06-202-4/+4
| | | | | | | | | | sizeof(ro_dst) is not necessarily the correct one. this change would also fix the recent path MTU discovery problem for the destination of an incoming TCP connection. Submitted by: JINMEI Tatuya <jinmei@kame.net> Obtained from: KAME MFC after: 2 weeks
* Do not perform arp send/resolve on an interface marked NOARP.jlemon2001-06-151-1/+9
| | | | | PR: 25006 MFC after: 2 weeks
* Fix a stack of KAME netinet6/in6.h warnings:peter2001-06-151-2/+4
| | | | | 592: warning: `struct mbuf' declared inside parameter list 595: warning: `struct ifnet' declared inside parameter list
* Sync with recent KAME.ume2001-06-1122-459/+697
| | | | | | | | | | | | | | | | | | This work was based on kame-20010528-freebsd43-snap.tgz and some critical problem after the snap was out were fixed. There are many many changes since last KAME merge. TODO: - The definitions of SADB_* in sys/net/pfkeyv2.h are still different from RFC2407/IANA assignment because of binary compatibility issue. It should be fixed under 5-CURRENT. - ip6po_m member of struct ip6_pktopts is no longer used. But, it is still there because of binary compatibility issue. It should be removed under 5-CURRENT. Reviewed by: itojun Obtained from: KAME MFC after: 3 weeks
* Make the default value of net.inet.ip.maxfragpackets andjesper2001-06-101-2/+3
| | | | | | | | net.inet6.ip6.maxfragpackets dependent on nmbclusters, defaulting to nmbclusters / 4 Reviewed by: bde MFC after: 1 week
* "Fix" the previous initial attempt at fixing TUNABLE_INT(). This timepeter2001-06-082-2/+2
| | | | | | | around, use a common function for looking up and extracting the tunables from the kernel environment. This saves duplicating the same function over and over again. This way typically has an overhead of 8 bytes + the path string, versus about 26 bytes + the path string.
* Move IPFilter into contrib.jlemon2001-06-0720-14535/+0
|
* Back out part of my previous commit. This was a last minute changepeter2001-06-072-2/+2
| | | | | and I botched testing. This is a perfect example of how NOT to do this sort of thing. :-(
* Make the TUNABLE_*() macros look and behave more consistantly like thepeter2001-06-062-4/+4
| | | | | SYSCTL_*() macros. TUNABLE_INT_DECL() was an odd name because it didn't actually declare the int, which is what the name suggests it would do.
* Silby's take one on increasing FreeBSD's resistance to SYN floods:jesper2001-06-062-2/+28
| | | | | | | | | | | | | | | | | | | One way we can reduce the amount of traffic we send in response to a SYN flood is to eliminate the RST we send when removing a connection from the listen queue. Since we are being flooded, we can assume that the majority of connections in the queue are bogus. Our RST is unwanted by these hosts, just as our SYN-ACK was. Genuine connection attempts will result in hosts responding to our SYN-ACK with an ACK packet. We will automatically return a RST response to their ACK when it gets to us if the connection has been dropped, so the early RST doesn't serve the genuine class of connections much. In summary, we can reduce the number of packets we send by a factor of two without any loss in functionality by ensuring that RST packets are not sent when dropping a connection from the listen queue. Submitted by: Mike Silbersack <silby@silby.com> Reviewed by: jesper MFC after: 2 weeks
* Add BSD-style copyright headersbrian2001-06-049-17/+253
| | | | Approved by: Charles Mott <cmott@scientech.com>
* Change to a standard BSD-style copyrightbrian2001-06-041-13/+22
| | | | Approved by: Atsushi Murai <amurai@spec.co.jp>
* Prevent denial of service using bogus fragmented IPv4 packets.jesper2001-06-031-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | A attacker sending a lot of bogus fragmented packets to the target (with different IPv4 identification field - ip_id), may be able to put the target machine into mbuf starvation state. By setting a upper limit on the number of reassembly queues we prevent this situation. This upper limit is controlled by the new sysctl net.inet.ip.maxfragpackets which defaults to 200, as the IPv6 case, this should be sufficient for most systmes, but you might want to increase it if you have lots of TCP sessions. I'm working on making the default value dependent on nmbclusters. If you want old behaviour (no upper limit) set this sysctl to a negative value. If you don't want to accept any fragments (not recommended) set the sysctl to 0 (zero). Obtained from: NetBSD MFC after: 1 week
* Add ``options RANDOM_IP_ID'' which randomizes the ID field of IP packets.kris2001-06-016-0/+234
| | | | | | | | | This closes a minor information leak which allows a remote observer to determine the rate at which the machine is generating packets, since the default behaviour is to increment a counter for each packet sent. Reviewed by: -net Obtained from: OpenBSD
* Back out jesper's 2001/05/31 14:58:11 PDT commit. It does not compile.obrien2001-06-011-31/+0
|
* Prevent denial of service using bogus fragmented IPv4 packets.jesper2001-05-311-0/+31
| | | | | | | | | | | | | | | | | | | | | A attacker sending a lot of bogus fragmented packets to the target (with different IPv4 identification field - ip_id), may be able to put the target machine into mbuf starvation state. By setting a upper limit on the number of reassembly queues we prevent this situation. This upper limit is controlled by the new sysctl net.inet.ip.maxfragpackets which defaults to NMBCLUSTERS/4 If you want old behaviour (no upper limit) set this sysctl to a negative value. If you don't want to accept any fragments (not recommended) set the sysctl to 0 (zero) Obtained from: NetBSD (partially) MFC after: 1 week
* Disable rfc1323 and rfc1644 TCP extensions if we havn't gotjesper2001-05-311-0/+9
| | | | | | | | | | | | any response to our third SYN to work-around some broken terminal servers (most of which have hopefully been retired) that have bad VJ header compression code which trashes TCP segments containing unknown-to-them TCP options. PR: kern/1689 Submitted by: jesper Reviewed by: wollman MFC after: 2 weeks
* Add an integer field to keep protocol-specific flags with links.ru2001-05-303-15/+20
| | | | | | | | | | For FTP control connection, keep the CRLF end-of-line termination status in there. Fixed the bug when the first FTP command in a session was ignored. PR: 24048 MFC after: 1 week
* Inline TCP_REASS() in the single location where it's used,jesper2001-05-292-66/+60
| | | | | | | | just as OpenBSD and NetBSD has done. No functional difference. MFC after: 2 weeks
* properly delay acks in half-closed TCP connectionsjesper2001-05-292-2/+2
| | | | | | PR: 24962 Submitted by: Tony Finch <dot@dotat.at> MFC after: 2 weeks
* In in_ifadown(), differentiate between whether the interface goesru2001-05-114-11/+15
| | | | | | | down or interface address is deleted. Only delete static routes in the latter case. Reported by: Alexander Leidinger <Alexander@leidinger.net>
* Undo part of the tangle of having sys/lock.h and sys/mutex.h included inmarkm2001-05-011-2/+4
| | | | | | | | | | | other "system" header files. Also help the deprecation of lockmgr.h by making it a sub-include of sys/lock.h and removing sys/lockmgr.h form kernel .c files. Sort sys/*.h includes where possible in affected files. OK'ed by: bde (with reservations)
* Say goodbye to TCP_COMPAT_42jesper2001-04-207-73/+0
| | | | | Reviewed by: wollman Requested by: wollman
* Randomize the TCP initial sequence numbers more thoroughly.kris2001-04-178-8/+161
| | | | | Obtained from: OpenBSD Reviewed by: jesper, peter, -developers
* fix security hole created by fragment cachedarrenr2001-04-065-10/+36
|
* pipe/queue are the only consumers of flow_id, so only set it in those casesbillf2001-04-061-1/+1
|
* MFC candidate.jesper2001-03-283-3/+5
| | | | | | | | | | | | | Change code from PRC_UNREACH_ADMIN_PROHIB to PRC_UNREACH_PORT for ICMP_UNREACH_PROTOCOL and ICMP_UNREACH_PORT And let TCP treat PRC_UNREACH_PORT like PRC_UNREACH_ADMIN_PROHIB This should fix the case where port unreachables for udp returned ENETRESET instead of ECONNREFUSED Problem found by: Bill Fenner <fenner@research.att.com> Reviewed by: jlemon
* MAN[1-9] -> MAN.ru2001-03-271-1/+1
|
* Add a missing m_pullup() before a mtod() in in_arpinput().yar2001-03-271-0/+6
| | | | | PR: kern/22177 Reviewed by: wollman
* Replace dyn_fin_lifetime with dyn_ack_lifetime for half-closed state.simokawa2001-03-271-1/+1
| | | | | | | Half-closed state could last long for some connections and fin_lifetime (default 20sec) is too short for that. OK'ed by: luigi
* Send the remains (such as I have located) of "block major numbers" tophk2001-03-261-1/+0
| | | | the bit-bucket.
* Make header files conform to style(9).brian2001-03-256-326/+311
| | | | | | Reviewed by (*): bde (*) alias_local.h only got a cursory glance.
* Remove an extraneous declaration.brian2001-03-251-1/+0
|
* IPv4 address is not unsigned int. This change introduces in_addr_t.ume2001-03-231-1/+1
| | | | | | | PR: 9982 Adviced by: des Reviewed by: -alpha and -net (no objection) Obtained from: OpenBSD
* Remove (non-protected) variable names from function prototypes.brian2001-03-221-7/+5
|
* Only flush rules that have a rule number above that set by a newpaul2001-03-211-8/+17
| | | | | | | | | | | sysctl, net.inet.ip.fw.permanent_rules. This allows you to install rules that are persistent across flushes, which is very useful if you want a default set of rules that maintains your access to remote machines while you're reconfiguring the other rules. Reviewed by: Mark Murray <markm@FreeBSD.org>
* Axe TCP_RESTRICT_RST. It was never a particularly good idea except for a fewdes2001-03-192-24/+2
| | | | | | | very specific scenarios, and now that we have had net.inet.tcp.blackhole for quite some time there is really no reason to use it any more. (last of three commits)
* Invalidate cached forwarding route (ipforward_rt) whenever a new routeru2001-03-193-1/+14
| | | | | | | | is added to the routing table, otherwise we may end up using the wrong route when forwarding. PR: kern/10778 Reviewed by: silence on -net
* Make sure the cached forwarding route (ipforward_rt) is still up beforeru2001-03-181-19/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | using it. Not checking this may have caused the wrong IP address to be used when processing certain IP options (see example below). This also caused the wrong route to be passed to ip_output() when forwarding, but fortunately ip_output() is smart enough to detect this. This example demonstrates the wrong behavior of the Record Route option observed with this bug. Host ``freebsd'' is acting as the gateway for the ``sysv''. 1. On the gateway, we add the route to the destination. The new route will use the primary address of the loopback interface, 127.0.0.1: : freebsd# route add 10.0.0.66 -iface lo0 -reject : add host 10.0.0.66: gateway lo0 2. From the client, we ping the destination. We see the correct replies. Please note that this also causes the relevant route on the ``freebsd'' gateway to be cached in ipforward_rt variable: : sysv# ping -snv 10.0.0.66 : PING 10.0.0.66: 56 data bytes : ICMP Host Unreachable from gateway 192.168.0.115 : ICMP Host Unreachable from gateway 192.168.0.115 : ICMP Host Unreachable from gateway 192.168.0.115 : : ----10.0.0.66 PING Statistics---- : 3 packets transmitted, 0 packets received, 100% packet loss 3. On the gateway, we delete the route to the destination, thus making the destination reachable through the `default' route: : freebsd# route delete 10.0.0.66 : delete host 10.0.0.66 4. From the client, we ping destination again, now with the RR option turned on. The surprise here is the 127.0.0.1 in the first reply. This is caused by the bug in ip_rtaddr() not checking the cached route is still up befor use. The debug code also shows that the wrong (down) route is further passed to ip_output(). The latter detects that the route is down, and replaces the bogus route with the valid one, so we see the correct replies (192.168.0.115) on further probes: : sysv# ping -snRv 10.0.0.66 : PING 10.0.0.66: 56 data bytes : 64 bytes from 10.0.0.66: icmp_seq=0. time=10. ms : IP options: <record route> 127.0.0.1, 10.0.0.65, 10.0.0.66, : 192.168.0.65, 192.168.0.115, 192.168.0.120, : 0.0.0.0(Current), 0.0.0.0, 0.0.0.0 : 64 bytes from 10.0.0.66: icmp_seq=1. time=0. ms : IP options: <record route> 192.168.0.115, 10.0.0.65, 10.0.0.66, : 192.168.0.65, 192.168.0.115, 192.168.0.120, : 0.0.0.0(Current), 0.0.0.0, 0.0.0.0 : 64 bytes from 10.0.0.66: icmp_seq=2. time=0. ms : IP options: <record route> 192.168.0.115, 10.0.0.65, 10.0.0.66, : 192.168.0.65, 192.168.0.115, 192.168.0.120, : 0.0.0.0(Current), 0.0.0.0, 0.0.0.0 : : ----10.0.0.66 PING Statistics---- : 3 packets transmitted, 3 packets received, 0% packet loss : round-trip (ms) min/avg/max = 0/3/10
OpenPOWER on IntegriCloud