Currently, BpfCoordinator only sets the data limit on a given
upstream whenever the first IPv6 rule is created on that
upstream, and clears it whenever the last rule is deleted on that
upstream. It never does this when adding or removing IPv4 rules.
This makes it impossible to offload traffic on IPv4-only
networks.
Fix this by setting the limit when IPv4 rules are created or
deleted as well.
Test: atest TetheringCoverageTests
Manual tests as the follows
Test {add, clear} limit with IPv6-only network [OK]
Test {add} limit with IPv4-only upstream [OK]
TODO:
Test {clear} limit with IPv4-only network. blocked by aosp/1579873
because the IPv4 rules have never deleted.
Change-Id: I5a29bdd18e564318759f617023163e23fb5a3ed0
Migrate Maze's BPF program attaching and detaching functions from
system/netd/server/OffloadUtils.{c, h} to tethering module.
Test: atest TetheringCoverageTests
Test case #1:
Enable WiFi hotspot and check tc filters are added or removed on both
wlan1 and rmnet_data#.
$ adb shell tc filter show dev wlan1 ingress
filter protocol ipv6 pref 1 bpf chain 0
filter protocol ipv6 pref 1 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_upstream6_ether:[*fsobj] direct-action
not_in_hw id 2 tag 7cf020cc09a7c982
filter protocol ip pref 2 bpf chain 0
filter protocol ip pref 2 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_upstream4_ether:[*fsobj] direct-action
not_in_hw id 7 tag 2f87d55b636c082c
$ adb shell tc filter show dev rmnet_data2 ingress;
filter protocol ipv6 pref 1 bpf chain 0
filter protocol ipv6 pref 1 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_downstream6_rawip:[*fsobj] direct-action
not_in_hw id 3 tag 8b3885b75bd261de
filter protocol ip pref 2 bpf chain 0
filter protocol ip pref 2 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_downstream4_rawip:[*fsobj] direct-action
not_in_hw id 6 tag b1c9478c91f8df9a
Test case #2:
Enable USB tethering and check tc filters are added or removed on both
rndis0 and rmnet_data#.
Test case #3:
Enable WiFi and USB tethering and check tc filter are added or removed
on rndis0, wlan1 and rmnet_data#.
Change-Id: I3f9a65043271bc8f5bf1b82ae505c471625ca9de
Add and remove downstream client information to BpfCoordinator
Required for building IPv4 forwarding rule when a conntrack event is
received. The IpServer provides the following elements of a rule which
is not included in conntrack event:
- Downstream interface index
- Downstream Mac address
- Client IP address to Client Mac address
Test: atest TetheringCoverageTests
Change-Id: I84db13acc047ace5730d17f0d3dd99544f516084
A preparation for starting monitoring conntrack event which is required
by IPv4 tethering offload.
Test: atest TetheringCoverageTests
Change-Id: Ied46aeca193554f52a90889dfdf92827e94845d6
Make the IP subnet persistent if it do not conflict with upstream.
It allow client to reuse its IP that usually reduce DHCP procedure.
Bug: 168169687
Test: atest TetheringTests
Change-Id: Iddc5304730dce7b11c5d124b7eddce057d752bbd
This patch is still needed and should go in now that the
error is fixed.
The patch was submitted into rvc-dev and is already in
rvc-dev-plus-aosp (patch in in ag/11923559, revert
skipped in ag/12072199). A follow-up will remove the
unused services.net-module-wifi target.
Test: originally tested in aosp/1324109
Test: m; manual: flashed, wifi and telephony working
Test: atest NetworkStackCoverageTests
Change-Id: I1074eedb0b0f156a1135e11210ec102de15ea674
Merged-In: Icd141a992c46290c74929785e261a1cd57bc001b
If dhcp server is obsolete, explicitly stop it to shut down its thread.
Bug: 161418295
Test: atest CtsTetheringTest
Change-Id: Ic5b876bd23711ec8d832879a7baee0495246b218
This reverts commit cf86031c12.
Reason for revert: Breaks the build b/160390899
Merged-In: Icd141a992c46290c74929785e261a1cd57bc001b
Change-Id: Ie10e66f61393602f17fbb61bf17230b176bf1f44
The classes should not be picked up from frameworks/base, as they are
part of several mainline modules.
Also refine comments in DhcpResults following feedback in previous
change.
(cherry-pick from internal branch skipping wifi classes; no other
conflict)
Bug: 151052811
Test: m; manual: flashed, wifi and telephony working
Test: atest NetworkStackCoverageTests
Merged-In: I7074651c6a2a7a6b11bcf13cc4bb03833d7d655f
Change-Id: I7074651c6a2a7a6b11bcf13cc4bb03833d7d655f
This change is a combination of following changes:
1) Tethering: add TETHERING_WIGIG type
Currently both WIFI and WIGIG use the same tethering type,
TETHERING_WIFI. This causes conflicts between the frameworks,
when both WIFI and WIGIG SoftAPs are started, one or both will
not work.
Fix this by using a seperate tethering type for WIGIG.
2) Tethering: remove TETHERING_WIGIG state machine on interface down
The wigig state machine relies on a TETHERING_STATE_CHANGED broadcast
that is sent when the tethering state machine is first created, during
interface up. Currently the tethering state machine is not removed
on interface down except for TETHERING_BLUETOOTH, and as a result
wigig tethering only works the first time SoftAP is started.
In order to fix this, remove the tethering state machine on interface
down for TETHERING_WIGIG as well.
Bug: 143356416
Test: TetheringCoverageTests
Change-Id: Ic4d3aca0ed69234093af7f0206dab3335938c52a
When LAN link is changed for using ethernet interface from Ethernet tethering to Ethernet,
there is confiict as Ethernet Tethering is trying to make ethernet link down and Ethernet is trying to make ethernet link up.
So, this would make Ethernet only manage ethernet interface link state.
Test: manual
Bug: 130840861
Change-Id: I1cd40ae764bdeecbb59e3889e9399b7f4b05f9cc
1. When Wi-Fi enabled, ap0 interface is added and IpNeighborMonitor's
start() is invoked in IpServer's constructor.
2. There's no stop for IpNeighborMonitor when IpServer stop.
3. During overnight test for Wi-Fi, networkstack is too slow to
process request due to memory leak in IpNeighborMonitor and
binder buffer is blocked causing exception.
Solution: Invoke IpNeighborMonitor.stop() in UnavailableState.enter().
Bug: 159097215
Test: automatic, turn on and off Wi-Fi every 6 seconds overnight
Change-Id: I8f60c13706f05306e8f25a15f7861d7ecabbc10e
The BPF tethering coordinator listens to the forwarding rule
changes for updating data limit which is applied in the following
conditions.
- After adding the first rule on a given upstream, add data limit.
- After removing the last rule on a given upstream, clear data limit.
- The service applies a new data limit on current upstream.
The reason for relying on rule changes is because the Tethering and
IpServer objects have multi-internal state machines. It is hard to
synchronize all of their states.
Note that the data limit cleanup for stopping or switching upstream
relies on offload rules are all removed as well.
Bug: 150736748
Test: manual
Change-Id: I829d36339973f9473fe6b616c48aa288f18d1c46
This effectively reverts:
commit da0fb1bca8
Author: Maciej Żenczykowski <maze@google.com>
Date: Wed Feb 19 01:24:39 2020 -0800
Reduce advertised ipv6 mtu by 16 to fit ethernet header
This is a temporary hack to workaround the inability of current
kernel's ebpf bpf_skb_change_mode() function to prefix a 14-byte
ethernet header on to a packet without going over the upstream
(source, rawip) interface's mtu *before* we bpf_redirect() to
the downstream (destination, ethernet) interface.
Test: build, atest, atest TetheringTests
Bug: 149816401
Test: flashed a flame with new kernel and it works at 1500 mtu
Bug: 149816401
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I76a75a16fa27b47d78816b2f9379ef4bb68beb00
Merged-In: I76a75a16fa27b47d78816b2f9379ef4bb68beb00
This is a preparation for moving adding/removing forwarding rules from
IpServer to BpfCoordinator.
Bug: 150736748
Test: atest IpServerTest
Change-Id: I85316ef09ff3c9389ded11dcc384493d699da48e
Make BPF tethering offload coordinator, BpfCoordinator,
registers a network stats provider, BpfTetherStatsProvider, and
provide the tethering stats from the BPF map.
Bug: 150736748
Test: new test BpfCoordinatorTest
Change-Id: I22e71f87b67668f7e733e4f215d93bf5b2c9380d
- Add New class PrivateAddressCoordinator to coordinate the private
address conflict problem.
- Downstream prefix would be random in 192.168.0.0/24 ~
192.168.255.0/24.
- If new upstream prefix is conflict with existing downstream prefix,
downstream would be kicked out and it would request a new one.
- The last conflict upstream prefixes would be blacklist. Avoid to
select downstream prefix which is conflict with prefixes in blacklist.
Bug: 130879722
Test: -build, flash, boot
-atest TetheringTests
Change-Id: Ib45b87bcd9eeb5da03fb7ec90b1af9ca53998cf5
If upstream is cellular, set the TTL in Router Advertisements to
"network-set TTL - 1" for carrier requirement. For other non-cellular
upstream, set TTL as "network-set TTL + 1" to preventing arbitrary
distinction between tethered and untethered traffic.
Bug: 154776299
Test: atest TetheringTests
Change-Id: I7f2696a642f96c6aafb5613b980bf5bcdd08bbda
Add the specific implementation of onNewPrefixRequest callback
on IpServer side, also refactor some common code.
Bug: 130741856
Test: atest TetheringTests
Change-Id: If2871bf899cb5890bbfee18063a194c92b6f474e
- Correct description and spelling in the code and xml files.
- Add a TODO for refactoring the IpServer constructor.
- Refine the if-statement for starting IP neighbor monitor.
Test: atest IpServerTest
Change-Id: If9c8bc6f785fa80575db56de4e223292e9807ace
If BPF offload device config is not enabled:
- Does not add/remove offload forwarding rules through disabling IP
neighbor monitor.
- Does not apply the RA MTU reduction.
Bug: 149997301
Test: atest IpServerTest
Change-Id: I2d6f80f0229f580c4b16243a064e889a6c37f77a
These events don't have MAC addresses, so the code attempts to
create an Ipv6ForwardingRule with a null MAC address. This
crashes when attempting to get the raw MAC address bytes to send
to netd in the TetherOffloadRuleParcel.
This was not caught by unit tests because the test exercise this
code path in a way that is not correct (by sending RTM_DELNEIGH
and NUD_FAILED events with MAC addresses). Fix the unit tests to
properly pass in null MAC addresses for these events.
Bug: 153697068
Test: fixed existing tests to be more realistic
Change-Id: I26d89a81f1c448d9b4809652b079a5f5eace3924
The netd tethering offload IPCs are changing from taking a list
of primitives to taking a TetherOffloadRuleParcel. Modify their
only caller.
Bug: 140541991
Test: atest IpServerTest
Change-Id: I83718c80ef9d31199c87021b4dd5821717fd5ba5
Per API review:
- @IntDef defined on the type integer parameter
- have getters on each parameter that is set in the
TetheringRequest.Builder
- new added API should not be deprecated
Below APIs is moved from system-current to module-lib-current that only
plafrom code(e.g. ConnectivityManager and Settings) can use them.
TetheringRequest.
onTetherableInterfaceRegexpsChanged, TetheringInterfaceRegexps:
Only platform code can use them because interfaces by regular
expressions are a mechanism which is planning to be deprecated.
Also rename some constants for easier to understand.
Bug: 149858697
Bug: 151243337
Test: m doc-comment-check-docs
atest TetheringTests
Change-Id: I45cb21d5bc919f6d32c42650326597d5173ea028
Merged-In: Idd041f0fbeca411ea23e49786a50dd7feb77ef45
Application can specify static ipv4 server and client address to setup
tethering and this is one shot configuration. Tethering service would
not save the configuration and the configuration would be reset when
tethering stop or start failure.
When startTethering callback fired, it just mean tethering is requested
successful. Therefore, callers may call startTethering again if
startTethering successful but do not receive following tethering active
notification for a while. Tethering service never actually does anything
synchronously when startTethering is called:
-startProvisioningIfNeeded just posts a message to the handler thread.
-enableTetheringInternal doesn't do anything synchronously, it just
asks the downstreams to get their interfaces ready and waits for
callbacks.
If tethering is already enabled with a different request,
tethering would be disabled and re-enabled.
Bug: 141256482
Test: -build, flash, boot
-atest TetheringTests
-atest CtsTetheringTest
Change-Id: I0399917e7cefa1547d617e688225544c4fc1a231
Add comments to getters as requested in API review, and remove the
expirationTime private field that was planned to be replaced with
LinkAddress expiration.
Test: atest TetheringTests
Fixes: 150878126
Change-Id: Iecf65859cdeeaac2fa7b817b4f505c510424ac89
Use IpNeighborMonitor to listen for ND cache events on the
downstream interface, and push downstream IPv6 fowarding rules
to netd.
Rules are pushed when:
- IPv6 neighbours appear/disappear on the downstream interface.
- The upstream changes.
Test: new unit test
Change-Id: I7b01ba179a4d6bb248fd6c4994e48800613a4efa
This is a temporary hack to workaround the inability of current
kernel's ebpf bpf_skb_change_mode() function to prefix a 14-byte
ethernet header on to a packet without going over the upstream
(source, rawip) interface's mtu *before* we bpf_redirect() to
the downstream (destination, ethernet) interface.
Test: build, atest, atest TetheringTests
Bug: 149816401
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I646148ebfd978a2489c0cd065e4b671b01150add
The callbacks are fired when the list of connected clients or their IP
addresses / hostname change.
Test: flashed, connected 2 devices, verified callbacks
Test: atest TetheringTests
Bug: 135411507
Change-Id: I96291038cf7b39a67547a5f74fcd7cbedc1ca002
Merged-In: I96291038cf7b39a67547a5f74fcd7cbedc1ca002
Ethernet tethering can be started via
startTethering(TETHERING_ETHERNET).
Test: flashed, enabled ethernet tethering, verified internet access on
downstream.
Bug: 130840861
Merged-In: I34842acd94b972e440c3622f7617df10c18acf65
Change-Id: I34842acd94b972e440c3622f7617df10c18acf65
(cherry-pick with conflicts in test-current.txt)
When leaving a group, all information are erased and no group interface
is passed to tethering service.
For separate group interface, tethering could be stopped
on p2p group interface removed. For shared group interface,
i.e. management interface and group interface share one
interface, ex. p2p0, tethering has no chance to be stopped since management
interface won't be removed after leaving a group.
Bug: 141382930
Test: atest FrameworksNetTests
Test: atest FrameworksWifiTests
Test: atest TetheringTests
Change-Id: Ib611018b67c76ff79c7e6658136721090feb145b
Currently NetworkStatsService is notified when downstream is
updated. However, it seems unnecessary given that tether stats
is persist since boot, and there is no any upstream change when
downstream is changed.
Test: atest NetworkStatsServiceTest IpServerTest
Bug: 130855321
Change-Id: Ie300bfeb0a04678fcfcf300843b6f859af9df91d
