Как отключить слежку файрфокса за сетевыми интерфейсами?

исчезает интерфейс ppp0

мож просто сказать pppd persist?

в фф не шарю, но мож он лезет в свой dns over https без прокси?

Попробуй network.connectivity-service.enabled=false

Не помогло.

persist

Прочитал что это, вряд ли поможет. Нужно чтобы во время ручного реконнекта (он может длиться долго) фф ничего не замечал.

А у тебя «соединение с сетью» в настройках «no proxy» или «system»?

Может быть network.notify.changed или еще что-то из этого поможет:

// # If true, network link events will change the value of navigator.onLine.
// # Whether IOService.connectivity and NS_IsOffline depends on connectivity status.
// Monitor OS online/offline connection state.
// http://bugzilla.mozilla.org/show_bug.cgi?id=620472
// http://trac.torproject.org/projects/tor/ticket/18945
// Default: "true".
user_pref("network.manage-offline-status", false);

// # Allow network detection of IPv6 related changes (_bug 1245059).
// _It looks like in some setups (e.g. slow networks) when IPv6 newtorking is enabled Firefox falsly detects
// network adapters switching and breaks connections, which can lead to being unable to open web pages and 
// such. This pref (if set to "false") switches to an older code for newtwork adapter switch detection, which
// knows only IPv4 (and ignores IPv6). This happens only on Windows, so it has a different default.
// http://bugzilla.mozilla.org/show_bug.cgi?id=1245059
// Default: "true" ("false" on Windows).
user_pref("network.notify.IPv6", false);

// # Allow the network changed event to get sent when a network topology or setup change is noticed while
// running.
// _Makes browser respond to network changes, such as switch WiFi networks, moving from VPN to non-VPN,
// resuming after laptop is sleeping etc. It flushes the DNS cache and checks HTTP connections (for http/1
// connections waits 5 seconds if there is any data is transer; for http/2 connections it sends pings).
// _There's a system-specific part of this functionality that monitors when there's a change in IP 
// address/interface on OS-level.
// http://bugzilla.mozilla.org/show_bug.cgi?id=939318
// Default: "true".
user_pref("network.notify.changed", false);

// # Whether to check the registry for NRPT rules on network changes that indicate that TRR should not be used.
// _NRPT - Name resolution policy table, is a function of the Windows client and server operating systems that
// allows administrators to enable policy-based name resolution request routing. Instead of sending all name 
// resolution requests to the DNS server configured on the computer's network adapter, the NRPT can be used to
// define unique DNS servers for for specific names or namespaces. 
// http://directaccess.richardhicks.com/2018/04/23/always-on-vpn-and-the-name-resolution-policy-table-nrpt/
// http://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn593632(v=ws.11)
// TRR - Trusted Recursive Resolver, the Mozilla's name for DNS over HTTPS (DoH).
// Default: "true".
user_pref("network.notify.checkForNRPT", false);

// # Whether to check the registry for proxies on network changes that indicate that TRR should not be used.
// Default: "true".
user_pref("network.notify.checkForProxies", false);

// # Whether to check the dnsSuffix on network changes.
// _The DNS suffix is automatically appended to all domain names when making a DNS lookup. (That's why it is
// called a "suffix", and there's nothing more to it.) This parameter is announced via DHCP to all hosts on 
// the network. For example, if a company office has a server called "app.example.com", they can announce DNS
// suffix "example.com" via DHCP and the same server becomes accessible simply as "app". Whenever you visit 
// http://app/ the OS will automatically try http://app.<DNS_suffix>/ instead, saving employees a bit of 
// unnecessary typing. 
// http://superuser.com/questions/1481698/dns-suffix-explanation
// Default: "true".
user_pref("network.notify.dnsSuffixList", false);

// # Whether NotifyIpInterfaceChange should be called immediately after registration in order to record the
// initial state of the network adapters. 
// Default: "true".
user_pref("network.notify.initial_call", false);

// # Whether to check for DNS resolvers.
// Default: "true".
user_pref("network.notify.resolvers", false);

Поставь librewolf или другие аналоги без телеметрии. Мацилла давным-давно скурвилась и уже лет 10 как торгует телеметрией. Я погуглил. Аналогов либревульве нет. Он единственный из которого выпотрошили телеметрию… А у тебя там какая-то проблема с тем, что фуфло что-то своевольничает

Может приоритет интерфейсу нужен другой

Запустить firefox в namespace где нет ppp0

Какое ещё no proxy? Я ж написал - все соединения через локальное прокси идут, оно и прописано.

Приоритеты тут ни при чём (впрочем я не знаю где ты их нашёл), фф вообще не должен следить за интерфейсами. Его дело - открыть сокет с помощью socket()+connect() и пользоваться им, остальные аспекты сети его касаться не должны.

По описанию прям то что нужно, и

connections waits 5 seconds

вот это похоже на симптом (хотя может не 5 а 6-7-8 секунд до забывания запросов).

Но - поставил в false network.manage-offline-status и все network.notify.* - не помогло.

Приоритеты тут ни при чём (впрочем я не знаю где ты их нашёл)

Шлюз по умолчанию

все соединения через локальное прокси идут, оно и прописано

В смысле?

У тебя в системе $http_proxy равно «адрес:порт» и этот же «адрес:порт» ты в браузере в настройках сетевого соединения руками вписал, если упрощать?

Если так, то имеет смысл поменять браузерные настройки прокси на «использовать системные», и посмотреть эффект.

Гораздо клёвей самому хорошенько отконфигурять policies.json и аннигилировать там любые своеволия так, как считаешь нужным именно ты, а не либрвульф/камуфокс/и.т.д, которые в соответствии со своей концепцией вполне могут выплеснуть вместе с водой пару каких-то дорогих именно тебе младенцев)

Шлюз по умолчанию разумеется ведёт на единственный сетевой интерфейс, но это никаким боком не приоритет.

У тебя в системе $http_proxy равно «адрес:порт» и этот же «адрес:порт» ты в браузере в настройках сетевого соединения руками вписал, если упрощать?

Никакие переменные окружения я не прописывал, я только прописал в браузере проксю. И вообще никаких «системных настроек прокси» у меня нет, это выдумки гномов и им подобных DE.

Если так, то имеет смысл поменять браузерные настройки прокси на «использовать системные», и посмотреть эффект.

Это тут ни при чём. Про проксю я упомянул вообще только для того, чтобы никто не думал что ядро дропнуло коннекты из-за отсутствия гейта для них. Нет, коннекты идут на 127.0.0.10, ядро их соответственно не дропало.

Никакие переменные окружения я не прописывал, я только прописал в браузере проксю

Ну так пропиши проксю в системе, а из браузера выпиши, просто приказав ему следовать системным настройкам. И тогда на смену интерфейса будет реагировать система, а не браузер.

Делай шлюз на 127… с прозрачным прокси, вместо обычного прокси, фф всё равно шлюз чекает, в мозыле зависимость от интернета насаждают пользователям инфа 100%, неважно свободный софт или нет, маркетолухи везде одинаковые, без интернета ничего не работает. Шучу.

... причём тут настройки прокси? Что за «система» которая будет реагировать на что-то?

При этом если грузилась какая-то новая вкладка, то загрузка просто прерывается без каких-либо оповещений, во вкладке остаётся пустое окно, зафейленной она не считается и ф5 в ней не работает (хорошо хоть можно навести фокус на урл и нажать энтер).

Я такой баг видел, когда сервер молча бросал соединение, безо всяких прокси и пропаж интерфейса и connectivity. Поэтому вот тут:

Когда вылетает pppd и исчезает интерфейс ppp0 - файрфокс отменяет все имеющиеся сетевые запросы от себя.

у меня возникает подозрение, что это не firefox тебе что-то отменяет, а прокся просто ресетит соединение, отчего всплывает баг.

Я бы ещё посмотрел на поведение curl -sv через ту же проксю во время пропажи интерфейса.

Я такой баг видел, когда сервер молча бросал соединение, безо всяких прокси и пропаж интерфейса и connectivity

И тут же поправлю себя. Попробовал воспроизвести через nc -lp 12345 и открытием http://127.0.0.1:12345. Простым ^C после получения запроса я такого поведения не добился, но если в ответ написать HTTP/1.0 204 No content и пустую строку вслед, поведение оказывается точь-в-точь как в описании: пустое окно, теряющее урл по F5.

В общем, я бы копал в эту сторону.

Нет, прокся ничего не отменяет, в ней такой логики нет и никогда не было - я эту проксю сам написал от начала до конца. Отменяет файрфокс.

в ней такой логики нет и никогда не было

Не отменяет возможных багов. Мало ли, на что ещё акторная лапша фаерфакса так реагирует. Было время, когда от смерти подпроцесса по OOM вкладки начинали демонстрировать такое поведение.

В общем, я бы всё-таки смотрел для начала на curl и на лог запросов в devtools вкладки.

Я понимаю твоё желание помочь, но направление кардинально неверно. С проксей всё в порядке, проблема целиком на стороне фф. И это не упавший подпроцесс, на них фф пишет надпись что вкладка упала.

И это не упавший подпроцесс, на них фф пишет надпись что вкладка упала

URL в адресной строке может теряться даже при наличии сообщения о крахе вкладки.

Ну и вообще там целый ворох багов про пропадающие урлы, некоторые даже в школу уже могут ходить, вот только навскидку:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1762987
• https://bugzilla.mozilla.org/show_bug.cgi?id=891452

С проксей всё в порядке

Вот этой?

С проксей всё в порядке, проблема целиком на стороне фф.

Кстати, я бы ещё вынес браузер на отдельный комплюхтер и посмотрел бы на результат. Сразу будет видно, в NS_NETWORK_LINK_TOPIC дело или в получаемом ответе.

Там как раз таки системные настройки прокси не выдумки они применяются через интеграцию с network manager. Это ты там себе что-то сломал систему, всё «лишнее» по твоему мнению выбросил, и в итоге у тебя непонятно всё как работает.

Это ржач. Напоминает местного чувака, который писал, что бтрфс говно, потому что его самописный дедупликатор убил ему данные

Кто не понял суть проблемы

fproxy v83 — локальный прокси-сервер для фильтрации http(s)-трафика

Там как раз таки системные настройки прокси не выдумки они применяются через интеграцию с network manager.

«Там» может и не выдумки. В нормальных системах их нет. Помоями (networkmanager) не пользуюсь.

Ну я не сомневался. В этом и причина твоих проблем. Тут можно и про Буратино написать и про горе от ума. Просто я и сам иногда это забываю

или в получаемом ответе.

Каком ещё получаемом ответе?

Повторю проблему: фф забывает запросы, висящие в состоянии ожидания. Правильное поведение - ждать ответ на них дальше.

Ну и вообще там целый ворох багов про пропадающие урлы, некоторые даже в школу уже могут ходить, вот только навскидку:

Да, фф ведёт себя именно так как будто я во всех вкладках нажал esc. То что урл исчезает при нажатии esc - я бы не стал это сходу называть багом (ведь если ты например нажал на ссылку а потом быстро нажал esc - остаётся старая страница со старым урлом и это, очевидно, правильное поведение), но от самовольно отменять запросы браузер не должен, он может их только зафейлить, выдав какую-нить надпись об ошибке. А в данном случае и фейлить не должен т.к. ничего не ломалось.

Каком ещё получаемом ответе?

От прокси, от кого ж ещё.

Вы почему-то упорно продолжаете утверждать, что «прокся хорошая, пули вылетели», никак не показывая это на деле, хотя я даже подсказал, как можно убедить в этом аудиторию.

Мне лень возиться со сборкой чудо-прокси, но мне сегодня не лень проверить всё остальное:

sudo bwrap --bind / / --proc /proc --dev /dev --bind /tmp/.X11-unix{,} --bind $XDG_RUNTIME_DIR{,} --unshare-net bash

ip link add omg type veth peer name wtf
ip link set dev wtf up
ip addr add dev wtf 10.0.0.1/24
su thriller -c 'firefox -no-remote -ProfileManager' &
nc -Nlp 12345 &

Далее ставим в about:preferences проксёй локалхост, меняем, как писали выше, network.notify.changed, лезем на какой-нибудь ЛОР, делаем ip link del omg и видим, что вкладка продолжает пытаться грузиться бесконечно долго, без отмен и исчезающих урлов.

Раз уж вам не помогло, придётся искать на стороне прокси.

От прокси, от кого ж ещё.

От прокси никакого ответа файрфоксу не поступает, коннект висит как висел, прокси ждёт пока сможет забрать ответ от сайта чтобы отдать его своему клиенту (файрфоксу). И если бы фф не дропал коннект - все эти отключения были бы спрятаны в нижних абстракциях, а фф всегда бы получал (может и с задержкой) ответ от сайта. Если подключаться к проксе через wget - всё разумеется работает как задумано, wget ждёт висящий запрос (ну, у него наверно таймаут есть какой-то но за 2 минуты он не наступил) и при появлении связи получает ответ от прокси. И вообще прекращай меня за нуба какого-то держать который не понимает что вокруг происходит, я с самого начала нормально сформулировал проблему. Если бы фф не был блоатварью я бы сам всё нашёл в исходнике и поправил, но исходники там отвратительные, а компиируется он полдня и без спец. тюнинга ещё и падает где-то в середине от нехватки 32-битной памяти. Вот думал может у кого есть решение чтобы не тратить на него силы, но пришёл ты и начал мне упрямо втирать всякую дичь, опять тратя время на бесполезные переписки и объяснения.

ip link del omg

Я не писал про ip link del, я писал про падающий pppd. Он, кроме собственно линка, ещё как минимум меняет днсы и гейт. Если что, запросы дропаются не только спустя 5 сек после выключения ppp, но и спустя 5 сек после его включения (то есть инета нет, запрос успешно отправлен проксе, прокся ждёт инет, фф ждёт проксю, инет формально появляется, 5 сек и фф дропает запрос). Ну и у тебя фф в контейнере, может быть он изолирован от чего-то что позволяло ему распознать ту ситуацию.

От прокси никакого ответа файрфоксу не поступает, коннект висит как висел

Если подключаться к проксе через wget - всё разумеется работает как задумано

Вооооот, с этого стоило начинать! (-:

но пришёл ты и начал мне упрямо втирать всякую дичь

Дичь — это когда сходу отвечают, что «этого не может быть, потому что этого не может быть никогда», ничем это не подкрепляя. Насмотрелись мы уже в интернете на тех, кто сначала кричит, что права на файлы в порядке, а потом «ой, вот тут забыл chmod сделать 😳».

Я не писал про ip link del, я писал про падающий pppd

А без network.notify.changed дроп интерфейса всё воспроизводит…

Он, кроме собственно линка, ещё как минимум меняет днсы и гейт.

…и было бы странно, если ли флаг с таким обобщённым названием работал выборочно.

Ещё проверил

- удаление/добавление дефолтного гейта

- редактирование /etc/resolv.conf

- добавление и удаление фейковых интерфейсов с помощью ip link и перестановку на них дефолтного гейта временно

это всё фф не триггерит

Добавка. Если добавлять или удалять default route с айпи-адресом - запросы слетают. У ppp айпи-адреса у гейта нет - от такого не слетают. Слетание всегда происходит через 5-6 сек после триггернувшего его события.

# pppd выключен

# тут от каждой слетает
ifup eth0
route delete default

# от этих команд не слетает
route add default eth0
route delete default

# от этих слетает и при добавлении и при удалении
route add default gw 192.168.1.1 eth0
route delete default

Видимо он следит за ip-адресом гейта. Но применительно к ppp это непонятно - там нет ip-адреса гейта в таблице роутинга, но от запуска и остановки pppd запросы тоже слетают. Возможно, у него какой-то алгоритм поиска этого айпи-адреса и он умеет его брать и из ifconfig (он там у ppp прописан).

При изменении сети фф отменяет висящие соединения и перепосылает запосы через dt. Попробуй убрать прокси или поставить проксю «которую не ты писал», возможно, всё заработает.

При изменении сети фф отменяет висящие соединения и перепосылает запосы через dt

Вот именно это поведение и надо устранить под корень.

Попробуй убрать прокси

Ещё один...

tldr;

Запусти «tcpdump -nvi any icmp» и урони pppd.
Может будет видно, что приходят «icmp dest unreachable» и на них приложения реагируют.

IMHO проблема в том, что tcp-соединения для https? запросов не всегда закрывают сразу (http keep-alive/connection reuse).
Если для исходящих соединений прокся использует адрес интерейса pppd,то после того как дропнули pppd и его интерфейс, то этим соединениям гарантированно приходит писец.
Как реагирует ФФ на то, что прокся сказала ОЙ - не знаю.

Интересно, если твоей проксе прибиндить адрес с которого она выполняет запросы к какому-нибудь постоянному интерфейсу, то ситуация изменется? Соответственно, на внешнем интерфейсе (pppX) не забыть про NAT для этого адреса.

# от этих команд не слетает
route add default eth0
route delete default

Охренеть. А смысл? eth0 это же не p2p.

Можно еще dummy интерфейс использовать

Я практически уверен что фокс триггерится на что-то из dbus, от networkmanager или networkd

Оторви фокс от говнопровода например при помощи DBUS_SYSTEM_BUS_ADDRESS="unix:path=/tmp/fuckyoupoettering"

Альтернативно можно запустить изолированный dbus (например через https://github.com/kopzinski/kop-dbus-tools ) и скормить уже его фуррифоксу.

Еще более альтернативно можно не запускать это говно если система не поражена системды-раком и блоатварным DE

Да тут и не в мацилле дело оказалось, а в его самописном говно-прокси кривом + борьбе с ветряными юнитами systemd… А либревольф - единственное решение без маяков наряду с унгуглед хромиум, все остальные браузеры «стучат». Ты не сможешь отключить слежку без модификации кода нигде

Я практически уверен что фокс триггерится на что-то из dbus, от networkmanager или networkd

Не угадали, netlink-ом ядро напрямую опрашивают.

Может будет видно, что приходят «icmp dest unreachable» и на них приложения реагируют.

Файрфоксу ничего не приходит, он коннектится только на 127.0.0.10, который слушает прокси.

Если для исходящих соединений прокся использует

Отстань от прокси, она всё делает правильно и держит локалхостовый коннект для фф в любом случае. И файрфоксу про всё это не сообщает, в том и суть.

Охренеть. А смысл? eth0 это же не p2p.

Смысл в том что слетаение происходит не в ядре, а в кривом коде файрфокса, и зависит оно от того что там нафантазировали его авторы, а не от реальных причин. Поэтому и перебирал разные варианты.

Я практически уверен что фокс триггерится на что-то из dbus, от networkmanager или networkd

Я запускал dbus-monitor без аргументов, там ни одного сообщения в момент обрыва/включения ppp не появляется. Или надо с какими-то аргументами запускать чтобы увидеть всё?

networkmanager и networkd отсутствуют.

Оторви фокс от говнопровода например при помощи DBUS_SYSTEM_BUS_ADDRESS=«unix:path=/tmp/fuckyoupoettering»

О, спасибо, я уже пытался это делать для других целей но не знал как. Слал SIGSTOP dbus-daemon-у, в итоге разный софт зависал в рандомных местах видимо ожидая от него ответ.

О, и за это спасибо, нашлось потенциальное место для фикса. Можно ли как-то заблокировать эти оповещения не патча бинарник фф?

Я выше уже писал, с какой ручкой из about:config это поведение у меня перестаёт воспроизводиться.

С добавлением/удалением айпи-адреса дефолтного роута тоже проверял? У меня, как оказалось, реагирует именно на него, а не на само наличие интерфейса (может быть реагировало и на интерфейс раньше, пока я в about:config не поотключал всё).