| Age | Commit message (Collapse) | Author |
|---|
|
|
|
PiperOrigin-RevId: 356762859
|
|
|
|
The limits for snd/rcv buffers for unix domain socket is controlled by the
following sysctls on linux
- net.core.rmem_default
- net.core.rmem_max
- net.core.wmem_default
- net.core.wmem_max
Today in gVisor we do not expose these sysctls but we do support setting the
equivalent in netstack via stack.Options() method. But AF_UNIX sockets in gVisor
can be used without netstack, with hostinet or even without any networking stack
at all. Which means ideally these sysctls need to live as globals in gVisor.
But rather than make this a big change for now we hardcode the limits in the
AF_UNIX implementation itself (which in itself is better than where we were
before) where it SO_SNDBUF was hardcoded to 16KiB. Further we bump the initial
limit to a default value of 208 KiB to match linux from the paltry 16 KiB we use
today.
Updates #5132
PiperOrigin-RevId: 356665498
|
|
|
|
PiperOrigin-RevId: 356645022
|
|
|
|
Utilities written to be common across IPv4/IPv6 are not planned to be
available for public use.
https://golang.org/doc/go1.4#internalpackages
PiperOrigin-RevId: 356554862
|
|
|
|
... as per RFC 7048. The Failed state is an internal state that is not
specified by any RFC; replacing it with the Unreachable state enables us to
expose this state while keeping our terminology consistent with RFC 4861 and
RFC 7048.
Unreachable state replaces all internal references for Failed state. However
unlike the Failed state, change events are dispatched when moving into
Unreachable state. This gives developers insight into whether a neighbor entry
failed address resolution or whether it was explicitly removed.
The Failed state will be removed entirely once all references to it are
removed. This is done to avoid a Fuchsia roll failure.
Updates #4667
PiperOrigin-RevId: 356554104
|
|
|
|
PiperOrigin-RevId: 356536548
|
|
|
|
Reported-by: syzbot+9ffc71246fe72c73fc25@syzkaller.appspotmail.com
PiperOrigin-RevId: 356536113
|
|
|
|
PiperOrigin-RevId: 356450303
|
|
|
|
IPv4 forwarding and reassembly needs support for option processing
and regular processing also needs options to be processed before
being passed to the transport layer. This patch extends option processing
to those cases and provides additional testing. A small change to the ICMP
error generation API code was required to allow it to know when a packet was
being forwarded or not.
Updates #4586
PiperOrigin-RevId: 356446681
|
|
|
|
The thing the lock protects will never be accessed concurrently.
PiperOrigin-RevId: 356423331
|
|
|
|
We previously return EINVAL when connecting to port 0, however this is not the
observed behavior on Linux. One of the observable effects after connecting to
port 0 on Linux is that getpeername() will fail with ENOTCONN.
PiperOrigin-RevId: 356413451
|
|
|
|
Reported-by: syzbot+d54bc27a15aefe52c330@syzkaller.appspotmail.com
PiperOrigin-RevId: 356406975
|
|
|
|
...as long as the network protocol supports duplicate address detection.
This CL provides the facilities for a netstack integrator to perform
DAD.
DHCP recommends that clients effectively perform DAD before accepting an
offer. As per RFC 2131 section 4.4.1 pg 38,
The client SHOULD perform a check on the suggested address to ensure
that the address is not already in use. For example, if the client
is on a network that supports ARP, the client may issue an ARP request
for the suggested request.
The implementation of ARP-based IPv4 DAD effectively operates the same
as IPv6's NDP DAD - using ARP requests and responses in place of
NDP neighbour solicitations and advertisements, respectively.
DAD performed by calls to (*Stack).CheckDuplicateAddress don't interfere
with DAD performed when a new IPv6 address is added. This is so that
integrator requests to check for duplicate addresses aren't unexpectedly
aborted when addresses are removed.
A network package internal package provides protocol agnostic DAD state
management that specific protocols that provide DAD can use.
Fixes #4550.
Tests:
- internal/ip_test.*
- integration_test.TestDAD
- arp_test.TestDADARPRequestPacket
- ipv6.TestCheckDuplicateAddress
PiperOrigin-RevId: 356405593
|
|
|
|
This makes it easier to implement dynamically sized types in go-marshal. You
really only need to implement MarshalBytes, UnmarshalBytes and SizeBytes to
implement the entire interface.
By using the `dynamic` tag, the autogenerator will generate the rest of the
methods for us.
This change also simplifies how KernelIPTGetEntries implements Marshallable
using the newly added utility.
PiperOrigin-RevId: 356397114
|
|
|
|
Fixes a bug in our getsockopt(2) implementation which was incorrectly using
binary.Size() instead of Marshallable.SizeBytes().
PiperOrigin-RevId: 356396551
|
|
|
|
Detect packet loss using reorder window and re-transmit them after the reorder
timer expires.
PiperOrigin-RevId: 356321786
|
|
|
|
It was replaced by NUD/neighborCache.
Fixes #4658.
PiperOrigin-RevId: 356085221
|
|
|
|
Before this change, packets were delivered asynchronously to the remote
end of a pipe. This was to avoid a deadlock during link resolution where
the stack would attempt to double-lock a mutex (see removed comments in
the parent commit for details).
As of https://github.com/google/gvisor/commit/4943347137, we do not hold
locks while sending link resolution probes so the deadlock will no
longer occur.
PiperOrigin-RevId: 356066224
|
|
|
|
Previously when sending NDP DAD or RS messages, we would hold a shared
lock which lead to deadlocks (due to synchronous packet loooping
(e.g. pipe and loopback link endpoints)) and lock contention.
Writing packets may be an expensive operation which could prevent other
goroutines from doing meaningful work if a shared lock is held while
writing packets.
This change upates the NDP DAD/RS timers to not hold shared locks while
sending packets.
PiperOrigin-RevId: 356053146
|
|
|
|
The network endpoints only look for other network endpoints of the
same kind. Since the network protocols keeps track of all endpoints,
go through the protocol to find an endpoint with an address instead
of the stack.
PiperOrigin-RevId: 356051498
|
|
|
|
Previously when sending probe messages, we would hold a shared lock
which lead to deadlocks (due to synchronous packet loooping (e.g. pipe
and loopback link endpoints)) and lock contention.
Writing packets may be an expensive operation which could prevent other
goroutines from doing meaningful work if a shared lock is held while
writing packets.
This change upates the NUD timers to not hold shared locks while
sending packets.
PiperOrigin-RevId: 356048697
|
|
|
|
Also while I'm here, update neighbor cahce/entry tests to use the
stack's RNG instead of creating a neigbor cache/entry specific one.
PiperOrigin-RevId: 356040581
|
|
|
|
The NIC structure is not to be used outside of the stack package
directly.
PiperOrigin-RevId: 356036737
|
|
|
|
Network endpoints that wish to check addresses on another NIC-local
network endpoint may now do so through the NetworkInterface.
This fixes a lock ordering issue between NIC removal and link
resolution. Before this change:
NIC Removal takes the stack lock, neighbor cache lock then neighbor
entries' locks.
When performing IPv4 link resolution, we take the entry lock then ARP
would try check IPv4 local addresses through the stack which tries to
obtain the stack's lock.
Now that ARP can check IPv4 addreses through the NIC, we avoid the lock
ordering issue, while also removing the need for stack to lookup the
NIC.
PiperOrigin-RevId: 356034245
|
|
|
|
After IPTables checks a batch of packets, we can write packets that are
not dropped or locally destined as a batch instead of individually.
This previously caused a bug since WritePacket* functions expect to take
ownership of passed PacketBuffer{List}. WritePackets assumed the list of
PacketBuffers will not be invalidated when calling WritePacket for each
PacketBuffer in the list, but this is not true. WritePacket may add the
passed PacketBuffer into a different list which would modify the
PacketBuffer in such a way that it no longer points to the next
PacketBuffer to write.
Example: Given a PB list of
PB_a -> PB_b -> PB_c
WritePackets may be iterating over the list and calling WritePacket for
each PB. When WritePacket takes PB_a, it may add it to a new list which
would update pointers such that PB_a no longer points to PB_b.
Test: integration_test.TestIPTableWritePackets
PiperOrigin-RevId: 355969560
|
