Age | Commit message (Collapse) | Author |
|
From RFC 793 s3.9 p58 Event Processing:
If RECEIVE Call arrives in CLOSED state and the user has access to such a
connection, the return should be "error: connection does not exist"
Fixes #1598
PiperOrigin-RevId: 293494287
|
|
PiperOrigin-RevId: 293271055
|
|
PiperOrigin-RevId: 293243342
|
|
Tests 65k connection attempts on common types of sockets to check for port
leaks.
Also fixes a bug where dual-stack sockets wouldn't properly re-queue
segments received while closing.
PiperOrigin-RevId: 293241166
|
|
PiperOrigin-RevId: 292624867
|
|
As per RFC 2464 section 7, an IPv6 packet with a multicast destination
address is transmitted to the mapped Ethernet multicast address.
Test:
- ipv6.TestLinkResolution
- stack_test.TestDADResolve
- stack_test.TestRouterSolicitation
PiperOrigin-RevId: 292610529
|
|
Test: header.TestEthernetAddressFromMulticastIPAddress
PiperOrigin-RevId: 292604649
|
|
When sending a RST on shutdown we need to double check the
state after acquiring the work mutex as the endpoint could
have transitioned out of a connected state from the time
we checked it and we acquired the workMutex.
I added two tests but sadly neither reproduce the panic. I am
going to leave the tests in as they are good to have anyway.
PiperOrigin-RevId: 292393800
|
|
When sending NDP messages with an unspecified source address, the Source
Link Layer address must not be included.
Test: stack_test.TestDADResolve
PiperOrigin-RevId: 292341334
|
|
Do not start a new goroutine when calling
stack.NDPDispatcher.OnDuplicateAddressDetectionStatus.
PiperOrigin-RevId: 292268574
|
|
PiperOrigin-RevId: 292233574
|
|
Update link address for senders of NDP Neighbor Solicitations when the NS
contains an NDP Source Link Layer Address option.
Tests:
- ipv6.TestNeighorSolicitationWithSourceLinkLayerOption
- ipv6.TestNeighorSolicitationWithInvalidSourceLinkLayerOption
PiperOrigin-RevId: 292028553
|
|
Test: stack_test.TestDADResolve
PiperOrigin-RevId: 292003124
|
|
Tests:
- header.TestNDPSourceLinkLayerAddressOptionEthernetAddress
- header.TestNDPSourceLinkLayerAddressOptionSerialize
- header.TestNDPOptionsIterCheck
- header.TestNDPOptionsIter
PiperOrigin-RevId: 291856429
|
|
PiperOrigin-RevId: 291803499
|
|
The preferred Copyright holder is "The gVisor Authors".
PiperOrigin-RevId: 291786657
|
|
Fixes #1656
PiperOrigin-RevId: 291777279
|
|
This is to aid later implementation for /dev/net/tun device.
PiperOrigin-RevId: 291746025
|
|
|
|
|
|
PiperOrigin-RevId: 291745021
|
|
|
|
gonet.Conn can be created with both gonet.NewConn and gonet.Dial.
gonet.PacketConn was created only by gonet.DialUDP. This prevented
us from being able to use PacketConn in udp.NewForwarder() context.
This simple constructor - NewPacketConn, allows user to create
correct structure from that context.
|
|
Fixes #1656
PiperOrigin-RevId: 291703760
|
|
Checksum computation is one of the most expensive bits of
packet processing. Manual unrolling of the loop provides
significant improvement in checksum speed.
Updates #1656
BenchmarkChecksum/checksum_64-12 49834124 23.6 ns/op
BenchmarkChecksum/checksum_128-12 27111997 44.1 ns/op
BenchmarkChecksum/checksum_256-12 11416683 91.5 ns/op
BenchmarkChecksum/checksum_512-12 6375298 174 ns/op
BenchmarkChecksum/checksum_1024-12 3403852 338 ns/op
BenchmarkChecksum/checksum_1500-12 2343576 493 ns/op
BenchmarkChecksum/checksum_2048-12 1730521 656 ns/op
BenchmarkChecksum/checksum_4096-12 920469 1327 ns/op
BenchmarkChecksum/checksum_8192-12 445885 2637 ns/op
BenchmarkChecksum/checksum_16384-12 226342 5268 ns/op
BenchmarkChecksum/checksum_32767-12 114210 10503 ns/op
BenchmarkChecksum/checksum_32768-12 99138 10610 ns/op
BenchmarkChecksum/checksum_65535-12 53438 21158 ns/op
BenchmarkChecksum/checksum_65536-12 52993 21067 ns/op
BenchmarkUnrolledChecksum/checksum_64-12 61035639 19.1 ns/op
BenchmarkUnrolledChecksum/checksum_128-12 36067015 33.6 ns/op
BenchmarkUnrolledChecksum/checksum_256-12 19731220 60.4 ns/op
BenchmarkUnrolledChecksum/checksum_512-12 9091291 116 ns/op
BenchmarkUnrolledChecksum/checksum_1024-12 4976406 226 ns/op
BenchmarkUnrolledChecksum/checksum_1500-12 3685224 328 ns/op
BenchmarkUnrolledChecksum/checksum_2048-12 2579108 447 ns/op
BenchmarkUnrolledChecksum/checksum_4096-12 1350475 887 ns/op
BenchmarkUnrolledChecksum/checksum_8192-12 658248 1780 ns/op
BenchmarkUnrolledChecksum/checksum_16384-12 335869 3534 ns/op
BenchmarkUnrolledChecksum/checksum_32767-12 168650 7095 ns/op
BenchmarkUnrolledChecksum/checksum_32768-12 168075 7098 ns/op
BenchmarkUnrolledChecksum/checksum_65535-12 75085 14277 ns/op
BenchmarkUnrolledChecksum/checksum_65536-12 75921 14127 ns/op
PiperOrigin-RevId: 291643290
|
|
PiperOrigin-RevId: 291426657
|
|
Increase the timeout to 1s when waiting for async NDP events to help
reduce flakiness. This will not significantly increase test times as the
async events continue to receive an event on a channel. The increased
timeout allows more time for an event to be sent on the channel as the
previous timeout of 100ms caused some flakes.
Test: Existing tests pass
PiperOrigin-RevId: 291420936
|
|
|
|
PiperOrigin-RevId: 291249314
|
|
- Wrap NIC's fields that should only be accessed while holding the mutex in
an anonymous struct with the embedded mutex.
- Make sure NIC's spoofing and promiscuous mode flags are only read while
holding the NIC's mutex.
- Use the correct endpoint when sending DAD messages.
- Do not hold the NIC's lock when sending DAD messages.
This change does not introduce any behaviour changes.
Tests: Existing tests continue to pass.
PiperOrigin-RevId: 291036251
|
|
The iptables binary is looking for libxt_.so when it should be looking
for libxt_udp.so, so it's having an issue reading the data in
xt_match_entry. I think it may be an alignment issue.
Trying to fix this is leading to me fighting with the metadata struct,
so I'm gonna go kill that.
|
|
|
|
*net.UDPAddr
PacketConn.LocalAddr() already returns *net.UDPAddr correctly.
|
|
|
|
PiperOrigin-RevId: 290840370
|
|
Such a stat accounts for all connections that are currently
established and not yet transitioned to close state.
Also fix bug in double increment of CurrentEstablished stat.
Fixes #1579
PiperOrigin-RevId: 290827365
|
|
|
|
|
|
|
|
|
|
|
|
PiperOrigin-RevId: 290793754
|
|
CERT Advisory CA-96.21 III. Solution advises that devices drop packets which
could not have correctly arrived on the wire, such as receiving a packet where
the source IP address is owned by the device that sent it.
Fixes #1507
PiperOrigin-RevId: 290378240
|
|
It was possible to use this function incorrectly, and its separation
wasn't buying us anything.
PiperOrigin-RevId: 290311100
|
|
If a previously added IPv6 address (statically or via SLAAC) was removed, it
would be left in an expired state waiting to be cleaned up if any references to
it were still held. During this time, the same address could be regenerated via
SLAAC, which should be allowed. This change supports this scenario.
When upgrading an endpoint from temporary or permanentExpired to permanent,
respect the new configuration type (static or SLAAC) and deprecated status,
along with the new PrimaryEndpointBehavior (which was already supported).
Test: stack.TestAutoGenAddrAfterRemoval
PiperOrigin-RevId: 289990168
|
|
This change adds support to send NDP Router Solicitation messages when a NIC
becomes enabled as a host, as per RFC 4861 section 6.3.7.
Note, Router Solicitations will only be sent when the stack has forwarding
disabled.
Tests: Unittests to make sure that the initial Router Solicitations are sent
as configured. The tests also validate the sent Router Solicitations' fields.
PiperOrigin-RevId: 289964095
|
|
The change to introduce worker goroutines can cause the endpoint
to transition to StateError and we should terminate the loop rather
than let the endpoint transition to a CLOSED state as we do
in case the endpoint enters TIME-WAIT/CLOSED. Moving to a closed
state would cause the actual error to not be propagated to
any read() calls etc.
PiperOrigin-RevId: 289923568
|
|
|
|
All inbound segments for connections in ESTABLISHED state are delivered to the
endpoint's queue but for every segment delivered we also queue the endpoint for
processing to a selected processor. This ensures that when there are a large
number of connections in ESTABLISHED state the inbound packets are all handled
by a small number of goroutines and significantly reduces the amount of work the
goscheduler has to perform.
We let connections in other states follow the current path where the
endpoint's goroutine directly handles the segments.
Updates #231
PiperOrigin-RevId: 289728325
|
|
PiperOrigin-RevId: 289718534
|