GitLab

To support simultaneous tuns UidMarkMap now allows for
overlaping/duplicate rules. If there are multiple rules for a given uid
the most recently added rule will be used in all cases.

When overlapping rules are added in addUidRule there may be multiple
iptables rules matching the uid. Since addUidRule appends it will use
the most recent rule as well, no change required. Previously
UidMarkMap->add would fail and the rule would never be added.

Bug: 12134439
Change-Id: I5f2976dd3ee334584a9f98f6eacd5edbe5c9bb6b

resolv's uid range=>iface map now allows overlap in uid ranges to support
simultaneous tuns. _resolv_clear_iface_for_uid_range now takes the
interface to support removing only one of the rules.

Bug: 12134439
Change-Id: I3e2a167875bbd381846d5c47d7b34c625abfb2e0

Routes are now encoded by ip rules that send connections to the Vpn
table if the connection is marked and the destination falls into a
route. This differs from the previous design where a mark meant that
the connection must go over the VPN, now a mark simply means that it
may.
Bug: 12549060
Change-Id: I9be7e27a0f46858f109d8bc5c5bced309b05201a

The default result for a uid without a mark should be MARK_PROTECT
because the service using the uid's mark may be covered by a VPN that
should not cover the user it is acting for.

Bug: 12608570
Change-Id: I2402cb86ddb2fe6e670d1793263ff6c2c31d32fe

Without this change, the VPN sets up a tun/ppp that needs a small
MTU, and during TCP SYN the MSS will end up matching the outgoing iface
MTU which is potentially too big.
This leads to connection flakiness. The wrong MSS is visible by
tcpdump-ing on the tun/ppp device.

With this change, the MSS now is correct.
It requires the kernel to be configured with
 CONFIG_NETFILTER_XT_TARGET_TCPMSS=y
If kernel is not configured, it silently fails.

Bug: 11579326
Change-Id: I254d8c39435b92dff91931e461e1efb8b35f6b1e

A split-tunnel vpn shouldn't snarf all dns queries if it's not
going to provide dns servers to service them.

bug:10115444
Change-Id: I4f8de66b75a04ca0e274edb92ace7acee762bca2

When opening the netlink socket, NetlinkManager specifies it's
interested in ND_USEROPT messages, but we since we don't have
code to parse them yet, we end up logging an error message for
packets that contain them. Get rid of the logspam by not asking
the kernel to receive them.

Bug: 10718651
Change-Id: Ib1b7748448a983cfa7bb7725e48e238d85152ea2

When a device first boots, there won't be any tethering stats, which
isn't an error.  Continue checking for partial results.

Bug: 5868832
Change-Id: Ic432f5f159320da9886d85c2525fa2cde8c67750

The change to enable address tracking via netlink incorrectly
changed the subsystem of rtnetlink events from "net" to
"interface". This broke interface add/delete notifications,
which come from the kernel with subsystem "net".

Switch back to "net" and deal with address tracking via new
action codes instead of a new subsystem.

Bug: 10433320
Change-Id: I59a50e9c7cb49f46e680c7d84ac8e196a861ca4b

Some of the bw_costly_<iface> rules would not get correctly flushed and
cleared on netd re-start, which would cause a failure when trying to
setup the bw_penalty_box as bw_costly_<iface> would reference it.
The resulting symptom would be that bandwidth could not be re-enabled.

Bug: 10183445
Change-Id: I79a8a73ae52e18b3bff8a58e47ac1aea2454ae63

Subscribe netd's netlink socket to listen to IPv4 and IPv6
address changes (and ND opts, which we'll need for IPv6 DNS
later), and make NetlinkHandler notify the system of address
changes.

Bug: 10232006
Change-Id: Ib9dfd58635dce389980d8ee9529a17661a02320a

* commit 'bca84afd':
  Incorrect memset parameters

Memset parameters swapped

Change-Id: I528c1f6de344447d3c43d89c1dd4cd87e1c5c5a7

Host exemption now properly handles routing for sockets that were
already marked

Change-Id: I55d5c00754036a5ef49379170c37607d3e71a1e8

* commit '8ab6df2e':
  Fix memset call

* commit '08ff0e40':
  Fix memset call

Parameters was passed in the wrong order.

Change-Id: I1d4d68f1ba729bf54da84cbcb5f631938ac697f2

Add commands for fetching the mark associated with routing a uid and for
fetching the mark associated with avoiding the fwmark routing rules

Change-Id: I4accd1a9aecd91f6f0630eb1a5466a81e309eeac

requestRouteToHost requires the ability to punch holes in the VPN for
certain addresses, this adds support for this under mark based VPNs.

Change-Id: I9d890829048624d43c0f1efaec54563a860e850f

Packets are now only marked for fwmark if their destination is in one of
the routes for the target interface.

Change-Id: Ided4ad992c4cf957d77ae11fa62ac4843a8592c7

Just a cleanup.

Change-Id: Ic5afd7bd194fdcad604d533ba95e4c23b10b3e24

The happy box needs to be able to let UID 0 (dhcp, ...) pass through.

Bug: 6212480
Change-Id: I9867b7db4e5ad71cfb1170659d2d6a14ca9590be

* ndc bandwidth happybox (enable | disable)
 - enable
  . creates a an empty happy_box chain which rejects all traffic from all UIDs by default.
  . Uses the penalty_box as a hook. Any costly_interface automatically  gets the happy_box as it has a penalty_box.
  . any app UID not in the happy_box will be treated as if it was in the penalty_box (i.e. addnaughtyapps)
  . penalty_box (addnaughtyapps) still applies.
 - disable
  . removes the happy box.
* ndc bandwidth addniceapps <appUid> ...
 - similar to addnaughtyapps, but for the happy_box
* ndc bandwidth removeniceapps <appUid> ...
 - similar to removenaughtyapps, but for the happy_box

Bug: 6212480
Change-Id: I1f10e8c6fa1b230c7b3bb070d88508e437589705

Rename some stuff in preparation for nice apps and the "happy box".

Bug: 6212480
Change-Id: I637c4283695ac619533999beab4f88968580d2e4

Currently the bandwidth controller will cut off traffic via an ICMP
destination unreachable message with code "administratively prohibited".
TCP's RFC1122 does not explicitly say what to do with it, but it does say
to abort the transmission when "port-unreachable" is seen.

Some servers keep on retrying with the "prohibited" ICMP message which
keeps the radio longer awake as more packets come in.

Bug: 9150002
Change-Id: I6eb1c3ae41c3890f26581a4b7464821b7ffb85f4

DNSProxyListener now supports bionic changes for marking DNS requests
for routing DNS requests with the uid routing rules

Change-Id: Iac9aa1bb14834be6da5e512405f23c6a72dc71ed

* Persistent stats
Previously we would parse the iptables counters out of the FORWARD
rules used for tethering. Those rules could come an go before they
were parsed, which would cause us to incorrectly count traffic.
Now we have separate counting rules (and quota2 counters) which
persist beyond tethering.

* Rename the iface0/iface1
Match NatControllers notions for tethering ifaces during enable.
Detect weird call from userspace (until b/9565268 gets fixed),
or else it leaves an ugly iptables state.

* The commands affected:
 - ndc bandwidth gettetheringstats intIface extIface
  . no change from before: return a single stats line
 - ndc bandwidth gettetheringstats
  . return a list of results showing all tethered stats
 - ndc bandwidth gettetheringstats "" extIface
 - ndc bandwidth gettetheringstats intIface
   . return a list of results matching the tethering on
     the given interface.

Bug: 9565268
Bug: 5868832
Change-Id: I8559d9a184abcffaf65998fb3cc8c9c50d46bf06

* commit '5ff04590':
  Revert "netd: reduce privileges"