Mycelium not working properly on my local machine

[ashraffouda]

after updating mycelium to the latest version

the logs shows it works but can not connect to any mycelium ip while other ppl can reach it
the logs looks good

[Eslam-Nawara]

I have a mycelium issue right now, I have mycelium running on my machine but I can't connect to my vm using mycelium, I have version 0.5.7 sometimes I get network not reachable other times it tried for a very long time to connect and it did not succeed

[ashraffouda]

I have a mycelium issue right now, I have mycelium running on my machine but I can't connect to my vm using mycelium, I have version 0.5.7 sometimes I get network not reachable other times it tried for a very long time to connect and it did not succeed

yes this happened with me also

[xmonader]

is that for wifi, or 4g?

[xmonader]

Took so long to actually do the ping, then you can see the latency, and after that it shows no route

on my regular wifi

[iwanbk]

probably related to the possibility of overloaded nodes, as discussed at #459

[Omarabdul3ziz]

am facing the same issue

mycelium version

myceliumd 0.5.7

run against the peers from docs

mycelium --peers tcp://188.40.132.242:9651 "quic://[2a01:4f8:212:fa6::2]:9651" tcp://185.69.166.7:9651 "quic://[2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651" tcp://65.21.231.58:9651 "quic://[2a01:4f9:5a:1042::2]:9651" "tcp://[2604:a00:50:17b:9e6b:ff:fe1f:e054]:9651" quic://5.78.122.16:9651 "tcp://[2a01:4ff:2f0:3621::1]:9651" quic://142.93.217.194:9651

logs

2024-11-26T11:20:19.405969Z  INFO connect_peer: mycelium::peer_manager: Connected to new peer endpoint.proto=Tcp endpoint.address=185.69.166.7:9651
2024-11-26T11:20:20.020717Z  INFO mycelium::router: Acquired route subnet=435:5c4f:b0d4:124b::/64 peer="TCP 192.168.1.117:45672 <-> 185.69.166.7:9651"
2024-11-26T11:20:38.033065Z  INFO mycelium::router: Lost route subnet=435:5c4f:b0d4:124b::/64 peer="TCP 192.168.1.117:45672 <-> 185.69.166.7:9651"
2024-11-26T11:21:02.435692Z  INFO mycelium::router: Acquired route subnet=435:5c4f:b0d4:124b::/64 peer="QUIC -> 5.78.122.16:9651"
2024-11-26T11:21:04.661732Z  INFO mycelium::router: Lost route subnet=52a:e212:a754:e581::/64 peer="TCP 192.168.1.117:59062 <-> 65.21.231.58:9651"
2024-11-26T11:21:07.107104Z  WARN connect_peer: quinn_udp: sendmsg error: Os { code: 101, kind: NetworkUnreachable, message: "Network unreachable" }, Transmit: { destination: [2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651, src_ip: None, enc: Some(Ect0), len: 1200, segment_size: None } endpoint.proto=Quic endpoint.address=[2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651
2024-11-26T11:21:17.274656Z  INFO mycelium::router: Lost route subnet=4f9:fe32:6b8a:630b::/64 peer="QUIC -> 5.78.122.16:9651"
2024-11-26T11:22:08.410392Z  INFO mycelium::router: Acquired route subnet=52a:e212:a754:e581::/64 peer="QUIC -> 5.78.122.16:9651"
2024-11-26T11:22:12.107237Z  WARN connect_peer: quinn_udp: sendmsg error: Os { code: 101, kind: NetworkUnreachable, message: "Network unreachable" }, Transmit: { destination: [2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651, src_ip: None, enc: Some(Ect0), len: 1200, segment_size: None } endpoint.proto=Quic endpoint.address=[2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651
2024-11-26T11:22:40.167874Z  INFO mycelium::router: Lost route subnet=52a:e212:a754:e581::/64 peer="QUIC -> 5.78.122.16:9651"
2024-11-26T11:22:48.856437Z  INFO mycelium::router: Acquired route subnet=52a:e212:a754:e581::/64 peer="QUIC -> 5.78.122.16:9651"
2024-11-26T11:23:17.107629Z  WARN connect_peer: quinn_udp: sendmsg error: Os { code: 101, kind: NetworkUnreachable, message: "Network unreachable" }, Transmit: { destination: [2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651, src_ip: None, enc: Some(Ect0), len: 1200, segment_size: None } endpoint.proto=Quic endpoint.address=[2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651

can't ping any mycelium IP

[LeeSmet]

There is currently some weird behavior going on on the public nodes. Essentially periodically there is a seemingly random reset, triggered by OOM (though memory does not necessarily increase). On some nodes this correlates to a large amount of connections coming in, though they are not added as peers strangely. Restarts of nodes leads to them being overloaded for some time as they attempt to process all the routes, which causes discards of some routes to keep the memory usage of outstanding updates bounded. Unfortunately I currently don't have time to dig deeper into.

Some pointers at this stage would be:

• connect to as many nodes as possible
• leave your node running (i.e. don't start it just at the time you need it, should that be the case)
• For the errors like this: 2024-11-26T11:23:17.107629Z WARN connect_peer: quinn_udp: sendmsg error: Os { code: 101, kind: NetworkUnreachable, message: "Network unreachable" }, Transmit: { destination: [2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651, src_ip: None, enc: Some(Ect0), len: 1200, segment_size: None } endpoint.proto=Quic endpoint.address=[2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651 I'm guessing there is no IPv6 connectivity to the node, try switching to ipv4 for those nodes, or try tcp first if that works for other nodes and you are using quic here

FWIW, the way routes are handled will be changed completely in the (near) future

[ashraffouda]

There is currently some weird behavior going on on the public nodes. Essentially periodically there is a seemingly random reset, triggered by OOM (though memory does not necessarily increase). On some nodes this correlates to a large amount of connections coming in, though they are not added as peers strangely. Restarts of nodes leads to them being overloaded for some time as they attempt to process all the routes, which causes discards of some routes to keep the memory usage of outstanding updates bounded. Unfortunately I currently don't have time to dig deeper into.

Some pointers at this stage would be:

• connect to as many nodes as possible
• leave your node running (i.e. don't start it just at the time you need it, should that be the case)
• For the errors like this: 2024-11-26T11:23:17.107629Z WARN connect_peer: quinn_udp: sendmsg error: Os { code: 101, kind: NetworkUnreachable, message: "Network unreachable" }, Transmit: { destination: [2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651, src_ip: None, enc: Some(Ect0), len: 1200, segment_size: None } endpoint.proto=Quic endpoint.address=[2a02:1802:5e:0:ec4:7aff:fe51:e36b]:9651 I'm guessing there is no IPv6 connectivity to the node, try switching to ipv4 for those nodes, or try tcp first if that works for other nodes and you are using quic here

FWIW, the way routes are handled will be changed completely in the (near) future

I did what u specified and no hope at all
1- the node is running overnight
2- all mycelium nodes in the zos config are provided
3- used only tcp/ipv4
same issue exists most of time not working but sometimes suddenly works

[Omarabdul3ziz]

i applied the suggestions by using only tcp&ipv4 and daemon is running for a while but i still facing the same issue

[coesensbert]

by now for me mycelium is not working well anywhere:

• monitoring over mycelium leaves many gaps and triggers alerts regularly
• ssh connections freeze all the time
• many times when one does deploy on the grid, the mycelium ip simply does not work. Wait a while, then it works for a few min's, then not again ..
• almost all of my existing mycelium ip's become unreachable after a while, only solution that i found is to re-generate a new key and restart mycelium

is someone trying to resolve these issues? As no real progress can be found