Age | Commit message (Collapse) | Author |
|
|
|
Test:
- TestV4UnknownDestination
- TestV6UnknownDestination
PiperOrigin-RevId: 328424137
|
|
|
|
The actual values used for this field in Netstack are actually EtherType values
of the protocol in an Ethernet frame. Eg. header.IPv4ProtocolNumber is 0x0800
and not the number of the IPv4 Protocol Number itself which is 4. Similarly
header.IPv6ProtocolNumber is set to 0x86DD whereas the IPv6 protocol number is
41.
See:
- https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml (For EtherType)
- https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml (For ProtocolNumbers)
PiperOrigin-RevId: 328407293
|
|
|
|
This change adds an option to replace the current implementation of ARP through
linkAddrCache, with an implementation of NUD through neighborCache. Switching
to using NUD for both ARP and NDP is beneficial for the reasons described by
RFC 4861 Section 3.1:
"[Using NUD] significantly improves the robustness of packet delivery in the
presence of failing routers, partially failing or partitioned links, or nodes
that change their link-layer addresses. For instance, mobile nodes can move
off-link without losing any connectivity due to stale ARP caches."
"Unlike ARP, Neighbor Unreachability Detection detects half-link failures and
avoids sending traffic to neighbors with which two-way connectivity is
absent."
Along with these changes exposes the API for querying and operating the
neighbor cache. Operations include:
- Create a static entry
- List all entries
- Delete all entries
- Remove an entry by address
This also exposes the API to change the NUD protocol constants on a per-NIC
basis to allow Neighbor Discovery to operate over links with widely varying
performance characteristics. See [RFC 4861 Section 10][1] for the list of
constants.
Finally, an API for subscribing to NUD state changes is exposed through
NUDDispatcher. See [RFC 4861 Appendix C][3] for the list of edges.
Tests:
pkg/tcpip/network/arp:arp_test
+ TestDirectRequest
pkg/tcpip/network/ipv6:ipv6_test
+ TestLinkResolution
+ TestNDPValidation
+ TestNeighorAdvertisementWithTargetLinkLayerOption
+ TestNeighorSolicitationResponse
+ TestNeighorSolicitationWithSourceLinkLayerOption
+ TestRouterAdvertValidation
pkg/tcpip/stack:stack_test
+ TestCacheWaker
+ TestForwardingWithFakeResolver
+ TestForwardingWithFakeResolverManyPackets
+ TestForwardingWithFakeResolverManyResolutions
+ TestForwardingWithFakeResolverPartialTimeout
+ TestForwardingWithFakeResolverTwoPackets
+ TestIPv6SourceAddressSelectionScopeAndSameAddress
[1]: https://tools.ietf.org/html/rfc4861#section-10
[2]: https://tools.ietf.org/html/rfc4861#appendix-C
Fixes #1889
Fixes #1894
Fixes #1895
Fixes #1947
Fixes #1948
Fixes #1949
Fixes #1950
PiperOrigin-RevId: 328365034
|
|
|
|
When SO_LINGER option is enabled, the close will not return until all the
queued messages are sent and acknowledged for the socket or linger timeout is
reached. If the option is not set, close will return immediately. This option
is mainly supported for connection oriented protocols such as TCP.
PiperOrigin-RevId: 328350576
|
|
|
|
We still deviate a bit from linux in how long we will actually wait in
FIN-WAIT-2. Linux seems to cap it with TIME_WAIT_LEN and it's not completely
obvious as to why it's done that way. For now I think we can ignore that and
fix it if it really is an issue.
PiperOrigin-RevId: 328324922
|
|
|
|
PiperOrigin-RevId: 328259353
|
|
|
|
This enables pre-release testing with 1.16. The intention is to replace these
with a nogo check before the next release.
PiperOrigin-RevId: 328193911
|
|
|
|
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
|
|
|
|
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
|
|
|
|
PiperOrigin-RevId: 327686558
|
|
|
|
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
|
|
|
|
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
|
|
|
|
Should have been removed in cl/326791119
https://github.com/google/gvisor/commit/9a7b5830aa063895f67ca0fdf653a46906374613
PiperOrigin-RevId: 327074156
|
|
PiperOrigin-RevId: 327042869
|
|
|
|
Previously the netstack supported assignment of a range of addresses.
This feature is not used so remove it.
PiperOrigin-RevId: 326791119
|
|
|
|
The NetworkEndpoint does not need to be created for each address.
Most of the work the NetworkEndpoint does is address agnostic.
PiperOrigin-RevId: 326759605
|
|
|
|
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
|
|
|
|
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
|
|
|
|
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
|
|
|
|
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
|
|
|
|
PiperOrigin-RevId: 326129258
|
|
|
|
NetworkEndpoints set the number on outgoing packets in Write() and
NetworkProtocols set them on incoming packets in Parse().
Needed for #3549.
PiperOrigin-RevId: 325938745
|
|
|
|
IPPacketInfo.DestinationAddr should hold the destination of the IP
packet, not the source. This change fixes that bug.
PiperOrigin-RevId: 325910766
|
|
|
|
Packets MUST NOT use a non-unicast source address for ICMP
Echo Replies.
Test: integration_test.TestPingMulticastBroadcast
PiperOrigin-RevId: 325634380
|
|
|
|
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
|
|
|