summaryrefslogtreecommitdiffhomepage
path: root/pkg/tcpip
AgeCommit message (Collapse)Author
2019-11-22Add segment dequeue check while emptying segment queue.Mithun Iyer
PiperOrigin-RevId: 282023891
2019-11-16Merge release-20191104.0-48-g5107e6b (automated)gVisor bot
2019-11-15Automated rollback of changelist 280594395Bhasker Hariharan
PiperOrigin-RevId: 280763655
2019-11-15Merge release-20191104.0-47-g3e534f2 (automated)gVisor bot
2019-11-15Handle in-flight TCP segments when moving to CLOSE.Mithun Iyer
As we move to CLOSE state from LAST-ACK or TIME-WAIT, ensure that we re-match all in-flight segments to any listening endpoint. Also fix LISTEN state handling of any ACK segments as per RFC793. Fixes #1153 PiperOrigin-RevId: 280703556
2019-11-15Merge release-20191104.0-45-g23574b1 (automated)gVisor bot
2019-11-14Fix panic when logging raw packets via sniffer.Kevin Krakauer
Sniffer assumed that outgoing packets have transport headers, but users can write packets via SOCK_RAW with arbitrary transport headers that netstack doesn't know about. We now explicitly check for the presence of network and transport headers before assuming they exist. PiperOrigin-RevId: 280594395
2019-11-14Merge release-20191104.0-40-g3f7d937 (automated)gVisor bot
2019-11-14Use PacketBuffers for outgoing packets.Kevin Krakauer
PiperOrigin-RevId: 280455453
2019-11-13Merge release-20191104.0-38-g6dd4c9e (automated)gVisor bot
2019-11-13Fix flaky behaviour during S/R.Bhasker Hariharan
PiperOrigin-RevId: 280280156
2019-11-12Merge release-20191104.0-33-g3f51bef (automated)gVisor bot
2019-11-12Do not handle TCP packets that include a non-unicast IP addressGhanan Gowripalan
This change drops TCP packets with a non-unicast IP address as the source or destination address as TCP is meant for communication between two endpoints. Test: Make sure that if the source or destination address contains a non-unicast address, no TCP packet is sent in response and the packet is dropped. PiperOrigin-RevId: 280073731
2019-11-12Merge release-20190806.1-397-g5398530 (automated)gVisor bot
2019-11-12Discover on-link prefixes from Router Advertisements' Prefix Information optionsGhanan Gowripalan
This change allows the netstack to do NDP's Prefix Discovery as outlined by RFC 4861 section 6.3.4. If configured to do so, when a new on-link prefix is discovered, the routing table will be updated with a device route through the nic the RA arrived at. Likewise, when such a prefix gets invalidated, the device route will be removed. Note, this change will not break existing uses of netstack as the default configuration for the stack options is set in such a way that Prefix Discovery will not be performed. See `stack.Options` and `stack.NDPConfigurations` for more details. This change reuses 1 option and introduces a new one that is required to take advantage of Prefix Discovery, all available under NDPConfigurations: - HandleRAs: Whether or not NDP RAs are processes - DiscoverOnLinkPrefixes: Whether or not Prefix Discovery is performed (new) Another note: for a NIC to process Prefix Information options (in Router Advertisements), it must not be a router itself. Currently the netstack does not have per-interface routing configuration; the routing/forwarding configuration is controlled stack-wide. Therefore, if the stack is configured to enable forwarding/routing, no router Advertisements (and by extension the Prefix Information options) will be processed. Tests: Unittest to make sure that Prefix Discovery and updates to the routing table only occur if explicitly configured to do so. Unittest to make sure at max stack.MaxDiscoveredOnLinkPrefixes discovered on-link prefixes are remembered. PiperOrigin-RevId: 280049278
2019-11-12Merge release-20190806.1-396-g57a2a5e (automated)gVisor bot
2019-11-12Add tests for SO_REUSEADDR and SO_REUSEPORT.Ian Gudger
* Basic tests for the SO_REUSEADDR and SO_REUSEPORT options. * SO_REUSEADDR functional tests for TCP and UDP. * SO_REUSEADDR and SO_REUSEPORT interaction tests for UDP. * Stubbed support for UDP getsockopt(SO_REUSEADDR). PiperOrigin-RevId: 280049265
2019-11-11Merge release-20190806.1-389-g7730716 (automated)gVisor bot
2019-11-11Make `connect` on socket returned by `accept` correctly error out with EISCONNgVisor bot
PiperOrigin-RevId: 279814493
2019-11-07Merge release-20190806.1-382-g66ebb65 (automated)gVisor bot
2019-11-07Add support for TIME_WAIT timeout.Bhasker Hariharan
This change adds explicit support for honoring the 2MSL timeout for sockets in TIME_WAIT state. It also adds support for the TCP_LINGER2 option that allows modification of the FIN_WAIT2 state timeout duration for a given socket. It also adds an option to modify the Stack wide TIME_WAIT timeout but this is only for testing. On Linux this is fixed at 60s. Further, we also now correctly process RST's in CLOSE_WAIT and close the socket similar to linux without moving it to error state. We also now handle SYN in ESTABLISHED state as per RFC5961#section-4.1. Earlier we would just drop these SYNs. Which can result in some tests that pass on linux to fail on gVisor. Netstack now honors TIME_WAIT correctly as well as handles the following cases correctly. - TCP RSTs in TIME_WAIT are ignored. - A duplicate TCP FIN during TIME_WAIT extends the TIME_WAIT and a dup ACK is sent in response to the FIN as the dup FIN indicates potential loss of the original final ACK. - An out of order segment during TIME_WAIT generates a dup ACK. - A new SYN w/ a sequence number > the highest sequence number in the previous connection closes the TIME_WAIT early and opens a new connection. Further to make the SYN case work correctly the ISN (Initial Sequence Number) generation for Netstack has been updated to be as per RFC. Its not a pure random number anymore and follows the recommendation in https://tools.ietf.org/html/rfc6528#page-3. The current hash used is not a cryptographically secure hash function. A separate change will update the hash function used to Siphash similar to what is used in Linux. PiperOrigin-RevId: 279106406
2019-11-07Merge release-20190806.1-379-g0c424ea (automated)gVisor bot
2019-11-06Rename nicid to nicID to follow go-readability initialismsGhanan Gowripalan
https://github.com/golang/go/wiki/CodeReviewComments#initialisms This change does not introduce any new functionality. It just renames variables from `nicid` to `nicID`. PiperOrigin-RevId: 278992966
2019-11-07Merge release-20190806.1-378-gadb10f4 (automated)gVisor bot
2019-11-06Internal change.gVisor bot
PiperOrigin-RevId: 278979065
2019-11-07Merge release-20190806.1-376-ge63db5e (automated)gVisor bot
2019-11-06Discover default routers from Router AdvertisementsGhanan Gowripalan
This change allows the netstack to do NDP's Router Discovery as outlined by RFC 4861 section 6.3.4. Note, this change will not break existing uses of netstack as the default configuration for the stack options is set in such a way that Router Discovery will not be performed. See `stack.Options` and `stack.NDPConfigurations` for more details. This change introduces 2 options required to take advantage of Router Discovery, all available under NDPConfigurations: - HandleRAs: Whether or not NDP RAs are processes - DiscoverDefaultRouters: Whether or not Router Discovery is performed Another note: for a NIC to process Router Advertisements, it must not be a router itself. Currently the netstack does not have per-interface routing configuration; the routing/forwarding configuration is controlled stack-wide. Therefore, if the stack is configured to enable forwarding/routing, no Router Advertisements will be processed. Tests: Unittest to make sure that Router Discovery and updates to the routing table only occur if explicitly configured to do so. Unittest to make sure at max stack.MaxDiscoveredDefaultRouters discovered default routers are remembered. PiperOrigin-RevId: 278965143
2019-11-06Merge release-20190806.1-375-ge1b21f3 (automated)gVisor bot
2019-11-06Use PacketBuffers, rather than VectorisedViews, in netstack.Kevin Krakauer
PacketBuffers are analogous to Linux's sk_buff. They hold all information about a packet, headers, and payload. This is important for: * iptables to access various headers of packets * Preventing the clutter of passing different net and link headers along with VectorisedViews to packet handling functions. This change only affects the incoming packet path, and a future change will change the outgoing path. Benchmark Regular PacketBufferPtr PacketBufferConcrete -------------------------------------------------------------------------------- BM_Recvmsg 400.715MB/s 373.676MB/s 396.276MB/s BM_Sendmsg 361.832MB/s 333.003MB/s 335.571MB/s BM_Recvfrom 453.336MB/s 393.321MB/s 381.650MB/s BM_Sendto 378.052MB/s 372.134MB/s 341.342MB/s BM_SendmsgTCP/0/1k 353.711MB/s 316.216MB/s 322.747MB/s BM_SendmsgTCP/0/2k 600.681MB/s 588.776MB/s 565.050MB/s BM_SendmsgTCP/0/4k 995.301MB/s 888.808MB/s 941.888MB/s BM_SendmsgTCP/0/8k 1.517GB/s 1.274GB/s 1.345GB/s BM_SendmsgTCP/0/16k 1.872GB/s 1.586GB/s 1.698GB/s BM_SendmsgTCP/0/32k 1.017GB/s 1.020GB/s 1.133GB/s BM_SendmsgTCP/0/64k 475.626MB/s 584.587MB/s 627.027MB/s BM_SendmsgTCP/0/128k 416.371MB/s 503.434MB/s 409.850MB/s BM_SendmsgTCP/0/256k 323.449MB/s 449.599MB/s 388.852MB/s BM_SendmsgTCP/0/512k 243.992MB/s 267.676MB/s 314.474MB/s BM_SendmsgTCP/0/1M 95.138MB/s 95.874MB/s 95.417MB/s BM_SendmsgTCP/0/2M 96.261MB/s 94.977MB/s 96.005MB/s BM_SendmsgTCP/0/4M 96.512MB/s 95.978MB/s 95.370MB/s BM_SendmsgTCP/0/8M 95.603MB/s 95.541MB/s 94.935MB/s BM_SendmsgTCP/0/16M 94.598MB/s 94.696MB/s 94.521MB/s BM_SendmsgTCP/0/32M 94.006MB/s 94.671MB/s 94.768MB/s BM_SendmsgTCP/0/64M 94.133MB/s 94.333MB/s 94.746MB/s BM_SendmsgTCP/0/128M 93.615MB/s 93.497MB/s 93.573MB/s BM_SendmsgTCP/0/256M 93.241MB/s 95.100MB/s 93.272MB/s BM_SendmsgTCP/1/1k 303.644MB/s 316.074MB/s 308.430MB/s BM_SendmsgTCP/1/2k 537.093MB/s 584.962MB/s 529.020MB/s BM_SendmsgTCP/1/4k 882.362MB/s 939.087MB/s 892.285MB/s BM_SendmsgTCP/1/8k 1.272GB/s 1.394GB/s 1.296GB/s BM_SendmsgTCP/1/16k 1.802GB/s 2.019GB/s 1.830GB/s BM_SendmsgTCP/1/32k 2.084GB/s 2.173GB/s 2.156GB/s BM_SendmsgTCP/1/64k 2.515GB/s 2.463GB/s 2.473GB/s BM_SendmsgTCP/1/128k 2.811GB/s 3.004GB/s 2.946GB/s BM_SendmsgTCP/1/256k 3.008GB/s 3.159GB/s 3.171GB/s BM_SendmsgTCP/1/512k 2.980GB/s 3.150GB/s 3.126GB/s BM_SendmsgTCP/1/1M 2.165GB/s 2.233GB/s 2.163GB/s BM_SendmsgTCP/1/2M 2.370GB/s 2.219GB/s 2.453GB/s BM_SendmsgTCP/1/4M 2.005GB/s 2.091GB/s 2.214GB/s BM_SendmsgTCP/1/8M 2.111GB/s 2.013GB/s 2.109GB/s BM_SendmsgTCP/1/16M 1.902GB/s 1.868GB/s 1.897GB/s BM_SendmsgTCP/1/32M 1.655GB/s 1.665GB/s 1.635GB/s BM_SendmsgTCP/1/64M 1.575GB/s 1.547GB/s 1.575GB/s BM_SendmsgTCP/1/128M 1.524GB/s 1.584GB/s 1.580GB/s BM_SendmsgTCP/1/256M 1.579GB/s 1.607GB/s 1.593GB/s PiperOrigin-RevId: 278940079
2019-11-06Merge release-20190806.1-374-gd0d89ce (automated)gVisor bot
2019-11-06Send a TCP RST in response to a TCP SYN-ACK on a listening endpointGhanan Gowripalan
This change better follows what is outlined in RFC 793 section 3.4 figure 12 where a listening socket should not accept a SYN-ACK segment in response to a (potentially) old SYN segment. Tests: Test that checks the TCP RST segment sent in response to a TCP SYN-ACK segment received on a listening TCP endpoint. PiperOrigin-RevId: 278893114
2019-11-06Merge release-20190806.1-373-ga824b48 (automated)gVisor bot
2019-11-06Validate incoming NDP Router Advertisements, as per RFC 4861 section 6.1.2Ghanan Gowripalan
This change validates incoming NDP Router Advertisements as per RFC 4861 section 6.1.2. It also includes the skeleton to handle Router Advertiements that arrive on some NIC. Tests: Unittest to make sure only valid NDP Router Advertisements are received/ not dropped. PiperOrigin-RevId: 278891972
2019-10-31Merge release-20190806.1-350-g3246040 (automated)gVisor bot
2019-10-30Deep copy dispatcher views.Kevin Krakauer
When VectorisedViews were passed up the stack from packet_dispatchers, we were passing a sub-slice of the dispatcher's views fields. The dispatchers then immediately set those views to nil. This wasn't caught before because every implementer copied the data in these views before returning. PiperOrigin-RevId: 277615351
2019-10-30Merge release-20190806.1-346-gdb37483 (automated)gVisor bot
2019-10-30Store endpoints inside multiPortEndpoint in a sorted orderAndrei Vagin
It is required to guarantee the same order of endpoints after save/restore. PiperOrigin-RevId: 277598665
2019-10-30Merge release-20190806.1-344-gdc21c5c (automated)gVisor bot
2019-10-29Add Close and Wait methods to stack.Ian Gudger
Link endpoints still don't have a unified way to be requested to stop. Updates #837 PiperOrigin-RevId: 277398952
2019-10-29Merge release-20190806.1-343-ga2c51ef (automated)gVisor bot
2019-10-29Add endpoint tracking to the stack.Ian Gudger
In the future this will replace DanglingEndpoints. DanglingEndpoints must be kept for now due to issues with save/restore. This is arguably a cleaner design and allows the stack to know which transport endpoints might still be using its link endpoints. Updates #837 PiperOrigin-RevId: 277386633
2019-10-29Merge release-20190806.1-340-gc0b8fd4 (automated)gVisor bot
2019-10-29Update build tags to allow Go 1.14Michael Pratt
Currently there are no ABI changes. We should check again closer to release. PiperOrigin-RevId: 277349744
2019-10-29Merge release-20190806.1-337-g7d80e85 (automated)gVisor bot
2019-10-29Allow waiting for Endpoint worker goroutines to finish.Ian Gudger
Updates #837 PiperOrigin-RevId: 277325162
2019-10-29Merge release-20190806.1-334-g41e2df1 (automated)gVisor bot
2019-10-29Support iterating an NDP options buffer.Ghanan Gowripalan
This change helps support iterating over an NDP options buffer so that implementations can handle all the NDP options present in an NDP packet. Note, this change does not yet actually handle these options, it just provides the tools to do so (in preparation for NDP's Prefix, Parameter, and a complete implementation of Neighbor Discovery). Tests: Unittests to make sure we can iterate over a valid NDP options buffer that may contain multiple options. Also tests to check an iterator before using it to see if the NDP options buffer is malformed. PiperOrigin-RevId: 277312487
2019-10-29Merge release-20190806.1-331-g0864549 (automated)gVisor bot
2019-10-28Use the user supplied TCP MSS when creating a new active socketGhanan Gowripalan
This change supports using a user supplied TCP MSS for new active TCP connections. Note, the user supplied MSS must be less than or equal to the maximum possible MSS for a TCP connection's route. If it is greater than the maximum possible MSS, the maximum possible MSS will be used as the connection's MSS instead. This change does not use this user supplied MSS for connections accepted from listening sockets - that will come in a later change. Test: Test that outgoing TCP SYN segments contain a TCP MSS option with the user supplied MSS if it is not greater than the maximum possible MSS for the route. PiperOrigin-RevId: 277185125
2019-10-25Merge release-20190806.1-328-g5a42105 (automated)gVisor bot
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 19:41:00 +0000