summaryrefslogtreecommitdiffhomepage
path: root/pkg/tcpip
AgeCommit message (Collapse)Author
2020-08-24Merge release-20200818.0-32-g339d266be (automated)gVisor bot
2020-08-24Consider loopback bound to all addresses in subnetGhanan Gowripalan
When a loopback interface is configurd with an address and associated subnet, the loopback should treat all addresses in that subnet as an address it owns. This is mimicking linux behaviour as seen below: ``` $ ip addr show dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group ... link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever $ ping 192.0.2.1 PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data. ^C --- 192.0.2.1 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1018ms $ ping 192.0.2.2 PING 192.0.2.2 (192.0.2.2) 56(84) bytes of data. ^C --- 192.0.2.2 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2039ms $ sudo ip addr add 192.0.2.1/24 dev lo $ ip addr show dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group ... link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 192.0.2.1/24 scope global lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever $ ping 192.0.2.1 PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data. 64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.131 ms 64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.046 ms 64 bytes from 192.0.2.1: icmp_seq=3 ttl=64 time=0.048 ms ^C --- 192.0.2.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2042ms rtt min/avg/max/mdev = 0.046/0.075/0.131/0.039 ms $ ping 192.0.2.2 PING 192.0.2.2 (192.0.2.2) 56(84) bytes of data. 64 bytes from 192.0.2.2: icmp_seq=1 ttl=64 time=0.131 ms 64 bytes from 192.0.2.2: icmp_seq=2 ttl=64 time=0.069 ms 64 bytes from 192.0.2.2: icmp_seq=3 ttl=64 time=0.049 ms 64 bytes from 192.0.2.2: icmp_seq=4 ttl=64 time=0.035 ms ^C --- 192.0.2.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3049ms rtt min/avg/max/mdev = 0.035/0.071/0.131/0.036 ms ``` Test: integration_test.TestLoopbackAcceptAllInSubnet PiperOrigin-RevId: 328188546
2020-08-20Merge release-20200810.0-74-g129018ab3 (automated)gVisor bot
2020-08-20Consistent precondition formattingMichael Pratt
Our "Preconditions:" blocks are very useful to determine the input invariants, but they are bit inconsistent throughout the codebase, which makes them harder to read (particularly cases with 5+ conditions in a single paragraph). I've reformatted all of the cases to fit in simple rules: 1. Cases with a single condition are placed on a single line. 2. Cases with multiple conditions are placed in a bulleted list. This format has been added to the style guide. I've also mentioned "Postconditions:", though those are much less frequently used, and all uses already match this style. PiperOrigin-RevId: 327687465
2020-08-20Merge release-20200810.0-73-gf12b545d8 (automated)gVisor bot
2020-08-20Skip listening TCP ports when trying to bind a free port.Bhasker Hariharan
PiperOrigin-RevId: 327686558
2020-08-20Merge release-20200810.0-72-g7ca62b9da (automated)gVisor bot
2020-08-20Only use the NextHeader value of the first IPv6 fragment extension header.Arthur Sfez
As per RFC 8200 Section 4.5: The Next Header field of the last header of the Per-Fragment headers is obtained from the Next Header field of the first fragment's Fragment header. Test: - pkg/tcpip/network/ipv6:ipv6_test - pkg/tcpip/network/ipv4:ipv4_test - pkg/tcpip/network/fragmentation:fragmentation_test Updates #2197 PiperOrigin-RevId: 327671635
2020-08-18Merge release-20200810.0-53-g4184a7d5f (automated)gVisor bot
2020-08-18RACK: Create a new list for segments.Nayana Bidari
RACK requires the segments to be in the order of their transmission or retransmission times. This cl creates a new list and moves the retransmitted segments to the end of the list. PiperOrigin-RevId: 327325153
2020-08-17Merge release-20200810.0-40-ge3c4bbd10 (automated)gVisor bot
2020-08-17Remove address range functionsGhanan Gowripalan
Should have been removed in cl/326791119 https://github.com/google/gvisor/commit/9a7b5830aa063895f67ca0fdf653a46906374613 PiperOrigin-RevId: 327074156
2020-08-17Add a unit test for out of order IP reassemblyArthur Sfez
PiperOrigin-RevId: 327042869
2020-08-15Merge release-20200810.0-36-g9a7b5830a (automated)gVisor bot
2020-08-15Don't support address rangesGhanan Gowripalan
Previously the netstack supported assignment of a range of addresses. This feature is not used so remove it. PiperOrigin-RevId: 326791119
2020-08-15Merge release-20200810.0-35-g1736b2208 (automated)gVisor bot
2020-08-14Use a single NetworkEndpoint per NIC per protocolGhanan Gowripalan
The NetworkEndpoint does not need to be created for each address. Most of the work the NetworkEndpoint does is address agnostic. PiperOrigin-RevId: 326759605
2020-08-14Merge release-20200810.0-29-g190634e0f (automated)gVisor bot
2020-08-14Give the ICMP Code its own typeJulian Elischer
This is a preparatory commit for a larger commit working on ICMP generation in error cases. This is removal of technical debt and cleanup in the gvisor code as part of gvisor issue 2211. Updates #2211. PiperOrigin-RevId: 326615389
2020-08-14Merge release-20200810.0-27-gd3bb50ebf (automated)gVisor bot
2020-08-13Use the user supplied MSS for accepted connectionsGhanan Gowripalan
This change supports using the user supplied MSS (TCP_MAXSEG socket option) for new socket connections created from a listening TCP socket. Note that the user supplied MSS will only be used if it is not greater than the maximum possible MSS for a TCP connection's route. If it is greater than the maximum possible MSS, the MSS will be capped at that maximum value. Test: tcp_test.TestUserSuppliedMSSOnListenAccept PiperOrigin-RevId: 326567442
2020-08-13Merge release-20200810.0-23-g47515f475 (automated)gVisor bot
2020-08-13Migrate to PacketHeader API for PacketBuffer.Ting-Yu Wang
Formerly, when a packet is constructed or parsed, all headers are set by the client code. This almost always involved prepending to pk.Header buffer or trimming pk.Data portion. This is known to prone to bugs, due to the complexity and number of the invariants assumed across netstack to maintain. In the new PacketHeader API, client will call Push()/Consume() method to construct/parse an outgoing/incoming packet. All invariants, such as slicing and trimming, are maintained by the API itself. NewPacketBuffer() is introduced to create new PacketBuffer. Zero value is no longer valid. PacketBuffer now assumes the packet is a concatenation of following portions: * LinkHeader * NetworkHeader * TransportHeader * Data Any of them could be empty, or zero-length. PiperOrigin-RevId: 326507688
2020-08-13Merge release-20200810.0-22-gb928d074b (automated)gVisor bot
2020-08-13Ensure TCP TIME-WAIT is not terminated prematurely.Bhasker Hariharan
Netstack's TIME-WAIT state for a TCP socket could be terminated prematurely if the socket entered TIME-WAIT using shutdown(..., SHUT_RDWR) and then was closed using close(). This fixes that bug and updates the tests to verify that Netstack correctly honors TIME-WAIT under such conditions. Fixes #3106 PiperOrigin-RevId: 326456443
2020-08-11Merge release-20200804.0-64-gc92242c89 (automated)gVisor bot
2020-08-11Fix-up issue comment.Adin Scannell
PiperOrigin-RevId: 326129258
2020-08-11Merge release-20200804.0-61-g8e31f0dc5 (automated)gVisor bot
2020-08-10Set the NetworkProtocolNumber of all PacketBuffers.Kevin Krakauer
NetworkEndpoints set the number on outgoing packets in Write() and NetworkProtocols set them on incoming packets in Parse(). Needed for #3549. PiperOrigin-RevId: 325938745
2020-08-10Merge release-20200804.0-60-g0a8ae4b32 (automated)gVisor bot
2020-08-10Populate IPPacketInfo with destination addressGhanan Gowripalan
IPPacketInfo.DestinationAddr should hold the destination of the IP packet, not the source. This change fixes that bug. PiperOrigin-RevId: 325910766
2020-08-09Merge release-20200804.0-54-gb404b5c25 (automated)gVisor bot
2020-08-08Use unicast source for ICMP echo repliesGhanan Gowripalan
Packets MUST NOT use a non-unicast source address for ICMP Echo Replies. Test: integration_test.TestPingMulticastBroadcast PiperOrigin-RevId: 325634380
2020-08-07Merge release-20200804.0-43-g94447aeab (automated)gVisor bot
2020-08-07Fix panic during Address Resolution of neighbor entry created by NSSam Balana
When a Neighbor Solicitation is received, a neighbor entry is created with the remote host's link layer address, but without a link layer address resolver. If the host decides to send a packet addressed to the IP address of that neighbor entry, Address Resolution starts with a nil pointer to the link layer address resolver. This causes the netstack to panic and crash. This change ensures that when a packet is sent in that situation, the link layer address resolver will be set before Address Resolution begins. Tests: pkg/tcpip/stack:stack_test + TestEntryUnknownToStaleToProbeToReachable - TestNeighborCacheEntryNoLinkAddress Updates #1889 Updates #1894 Updates #1895 Updates #1947 Updates #1948 Updates #1949 Updates #1950 PiperOrigin-RevId: 325516471
2020-08-07Merge release-20200804.0-40-g10c13bcca (automated)gVisor bot
2020-08-07tcp: change the limit of TCP_LINGER2Andrei Vagin
It was changed in the Linux kernel: commit f0628c524fd188c3f9418e12478dfdfadacba815 Date: Fri Apr 24 16:06:16 2020 +0800 net: Replace the limit of TCP_LINGER2 with TCP_FIN_TIMEOUT_MAX PiperOrigin-RevId: 325493859
2020-08-06Merge release-20200804.0-28-gfc4dd3ef4 (automated)gVisor bot
2020-08-06Join IPv4 all-systems group on NIC enableGhanan Gowripalan
Test: - stack_test.TestJoinLeaveMulticastOnNICEnableDisable - integration_test.TestIncomingMulticastAndBroadcast PiperOrigin-RevId: 325185259
2020-08-06Merge release-20200804.0-27-g35312a95c (automated)gVisor bot
2020-08-05Add loss recovery option for TCP.Nayana Bidari
/proc/sys/net/ipv4/tcp_recovery is used to enable RACK loss recovery in TCP. PiperOrigin-RevId: 325157807
2020-08-06Merge release-20200804.0-24-g90a2d4e82 (automated)gVisor bot
2020-08-05Support receiving broadcast IPv4 packetsGhanan Gowripalan
Test: integration_test.TestIncomingSubnetBroadcast PiperOrigin-RevId: 325135617
2020-08-05Merge release-20200804.0-22-ge7b232a5b (automated)gVisor bot
2020-08-05Prefer RLock over Lock in functions that don't need Lock().Bhasker Hariharan
Updates #231 PiperOrigin-RevId: 325097683
2020-08-05Merge release-20200622.1-336-g0e6f7a12c (automated)gVisor bot
2020-08-04Update variables for implementation of RACK in TCPNayana Bidari
RACK (Recent Acknowledgement) is a new loss detection algorithm in TCP. These are the fields which should be stored on connections to implement RACK algorithm. PiperOrigin-RevId: 324948703
2020-08-04Merge release-20200622.1-329-g00993130e (automated)gVisor bot
2020-08-04Use 1 fragmentation component per IP stackGhanan Gowripalan
This will help manage memory consumption by IP reassembly when receiving IP fragments on multiple network endpoints. Previously, each endpoint would cap memory consumption at 4MB, but with this change, each IP stack will cap memory consumption at 4MB. No behaviour changes. PiperOrigin-RevId: 324913904
2020-08-03Merge release-20200622.1-313-gb2ae7ea1b (automated)gVisor bot
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-21 00:42:07 +0000