summaryrefslogtreecommitdiffhomepage
path: root/pkg/tcpip/network
AgeCommit message (Collapse)Author
2020-12-28Merge release-20201208.0-89-g3ff7324df (automated)gVisor bot
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-21Prefer matching labels and longest matching prefixGhanan Gowripalan
...when performing source address selection for IPv6. These are defined in RFC 6724 section 5 rule 6 (prefer matching label) and rule 8 (use longest matching prefix). This change also considers ULA of global scope instead of its own scope, as per RFC 6724 section 3.1: Also, note that ULAs are considered as global, not site-local, scope but are handled via the prefix policy table as discussed in Section 10.6. Test: stack_test.TestIPv6SourceAddressSelectionScope Startblock: has LGTM from peterjohnston and then add reviewer brunodalbo PiperOrigin-RevId: 348580996
2020-12-16Cleanup locking in multicast group protocol testsGhanan Gowripalan
Startblock: has LGTM from asfez and then add reviewer tamird PiperOrigin-RevId: 347928471
2020-12-15Don't split enabled flag across multicast group stateGhanan Gowripalan
Startblock: has LGTM from asfez and then add reviewer brunodalbo PiperOrigin-RevId: 347716242
2020-12-12Merge release-20201208.0-40-g08d36b6c6 (automated)gVisor bot
2020-12-12Reduce the memory overhead in IP fragment managementToshi Kikuchi
- Deep-copy pkt.Data and hold it instead of shallow-copy (vv.Clone). This allows the pkt's backing array, which includes the header portion, to be freed. - Remove fragHeap. The fragments are now held in holes struct instead. - Stop reserving the initial capacity of holes slice. PiperOrigin-RevId: 347198744
2020-12-12Merge release-20201208.0-39-g4aef908c9 (automated)gVisor bot
2020-12-12Introduce IPv6 extension header serialization facilitiesBruno Dal Bo
Adds IPv6 extension header serializer and Hop by Hop options serializer. Add RouterAlert option serializer and use it in MLD. Fixed #4996 Startblock: has LGTM from marinaciocea and then add reviewer ghanan PiperOrigin-RevId: 347174537
2020-12-10Merge release-20201130.0-80-g53a95ad0d (automated)gVisor bot
2020-12-10Use specified source address for IGMP/MLD packetsGhanan Gowripalan
This change also considers interfaces and network endpoints enabled up up to the point all work to disable them are complete. This was needed so that protocols can perform shutdown work while being disabled (e.g. sending a packet which requires the endpoint to be enabled to obtain a source address). Bug #4682, #4861 Fixes #4888 Startblock: has LGTM from peterjohnston and then add reviewer brunodalbo PiperOrigin-RevId: 346869702
2020-12-10Merge release-20201130.0-69-g50189b0d6 (automated)gVisor bot
2020-12-09Do not perform IGMP/MLD on loopback interfacesGhanan Gowripalan
The loopback interface will never have any neighbouring nodes so advertising its interest in multicast groups is unnecessary. Bug #4682, #4861 Startblock: has LGTM from asfez and then add reviewer tamird PiperOrigin-RevId: 346587604
2020-12-09Merge release-20201130.0-65-g96d14de0f (automated)gVisor bot
2020-12-09export MountTempDirectoryZeling Feng
PiperOrigin-RevId: 346487763
2020-12-07Merge release-20201130.0-57-g0e5ba13b3 (automated)gVisor bot
2020-12-07Remove stale commentSam Balana
Removes comment lines about MaxUnsolicitedReportDelay. This is already documented in the comment for GenericMulticastProtocolOptions. PiperOrigin-RevId: 346185053
2020-12-05Merge release-20201130.0-46-gdf2dbe3e3 (automated)gVisor bot
2020-12-04Remove stack.ReadOnlyAddressableEndpointStateGhanan Gowripalan
Startblock: has LGTM from asfez and then add reviewer tamird PiperOrigin-RevId: 345815146
2020-12-04Merge release-20201130.0-39-gfd28ccfaa (automated)gVisor bot
2020-12-04Introduce IPv4 options serializer and add RouterAlert to IGMPBruno Dal Bo
PiperOrigin-RevId: 345701623
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-12-02Merge release-20201117.0-100-gbdaae08ee (automated)gVisor bot
2020-12-02Extract ICMPv4/v6 specific stats to their own typesArthur Sfez
This change lets us split the v4 stats from the v6 stats, which will be useful when adding stats for each network endpoint. PiperOrigin-RevId: 345322615
2020-12-02Merge release-20201117.0-99-g6a26930ee (automated)gVisor bot
2020-12-02Abandon reassembly of a packet if fragments overlapArthur Sfez
However, receiving duplicated fragments will not cause reassembly to fail. This is what Linux does too: https://github.com/torvalds/linux/blob/38525c6/net/ipv4/inet_fragment.c#L355 PiperOrigin-RevId: 345309546
2020-12-01Merge release-20201117.0-84-g25570ac4f (automated)gVisor bot
2020-12-01Track join count in multicast group protocol stateGhanan Gowripalan
Before this change, the join count and the state for IGMP/MLD was held across different types which required multiple locks to be held when accessing a multicast group's state. Bug #4682, #4861 Fixes #4916 PiperOrigin-RevId: 345019091
2020-11-30Add more fragment reassembly testsToshi Kikuchi
These tests check if a maximum-sized (64k) packet is reassembled without receiving a fragment with MF flag set to zero. PiperOrigin-RevId: 344913172
2020-11-30Merge release-20201117.0-78-ge81300866 (automated)gVisor bot
2020-11-30Perform IGMP/MLD when the NIC is enabled/disabledGhanan Gowripalan
Test: ip_test.TestMGPWithNICLifecycle Bug #4682, #4861 PiperOrigin-RevId: 344888091
2020-11-27Merge release-20201109.0-121-g4fd71a7b2 (automated)gVisor bot
2020-11-27Don't add a temporary address to send DAD/RS packetsGhanan Gowripalan
Bug #4803 PiperOrigin-RevId: 344553664
2020-11-26Merge release-20201109.0-118-gbc81fcced (automated)gVisor bot
2020-11-25Support listener-side MLDv1Ghanan Gowripalan
...as defined by RFC 2710. Querier (router)-side MLDv1 is not yet supported. The core state machine is shared with IGMPv2. This is guarded behind a flag (ipv6.Options.MLDEnabled). Tests: ip_test.TestMGP* Bug #4861 PiperOrigin-RevId: 344344095
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-24Merge release-20201109.0-113-g4da63dc82 (automated)gVisor bot
2020-11-24Report correct pointer value for "bad next header" ICMP errorJulian Elischer
Because the code handles a bad header as "payload" right up to the last moment we need to make sure payload handling does not remove the error information. Fixes #4909 PiperOrigin-RevId: 344141690
2020-11-24Merge release-20201109.0-110-g732e98985 (automated)gVisor bot
2020-11-24Extract IGMPv2 core state machineGhanan Gowripalan
The IGMPv2 core state machine can be shared with MLDv1 since they are almost identical, ignoring specific addresses, constants and packets. Bug #4682, #4861 PiperOrigin-RevId: 344102615
2020-11-24Merge release-20201109.0-108-g1de08889d (automated)gVisor bot
2020-11-24Deduplicate code in ipv6.protocolGhanan Gowripalan
PiperOrigin-RevId: 344009602
2020-11-24Merge release-20201109.0-107-gba2d5cb7e (automated)gVisor bot
2020-11-23Use time.Duration for IGMP Max Response Time fieldGhanan Gowripalan
Bug #4682 PiperOrigin-RevId: 343993297
2020-11-20Merge release-20201109.0-95-gfbc4a8dbd (automated)gVisor bot
2020-11-19Perform IGMPv2 when joining IPv4 multicast groupsRyan Heacock
Added headers, stats, checksum parsing capabilities from RFC 2236 describing IGMPv2. IGMPv2 state machine is implemented for each condition, sending and receiving IGMP Membership Reports and Leave Group messages with backwards compatibility with IGMPv1 routers. Test: * Implemented igmp header parser and checksum calculator in header/igmp_test.go * ipv4/igmp_test.go tests incoming and outgoing IGMP messages and pathways. * Added unit test coverage for IGMPv2 RFC behavior + IGMPv1 backwards compatibility in ipv4/igmp_test.go. Fixes #4682 PiperOrigin-RevId: 343408809
2020-11-19Merge release-20201109.0-91-g49adf36ed (automated)gVisor bot
2020-11-19Fix possible panic due to bad data.Julian Elischer
Found by a Fuzzer. Reported-by: syzbot+619fa10be366d553ef7f@syzkaller.appspotmail.com PiperOrigin-RevId: 343379575
2020-11-19Merge release-20201109.0-88-g27ee4fe76 (automated)gVisor bot
2020-11-19Don't hold AddressEndpoints for multicast addressesGhanan Gowripalan
Group addressable endpoints can simply check if it has joined the multicast group without maintaining address endpoints. This also helps remove the dependency on AddressableEndpoint from GroupAddressableEndpoint. Now that group addresses are not tracked with address endpoints, we can avoid accidentally obtaining a route with a multicast local address. PiperOrigin-RevId: 343336912