it look like you debian dont know where is internet or something like this
can you go to node pc and try to ping google for example
also does you node connecter with wire or wifi or boath of then, try to turn off wifi then.
Ping command from my problematic node:
heraclitus@raspberrypi-cz-a:~ $ ping www.google.com
PING www.google.com (142.251.36.132) 56(84) bytes of data.
64 bytes from prg03s12-in-f4.1e100.net (142.251.36.132): icmp_seq=1 ttl=115 time=10.1 ms
64 bytes from prg03s12-in-f4.1e100.net (142.251.36.132): icmp_seq=2 ttl=115 time=9.84 ms
64 bytes from prg03s12-in-f4.1e100.net (142.251.36.132): icmp_seq=4 ttl=115 time=6.58 ms
64 bytes from prg03s12-in-f4.1e100.net (142.251.36.132): icmp_seq=5 ttl=115 time=6.61 ms
^C
--- www.google.com ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4016ms
rtt min/avg/max/mdev = 6.582/8.286/10.123/1.695 ms
Traceroute output:
heraclitus@raspberrypi-cz-a:~ $ traceroute www.google.com.tr
traceroute to www.google.com.tr (142.251.36.131), 30 hops max, 60 byte packets
1 compalhub.home (192.168.0.1) 4.472 ms 5.352 ms 6.211 ms
2 * * *
3 ip-86-49-55-193.bb.vodafone.cz (86.49.55.193) 27.414 ms 27.702 ms 27.812 ms
4 a0sit-rc-01-ae23.net.vodafone.cz (185.188.187.232) 29.508 ms 30.178 ms 30.322 ms
5 * * *
6 * * *
7 142.250.164.176 (142.250.164.176) 15.562 ms 17.442 ms 18.685 ms
8 * * *
9 142.251.224.228 (142.251.224.228) 23.552 ms 142.251.224.124 (142.251.224.124) 13.994 ms prg03s12-in-f3.1e100.net (142.251.36.131) 15.500 ms
can you access your dashboard from local network?
also is it possible that you already that ip in other device that you setuped in node? in your local network.
Yes, I can:
But the weird thing about Node Status Page is when I hover the “Misconfigured” text it shows below message(Port 7777 ?):
QUIC is misconfigured. You must forward port 7777 for both TCP and UDP to enable QUIC.
See Step 3. Setup Port Forwarding - Storj Docs on how to do this
There is no IP conflict. I’ve 5 devices on my local network now and every one of them has different local IP.
to check that there is some nat or not, you can try to stop node, then find some program or something with tcp listener and setup it to same port or to next port, and make port forward to it, and check is it opened.
To me it looks like you have misconfigured port forwarding - not to the node internal ip or some other rules that reject external connections on this port.
I highly doubt that your ISP blocks this port, as i see ‘connection refused’ message by tryging to connect to this port and IP. ISPs rather block incoming traffic by dropping packets not rejecting.
1 Like
I had some time today and I’ve done some more investigation. I’ve exposed the 14002 port number to the outside world and it is working, I’m able to reach my dashboard from outside. And also checked the status of the port using an online port-checker, and everything is fine for 14002.
As the 14002 port number is working I can’t see any reason for ISP to block the 28967 port. I thought maybe it is because my raspberry-pi-4(64Bit) blocks some of the outgoing ports. To verify that I’ve compared the iptables outputs of my working node (static-ip, raspberry pi-3, different location) and the problematic node (DDNS, raspberrypi4 64Bit).
iptables output for my working node:
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
199K 11M ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.3 tcp dpt:28967
1386 1774K ACCEPT udp -- !docker0 docker0 0.0.0.0/0 172.17.0.3 udp dpt:28967
29 1548 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.3 tcp dpt:14002
iptables output for my problematic node:
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
72 4320 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.3 tcp dpt:28967
0 0 ACCEPT udp -- !docker0 docker0 0.0.0.0/0 172.17.0.3 udp dpt:28967
6 352 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.3 tcp dpt:14002
As you can see in the second iptables output 28967/UDP has 0 bytes. But I don’t see any restriction on the outgoing direction when I look whole output.
May I get disqualified? I saw the @BrightSilence’s comment here. And executed the below command to check the identity.
docker exec -it storagenode ls -l /app/identity
total 24
-rw-r--r-- 1 1000 1000 558 Jan 14 19:10 ca.1673723418.cert
-rw-r--r-- 1 1000 1000 1088 Jan 14 19:10 ca.cert
-rw------- 1 1000 1000 241 Jan 14 06:40 ca.key
-rw-r--r-- 1 1000 1000 1100 Jan 14 19:10 identity.1673723418.cert
-rw-r--r-- 1 1000 1000 1630 Jan 14 19:10 identity.cert
-rw------- 1 1000 1000 241 Jan 14 06:40 identity.key
Looks like there is no issue regarding identity. Shall I reconfigure my node from the beginning by generating a new token?
I’m still waiting for a response from ISP probably they’ll call me tomorrow but I’m feeling that the problem is not on their end.
Lastly, I’ve tried to change the port numbers with each other in my run command to be sure that the problem is not because of the ISP as below:
docker run -d --restart unless-stopped --stop-timeout 300 \
-p 14002:14002/tcp \
-p 14002:14002/udp \
-p 28967:28967\
-e WALLET="??????" \
-e EMAIL="abcdefg@gmail.com" \
-e ADDRESS="MY_DDNS:14002" \
-e STORAGE="748GB" \
--user $(id -u):$(id -g) \
--mount type=bind,source="/home/heraclitus/.local/share/storj/identity/storagenode",destination=/app/id>
--mount type=bind,source="/storj-storage1/storagenode",destination=/app/config \
--name storagenode storjlabs/storagenode:latest
Unfortunately, that trick did not work, I was able to connect to my dashboard through MY_DDNS:14002 link. My expectation was to reach my dashboard through MY_DDNS:28967 link, but weirdly it did not work.
this will not work. If you suspect blocking of 28967 port, you may configure it like this:
-p 14002:14002 \
-p 28968:28967/tcp \
-p 28968:28967/udp \
-e WALLET="??????" \
-e EMAIL="abcdefg@gmail.com" \
-e ADDRESS="MY_DDNS:28968" \
and forward port TCP+UDP 28968 instead of 28967. You may also use any other free port instead of 28968, just update your docker run command and port forwarding rule accordingly.
Hello, thank you for your reply.
I’ve done a port test using the Netcat tool. And looks like there is no issue either on port 28967 or with the port-forwarding rule, please see the below image. The device on the left-hand side is one of my devices (located in TR) and is configured as a client to send messages through port number 28967/UDP and on the right-hand side you’re seeing my second device (located in CZ) with a different IP address configured as a server and it accepts packets through 28967/UDP port.
To be sure about the TCP connection I’ve also created a simple website that uses 28967/TCP is also working right now.
On my end and also on the ISP end connection configuration looks okay. I’m planning to reconfigure my problematic node again but I’d like to understand what is the issue. Do you have any thoughts?
Thank you.
Please try to stop and remove the container, then rename the config.yaml file and run the node back.
Make sure your ports look like
-p 14002:14002 \
-p 28967:28967/tcp \
-p 28967:28967/udp \
-e ADDRESS="MY_DDNS:28967" \
and ports TCP 28967 and UDP 28967 are forwarded correctly to IP of your host.
I’ve figured out the issue and my node is up now without any issues. Long story short the mounting point (folder) that I created permission level was root(config.yaml file wasn’t under the /storj-node1 mounting point), therefore STORJ did not have write permission to that folder.
1 Like