Age | Commit message (Collapse) | Author |
|
|
|
Also refactor the template and CheckedObject interface to make this cleaner.
Updates #1486.
PiperOrigin-RevId: 339577120
|
|
|
|
This makes handling inbound fragmented packets easier, because a fragmented
packet might not have an actual ICMP header but only a payload. After this
change, the ICMPv4 is the last layer you can get because the payload is
embedded in it.
Note that this makes it consistent with the ICMPv6 implementation.
While I'm here, I've also added the Ident and Sequence fields on the ICMPv4
type. Defaults are still zero.
PiperOrigin-RevId: 339577094
|
|
|
|
PiperOrigin-RevId: 339570821
|
|
|
|
PiperOrigin-RevId: 339540747
|
|
|
|
Updates #1199
PiperOrigin-RevId: 339528827
|
|
|
|
Use the stack clock instead. Change NeighborEntry.UpdatedAt to
UpdatedAtNanos.
PiperOrigin-RevId: 339520566
|
|
|
|
PiperOrigin-RevId: 339505487
|
|
PiperOrigin-RevId: 339504677
|
|
|
|
PiperOrigin-RevId: 339476515
|
|
|
|
#4641 fixed the PHP runtime test ext/standard/tests/network/bug20134.phpt.
We should start testing it again.
Also excluded another flaky test. Seems like a test bug.
PiperOrigin-RevId: 339475716
|
|
|
|
PiperOrigin-RevId: 339459247
|
|
|
|
PiperOrigin-RevId: 339404936
|
|
Signed-off-by: Min Le <lemin.lm@antgroup.com>
|
|
|
|
PiperOrigin-RevId: 339385609
|
|
|
|
PiperOrigin-RevId: 339380431
|
|
|
|
IPv4 options extend the size of the IP header and have a basic known
format. The framework can process that format without needing to know
about every possible option. We can add more code to handle additional
option types as we need them. Bad options or mangled option entries
can result in ICMP Parameter Problem packets. The first types we
support are the Timestamp option and the Record Route option, included
in this change.
The options are processed at several points in the packet flow within
the Network stack, with slightly different requirements. The framework
includes a mechanism to control this at each point. Support has been
added for such points which are only present in upcoming CLs such as
during packet forwarding and fragmentation.
With this change, 'ping -R' and 'ping -T' work against gVisor and Fuchsia.
$ ping -R 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(124) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.990 ms
NOP
RR: 192.168.1.1
192.168.1.2
192.168.1.1
$ ping -T tsprespec 192.168.1.2 192.168.1.1 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(124) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.20 ms
TS: 192.168.1.2 71486821 absolute
192.168.1.1 746
Unit tests included for generic options, Timestamp options
and Record Route options.
PiperOrigin-RevId: 339379076
|
|
|
|
PiperOrigin-RevId: 339377254
|
|
|
|
This change wakes up any waiters when we receive an ICMP port unreachable
control packet on an UDP socket as well as sets waiter.EventErr in
the result returned by Readiness() when e.lastError is not nil.
The latter is required where an epoll()/poll() is done after the error
is already handled since we will never notify again in such cases.
PiperOrigin-RevId: 339370469
|
|
|
|
This PR implements /proc/[pid]/mem for `pkg/sentry/fs` (refer to #2716) and `pkg/sentry/fsimpl`.
@majek
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/4060 from lnsp:proc-pid-mem 2caf9021254646f441be618a9bb5528610e44d43
PiperOrigin-RevId: 339369629
|
|
|
|
PiperOrigin-RevId: 339363816
|
|
|
|
...instead of passing its fields piecemeal.
PiperOrigin-RevId: 339345899
|
|
|
|
In VFS1's overlayfs, files use the device and inode number of the lower layer
inode if one exists, and the upper layer inode otherwise. The former behavior
is inefficient (requiring lower layer lookups even if the file exists and is
otherwise wholly determined by the upper layer), and somewhat dangerous if the
lower layer is also observable (since both the overlay and lower layer file
will have the same device and inode numbers and thus appear to be the same
file, despite being behaviorally different). VFS2 overlayfs imitates Linux
overlayfs (in its default configuration) instead; it always uses the inode
number from the originating layer, but synthesizes a unique device number for
directories and another device number for non-directory files that have not
been copied-up.
As it turns out, the latter is insufficient (in VFS2, and possibly Linux as
well), because a given layer may include files with different device numbers.
If two distinct files on such a layer have device number X and Y respectively,
but share inode number Z, then the overlay will map both files to some private
device number X' and inode number Z, potentially confusing applications. Fix
this by assigning synthetic device numbers based on the lower layer's device
number, rather than the lower layer's vfs.Filesystem.
PiperOrigin-RevId: 339300341
|
|
|
|
Updates #3921
PiperOrigin-RevId: 339195417
|
|
|
|
PiperOrigin-RevId: 339182848
|
|
|
|
PiperOrigin-RevId: 339182137
|
|
|
|
PiperOrigin-RevId: 339166854
|