[SOLVED] is wget not working? (Unify router problem)

z0rg0n · Aug 22, 2024

I've been trying to run Proxmox VE helper scripts to help me get things running but all the scripts I try just spin forever.

From this thread it seems like maybe it's something being blocked.

As a test I tried to run:

Code:

wget github.com

And it outputs:

Code:

--2024-08-23 05:55:27--  http://github.com/
Resolving github.com (github.com)... 20.27.177.113
Connecting to github.com (github.com)|20.27.177.113|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/ [following]
--2024-08-23 05:55:27--  https://github.com/
Connecting to github.com (github.com)|20.27.177.113|:443... connected.

Then stops and I have to interrupt it.

I'm wondering if this is and indication that github is being blocked somehow by my ISP as in the thread I shared above. Or maybe it's something else I'm not understanding. I think it's the former because

PHP:

ping github.com

is not losing any packets.

Falk R. · Aug 22, 2024

Then check whether the destination can be reached from the script. There is probably a faulty URL in the script.

z0rg0n · Aug 22, 2024

The destination seems to be working 100% when I browse it from my laptop:
https://github.com/tteck/Proxmox/raw/main/misc/post-pve-install.sh
Gives a page that looks like this:

...

That's why I was thinking it's something wrong with wget or maybe it's my network.

billy999 · Aug 22, 2024

The log only shows a basic HTTPS redirect which is perfectly fine. Does curl work?

z0rg0n · Aug 22, 2024

Something interesting maybe.
Running

Code:

wget https://raw.githubusercontent.com/tteck/Proxmox/main/misc/post-pve-install.sh

Outputs what makes it look like Proxmox can see that webpage:

Code:

--2024-08-23 06:20:11--  https://raw.githubusercontent.com/tteck/Proxmox/main/misc/post-pve-install.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.110.133, 185.199.108.133, 185.199.111.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.110.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9213 (9.0K) [text/plain]
Saving to: ‘post-pve-install.sh.1’

post-pve-install.sh.1         100%[===============================================>]   9.00K  --.-KB/s    in 0.005s 

2024-08-23 06:20:24 (1.68 MB/s) - ‘post-pve-install.sh.1’ saved [9213/9213]

z0rg0n · Aug 22, 2024

billy999 said:
The log only shows a basic HTTPS redirect which is perfectly fine. Does curl work?

No it is not!

Code:

curl https://github.com

Spins for a long time then outputs:
curl: (35) Recv failure: Connection reset by peer

So my curl command is broken? What could be the cause of this?

billy999 · Aug 22, 2024

z0rg0n said:
No it is not!

Code:

curl https://github.com

Does the same thing. It just spins forever and outputs nothing!

So my curl command is broken? What could be the cause of this?

Can you do curl -v https://github.com and post the output?

z0rg0n · Aug 22, 2024

billy999 said:
Can you do curl -v https://github.com and post the output?

The output is:

Code:

*   Trying 20.27.177.113:443...
* Connected to github.com (20.27.177.113) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to github.com:443
* Closing connection 0
curl: (35) Recv failure: Connection reset by peer

Which means it's not working I believe? Although I'm not sure why or what it all really means.

billy999 · Aug 22, 2024

z0rg0n said:

The output is:

Code:

*   Trying 20.27.177.113:443...
* Connected to github.com (20.27.177.113) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to github.com:443
* Closing connection 0
curl: (35) Recv failure: Connection reset by peer

Which means it's not working I believe? Although I'm not sure why or what it all really means.

Why does github.com resolve to 20.27.177.113? It should be 140.82.113.3 , can you check your DNS?

z0rg0n · Aug 23, 2024

billy999 said:
Why does github.com resolve to 20.27.177.113? It should be 140.82.113.3 , can you check your DNS?

Could it be that queries from different countries resolve to a different IP?

~~My laptop connects to that same IP address and outputs a bunch of different stuff.~~ My laptop is not exhibiting the same behavior as Proxmox.
curl -v https://github.com

Code:

*   Trying 20.27.177.113:443...
* Connected to github.com (20.27.177.113) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=github.com
*  start date: Mar  7 00:00:00 2024 GMT
*  expire date: Mar  7 23:59:59 2025 GMT
*  subjectAltName: host "github.com" matched cert's "github.com"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo ECC Domain Validation Secure Server CA
*  SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: github.com]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x55683e7b6ce0)
> GET / HTTP/2
> Host: github.com
> user-agent: curl/7.88.1
> accept: */*
>
^C

Then it keeps going spitting out a bunch of data.

Proxmox is set to cloudflare as my DNS server I'm pretty sure:

And all the ping requests seem to work and are also resolving to that same 20.27.177.113:

Code:

PING github.com (20.27.177.113) 56(84) bytes of data.
64 bytes from 20.27.177.113 (20.27.177.113): icmp_seq=1 ttl=115 time=4.90 ms
64 bytes from 20.27.177.113 (20.27.177.113): icmp_seq=2 ttl=115 time=5.87 ms
64 bytes from 20.27.177.113 (20.27.177.113): icmp_seq=3 ttl=115 time=5.88 ms
^C
--- github.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 4.897/5.550/5.884/0.462 ms

billy999 · Aug 23, 2024

z0rg0n said:

Could it be that queries from different countries resolve to a different IP?

My laptop connects to that same IP address and outputs a bunch of different stuff.
curl -v https://github.com

Code:

*   Trying 20.27.177.113:443...
* Connected to github.com (20.27.177.113) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=github.com
*  start date: Mar  7 00:00:00 2024 GMT
*  expire date: Mar  7 23:59:59 2025 GMT
*  subjectAltName: host "github.com" matched cert's "github.com"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo ECC Domain Validation Secure Server CA
*  SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: github.com]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x55683e7b6ce0)
> GET / HTTP/2
> Host: github.com
> user-agent: curl/7.88.1
> accept: */*
>
^C

Then it keeps going spitting out a bunch of data.

Proxmox is set to cloudflare as my DNS server I'm pretty sure:
View attachment 73480
And all the ping requests seem to work and are also resolving to that same 20.27.177.113:

Code:

PING github.com (20.27.177.113) 56(84) bytes of data.
64 bytes from 20.27.177.113 (20.27.177.113): icmp_seq=1 ttl=115 time=4.90 ms
64 bytes from 20.27.177.113 (20.27.177.113): icmp_seq=2 ttl=115 time=5.87 ms
64 bytes from 20.27.177.113 (20.27.177.113): icmp_seq=3 ttl=115 time=5.88 ms
^C
--- github.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 4.897/5.550/5.884/0.462 ms

Yes that looks fine, it might be an MTU issue. Can you post the output of ip a?

z0rg0n · Aug 23, 2024

The output of ip a is:

Rich (BB code):

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether a4:ae:11:1c:89:2d brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6
3: wlp0s20f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 8c:c6:81:6f:a0:ae brd ff:ff:ff:ff:ff:ff
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a4:ae:11:1c:89:2d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.223/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::a6ae:11ff:fe1c:892d/64 scope link
       valid_lft forever preferred_lft forever

lol. I have no idea what's going on now. Sorry I'm just being a dumb end user at this point.

billy999 · Aug 23, 2024

z0rg0n said:

The output of ip a is:

Rich (BB code):

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether a4:ae:11:1c:89:2d brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6
3: wlp0s20f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 8c:c6:81:6f:a0:ae brd ff:ff:ff:ff:ff:ff
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a4:ae:11:1c:89:2d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.223/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::a6ae:11ff:fe1c:892d/64 scope link
       valid_lft forever preferred_lft forever

lol. I have no idea what's going on now. Sorry I'm just being a dumb end user at this point.

That looks fine too. Is the firewall on? Maybe try with it off. Otherwise im out of ideas actually, next step would be inspecting TCP packets themselves but my networking knowledge already ends here. You could search online with the error message Recv failure: Connection reset by peer and try other fixing attempts

z0rg0n · Aug 23, 2024

The firewall is set to default and since I can reach the sites on my laptop I figure it's not that.

I'll have to try to do another clean install of Proxmox and to see if it's just like a fluke.

To consolidate our findings so far:

wget github.com
Works fine in Proxmox

ip a
Shows that Proxmox is connected to my network correctly

ping github.com
Shows that Proxmox can see github fine

wget github.com
Output further confirms that Proxmox can see github.com and confirms that wget is working.

But curl -v github.com does not work in Proxmox even though it does work on another machine on my network.

Is that about the gist of it?

z0rg0n · Aug 23, 2024

Have the same problem on a new install. ~~The next thing I'm going to try is bringing the NUC to a friends house and seeing if I can reproduce the issue~~. After that I'll buy a new NUC and try again.
Edit: I have no friends with internet and I doubt this will work at the library.

Here are my steps from start to finish

Download Proxmox VE 8.2 ISO Installer from https://www.proxmox.com/en/downloads/proxmox-virtual-environment/iso
Verify the SHA256SUM using sha256sum proxmox-ve_8.2-2.iso
Reformat thumb drive
Flash a thumb with the iso drive using this guide
Plug in the thumb drive to the NUC and enter BIOS. Boot to the thumb drive and enter the Proxmox setup
Proxmox install;
1. For network settings:
  1. IPv4/CIDR: 192.168.1.223/24
  2. Gateway (IPv4): 192.168.1.1

For Proxmox network settings I match these up with my unify router.

Router settings
Gateway IP: 192.168.1.1
Broadcast IP: 192.168.1.255
IP Range: 192.168.1.6 - 192.168.1.254
Subnet Mask: 225.225.225.0
DNS Server Primary: 1.1.1.1
DNS Server Secondary: 8.8.8.8
IPv6 Connection: Disabled

From here I repeat the tests from before:

curl -v https://github.comOutput
ip aOutput
ping github.comOutput
wget github.comOutput then it locks up
bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/misc/post-pve-install.sh)"No output

BobhWasatch · Aug 23, 2024

Are you sure that nothing else on your network is using 192.168.1.223? That would be in the default DHCP range of a lot of routers.

z0rg0n · Aug 25, 2024

I'm almost certain that that was the only device on that IP. I've only got my laptop and phone other than the proxmox box.

I bought a cheepo router this weekend and tried again with that. wget and the helper scripts worked at expected. looks like it's got something to do with the Unify router.

I'm closing this thread and am going to dive into this router or just stick with this junky one. Thank you so much for your help everyone!

z0rg0n · Aug 26, 2024

Instructions on solution for anyone finding this down the line.

My ISP uses PPPoE which reduces the MTU from what the router thinks it should be. I had to do a ping test to determine what the MTU was then adjusted the MSS settings in my Unify router to match this.

billy999 · Aug 26, 2024

z0rg0n said:
Instructions on solution for anyone finding this down the line.

My ISP uses PPPoE which reduces the MTU from what the router thinks it should be. I had to do a ping test to determine what the MTU was then adjusted the MSS settings in my Unify router to match this.

Great that you were able to find the solution. A proper router should be able to autodetect these things anyway

[SOLVED] is wget not working? (Unify router problem)

New Member

Distinguished Member

New Member

Member

New Member

New Member

Member

New Member

Member

New Member

Member

New Member

Member

New Member

New Member

Famous Member

New Member

New Member

Member