UDP packets can be built as:
val p = ether / ipv6 / udp / data
val p2 = ether / ipv4 / udp / data
val p3 = ether / ipv4 / udp / ipv4 / udp / data
This also gets rid of Icmp6Pkt in favor of a function call that
calculates the checksum over an L4 packet.
This does add a bit of duplication: the build() function for RA and NA
packets is identical, and UdpPkt#build() is not far off. However, subtle
differences in L4 packet format (namely the checksum and length
positions) make generalizing this code difficult. This is possible by
passing the checksum position, proto byte, and adding an abstract
function that fills in the L4 length field before performing checksum
calculation. However, this complexity is likely not worth it. If the
repetition becomes obvious once more protocols (such as ICMPv4/6 echo,
etc.) are added, this decision will be revisited.
Test: TH
Flag: EXEMPT mainline
Bug: 1000001
Change-Id: Ia78792418f29a3be091ebdc9bb2c26e45da9f2b1
Patrick Rohrauthored and Maciej Żenczykowskicommited 2025-04-07 14:22:43 -07:00
Options and fragments aren't currently supported.
Test: decoded test packet on packetor.com
Flag: EXEMPT mainline
Bug: 1000001
Change-Id: Ia3a094cb1d2b093cae2f372cc84a72ad7e107105
This commit increases the timeout for the
ApfIntegrationTest#testReadWriteProgram() test case from 15 minutes to
20 minutes. This change ensures that the test does not timeout on slower
devices.
Bug: 407721406
Flag: EXEMPT bug fix
Test: TH
Change-Id: I8c2b5d36aebc2f2fa66f2d72cccd88bf74f50b68
ApfIntegrationTest includes test cases that require turning off the
screen and waiting before sending packets. On devices with low power
standby capabilities, such as Android TVs, the packets sent by these CTS
test cases can be blocked. To prevent this interference, this commit
temporarily disables the low power standby policy during test execution.
Bug: 407698167
Flag: EXEMPT bug fix
Test: manually test on TV and Phone
Change-Id: I7312626b4d1939847e5bf5267da5e81dab241a64
The DataStore is now unused and can be safely removed. See b/407940468
for more details on why this preferences file was removed.
Fixes: 407940468
Test: atest NetworkSecurityUnitTests
Flag: com.android.net.ct.flags.certificate_transparency_service
Change-Id: Ic4427958acef94984f728398bdb9a6f7e53a9cbe
And integrate into EthernetManager. So it can make proper use of
PacketBuilderUtils.
Test: TH
Flag: EXEMPT mainline
Bug: 1000001
Change-Id: Ifbca38e6efde68e015c69bf919d079d1605310d1
When MdnsMultinetworkSocketClient stops using a socket (when
isSocketActive starts returning false), the packet handler should be
removed from that socket. The code only removed it from the
mSocketPacketHandlers map without clearing it from the socket.
This caused packets to be handled potentially many times, affecting
performance.
Bug: 406623719
Bug: 408324621
Test: atest
Flag: EXEMPT bugfix
Change-Id: I3d1117a4b847f3b95a01fc8a5997a53655ef608a
Address the TODO to allow tagging sockets, which was done before the
code was imported to the Android codebase.
Also remove the comment in MdnsSocket, as the tagging is already done by
setting the thread tag, and tagSocket in the original code actually did
nothing for DatagramSockets.
The option is unset in the Android repository, so this code is unused
there.
Test: atest
Flag: EXEMPT unused in Android repo
Change-Id: Ifccc4ec2f0b63bf2caabe1d9ef4f57f08731a2b1
Scapy allows building packets in order, i.e. by assembling them using
the division operator: val p = ether / ipv6 / icmpv6.
This change adds support for an identical pattern. To do so, it first
assembles all packets in order inside a packet builder class. When
build() is called, it traverses the packet list in reverse and assembles
the final packet, similar to ther original instance of the code. To
support checksum generation in the future, the code also keeps track of
the "closest pseudo header packet", i.e. the nearest encapsulating IPv6
(and soon IPv4) packet. This architecture should eventually be able to
support the creation of more complex packets, for example:
val p = ether / ipv6 / ipv6-ext / udp / ipv6 / udp.
(Note that now that I am writing this, I realize that this could
probably be significantly simplified by including IPv6 extension header
support as part of Ip6Pkt and always using the encapsulating packet for
the pseudo header...)
This code does not yet implement checksum generation.
Test: TH
Flag: EXEMPT mainline
Bug: 1000001
Change-Id: I9b0fa0e5bb66edf6928d9b96144c5ed133ebab64
The ct.preferences file has caused some issues (e.g. b/404408218), and
now that the logic of the logging is on every log list update (as
opposed to a certain number of consecutive failures), there is limited
utility in still relying on the DataStore to maintain a number of
crashes as this can be aggregated on the server side anyways.
Bug: 407940468
Test: atest NetworkSecurityUnitTests
Flag: com.android.net.ct.flags.certificate_transparency_service
Change-Id: I63bd9d87e1abd74c112485e8debfa284b81cc1ad
Improve the previous MdnsServiceCache change to only update
mNextExpirationTime when a service has expired.
Bug: 387910548
Test: atest ConnectivityCoverageTests NsdManagerTest
Flag: EXEMPT legacy flag nsd_optimized_expired_service_removal
Change-Id: Ia9b1fd4c16daa06af9818ff50c0a6c6e43f00ff8
Remi NGUYEN VANauthored and Paul Hucommited 2025-04-03 09:32:56 +00:00
The lost callback should be skipped if the service has not been
previously notified. Otherwise, the listener could inadvertently
initiate the service removal process for the incorrect service.
Bug: 387910548
Test: atest ConnectivityCoverageTests NsdManagerTest
Flag: EXEMPT legacy flag nsd_optimized_expired_service_removal
Change-Id: I7fdf31f0b15f19becc10fcb35c7b1f47dcc38c27
This commit introduces a new feature to optimize the removal of
expired services. After the query is sent, a task is scheduled
with a 2-second delay to wait for responses. During this delay,
if a service response is received, the service information is
updated, and the service is removed from the removal list. After
the delay, services that are expired, have sent a query, and for
which the query time was 2 seconds ago are removed, and listeners
are notified.
Bug: 387910548
Test: atest ConnectivityCoverageTests NsdManagerTest
Flag: EXEMPT legacy flag nsd_optimized_expired_service_removal
Change-Id: I498747839664eed8fe5b73a6f6d002deb9167271
Update MdnsServiceCache to enhance its ability to retrieve
responses and manage expired services effectively. Introduce an
argument `excludeExpiredServices` to control whether expired
services should be excluded when retrieving responses. And add a
new method `markExpiredServices` to mark services as expired
based on their TTL and current time.
Bug: 387910548
Test: atest ConnectivityCoverageTests NsdManagerTest
Flag: EXEMPT legacy flag nsd_optimized_expired_service_removal
Change-Id: Ifa30fbe75a72ea400a69ab258d67381a54faf9b5
Updated the MdnsServiceCache to maintain the first query time
after the last update of cached services, allowing for more
accurate expired service management.
Bug: 387910548
Test: atest ConnectivityCoverageTests NsdManagerTest
Flag: EXEMPT legacy flag nsd_optimized_expired_service_removal
Change-Id: I6da0691ece239b3b2e5dc5198a656cf21b30e953
MdnsResponseDecoder flushed all address records when receiving an
address record with the the cache-flush bit is set. However as per
RFC6762 10.2, only records with a matching rrtype should be
flushed, which means that AAAA records should not be flushed when an A
record is received, and vice-versa.
Fix the logic and include a default-on flag to allow turning it off if
needed.
Test: atest
Flag: EXEMPT bugfix
Bug: 407698496
Change-Id: I6142f9996362dd7c16b4e80c8019f0cb1caef174
This is a stopgap to palliate a bad interaction between
ConnectivityService and JobScheduler.
To help developers find request leaks and protect against OOMs
in the system server, ConnectivityService is enforncing a maximum
number of network requests/callbacks per UID. It has a higher
value for system UIDs because some system components need to
file requests on behalf of apps, most prominently JobScheduler.
The count is increased on entry in ConnectivityService, on the
Binder thread ; this is when CS can throw TooManyRequestsException
to the caller, it could not do that later when the request is
actually registered on the handler thread.
Conversely it only decreases the count on the handler thread,
because until then it doesn't know whether the request was
actually registered, and it can't look at that data structure on
the Binder thread.
This leads to a slightly confusing result where a UID can register
a request immediately after it unregisters one, and it will receive
TooManyRequestsException, because the unregister hasn't been
processed yet and the count not decremented yet.
This is arguably a bug, but if your app is treading on that last
request, you almost certainly had a leak anyway, and you should
not be trying to play with the exact count of requests either.
The remaining case is when an app would unregister and register
requests again in a tight loop, but there is no valid use case for
that, right ? Right !?
Enter JobScheduler. Because the limit for system UIDs is 250
requests but there can be more than 250 UIDs (especially on
devices with multiple users), JobScheduler has its own limit of
requests (which is set to 125). It has heuristics to choose which
are the most important 125 UIDs to file requests for.
When the request count exceeds 125, or when something
happens that may change which are the most important 125
UIDs, JobScheduler will re-evaluate which are the most important
ones. Upon doing this, it will unregister all requests and file
again the important ones in a tight loop. At worst, it will
therefore remove 125 requests and add 125 requests again,
taking up at most all 250 requests allowed for system UIDs ;
if the system server has any other request outstanding (and
it does), it may hit the issue where CS doesn't know yet that
requests have been unregistered, and crashes and hilarity ensue.
To palliate the issue above, this patch increases the allowed
request count for system UIDs by 125. This immediately should
fix the issue where all 250 requests are taken up by JobScheduler.
For a long-term fix, we should instead make at least one of the
following fixes :
- Have JobScheduler be smarter, and make sure it only unregisters
the requests that it no longer needs instead of all of them.
- Make CS only throw when the requests are really full, by using
some combination of locking, making the caller wait or similar.
- Have a separate pool of requests for JobScheduler that is
dimensioned so it knows it can file all the necessary requests
and no longer has to limit itself, and simplify the JS code.
Flag: EXEMPT bugfix
Bug: 391114053
Test: ConnectivityServiceTest
Change-Id: I4c4702e2d0c5d03eb5f3d6fe0f1578a210b188e8
Patrick Rohr
commited 
Treehugger Robot
authored and
Android (Google) Code Review
commited 
Maciej Żenczykowski
authored and
Bessie Jiang
authored and
Yuyang Huang
commited 
Bill Yi
commited 
Remi NGUYEN VAN
commited 
Jean Chalard
authored and
Sandro Montanari
authored and
Xiao Ma
authored and
Paul Hu
commited 
Tomasz Wasilczyk
authored and