summaryrefslogtreecommitdiffhomepage
path: root/pkg/tcpip/link
AgeCommit message (Collapse)Author
2021-01-29Merge release-20210125.0-21-g8d1afb418 (automated)gVisor bot
2021-01-28Change tcpip.Error to an interfaceTamir Duberstein
This makes it possible to add data to types that implement tcpip.Error. ErrBadLinkEndpoint is removed as it is unused. PiperOrigin-RevId: 354437314
2021-01-26Merge release-20210112.0-86-gb4665aef8 (automated)gVisor bot
2021-01-25fdbased: Dedup code related to iovec readingTing-Yu Wang
PiperOrigin-RevId: 353755271
2021-01-21Merge release-20210112.0-60-g89df5a681 (automated)gVisor bot
2021-01-21Queue packets in WritePackets when resolving link addressGhanan Gowripalan
Test: integration_test.TestWritePacketsLinkResolution Fixes #4458. PiperOrigin-RevId: 353108826
2021-01-21Merge release-20210112.0-59-g0ca4cf769 (automated)gVisor bot
2021-01-21Populate EgressRoute, GSO, Netproto in NICGhanan Gowripalan
fdbased and qdisc layers expect these fields to already be populated before being reached. PiperOrigin-RevId: 353099492
2021-01-16Merge release-20210112.0-39-g2814a032b (automated)gVisor bot
2021-01-15Support GetLinkAddress with neighborCacheGhanan Gowripalan
Test: integration_test.TestGetLinkAddress PiperOrigin-RevId: 352119404
2021-01-16Merge release-20210112.0-38-gfd5b52c87 (automated)gVisor bot
2021-01-15Only pass stack.Route's fields to LinkEndpointsGhanan Gowripalan
stack.Route is used to send network packets and resolve link addresses. A LinkEndpoint does not need to do either of these and only needs the route's fields at the time of the packet write request. Since LinkEndpoints only need the route's fields when writing packets, pass a stack.RouteInfo instead. PiperOrigin-RevId: 352108405
2021-01-15Merge release-20210112.0-34-g55c7fe48d (automated)gVisor bot
2021-01-15Populate EgressRoute, GSO, Netproto for batch writesGhanan Gowripalan
We loop over the list of packets anyways so setting these aren't expensive. Now that they are populated only by the link endpoint that uses them, TCP does not need to. PiperOrigin-RevId: 352090853
2021-01-13Switch uses of os.Getenv that check for empty string to os.LookupEnv.Dean Deng
Whether the variable was found is already returned by syscall.Getenv. os.Getenv drops this value while os.Lookupenv passes it along. PiperOrigin-RevId: 351674032
2021-01-12Fix simple mistakes identified by goreportcard.Adin Scannell
These are primarily simplification and lint mistakes. However, minor fixes are also included and tests added where appropriate. PiperOrigin-RevId: 351425971
2021-01-06Merge release-20201208.0-118-g7817e3b5e (automated)gVisor bot
2021-01-06Do not filter frames in ethernet link endpointGhanan Gowripalan
Ethernet frames are usually filtered at the hardware-level so there is no need to filter the frames in software. For test purposes, a new link endpoint was introduced to filter frames based on their destination. PiperOrigin-RevId: 350422941
2020-12-28Merge release-20201208.0-89-g3ff7324df (automated)gVisor bot
2020-12-22Correctly log sniffed ARP packetsTamir Duberstein
This condition was inverted in 360006d. PiperOrigin-RevId: 348679088
2020-12-22Invoke address resolution upon subsequent traffic to Failed neighborPeter Johnston
Removes the period of time in which subseqeuent traffic to a Failed neighbor immediately fails with ErrNoLinkAddress. A Failed neighbor is one in which address resolution fails; or in other words, the neighbor's IP address cannot be translated to a MAC address. This means removing the Failed state for linkAddrCache and allowing transitiong out of Failed into Incomplete for neighborCache. Previously, both caches would transition entries to Failed after address resolution fails. In this state, any subsequent traffic requested within an unreachable time would immediately fail with ErrNoLinkAddress. This does not follow RFC 4861 section 7.3.3: If address resolution fails, the entry SHOULD be deleted, so that subsequent traffic to that neighbor invokes the next-hop determination procedure again. Invoking next-hop determination at this point ensures that alternate default routers are tried. The API for getting a link address for a given address, whether through the link address cache or the neighbor table, is updated to optionally take a callback which will be called when address resolution completes. This allows `Route` to handle completing link resolution internally, so callers of (*Route).Resolve (e.g. endpoints) don’t have to keep track of when it completes and update the Route accordingly. This change also removes the wakers from LinkAddressCache, NeighborCache, and Route in favor of the callbacks, and callers that previously used a waker can now just pass a callback to (*Route).Resolve that will notify the waker on resolution completion. Fixes #4796 Startblock: has LGTM from sbalana and then add reviewer ghanan PiperOrigin-RevId: 348597478
2020-12-12Merge release-20201208.0-36-g1e92732eb (automated)gVisor bot
2020-12-11Merge release-20201130.0-84-gbcb97a3bb (automated)gVisor bot
2020-12-10Disable host reassembly for fragments.Bhasker Hariharan
fdbased endpoint was enabling fragment reassembly on the host AF_PACKET socket to ensure that fragments are delivered inorder to the right dispatcher. But this prevents fragments from being delivered to gvisor at all and makes testing of gvisor's fragment reassembly code impossible. The potential impact from this is minimal since IP Fragmentation is not really that prevelant and in cases where we do get fragments we may deliver the fragment out of order to the TCP layer as multiple network dispatchers may process the fragments and deliver a reassembled fragment after the next packet has been delivered to the TCP endpoint. While not desirable I believe the impact from this is minimal due to low prevalence of fragmentation. Also removed PktType and Hatype fields when binding the socket as these are not used when binding. Its just confusing to have them specified. See: https://man7.org/linux/man-pages/man7/packet.7.html "Fields used for binding are sll_family (should be AF_PACKET), sll_protocol, and sll_ifindex." Fixes #5055 PiperOrigin-RevId: 346919439
2020-12-03Merge release-20201130.0-31-g3ff1aef54 (automated)gVisor bot
2020-12-03Make `stack.Route` thread safePeter Johnston
Currently we rely on the user to take the lock on the endpoint that owns the route, in order to modify it safely. We can instead move `Route.RemoteLinkAddress` under `Route`'s mutex, and allow non-locking and thread-safe access to other fields of `Route`. PiperOrigin-RevId: 345461586
2020-11-25Merge release-20201109.0-117-g2485a4e2c (automated)gVisor bot
2020-11-25Make stack.Route safe to access concurrentlyGhanan Gowripalan
Multiple goroutines may use the same stack.Route concurrently so the stack.Route should make sure that any functions called on it are thread-safe. Fixes #4073 PiperOrigin-RevId: 344320491
2020-11-18Merge release-20201109.0-69-g9d148627f (automated)gVisor bot
2020-11-18Introduce stack.WritePacketToRemote, remove LinkEndpoint.WriteRawPacketBruno Dal Bo
Redefine stack.WritePacket into stack.WritePacketToRemote which lets the NIC decide whether to append link headers. PiperOrigin-RevId: 343071742
2020-11-17Merge release-20201109.0-60-g7492ed6bd (automated)gVisor bot
2020-11-17Add per-sniffer instance log prefixBruno Dal Bo
A prefix associated with a sniffer instance can help debug situations where more than one NIC (i.e. more than one sniffer) exists. PiperOrigin-RevId: 342950027
2020-11-16Merge release-20201109.0-51-gcc5cfce4c (automated)gVisor bot
2020-11-16Remove ARP address workaroundGhanan Gowripalan
- Make AddressableEndpoint optional for NetworkEndpoint. Not all NetworkEndpoints need to support addressing (e.g. ARP), so AddressableEndpoint should only be implemented for protocols that support addressing such as IPv4 and IPv6. With this change, tcpip.ErrNotSupported will be returned by the stack when attempting to modify addresses on a network endpoint that does not support addressing. Now that packets are fully handled at the network layer, and (with this change) addresses are optional for network endpoints, we no longer need the workaround for ARP where a fake ARP address was added to each NIC that performs ARP so that packets would be delivered to the ARP layer. PiperOrigin-RevId: 342722547
2020-11-09Merge release-20201030.0-53-g0fb5353e4 (automated)gVisor bot
2020-11-09Initialize references with a value of 1.Dean Deng
This lets us avoid treating a value of 0 as one reference. All references using the refsvfs2 template must call InitRefs() before the reference is incremented/decremented, or else a panic will occur. Therefore, it should be pretty easy to identify missing InitRef calls during testing. Updates #1486. PiperOrigin-RevId: 341411151
2020-11-07Merge release-20201030.0-46-g5288e1941 (automated)gVisor bot
2020-11-06Trim link headers from buffer clone when sniffingGhanan Gowripalan
PiperOrigin-RevId: 341135083
2020-10-29Merge release-20201019.0-95-g3b4674ffe (automated)gVisor bot
2020-10-23Merge release-20201019.0-34-g9ca66ec59 (automated)gVisor bot
2020-10-23Rewrite reference leak checker without finalizers.Dean Deng
Our current reference leak checker uses finalizers to verify whether an object has reached zero references before it is garbage collected. There are multiple problems with this mechanism, so a rewrite is in order. With finalizers, there is no way to guarantee that a finalizer will run before the program exits. When an unreachable object with a finalizer is garbage collected, its finalizer will be added to a queue and run asynchronously. The best we can do is run garbage collection upon sandbox exit to make sure that all finalizers are enqueued. Furthermore, if there is a chain of finalized objects, e.g. A points to B points to C, garbage collection needs to run multiple times before all of the finalizers are enqueued. The first GC run will register the finalizer for A but not free it. It takes another GC run to free A, at which point B's finalizer can be registered. As a result, we need to run GC as many times as the length of the longest such chain to have a somewhat reliable leak checker. Finally, a cyclical chain of structs pointing to one another will never be garbage collected if a finalizer is set. This is a well-known issue with Go finalizers (https://github.com/golang/go/issues/7358). Using leak checking on filesystem objects that produce cycles will not work and even result in memory leaks. The new leak checker stores reference counted objects in a global map when leak check is enabled and removes them once they are destroyed. At sandbox exit, any remaining objects in the map are considered as leaked. This provides a deterministic way of detecting leaks without relying on the complexities of finalizers and garbage collection. This approach has several benefits over the former, including: - Always detects leaks of objects that should be destroyed very close to sandbox exit. The old checker very rarely detected these leaks, because it relied on garbage collection to be run in a short window of time. - Panics if we forgot to enable leak check on a ref-counted object (we will try to remove it from the map when it is destroyed, but it will never have been added). - Can store extra logging information in the map values without adding to the size of the ref count struct itself. With the size of just an int64, the ref count object remains compact, meaning frequent operations like IncRef/DecRef are more cache-efficient. - Can aggregate leak results in a single report after the sandbox exits. Instead of having warnings littered in the log, which were non-deterministically triggered by garbage collection, we can print all warning messages at once. Note that this could also be a limitation--the sandbox must exit properly for leaks to be detected. Some basic benchmarking indicates that this change does not significantly affect performance when leak checking is enabled, which is understandable since registering/unregistering is only done once for each filesystem object. Updates #1486. PiperOrigin-RevId: 338685972
2020-10-20Fix nogo test in //pkg/tcpip/...Ting-Yu Wang
PiperOrigin-RevId: 338168977
2020-10-16Don't include link header when forwarding packetsGhanan Gowripalan
Before this change, if a link header was included in an incoming packet that is forwarded, the packet that gets sent out will take the original packet and add a link header to it while keeping the old link header. This would make the sent packet look like: OUTGOING LINK HDR | INCOMING LINK HDR | NETWORK HDR | ... Obviously this is incorrect as we should drop the incoming link header and only include the outgoing link header. This change fixes this bug. Test: integration_test.TestForwarding PiperOrigin-RevId: 337571447
2020-10-09Merge release-20200928.0-78-g743327817 (automated)gVisor bot
2020-10-09Merge release-20200928.0-77-g257703c05 (automated)gVisor bot
2020-10-09Automated rollback of changelist 336304024Ghanan Gowripalan
PiperOrigin-RevId: 336339194
2020-10-09Merge release-20200928.0-74-g8566decab (automated)gVisor bot
2020-10-09Automated rollback of changelist 336185457Bhasker Hariharan
PiperOrigin-RevId: 336304024
2020-10-08Merge release-20200928.0-71-g6768e6c59 (automated)gVisor bot
2020-10-08Do not resolve routes immediatelyGhanan Gowripalan
When a response needs to be sent to an incoming packet, the stack should consult its neighbour table to determine the remote address's link address. When an entry does not exist in the stack's neighbor table, the stack should queue the packet while link resolution completes. See comments. PiperOrigin-RevId: 336185457