rust-libp2p
rust-libp2p copied to clipboard
libp2p
Relay server: support listening on both WebRTC and WebSocket
Description
Proposed solution: Add configuration and implementation to allow the relay server to bind to both WebRTC and WebSocket addresses. Use case:
Clients behind different NAT/firewall setups. Improved interoperability with different types of libp2p implementations. Related work:
Demonstration of JavaScript WebRTC peers connecting through the Rust relay server: js-libp2p-examples Issue #226 js-libp2p-examples PR #227
Motivation
This work is part of a comprehensive test of WebRTC support across different libp2p implementations. The current focus is on enabling JavaScript peers to connect via a Rust relay server. In the future, the goal is to extend these tests to include scenarios where JavaScript and Rust private peers can interoperate using WebRTC through the relay. Supporting both WebRTC and WebSocket transports on the relay server will improve connectivity options and interoperability for clients using different protocols.
Current Implementation
Currently, the relay server does not listen on either WebRTC or WebSocket transports. This is needed for JavaScript peers—and, in the future, Rust peers using WebRTC—to connect to the relay server.
Are you planning to do it yourself in a pull request?
Yes
... just to prove: the content of <network-id>.local.conf file is:
allowManaged=1
allowGlobal=0
allowDefault=0
allowDNS=0
The UI is showing the same:
Well, I'm reading this notes, like this part:
The default route workaround is also known, but for this to work there must be a known default IP that resolves to a known ARP address. This works for an OpenVPN tunnel, but not here because this isn't a tunnel. It's a mesh. There is no "other end," or any other known always on IP.
and I wonder, why could not be solved this with a simple trick:
- on each defined network, the starting address (like: 10.121.17.1) should be a fake tunnel address? There would be a Checkbox, just like "managed" , "DSN" ... called:
- Fake default IP [ x ] default:
Trueit is still not too late to do this.
IMHO prioritising this:
- "Networks without default routes are "unidentified networks" and cannot have their firewall classification changed by the user (easily)"
instead of:
- risking complete internet blockade
is not a good concept. I have used OpenVPN over 10+ years with "undefined network", before the new generation of TAP driver came and asked about network type, and it worked fine enough.
TODO :
This should be a intaller's/user's choise rather than forcing an unwanted route table on us. So at least one more checkbox should be present:
[x] Add fake GW
which could be turned off!
PS: Users do not have the right to choose the network type anyway!!! Only Administrators. ZT is asking it again and again each time it connects. (And creates a new adapter.) A very annoying mechanism, which would also be solved by this.
Thanks for writing this up. It's unlikely this route is the reason your internet is breaking. It's been working this way for like 10 years. Other options are an overlapping zerotier and physical subnet, or some kind of routing loop.
It's unlikely this route is the reason your internet is breaking.
Yes, it does! As I've wrote: the second I delete this route, the internet is restored! If I disconnect and reconnect ZT >> the same route appears again >> the internet is blocked again! (Can not even ping 1.1.1.1 nor 8.8.8.8)
This is a fact.
I've red many topics during the last 6 month and I saw many similar cases where the user did not understand what is happening, because they had no knowledge of routing tables and how to diagnose.
And it's not just 1 PC, which produced this, but several around the country on which I installed ZT on. And since I've uninstalled ZT from those PCs, everything went back to normal.
It's been working this way for like 10 years. Other options are an overlapping zerotier and physical subnet, or some kind of routing loop.
That's why I've suggested: This must be an optional switch. There is no other way now, but still better than nothing. Admins can decide how/if they will re-configure their subnets to exclude first IP of it.
Can you provide steps to reproduce?
Sorry, I can not, because I do not know why Windows sometimes ignores the metric of default route. Sometimes it happens on some PCs 2-3 times a day, but normally nothing happens for weeks.
I was thinking, and maybe I have an other solution: What if we leave everything how it is, but:
- if something is routed to this fake route, so basically back to ZT network,
- and
allowDefault=0, than: - ZT TAP driver should route trafik back internally to the real default gateway?
Would that be possible?
I have occasionally spotted this behavior, and I agree that an option to disable the automatic addition of fake GW would be nice. I solved this by automatic removal of this route with batch script.
I recently had this issue on Ubuntu 24.04. It used to work fine then suddenly after a reboot it started to happen - no internet. Hopefully I found the culprit quite fast and I just disabled zerotier completely and I think I should look for some other solution - this is unacceptable that it suddenly completely makes my computer unusable. What it is going to do next, wipe my hard drive just in case?
on Ubuntu 24.04.
That's interesting! Because only Windows system supposed to be affected by this behaviour. At least according to the author of this project. See: https://github.com/zerotier/ZeroTierOne/issues/1040#issuecomment-532328270
Bug Report (English)
Subject: Persistent Default Routing Issue with ZeroTier on Debian 12
Hello,
I'm experiencing a persistent default routing problem when using ZeroTier on Debian 12. After a system reboot (or even a few minutes after manually restarting ZeroTier), internet access is lost. This happens despite the main network interface (wlp2s0) being active and having a seemingly correct route. To restore internet access, I need to run sudo systemctl restart zerotier-one.service.
Problem Description:
Upon system boot, or after a short period following a ZeroTier restart, an incorrect entry appears in the default routing table. This entry effectively "intercepts" traffic intended for the internet.
Steps to Reproduce:
Install Debian 12.
Install ZeroTier (version 1.14.2).
Connect to a ZeroTier network (Network ID: abcd1234efgh5678).
Check ip route show default before and after restarting the ZeroTier service.
Expected Behavior:
After ZeroTier starts, the default route should remain consistently directed through the main network interface (wlp2s0) and its gateway (192.168.8.8), ensuring uninterrupted internet access. ZeroTier should not add default routes if it's not configured as an Exit Node, and the allowDefault parameter is set to 0.
Actual Behavior:
After system boot (or a few minutes after systemctl restart zerotier-one.service), ip route show default displays:
default dev zthvxzthvj scope link default via 192.168.8.8 dev wlp2s0 proto dhcp src 192.168.8.100 metric 600
Concurrently, zerotier-cli listnetworks for the zthvxzthvj interface (which is joined to network abcd1234efgh5678) shows these problematic routes:
route4 0.0.0.0/32 metric 0
route4 default metric 0
This consistently leads to a loss of internet connectivity. Restarting zerotier-one.service provides a temporary fix.
Troubleshooting Steps Taken:
The allowDefault parameter for the network is set to 0 (zerotier-cli set abcd1234efgh5678 allowDefault=0).
Сообщение об ошибке (Русский)
Тема: Постоянная проблема с маршрутизацией по умолчанию и ZeroTier на Debian 12
Тело сообщения:
Здравствуйте!
Столкнулся с постоянной проблемой маршрутизации по умолчанию при использовании ZeroTier на Debian 12. После перезагрузки системы (или даже спустя несколько минут после ручного перезапуска ZeroTier), доступ к интернету пропадает. Это происходит, несмотря на то, что основной сетевой интерфейс (wlp2s0) активен и имеет правильный маршрут. Для восстановления доступа требуется выполнить sudo systemctl restart zerotier-one.service.
Описание проблемы:
При загрузке системы или спустя некоторое время после запуска ZeroTier, в таблице маршрутизации по умолчанию появляется некорректная запись, которая эффективно "перехватывает" трафик, предназначенный для интернета.
Шаги для воспроизведения:
Установить Debian 12.
Установить ZeroTier (версия 1.14.2).
Подключиться к ZeroTier сети (Network ID: abcd1234efgh5678).
Проверить ip route show default до и после перезапуска службы ZeroTier.
Ожидаемое поведение:
После запуска ZeroTier, маршрут по умолчанию должен оставаться постоянно направленным через основной сетевой интерфейс (wlp2s0) и его шлюз (192.168.8.8), обеспечивая бесперебойный доступ в интернет. ZeroTier не должен добавлять маршруты по умолчанию, если он не настроен как Exit Node, и параметр allowDefault установлен в 0.
Фактическое поведение:
После загрузки (или спустя несколько минут после systemctl restart zerotier-one.service), ip route show default показывает:
default dev zthvxzthvj scope link default via 192.168.8.8 dev wlp2s0 proto dhcp src 192.168.8.100 metric 600
При этом zerotier-cli listnetworks для интерфейса zthvxzthvj (который присоединен к сети abcd1234efgh5678) содержит эти проблемные маршруты:
route4 0.0.0.0/32 metric 0
route4 default metric 0
Это постоянно приводит к потере интернет-соединения. Перезапуск zerotier-one.service временно решает проблему.
Что уже было предпринято:
Параметр allowDefault для сети установлен в 0 (zerotier-cli set abcd1234efgh5678 allowDefault=0).
Issue Resolved (English)
Subject: RESOLVED: Persistent Default Routing Issue with ZeroTier on Debian 12
Hello,
I'm writing to confirm that the issue with persistent default routing on my Debian 12 system, which occurred when using ZeroTier, has been resolved.
The root cause was a conflict between ConnMan and NetworkManager, both of which were installed on the system and likely competing for control over network interfaces and routing.
Resolution:
The problem was resolved by completely purging ConnMan from the system using sudo apt purge connman. This eliminated the conflict, allowing NetworkManager and ZeroTier to manage network interfaces and routes without interference.
After removing ConnMan, the problematic default dev zthvxzthvj scope link and route4 0.0.0.0/32 metric 0 entries no longer appear in the routing table, and internet access remains stable after reboots and ZeroTier restarts.
Thank you for your assistance and suggestions in troubleshooting this issue.
Проблема решена (Русский)
Тема: РЕШЕНО: Постоянная проблема с маршрутизацией по умолчанию и ZeroTier на Debian 12
Здравствуйте!
Сообщаю, что проблема с постоянной маршрутизацией по умолчанию на моей системе Debian 12 при использовании ZeroTier решена.
Основной причиной был конфликт между ConnMan и NetworkManager, которые оба были установлены в системе и, вероятно, конкурировали за управление сетевыми интерфейсами и маршрутизацией.
Решение:
Проблема была устранена путем полного удаления ConnMan из системы с помощью команды sudo apt purge connman. Это устранило конфликт, позволив NetworkManager и ZeroTier управлять сетевыми интерфейсами и маршрутами без помех.
После удаления ConnMan проблемные записи default dev zthvxzthvj scope link и route4 0.0.0.0/32 metric 0 больше не появляются в таблице маршрутизации, и доступ в интернет остается стабильным после перезагрузок и перезапусков ZeroTier.
Благодарю за вашу помощь и предложения в поиске и устранении этой проблемы.
I found a workaround for this workaround.😂
- Create a batch to disable the workaround by deleting the routing entry. The batch should be like this:
route delete 0.0.0.0 MASK 0.0.0.0 25.255.255.254 - Create a task to run the batch in Windows task scheduler (taskschd.msc). Set it to be run as admin. Set the task to be triggered on event Microsoft-Windows-NetworkProfile/Optional, event ID: 4002
It's unlikely this route is the reason your internet is breaking.
Yes, it does! As I've wrote: the second I delete this route, the internet is restored! If I disconnect and reconnect ZT >> the same route appears again >> the internet is blocked again! (Can not even ping 1.1.1.1 nor 8.8.8.8)
This is a fact.
I've red many topics during the last 6 month and I saw many similar cases where the user did not understand what is happening, because they had no knowledge of routing tables and how to diagnose.
And it's not just 1 PC, which produced this, but several around the country on which I installed ZT on. And since I've uninstalled ZT from those PCs, everything went back to normal.
It's been working this way for like 10 years. Other options are an overlapping zerotier and physical subnet, or some kind of routing loop.
That's why I've suggested: This must be an optional switch. There is no other way now, but still better than nothing. Admins can decide how/if they will re-configure their subnets to exclude first IP of it.
Very insightful, I can't agree more. When making virtual local network for gaming like me, Windows firewall is not required (actually I prefer it disabled because a lot of connectivity issues originate from the firewall). There should be a feature that allow user turn it off manually.
I think the issue can be reproduced when the real network controller is crowded with traffic, because the issue happens much more frequently when I move to a place where the bandwidth of the network is relatively small.
