We weren't notifying the second tethered iface of it's upstream iface name so its traffic
was not getting routed correctly.
We also weren't clearing out our connected iface name when we untethered, so the route rules
weren't getting flushed when the last tether came down.
Change-Id: I34e5d672ea882c89c8f582d69d6dc421cb52d4b4
Previously we only supported a single range - this was inadequate for
multiple interfaces. Adding a second range so we can support
both usb and wifi tethering.
Also moving out of the zero-conf range as our dhcp client won't
accept ip addrs in that range (no nexus to nexus wifi action).
bug: 2537963
bug: 2533491
bug: 2538303
Change-Id: I600b421343c28c2f9839ed2076122ae3d0ff5d3d
If the phone is configured to require a DUN connection when on mobile but also accepts
wifi upstream connections, there was a bug in the logic and you'd be left with no
upstream connection.
bug:2533914
Change-Id: I30d44764f578be4cf2c29ee90d39e8563dda06fb
Used to see multiple notifications if usb tethering and wifi tethering were both used.
bug:2527862
Change-Id: Idc6299c0a70564dd7c8d8d7fe13bde83723134ae
Tethering will now persist to on (until turned off) through upstream net drops,
tunnels, switches to wifi or 2G, mms sends, etc. It will also strive to use
the most natural connection and only go to HiPri/Dun APNs when needed.
bug:2519915
bug:2501837
Change-Id: Iedf6647daad8df507d7c87d1130b204b0a0acc7b
Now Tethering gets notified of UMS changes. Turns out UMS Broadcasts
have attached data with a file scheme and the filter had to be set
correctly.
bug:2504908
Change-Id: I67d979000196c90068fe59846b4fa2bbf6ea00d8
Also make the usb interface configuration more robust so retries are possible.
Makes all Tethering errors recoverable - no harm letting them try again anyway. Worst case
is they need to reboot.
when USB is connected and disconnected.
This is needed because the UMS broadcasts will not be sent when UMSis disabled.
Change-Id: I4488fee2c19ac9c901596d1430ea371df97e4325
Signed-off-by: Mike Lockwood <lockwood@android.com>
