peers UNRESPONSIVE
Opened this issue · 43 comments
hi.
several peers are no longer online and appear UNRESPONSIVE:
v0.0000.0000.0000.0015.kw0vfw3tmb6u6p21z5jmmymdlumwknlg3x8muk5mcw66tdpqlw30.k UNRESPONSIVE in 0kb/s out 0kb/s "Magik6k-sbg1"
v0.0000.0000.0000.001b.yrgb0xwfr9pz8swvnv6m9by8zw7v7uxxhl07qz318cjuvfgs1fc0.k UNRESPONSIVE in 0kb/s out 0kb/s "jazzanet"
v0.0000.0000.0000.0019.8268mn1bvz66nbb74tqw7ynjkcjrtruv8pgjf9kr34zv5d60p3r0.k UNRESPONSIVE in 0kb/s out 0kb/s "llygaid.cwningen.cymru"
v0.0000.0000.0000.0017.7ktfb2n336bguhfx81ts15qgjb8mjj4rz3vrnvj2dw89wsmmtpg0.k UNRESPONSIVE in 0kb/s out 0kb/s "penfar.cwningen.cymru"
v0.0000.0000.0000.0015.1nctdb89gtfrlnu71zyq97n14frl1r4z0ylwzc8vn7kpvrzu4yl0.k UNRESPONSIVE in 0kb/s out 0kb/s "igel-amersfoort"
the peers above are used, in my specific environment, only over ipv4.
are there any plans on bringing them back on?
thanks
I can confirm "Magik6k-sbg1" "jazzanet" "igel-amersfoort", many days, maybe weeks or months unresponsive
@magik6k, @wfleurant, any comment?
I've also pinged the other operators via email.
I know that I've been having trouble pinging nodes lately, even when they are known to be available.
If we don't get any feedback from the operators, then we can remove the listings.
Should be fixed, can you confirm it's working?
@magik6k: the ipv4 peer is still UNRESPONSIVE on my side. the details of the peer are the ones in magik6k.net.k
Looks like it's fixed now:
$ ./peerStats | grep outer | wc -l
72
yrgb0xwfr9pz8swvnv6m9by8zw7v7uxxhl07qz318cjuvfgs1fc0.k v0 fail 0 0 0 4K jazzanet
g2xyf69w70q4q2nzfyhs5ybdhpgx0uz56zxqlj27g2ytnklqvxv0.k v0 fail 0 0 0 440B florianb
1nctdb89gtfrlnu71zyq97n14frl1r4z0ylwzc8vn7kpvrzu4yl0.k v0 fail 0 0 0 560B igel-amersfoort
I've updated things; let me know if you've any issues (the keys have all changed though)
@cwningen the updated IPv4 peers (coes, penfar, traed) are marked unresponsive on my side. I've tested this from two nodes on different networks.
v0.0000.0000.0000.001b.s8luk50utykxh6l228ycyrfydclcdddl0143wmg5mf0cpw42w4h0.k UNRESPONSIVE in 0kb/s out 0kb/s "coes.cwningen.cymru"
v0.0000.0000.0000.0019.pp6c01cnz51t2vyl1jmzbply1n662c13nm6mzprx0g5djkvl3470.k UNRESPONSIVE in 0kb/s out 0kb/s "penfar.cwningen.cymru"
v0.0000.0000.0000.0017.p8q8bsbvlr3xjh2hqlzyfcgjsk2mjm7fl8s5w73v68925n4f6nb0.k UNRESPONSIVE in 0kb/s out 0kb/s "traed.cwningen.cymru"
Odd, I can see they're all up and I have connection to and can see various things through them. Although given the timing of your comment it might be down to my upstreams AS44684 having issues over the weekend. Are they still appearing down to you?
can't connect to eu/ru/spb/ru.spb.tokakoka.k from 2 different PC/networks
@cwningen I am exhibiting the same issues on two of my nodes, toward the peers over IPv4, maybe someone else can join in and let us know if it's working for them?
Can't connect to *.swningen.cymru ipv4 from NL and from RU
Odd. cjdroute was receiving the packets but not sending back on the correct address as these hosts have multiple addresses, it used the defaults. I've explicitly set the bind addresses for v4 and v6 accordingly so it should now work for others. Have confirmed it does work over v4 here post change and restart.
I would like to close this issue. The following peers are still unresponsive on my side (IPv4 only):
v0.0000.0000.0000.0017.tpf7pdj6pby9r2smxuwmkvzfrfj6jb0brch8yhp3jsxbrf3ld0h0.k UNRESPONSIVE in 0kb/s out 0kb/s "bliss.willeponken.me"
v0.0000.0000.0000.00aa.yrgb0xwfr9pz8swvnv6m9by8zw7v7uxxhl07qz318cjuvfgs1fc0.k UNRESPONSIVE in 0kb/s out 0kb/s "jazzanet"
v0.0000.0000.0000.009e.g2xyf69w70q4q2nzfyhs5ybdhpgx0uz56zxqlj27g2ytnklqvxv0.k UNRESPONSIVE in 0kb/s out 0kb/s "florianb"
v0.0000.0000.0000.001f.1nctdb89gtfrlnu71zyq97n14frl1r4z0ylwzc8vn7kpvrzu4yl0.k UNRESPONSIVE in 0kb/s out 0kb/s "igel-amersfoort"
@ansuz let me know if this should be closed anytime soon. thanks!
@lvlts by close do you mean resolve?
Your peerStats output has enough information for me to figure out which peers are problematic, but I'd have to do some digging. I'm around to answer questions and do stuff that only repo owners can do, but I'm happiest when these issues resolve themselves.
Could you figure out who owns those nodes, and mention them all here? If it's @cwningen's nodes affected...
Have confirmed it does work over v4 here post change and restart.
I'm not sure what to do if they've confirmed it's working from a different location. There could be lots of things interfering with your nodes, which would not necessarily affect other's usage of the same credentials, so I'm hesitant to remove them. Perhaps you could work out a time to chat via irc or some other im platform, and debug the issue.
If the issue can't be narrowed down, but the nodes work for others, the best I can offer is to try using a different set of credentials.
So, the following nodes, as of this writing, are appearing UNRESPONSIVE (IPv4):
| Owner | Node | Initial commit |
|---|---|---|
| @willeponken | eu/se/lulea/bliss.willeponken.me.k |
dcd3963 |
| @jaythespacehound | de/bavaria/hype.jazzanet.com.k |
9589dd9 |
| @fbrandstetter | nl/amsterdam/florianb.ams.k |
682ed17 |
I'm only able to validate these nodes from two locations, it would be great if someone else can also check the peering on these. Also, thank you @cwningen - nodes are working now.
@kyrias The nodes listed in stash-crypto.k appear to be down at this time. Are you planning to bring these peers back up?
it seems, that this nodes are offline more time:
| Owner | Node | Initial commit |
|---|---|---|
| @belovachap | /na/us/california/san-francisco/salesforce-tower.k | 39a0f5b |
| @NateBrune | /na/us/pennsylvania/nat.usa.k | 1aba1db |
| @kylerchin | /na/us/california/san-francisco/kylerchin/bootnode-1.k | 350fdc4 |
| @kylerchin | /na/us/california/san-francisco/kylerchin/bootnode-2.k | 350fdc4 |
| @Show-vars | /eu/ru/moscow/h.bunjlabs.com.k | 5fc0fd9 |
| @ansuz | /eu/ru/moscow/node01.msk.ru-mesh.net.k | 7a57278 |
| @iczero | /na/us/northcarolina/charlotte/ic2.hellomouse.cf.k | 218e225 |
| @ValdekGreen | /peers/eu/fr/paris/h.valdek.ml.k | 887d33c |
@blackknight36 @CupIvan If either of you would have bothered actually looking at the last commit for the things you ping me for you would have realized that I have absolutely nothing to do with either server.
Yes, remove mine please!
Or I should create pull request?
Oh, hello! Sorry, I haven't been running those servers for quite a while 😿 I can make a pull request to clean them out :)
Update! #141 🌈
Hi all, I can't maintain this any more and added a pull request to delete de/bavaria/hype.jazzanet.com.k
#143
Sorry all for the length of time on this
please check this peers, it seems unresponsive long time (ping fail):
| owner | node | commit |
|---|---|---|
| @wfleurant | /eu/nl/amsterdam/igel-amersfoort.ams.k | 1e715a2 |
| @kylerchin | /na/us/northcarolina/charlotte/ic2.hellomouse.cf.k | 350fdc4 |
| @bug0000 | /eu/ru/spb/ru.spb.tokakoka.k | 53660ef |
| @willeponken | /eu/se/lulea/bliss.willeponken.me.k | dcd3963 |
| @geistesk | /eu/de/hesse/h.ancha.lurk.space.k | bfc3a41 |
| @iczero | /eu/ua/kiev/kiev/ic.hellomouse.cf.k | 218e225 |
| @oniichaNj | /eu/nl/amsterdam/mrowr.me.k | a48b755 |
| @kylerchin | /na/us/california/san-francisco/kylerchin/bootnode-2.k | 350fdc4 |
| @merkjinx | /eu/fr/paris/h.rwfr.k | fed5ad7 |
| @cwningen | /eu/uk/london/cwningen.cymru.k | ff568ce |
| @Show-vars | /eu/ru/moscow/node01.msk.ru-mesh.net.k | 5fc0fd9 |
My apologies I recently migrated servers, will update ASAP.
Is there any way we could set up an automated process to monitor these nodes?
Is there any way we could set up an automated process to monitor these nodes?
wrote simple script for ping public peers by IP and IPv6: cjdelisle/cjdns#1188
Mine (/eu/de/hesse/h.ancha.lurk.space.k) is down for some time due to high traffic rates affecting the network. I'm sorry for forgetting to remove it and will open a PR.
I pinged all nodes in repo with my script. There are problem nodes in table:
I'm migrating my node, will update once done
I'm no longer hosting mrowr.me and it can be removed.
ru-mesh.net.k can be deleted too. Unfortunately I no longer have access to this domain and I have no plans to migrate this node. Sorry for that.
My node is definitely online, IPv4 should respond.
PING linux1.tor1.watters.ws (165.227.44.84) 56(84) bytes of data.
64 bytes from linux1.tor1.watters.ws (165.227.44.84): icmp_seq=1 ttl=52 time=19.1 ms
64 bytes from linux1.tor1.watters.ws (165.227.44.84): icmp_seq=2 ttl=52 time=18.9 ms
My node is definitely online, IPv4 should respond.
ping from my computer is fail
PING 165.227.44.84 (165.227.44.84) 56(84) bytes of data.
From 165.227.44.84 icmp_seq=1 Destination Port Unreachable
but I test from another server - it seems ok
PING 165.227.44.84 (165.227.44.84) 56(84) bytes of data.
64 bytes from 165.227.44.84: icmp_seq=1 ttl=47 time=133 ms
probably it is the russian blocking internet system :-(
isn't cjdns supposed to be censorship proof?
@obedm503 the network as a whole is supposed to be censorship proof, but specific links over the internet can be censored as everything else on the internet.
hi, if you also want to double-check availability through an EC2 (afaik) instance, I have a Travis-CI build which runs on a daily basis located at: https://lvlts.github.io/hyperboria-peer-check/
Feel free to check out the repository, which contains the build scripts which output that page. The downside to it is that I have not been able to test the IPv6 builds, as Travis does not support IPv6, and other means (Miredo) do not work, due to the restricted capabilities the build environment has. I also noticed that the @magik6k node is no longer available on IPv4 lately.
This peers unresponsive more than 3 weeks, please check it:
| IPv4 | ping | IPv6 | owner | url |
|---|---|---|---|---|
| 149.56.19.79 | FAIL | :dd38 | @justusranvier | /na/ca/ontario/stash-crypto.k |
| 68.96.80.134 | FAIL | :4f30 | @kylerchin | /na/us/california/orange-county/logic0x-markets-irvine.k |
| 195.201.148.242 | FAIL | :b4ed | @Weuxel | /eu/de/bavaria/weuxel.modi.k |
Pull request for deletion of /eu/de/bavaria/weuxel.modi.k created.