Problems on Raspberry 5

I run a note (0.32.1 64bit ARM) on a Raspberry 5.
The note is not reachable from other notes.

Inbrowser.link can’t fetch any data from my node even in the local network.

I also have nodes running on X86 Linux and every thing works fine.

Fetching data from outside to my raspberry node works fine.

I use port 4001 behind a nat rooter but this port is forwarded to my raspberry.

https://check.ipfs.network/ can help you diagnose it.

Probably make sure that you’ve forwarded to the correct internal IP. As you said I also have nodes running on X86 Linux and every thing works fine. which makes me think/assume that your 4001 port might be forwarded to a different local ip.

Also make sure you can dial your own node within your own local network. If you can’t then there’s probably an ip setting in the config prohibiting it like a 127.0.0.1 (allow only on-node traffic) that you might want to have as 0.0.0.0 (allow the local network).

1 Like

Thanks for your response.

I didn’t change the config file. The swarm is listening on 0.0.0.0 and not on the backloop address.

Port 4001 tcp + udp is forwarded correctly.

I guess most people using the X86 versions, so it might be that there is a undetected bug in the 64 bit arm version that’s cause it not to function well.

It’s a fresh install off v0.32.1 not an update form a previous version.

From https://check.ipfs.network/:

Could not connect to multiaddr: failed to dial: failed to dial 12D3XXXXXXXXXXXXXXXXXXXXXXX: all dials failed
  * [/ip4/127.0.0.1/tcp/4001] gater disallows connection to peer
  * [/ip4/127.0.0.1/udp/4001/webrtc-direct/certhash/uEiCLpmdVOhWuiMpBtFC_bl71V5wswB5Ewtw8mqt6yuX-Fg] gater disallows connection to peer
  * [/ip4/127.0.0.1/udp/4001/quic-v1] gater disallows connection to peer
  * [/ip4/192.168.178.27/tcp/4001] gater disallows connection to peer
  * [/ip4/192.168.178.27/udp/4001/webrtc-direct/certhash/uEiCLpmdVOhWuiMpBtFC_bl71V5wswB5Ewtw8mqt6yuX-Fg] gater disallows connection to peer
  * [/ip4/192.168.178.27/udp/4001/quic-v1] gater disallows connection to peer
  * [/ip6/::1/tcp/4001] gater disallows connection to peer
  * [/ip6/::1/udp/4001/webrtc-direct/certhash/uEiCLpmdVOhWuiMpBtFC_bl71V5wswB5Ewtw8mqt6yuX-Fg] gater disallows connection to peer
  * [/ip6/::1/udp/4001/quic-v1] gater disallows connection to peer
  * [/ip4/87.123.47.57/udp/0/webrtc-direct/certhash/uEiCLpmdVOhWuiMpBtFC_bl71V5wswB5Ewtw8mqt6yuX-Fg] dial backoff
  * [/ip6/2001:9e8:82b2:e100:6170:19ce:e827:ec31/udp/4001/webrtc-direct/certhash/uEiCLpmdVOhWuiMpBtFC_bl71V5wswB5Ewtw8mqt6yuX-Fg] dial backoff
  * [/ip4/87.123.47.57/udp/0/quic-v1] INTERNAL_ERROR (local): write udp4 0.0.0.0:41462->87.123.47.57:0: sendmsg: invalid argument
  * [/ip6/2001:9e8:82b2:e100:6170:19ce:e827:ec31/udp/4001/quic-v1] timeout: no recent network activity
  * [/ip6/2001:9e8:82b2:e100:6170:19ce:e827:ec31/tcp/4001] dial tcp6 [::]:33017->[2001:9e8:82b2:e100:6170:19ce:e827:ec31]:4001: i/o timeout
  * [/ip4/87.123.47.57/tcp/0] dial tcp4 0.0.0.0:46673->87.123.47.57:0: i/o timeout
✅ Found multiaddrs advertised in the DHT:
	/ip4/127.0.0.1/tcp/4001
	/ip4/127.0.0.1/udp/4001/quic-v1
	/ip4/127.0.0.1/udp/4001/quic-v1/webtransport/certhash/uEiB--vi-k_800IZW8Mf7NgDFWA1CktFNfsgHPYRyMGYMEw/certhash/uEiBpn3Bt6MGmjFjkKhCslWarwdTVwzkvQXm9LiZn-1DoYw
	/ip4/127.0.0.1/udp/4001/webrtc-direct/certhash/uEiCLpmdVOhWuiMpBtFC_bl71V5wswB5Ewtw8mqt6yuX-Fg
	/ip4/192.168.178.27/tcp/4001
	/ip4/192.168.178.27/udp/4001/quic-v1
	/ip4/192.168.178.27/udp/4001/quic-v1/webtransport/certhash/uEiB--vi-k_800IZW8Mf7NgDFWA1CktFNfsgHPYRyMGYMEw/certhash/uEiBpn3Bt6MGmjFjkKhCslWarwdTVwzkvQXm9LiZn-1DoYw
	/ip4/192.168.178.27/udp/4001/webrtc-direct/certhash/uEiCLpmdVOhWuiMpBtFC_bl71V5wswB5Ewtw8mqt6yuX-Fg
	/ip4/87.123.47.57/tcp/0
	/ip4/87.123.47.57/udp/0/quic-v1
	/ip4/87.123.47.57/udp/0/quic-v1/webtransport/certhash/uEiB--vi-k_800IZW8Mf7NgDFWA1CktFNfsgHPYRyMGYMEw/certhash/uEiBpn3Bt6MGmjFjkKhCslWarwdTVwzkvQXm9LiZn-1DoYw
	/ip4/87.123.47.57/udp/0/webrtc-direct/certhash/uEiCLpmdVOhWuiMpBtFC_bl71V5wswB5Ewtw8mqt6yuX-Fg
	/ip6/2001:9e8:82b2:e100:6170:19ce:e827:ec31/tcp/4001
	/ip6/2001:9e8:82b2:e100:6170:19ce:e827:ec31/udp/4001/quic-v1
	/ip6/2001:9e8:82b2:e100:6170:19ce:e827:ec31/udp/4001/quic-v1/webtransport/certhash/uEiB--vi-k_800IZW8Mf7NgDFWA1CktFNfsgHPYRyMGYMEw/certhash/uEiBpn3Bt6MGmjFjkKhCslWarwdTVwzkvQXm9LiZn-1DoYw
	/ip6/2001:9e8:82b2:e100:6170:19ce:e827:ec31/udp/4001/webrtc-direct/certhash/uEiCLpmdVOhWuiMpBtFC_bl71V5wswB5Ewtw8mqt6yuX-Fg
	/ip6/::1/tcp/4001
	/ip6/::1/udp/4001/quic-v1
	/ip6/::1/udp/4001/quic-v1/webtransport/certhash/uEiB--vi-k_800IZW8Mf7NgDFWA1CktFNfsgHPYRyMGYMEw/certhash/uEiBpn3Bt6MGmjFjkKhCslWarwdTVwzkvQXm9LiZn-1DoYw
	/ip6/::1/udp/4001/webrtc-direct/certhash/uEiCLpmdVOhWuiMpBtFC_bl71V5wswB5Ewtw8mqt6yuX-Fg
❌ Could not find the multihash in DHT or IPNI

I guess most people using the X86 versions, so it might be that there is a undetected bug in the 64 bit arm version that’s cause it not to function well.

FWIW, I’ve been running a swarm of ~100-200 nodes on arm64, with maybe one x86_64 node. Mostly Raspberry Pi 4B, and it works well most of the time, the only problem I experience is `ipfs pin add` often hangs with a wantlist of ~7 CIDs - #5 by hector, and I’m told that may be fixed in 0.33.0-rc1 but I’ve not yet had a chance to try it.

So I don’t think your system being a Raspberry Pi 5 should cause you any problems. As the other posters have mentioned, I would be suspicious of your network setup - firewalls, NAT, etc.

1 Like

if check.ipfs.network is showing failure to connect, then inbrowser.link with default settings won’t be able to access the content either.

If you can get a valid endpoint and access that, you can configure your own node as your trustless gateway, but ideally you shouldn’t have to do that at all

I think /ip4/87.123.47.57/tcp/0 is not normal. TCP port should not be 0.

Any idea how you managed that?

Other than that, you have dial-backoffs and timeouts on ipv6, which look a lot like your port forwarding is not setup correctly.

1 Like

I did not change anything in the config file, except “StorageMax”: “100GB” was set to this increased valve.

Also wrong settings on IPV6 should not prevent my node to get connections over IPV4.

With my X86 Linux nodes I never had similar problems so this is real strange for me.

Could be? I don’t have rpi5 at hand, but docker run --rm -it --net=host ipfs/kubo:v0.33.0-rc3 works fine on rpi4.

Would be good to have someone with rpi5 to confirm if they have similar issue, until we have second data point from other rpi5 user, this looks more like something specific your network setup somehow.

All or just WAN? Are you able to dial Raspbery PI Peer from within LAN?

Try vole:

$ vole libp2p identify /ip4/LAN-IP/tcp/4001/p2p/12D3XXXXXXXXXXXXXXXXXXXXXXX

Try 0.33.0-rc3 with ipfs config --json AutoTLS.Enabled true

AutoTLS will enable additional transport for browser-based clients like inbrowser.link.

There was indeed a wrong setting in my rooter witch prevented incoming ipv6 traffic.

And i found an explanation why my X86 node had been reachable. On my X86 i see always connections over p2p-circut with ipfs id.

On my raspberry there are no p2p-circut addresses shown.

So because everything worked i did not check the connectivity on my X86 nodes.

Thanks to anybody here to give me support.