summaryrefslogtreecommitdiffhomepage
path: root/pkg/tcpip/link/qdisc
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-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-08-11Merge release-20200804.0-64-gc92242c89 (automated)gVisor bot
2020-08-11Fix-up issue comment.Adin Scannell
PiperOrigin-RevId: 326129258
2020-07-22Merge release-20200622.1-184-g71bf90c55 (automated)gVisor bot
2020-07-22Support for receiving outbound packets in AF_PACKET.Bhasker Hariharan
Updates #173 PiperOrigin-RevId: 322665518
2020-07-15Merge release-20200622.1-162-gfef90c61c (automated)gVisor bot
2020-07-15Fix minor bugs in a couple of interface IOCTLs.Bhasker Hariharan
gVisor incorrectly returns the wrong ARP type for SIOGIFHWADDR. This breaks tcpdump as it tries to interpret the packets incorrectly. Similarly, SIOCETHTOOL is used by tcpdump to query interface properties which fails with an EINVAL since we don't implement it. For now change it to return EOPNOTSUPP to indicate that we don't support the query rather than return EINVAL. NOTE: ARPHRD types for link endpoints are distinct from NIC capabilities and NIC flags. In Linux all 3 exist eg. ARPHRD types are stored in dev->type field while NIC capabilities are more like the device features which can be queried using SIOCETHTOOL but not modified and NIC Flags are fields that can be modified from user space. eg. NIC status (UP/DOWN/MULTICAST/BROADCAST) etc. Updates #2746 PiperOrigin-RevId: 321436525
2020-06-03Merge release-20200522.0-72-gd3a8bffe (automated)gVisor bot
2020-06-03Pass PacketBuffer as pointer.Ting-Yu Wang
Historically we've been passing PacketBuffer by shallow copying through out the stack. Right now, this is only correct as the caller would not use PacketBuffer after passing into the next layer in netstack. With new buffer management effort in gVisor/netstack, PacketBuffer will own a Buffer (to be added). Internally, both PacketBuffer and Buffer may have pointers and shallow copying shouldn't be used. Updates #2404. PiperOrigin-RevId: 314610879
2020-05-28Merge release-20200518.0-47-g835e8c89 (automated)gVisor bot
2020-05-27Remove linkEP from DeliverNetworkPacketSam Balana
The specified LinkEndpoint is not being used in a significant way. No behavior change, existing tests pass. This change is a breaking change. PiperOrigin-RevId: 313496602
2020-05-27Merge release-20200518.0-45-g0bc022b7 (automated)gVisor bot
2020-05-11Merge release-20200422.0-66-ge838e7a (automated)gVisor bot
2020-05-11Automated rollback of changelist 310417191Bhasker Hariharan
PiperOrigin-RevId: 310963404
2020-05-07Merge release-20200422.0-50-g28b5565 (automated)gVisor bot
2020-05-07Automated rollback of changelist 309339316Bhasker Hariharan
PiperOrigin-RevId: 310417191
2020-05-01Merge release-20200422.0-8-g8962b78 (automated)gVisor bot
2020-04-30Enable FIFO QDisc by default in runsc.Bhasker Hariharan
Updates #231 PiperOrigin-RevId: 309339316
2020-04-30Merge release-20200422.0-7-gae15d90 (automated)gVisor bot
2020-04-30FIFO QDisc implementationBhasker Hariharan
Updates #231 PiperOrigin-RevId: 309323808