Unable to read from stream socket: Resource temporarily unavailable

[FlexMcMurphy]

I am using iPerf3 to send UDP packets to my home server over Port 80 over a public Wifi network.

On the server side, in my LAN, I get this:

Server listening on 5003
------------------------------------------------------------------
Accepted connection from [ip-address], port [port_num]
------------------------------------------------------------------

... then nothing else appears on the server side.

On the Client side, using the public Wifi network, there is a delay of several seconds then I get this error:

Unable to read from stream socket: Resource temporarily unavailable

I do not get this error when I try to send UDP packets on Port 443 on that same public Wifi network.
When I switch to a mobile 4G hotspot I do not get this error with UDP packets on Ports 80 or 443.
Is UDP maybe blocked on Port 80 on the Wifi network?

I started two iperf3 server instances on a device in my home LAN like this:

iperf3 -s -p 5003
iperf3 -s -p 5004

On my home router I port forwarded Port 80 to 5003 and Port 443 external to 5004 internal.

Then from my laptop connected to the 4G from my phone hotspot OR from the public Wifi network I run these commands to test the connection with UDP and TCP packets.

iperf3 -u -c [my router public ip address] -b 1M -p 80
iperf3 -c [my router public ip address] -b 1M -p 80
iperf3 -u -c [my router public ip address] -b 1M -p 443
iperf3 -c [my router public ip address] -b 1M -p 443

The device in my LAN running the iPerf3 server is Ubuntu 20.04 running on a Raspberry Pi 4 (Kernel 5.15)

iperf -v
Version is iperf 3.9 (cJSON 1.7.13)

The device running iPerf3 as a client is a laptop running Manjaro (Kernel 6.1.71)

iperf -v
Version is iperf 3.16 (cJSON 1.7.15)

I wonder is this simply a case that UDP is blocked on Port 80 on the Wifi network? But why would UDP be blocked on Port 80 and not Port 443? How else could I test if UDP is blocked on Port 80 on this Wifi network? My iPerf3 versions on the client and server are not the same but I don't think that is the issue?

Cheers,

Flex

[bmah888]

Lots to unpack here! Those two versions of iperf3 should interoperate fine (true in general for any iperf3 versions), if they don't that's a bug we should fix.

I presume your port-forwarding is for both TCP and UDP? Otherwise there's no way the client could make the TCP connection for the iperf3 control channel.

I'll note that iperf3 wasn't explicitly designed to work to a server behind a NAT, and I thought I'd convinced myself at one point that this wasn't going to work. I could be wrong though. Did your TCP tests work?

Are you trying to test something like QUIC over UDP/80 or UDP/443? It's certainly possible that something's filtering that out.

[FlexMcMurphy]

Thanks Bruce.

Yes I'm port forwarding both TCP and UDP on each Port.

The TCP tests work on each Port and the UDP tests work on Port 443 just not 80.

It's a public wifi network but I don't know anything about what filtering it might have in place.

I'm not trying out QUIC just checking if I could use WireGuard on that Wifi network and it needs UDP. I guess I can just use Port 443 and a demultiplexer like SSLH in my home server.

I'll do a few more iperf3 tests with verbose output and then try other tools like netcat and i dunno maybe curl or something, more googling on the way!

Thank you,

Flex

[v587xpt]

I had the same problem，When using UDP for testing，And it's on a public network。
After testing, I always thought it was a firewall problem, but couldn't be sure。
If you solve this problem, please let me know the method, thank you 。(✪ω✪)

[FlexMcMurphy]

I have not looked in to this issue since. UDP was working for me over port 443 so I guess use that if you can.