Дэниэл Покок (Daniel Pocock), мэйнтейнер некоторых пакетов в Debian и Fedora, опубликовал интересный разбор организации работы tethering-режима в новых выпусках платформы Android. Tethering позволяет использовать телефон в качестве точки доступа для организации выхода в Сеть внешних устройств через установленное на смартфоне интернет-соединение. При установке очередного обновления прошивки Android, Дэниэл столкнулся с проблемами при работе устройств через tethering-соединение, при том, что при открытии тех же ресурсов со смартфона проблем со скоростью и доступом не наблюдалось.

Казалось бы, что не должно быть разницы при работе со смартфона или с внешнего устройства через этот же смартфон, так как интернет-соединение одно и для оператора трафик локального запроса и запроса через режим tethering неотличим. На самом деле, оказалось, что операторам предоставлена возможность различать трафик со смартфона и через режим tethering, в чём Дэниэл усматривает существенное ущемление приватности и ограничение прав пользователя. Некоторые операторы явно понижают качество сервиса для tethering-трафика, предполагая, что 3G-соединение смартфона недопустимо использовать для раздачи интернета на другие устройства. Компания Vodafone Italy, клиентом которой является Дэниэл, вообще заблокировала возможность использования tethering. Проблема также проявляется в прошивках CyanogenMod.

Технически разделение локального и tethering-трафика осуществляется через создание для tethering-соединения другого сетевого интерфейса с отдельным IP-адресом. При этом такое поведение рассматривается разработчиками как штатная функциональность, а не ошибка. Дэниэл не согласен с такой трактовкой и считает, что операторы связи заинтересованы в утечке данных о типе соединения и добились внесения данной возможности для получения своей экономической выгоды путем навязывания продаж USB-модемов как отдельного сервиса.

   shell@android:/ # ip route
   0.0.0.0/1 dev tun0  scope link
   default via 100.66.150.89 dev rmnet_usb0
   83.224.66.138 via 100.87.31.214 dev rmnet_usb1
   83.224.70.94 via 100.87.31.214 dev rmnet_usb1
   100.66.150.88/30 dev rmnet_usb0  proto kernel  scope link  src 100.66.150.90
   100.66.150.89 dev rmnet_usb0  scope link
   100.87.31.212/30 dev rmnet_usb1  proto kernel  scope link  src 100.87.31.213
   100.87.31.214 dev rmnet_usb1  scope link
   128.0.0.0/1 dev tun0  scope link
   192.168.42.0/24 dev rndis0  proto kernel  scope link  src 192.168.42.129

   shell@android:/ # ip rule show
   0:      from all lookup local
   32765:  from 192.168.42.0/24 lookup 60
   32766:  from all lookup main
   32767:  from all lookup default

   shell@android:/ # ip route show table 60
   default via 100.87.51.57 dev rmnet_usb1
   100.87.51.57 dev rmnet_usb1
   192.168.42.0/24 dev rndis0  scope link

Для устройств, на которых открыт доступ root, в качестве решения проблемы Дэниэл предлагает осуществить привязку tethering-соединения к основному сетевому интерфейсу, через который организован выход в интернет локальных приложений смартфона:

   # Находим правило, перенаправляющее трафик из tethering-подсети (в нашем случае 32765):
   shell@android:/ # ip rule show
   0:      from all lookup local
   32765:  from 192.168.42.0/24 lookup 60
   32766:  from all lookup main
   32767:  from all lookup default

   # Удаляем перенаправление
   shell@android:/ # ip rule del pref 32765
 
   # Меняем правила NAT-трансляции, переделав их  на основной интерфейс rmnet_usb0 
   # вместо по умолчанию используемого rmnet_usb1:
   shell@android:/ # iptables -t nat -I natctrl_nat_POSTROUTING -s 192.168.0.0/16 -o rmnet_usb0 -j MASQUERADE
   shell@android:/ # iptables -I natctrl_FORWARD -i rmmnet_usb0 -j RETURN

Дополнение: можно воспользоваться более простым способом, поправив при помощи sqlite содержимое базы /data/data/com.android.providers.settings/databases/settings.db, заменив значение поля tether_dun_required на 0.