Error any valid prefix is expected rather than

---

---

---

---

---

---

---

---

---

---

OpenVPN Support Forum

Community Support Forum

ERROR AFTER UPGRADE: Error: any valid prefix is expected rather than

ERROR AFTER UPGRADE: Error: any valid prefix is expected rather than

Post by bjpp2523 » Tue Sep 13, 2022 4:10 pm

We recently upgraded from Ubuntu 16.04 to 20.04 and right after the upgrade OpenVPN stopped working.

The current version of OpenVPN we have is

Server Kernel / OS

Re: ERROR AFTER UPGRADE: Error: any valid prefix is expected rather than

Post by TinCanTech » Tue Sep 13, 2022 5:08 pm

More by luck than judgement.

Re: ERROR AFTER UPGRADE: Error: any valid prefix is expected rather than

Post by bjpp2523 » Tue Sep 13, 2022 5:50 pm

Yup. You’re damn right.

I edited the original post and added more information of the client trying to connect. Aswell as the server, except logs.

Re: ERROR AFTER UPGRADE: Error: any valid prefix is expected rather than

Post by TinCanTech » Tue Sep 13, 2022 6:02 pm

And you still have no idea what you have done wrong ?

What you should do is switch back to — dev tun

Re: ERROR AFTER UPGRADE: Error: any valid prefix is expected rather than

Post by bjpp2523 » Tue Sep 13, 2022 6:21 pm

Re: ERROR AFTER UPGRADE: Error: any valid prefix is expected rather than

Post by bjpp2523 » Tue Sep 13, 2022 6:27 pm

TUN mode has never been used. We’ve always used TAP.
We have around 10 clients (with OpenVPN 2.4.7 and 2.3.10) connected with TAP mode. Yes, i know you would ve thinking «Why you have clients still using 2.3.10?» which i would answer with «They’re still on Ubuntu 16.04» and that would lead to another question «WHY NOT UPGRADE THOSE CLIENT’S OS?!» And. I know. That’s something we’re doing right now and that’s why we faced the issue in this topic.

I’ve read that recent versions of OpenVPN only support TUN mode, which i’ve been suggesting to change to. Even though there are alot of changes that need to be done in many services that are currently running.

Re: ERROR AFTER UPGRADE: Error: any valid prefix is expected rather than

Post by dazo » Wed Sep 14, 2022 12:13 pm

Just a follow up on «recent versions» and «TUN only».

Generally speaking, TUN is preferred. There are few use cases where TAP is the right or sane option — but TAP can be the only right option in some cases. But over the last 10+ years I’ve done OpenVPN setups and development, I’ve only seen a handful use cases for TAP. TUN gives lesser overhead (no Ethernet frames being passed back and forth over the tunnel) and it reduces broadcast noise and potential DHCP server conflicts — to mention a few benefits with TUN.

The OpenVPN 3 Core library, which the OpenVPN Connect clients are built on only supports TUN. The OpenVPN 3 Linux project has the same limitation. Android and iOS only supports TUN mode for VPN applications. Windows has a VPN API in newer Windows releases (Win 10 and newer, iirc), which also only supports TUN mode. Further the OpenVPN Data Channel Offload (DCO) drivers for Linux, Windows and FreeBSD will also only support TUN mode. DCO moves a lot of the cryptographic operations into the OS kernel, which can then process, decrypt and encrypt traffic much more efficiently — so the VPN tunnel gets a better throughput.

But TAP support will not disappear in the near or foreseeable future. OpenVPN 2.x releases will continue to support TAP mode as long as the virtual network driver (the «tun/tap driver») supports TAP mode. In practice, that will mean TAP will be supported on Linux and BSD using the well used «tun» driver (it supports TAP mode too). On Windows the tap-windows6 driver will also continue to support TAP mode. But there will be no Android/iOS support for TAP; that is an OS limitation.

All said, planning ahead to move to TUN mode will give you more advantages — in particular performance wise. And it will open the possibilities to move over to DCO later on as well. Just ensure you use AES-GCM based ciphers and do not enable compression, then you should be fairly well settled for the future. You should also plan to lower the —tun-mtu value as well; IIRC,I believe that will be reduced to 1420 with the OpenVPN 2.6 release.

Источник

OpenVPN Support Forum

Community Support Forum

Can downgrade openvpn version to 2.3 in Ubuntu 18.04 LTS?

Can downgrade openvpn version to 2.3 in Ubuntu 18.04 LTS?

Post by crainar » Tue Feb 12, 2019 5:55 pm

I need to install version opencpn 2.3.xx on a Linux Ubuntu 18.04 LTS.

Is this possible?

How can you do it?

Thanks to everyone in advance.

This is for new Ubuntu 18.04 LTS client with openvpn 2.4.4

My server is Ubuntu 16.04 LTS with openvpn 2.3.10

At this moment when I try to connect in new client with Ubuntu 18 openvpn log error:

Error: any valid prefix is expected rather than «10.8.110.21/-1».
Tue Feb 12 18:11:57 2019 us=155560 Linux ip addr add failed: external program exited with error status: 1
Tue Feb 12 18:11:57 2019 us=155759 Exiting due to fatal error

I try : sudo apt-get install openvpn=2.3.10 but doesn’t workn error: can’t find in repository version «2.3.10»

If I put openvpn 2.3 with Ubuntu 16 its work, but I need Ubuntu 18.04 in new client.

Re: Can downgrade openvpn version to 2.3 in Ubuntu 18.04 LTS?

Post by TinCanTech » Tue Feb 12, 2019 6:10 pm

The error has nothing to do with your version of openvpn.

Please correct the error in your config file.

Re: Can downgrade openvpn version to 2.3 in Ubuntu 18.04 LTS?

Post by crainar » Tue Feb 12, 2019 7:40 pm

But my client (2.4.4 version) config file only have:

client
dev tap
;dev tun
;dev-node MyTap
;proto tcp
proto udp
remote 185.166.214.136 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /home/MaskedSoftware/VPNs/SEMMINER1/ca.crt
cert /home/MaskedSoftware/VPNs/SEMMINER1/nodeAPI2.crt
key /home/MaskedSoftware/VPNs/SEMMINER1/nodeAPI2.key
tls-auth /home/MaskedSoftware/VPNs/SEMMINER1/ta.key 1
cipher AES-256-CBC
compress

Re: Can downgrade openvpn version to 2.3 in Ubuntu 18.04 LTS?

Post by crainar » Tue Feb 12, 2019 7:44 pm

Server (2.3.10 version) config only have it:

;local a.b.c.d
port 1194
;proto tcp
proto udp
dev tap
;dev tun
;dev-node MyTap
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key # This file should be kept secret
dh /etc/openvpn/dh2048.pem
;topology subnet
;server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
server-bridge 10.8.110.4 255.255.254.0 10.8.110.50 10.8.111.250
;server-bridge
;push «route 192.168.10.0 255.255.255.0»
;push «route 192.168.20.0 255.255.255.0»
client-config-dir /etc/openvpn/staticclients
;route 192.168.40.128 255.255.255.248
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
;learn-address ./script
;push «redirect-gateway def1 bypass-dhcp»
;push «dhcp-option DNS 208.67.220.220»
client-to-client
duplicate-cn
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0 # This file is secret
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
cipher AES-256-CBC
;cipher DES-EDE3-CBC # Triple-DES
;auth SHA256
comp-lzo
;max-clients 100
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
log-append openvpn.log
verb 6
;mute 20

Re: Can downgrade openvpn version to 2.3 in Ubuntu 18.04 LTS?

Post by crainar » Tue Feb 12, 2019 7:52 pm

The error has nothing to do with your version of openvpn.

Please correct the error in your config file.

May be a problem in static client file on server at line?
ifconfig-push 10.8.110.21 10.8.110.0

(in client 2.3.10 work but in 2.4.4 it work?

Re: Can downgrade openvpn version to 2.3 in Ubuntu 18.04 LTS?

Post by crainar » Wed Feb 13, 2019 8:10 am

The error has nothing to do with your version of openvpn.

Please correct the error in your config file.

Thanks, I solve the problem, was in client config dir file, I assign this line :

ifconfig-push 10.8.110.21 10.8.110.0 [BAD]

ifconfig-push 10.8.110.21 255.255.255.0 [GOOD]

Источник

pveceph createosd — Error: any valid prefix is expected rather than «»

cjmurray

Member

I have a couple of separate Proxmox clusters using Ceph, and both won’t allow me to create OSDs at the moment:

# pveceph createosd /dev/sdd
Error: any valid prefix is expected rather than «».
command ‘/sbin/ip address show to » up’ failed: exit code 1

Testing ‘ip address show’ with the correct node IP does return the correct detail. Any pointers to where I can troubleshoot next would be appreciated. The cluster’s health seems otherwise fine, as is «pveceph lspools», «ceph status» etc. There seems to be something particular about creating an OSD that cares about the hostname/ip address.

Thank you,
Chris

proxmox-ve: 6.1-2 (running kernel: 5.3.13-1-pve)
pve-manager: 6.1-5 (running version: 6.1-5/9bf06119)
pve-kernel-5.3: 6.1-1
pve-kernel-helper: 6.1-1
pve-kernel-5.0: 6.0-11
pve-kernel-4.15: 5.4-6
pve-kernel-5.3.13-1-pve: 5.3.13-1
pve-kernel-5.0.21-5-pve: 5.0.21-10
pve-kernel-4.15.18-18-pve: 4.15.18-44
pve-kernel-4.15.18-9-pve: 4.15.18-30
ceph: 14.2.6-pve1
ceph-fuse: 14.2.6-pve1
corosync: 3.0.2-pve4
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.13-pve1
libpve-access-control: 6.0-5
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-10
libpve-guest-common-perl: 3.0-3
libpve-http-server-perl: 3.0-3
libpve-storage-perl: 6.1-3
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4

pve6+1
lvm2: 2.03.02-pve3
lxc-pve: 3.2.1-1
lxcfs: 3.0.3-pve60
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.1-2
pve-cluster: 6.1-3
pve-container: 3.0-18
pve-docs: 6.1-3
pve-edk2-firmware: 2.20191127-1
pve-firewall: 4.0-9
pve-firmware: 3.0-4
pve-ha-manager: 3.0-8
pve-i18n: 2.0-3
pve-qemu-kvm: 4.1.1-2
pve-xtermjs: 3.13.2-1
qemu-server: 6.1-4
smartmontools: 7.1-pve1
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.2-pve2

Источник

Error 502 when trying to access to web UI or rpc by transmission-openvpn-proxy #2208

Is there a pinned issue for this?

• I have read the pinned issues and could not find my issue

Is there an existing or similar issue/discussion for this?

• I have searched the existing issues
• I have searched the existing discussions

• I have read the documentation, especially the FAQ and Troubleshooting parts

• I have checked the provider repo for issues
• My issue is NOT related to a provider

Are you using the latest release?

Have you tried using the dev branch latest?

Docker run config used

transmission:
container_name: Transmission
ports:
— 9091:9091
volumes:
— transmission_config:/config
— /media/Bobo4TO/Downloads:/data
— /etc/localtime:/etc/localtime:ro
environment:
— OPENVPN_PASSWORD=MYPASS
— OPENVPN_PROVIDER=PUREVPN
— OPENVPN_USERNAME=MYUSER
— TRANSMISSION_WEB_UI=combustion
— OPENVPN_OPTS=—inactive 3600 —ping 10 —ping-exit 60
— TRANSMISSION_INCOMPLETE_DIR_ENABLED=false
— TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
— TRANSMISSION_RPC_PASSWORD=PASS
— TRANSMISSION_RPC_PORT=9091
— TRANSMISSION_RPC_USERNAME=ME
— TRANSMISSION_DOWNLOAD_DIR=/data
— OPENVPN_CONFIG=’at2-ovpn-udp, gr2-ovpn-udp, tw2-ovpn-udp, ussf2-ovpn-udp, uk-obf-udp, au-sd2-ovpn-udp, hk2-ovpn-udp, ustx2-ovpn-udp, ukg2-ovpn-udp, au2-ovpn-udp, in2-ovpn-udp, usut2-ovpn-udp, ukl2-ovpn-udp, au2-pe-ovpn-udp, it2-ovpn-udp, usva2-ovpn-udp, ukm2-ovpn-udp, br2-ovpn-udp, jp2-ovpn-udp, uswdc2-ovpn-udp, us2-ovpn-udp, ca2-ovpn-udp, kr2-ovpn-udp, vlap-ph2-ovpn-udp, usfl2-ovpn-udp, cav2-ovpn-udp, my2-ovpn-udp, vlap-th2-ovpn-udp, usga2-ovpn-udp, ch2-ovpn-udp, nl2-ovpn-udp, vlap-vn2-ovpn-udp, p2p-udp, usil2-ovpn-udp, cz2-ovpn-udp, usla2-ovpn, vleu-be2-ovpn-udp, pl2-ovpn-udp, usla2-ovpn-udp, de2-ovpn-udp, vleu-no2-ovpn-udp, pt2-ovpn-udp, usnj2-ovpn-udp, vlus-mx2-ovpn-udp, dk2-ovpn-udp, ru2-ovpn-udp, usny2-ovpn-udp, vlus-pa2-ovpn-udp, es2-ovpn-udp, se2-ovpn-udp, usphx2-ovpn-udp, za2-ovpn-udp, fr2-ovpn-udp, sg2-ovpn-udp, ussa2-ovpn-udp’
— LOCAL_NETWORK=»192.168.1.0/24″
cap_add:
— NET_ADMIN
devices:
— /dev/net/tun
dns:
— 8.8.8.8
— 8.8.4.4
logging:
driver: json-file
options:
max-size: 10m
image: haugene/transmission-openvpn
networks:
— traefik

transmission_proxy:
container_name: Transmission_proxy
restart : unless-stopped
image: haugene/transmission-openvpn-proxy
links:
— transmission:transmission
ports:
— 8081:8080
volumes:
— /etc/localtime:/etc/localtime:ro
labels:
traefik.enable: true
traefik.http.routers.transmission-proxy-http.rule: Host( transmission-proxy.someurl )
traefik.http.routers.transmission-proxy-http.entryPoints: insecure
traefik.http.routers.transmission-proxy-https.rule: «Host( transmission-proxy.someurl )»
traefik.http.routers.transmission-proxy-http.middlewares: https-redirect@file
traefik.http.routers.transmission-proxy-https.entrypoints: «secure»
traefik.http.routers.transmission-proxy-https.middlewares: «security@file, compression@file»
traefik.http.routers.transmission-proxy-https.service: «transmission-proxy-serverparisdocker»
traefik.http.services.transmission-proxy-serverparisdocker.loadbalancer.server.port: «8080»
traefik.http.routers.transmission-proxy-https.tls: «true»
traefik.http.routers.transmission-proxy-https.tls.certresolver: «letsencrypt»
networks:
— traefik

Current Behavior

The docker and the vpn connect to the VPN provider.
I have an IP from the VPN provider.

When I try to access to the web UI or when I pass by the android app transmission, I have a 502 Bad Gateway.
I have this on the proxy container log :
2022/03/04 18:16:30 [error] 24#24: *106 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.36, server: , request: «GET /transmission/rpc/ HTTP/1.1», upstream: «http://172.18.0.8:9091/transmission/rpc/», host: «192.168.1.26:8081», referrer: «http://192.168.1.26:8081/transmission/rpc/»

I can’t add or delete torrents.

Expected Behavior

Acces to Web UI and/or by the android app transmission

How have you tried to solve the problem?

1. Switch version 3.6,3.7,4.0,dev
2. Debug my server network
3. change port
4. pray..

Log output

From transmission-openvpn-proxy :
192.168.1.27 — baudouin [04/Mar/2022:18:24:54 +0100] «POST /transmission/rpc HTTP/1.1» 502 157 «-» «Google-HTTP-Java-Client/1.22.0 (gzip)»
2022/03/04 18:24:55 [error] 24#24: *111 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.27, server: , request: «POST /transmission/rpc HTTP/1.1», upstream: «http://172.18.0.8:9091/transmission/rpc», host: «192.168.1.26:8081»
192.168.1.27 — baudouin [04/Mar/2022:18:24:55 +0100] «POST /transmission/rpc HTTP/1.1» 502 157 «-» «Google-HTTP-Java-Client/1.22.0 (gzip)»
2022/03/04 18:24:56 [error] 24#24: *111 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.27, server: , request: «POST /transmission/rpc HTTP/1.1», upstream: «http://172.18.0.8:9091/transmission/rpc», host: «192.168.1.26:8081»
192.168.1.27 — baudouin [04/Mar/2022:18:24:56 +0100] «POST /transmission/rpc HTTP/1.1» 502 157 «-» «Google-HTTP-Java-Client/1.22.0 (gzip)»

From transmission-openvpn :
Starting container with revision: 8cc1870
Creating TUN device /dev/net/tun
mknod: /dev/net/tun: File exists
Using OpenVPN provider: PUREVPN
Running with VPN_CONFIG_SOURCE auto
No bundled config script found for PUREVPN. Defaulting to external config
Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.4lFWX2dtVS
Extracting configs to /tmp/tmp.oRl7poBnAo
Found configs for PUREVPN in /tmp/tmp.oRl7poBnAo/vpn-configs-contrib-main/openvpn/purevpn, will replace current content in /etc/openvpn/purevpn
Cleanup: deleting /tmp/tmp.4lFWX2dtVS and /tmp/tmp.oRl7poBnAo
55 servers found in OPENVPN_CONFIG, usva2-ovpn-udp chosen randomly
Starting OpenVPN using config usva2-ovpn-udp.ovpn
Modifying /etc/openvpn/purevpn/usva2-ovpn-udp.ovpn for best behaviour in this container
Modification: Point auth-user-pass option to the username/password file
Modification: Change ca certificate path
Modification: Change ping options
Modification: Update/set resolv-retry to 15 seconds
Modification: Change tls-crypt keyfile path
Modification: Set output verbosity to 3
Modification: Remap SIGUSR1 signal to SIGTERM, avoid OpenVPN restart loop
Setting OpenVPN credentials.
adding route to local network «192.168.1.0/24» via 172.18.0.1 dev eth0
Error: any valid prefix is expected rather than «»192.168.1.0/24″».
Fri Mar 4 17:59:37 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 19 2021
Fri Mar 4 17:59:37 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Fri Mar 4 17:59:37 2022 NOTE: the current —script-security setting may allow this configuration to call user-defined scripts
Fri Mar 4 17:59:37 2022 Outgoing Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Fri Mar 4 17:59:37 2022 Incoming Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Fri Mar 4 17:59:37 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]37.221.173.211:1194
Fri Mar 4 17:59:37 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Mar 4 17:59:37 2022 UDP link local: (not bound)
Fri Mar 4 17:59:37 2022 UDP link remote: [AF_INET]37.221.173.211:1194
Fri Mar 4 17:59:37 2022 TLS: Initial packet from [AF_INET]37.221.173.211:1194, sid=8d23be91 5032e959
Fri Mar 4 17:59:37 2022 VERIFY OK: depth=1, C=HK, ST=Central, L=HK, O=Secure-ServerCA, OU=IT, CN=Secure-ServerCA, name=Secure-ServerCA, emailAddress=mail@host.domain
Fri Mar 4 17:59:37 2022 VERIFY KU OK
Fri Mar 4 17:59:37 2022 Validating certificate extended key usage
Fri Mar 4 17:59:37 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Mar 4 17:59:37 2022 VERIFY EKU OK
Fri Mar 4 17:59:37 2022 VERIFY OK: depth=0, C=HK, ST=Central, L=HK, O=Secure-Server, OU=IT, CN=Secure-Server, name=changeme, emailAddress=mail@host.domain
Fri Mar 4 17:59:37 2022 WARNING: ‘link-mtu’ is used inconsistently, local=’link-mtu 1558′, remote=’link-mtu 1550′
Fri Mar 4 17:59:37 2022 WARNING: ‘cipher’ is used inconsistently, local=’cipher AES-256-CBC’, remote=’cipher AES-256-GCM’
Fri Mar 4 17:59:37 2022 WARNING: ‘auth’ is used inconsistently, local=’auth SHA1′, remote=’auth [null-digest]’
Fri Mar 4 17:59:37 2022 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Fri Mar 4 17:59:37 2022 [Secure-Server] Peer Connection Initiated with [AF_INET]37.221.173.211:1194
Fri Mar 4 17:59:39 2022 SENT CONTROL [Secure-Server]: ‘PUSH_REQUEST’ (status=1)
Fri Mar 4 17:59:39 2022 PUSH: Received control message: ‘PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 172.94.28.3,dhcp-option DNS 172.94.28.5,sndbuf 393216,rcvbuf 393216,comp-lzo no,route-gateway 172.94.28.225,topology subnet,ping 10,ping-restart 120,ifconfig 172.94.28.228 255.255.255.224,peer-id 2,cipher AES-256-GCM’
Fri Mar 4 17:59:39 2022 OPTIONS IMPORT: timers and/or timeouts modified
Fri Mar 4 17:59:39 2022 OPTIONS IMPORT: compression parms modified
Fri Mar 4 17:59:39 2022 OPTIONS IMPORT: —sndbuf/—rcvbuf options modified
Fri Mar 4 17:59:39 2022 Socket Buffers: R=[212992->425984] S=[212992->425984]
Fri Mar 4 17:59:39 2022 OPTIONS IMPORT: —ifconfig/up options modified
Fri Mar 4 17:59:39 2022 OPTIONS IMPORT: route options modified
Fri Mar 4 17:59:39 2022 OPTIONS IMPORT: route-related options modified
Fri Mar 4 17:59:39 2022 OPTIONS IMPORT: —ip-win32 and/or —dhcp-option options modified
Fri Mar 4 17:59:39 2022 OPTIONS IMPORT: peer-id set
Fri Mar 4 17:59:39 2022 OPTIONS IMPORT: adjusting link_mtu to 1625
Fri Mar 4 17:59:39 2022 OPTIONS IMPORT: data channel crypto options modified
Fri Mar 4 17:59:39 2022 Data Channel: using negotiated cipher ‘AES-256-GCM’
Fri Mar 4 17:59:39 2022 Outgoing Data Channel: Cipher ‘AES-256-GCM’ initialized with 256 bit key
Fri Mar 4 17:59:39 2022 Incoming Data Channel: Cipher ‘AES-256-GCM’ initialized with 256 bit key
Fri Mar 4 17:59:39 2022 ROUTE_GATEWAY 172.18.0.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:12:00:08
Fri Mar 4 17:59:39 2022 TUN/TAP device tun0 opened
Fri Mar 4 17:59:39 2022 TUN/TAP TX queue length set to 100
Fri Mar 4 17:59:39 2022 /sbin/ip link set dev tun0 up mtu 1500
Fri Mar 4 17:59:39 2022 /sbin/ip addr add dev tun0 172.94.28.228/27 broadcast 172.94.28.255
Fri Mar 4 17:59:39 2022 /etc/openvpn/tunnelUp.sh tun0 1500 1553 172.94.28.228 255.255.255.224 init
Up script executed with tun0 1500 1553 172.94.28.228 255.255.255.224 init
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 172.94.28.228
Using Combustion UI, overriding TRANSMISSION_WEB_HOME
Updating Transmission settings.json with values from env variables
Using existing settings.json for Transmission /data/transmission-home/settings.json
Overriding bind-address-ipv4 because TRANSMISSION_BIND_ADDRESS_IPV4 is set to 172.94.28.228
Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /data
Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /data/incomplete
Overriding incomplete-dir-enabled because TRANSMISSION_INCOMPLETE_DIR_ENABLED is set to false
Overriding rpc-authentication-required because TRANSMISSION_RPC_AUTHENTICATION_REQUIRED is set to true
Overriding rpc-password because TRANSMISSION_RPC_PASSWORD is set to [REDACTED]
Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091
Overriding rpc-username because TRANSMISSION_RPC_USERNAME is set to ME
Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch
sed’ing True to true
————————————-‘
Transmission will run as
————————————-‘
User name: root
User uid: 0
User gid: 0
————————————-‘
STARTING TRANSMISSION
Transmission startup script complete.
Fri Mar 4 17:59:41 2022 /sbin/ip route add 37.221.173.211/32 via 172.18.0.1
Fri Mar 4 17:59:41 2022 /sbin/ip route add 0.0.0.0/1 via 172.94.28.225
Fri Mar 4 17:59:41 2022 /sbin/ip route add 128.0.0.0/1 via 172.94.28.225
Fri Mar 4 17:59:41 2022 Initialization Sequence Completed

HW/SW Environment

Anything else?

The text was updated successfully, but these errors were encountered:

Источник

Description Zhiqiang Fang 2021-04-17 02:57:42 UTC Description of problem: When IPv4 address contains 08 or 09 or 008 or 009, "ip address add" command fails with error "Error: any valid prefix is expected rather than". Version-Release number of selected component (if applicable): RHEL DISTRO=RHEL-8.3.1-updates-20210330.1 # uname -r 4.18.0-240.22.1.el8_3.x86_64 # rpm -qa | grep iproute iproute-5.3.0-5.el8.x86_64 iproute-tc-5.3.0-5.el8.x86_64 How reproducible: [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.01/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.02/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.03/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.04/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.05/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.06/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.07/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.08/24 dev ens8f0 Error: any valid prefix is expected rather than "1.1.1.08/24". <<<------08 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.09/24 dev ens8f0 Error: any valid prefix is expected rather than "1.1.1.09/24". <<<------09 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.010/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.1.011/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.02.11/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.03.11/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.04.11/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.05.11/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.06.11/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.07.11/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.08.11/24 dev ens8f0 Error: any valid prefix is expected rather than "1.1.08.11/24". <<<------08 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.1.09.11/24 dev ens8f0 Error: any valid prefix is expected rather than "1.1.09.11/24". <<<------09 [root@wsfd-advnetlab36 ls-lr]# [root@wsfd-advnetlab36 ls-lr]# ip a a 1.08.9.11/24 dev ens8f0 Error: any valid prefix is expected rather than "1.08.9.11/24". <<<------08 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.09.9.11/24 dev ens8f0 Error: any valid prefix is expected rather than "1.09.9.11/24". <<<------09 [root@wsfd-advnetlab36 ls-lr]# ip a a 08.8.8.8/24 dev ens8f0 Error: any valid prefix is expected rather than "08.8.8.8/24". <<<------08 [root@wsfd-advnetlab36 ls-lr]# ip a a 09.8.8.8/24 dev ens8f0 Error: any valid prefix is expected rather than "09.8.8.8/24". <<<------09 [root@wsfd-advnetlab36 ls-lr]# ip a a 07.8.8.8/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# [root@wsfd-advnetlab36 ls-lr]# ip a a 1.003.11.11/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.007.11.11/24 dev ens8f0 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.008.11.11/24 dev ens8f0 Error: any valid prefix is expected rather than "1.008.11.11/24". <<<------008 [root@wsfd-advnetlab36 ls-lr]# ip a a 1.009.11.11/24 dev ens8f0 Error: any valid prefix is expected rather than "1.009.11.11/24". <<<------009 Steps to Reproduce: 1. 2. 3. Actual results: Command "ip address add" fails with error "Error: any valid prefix is expected rather than" Expected results: The command can be executed successfully. Additional info: Comment 1 Andrea Claudi 2021-04-17 16:55:06 UTC Hi Zhiqiang, and thanks for reporting this. As far as it can sound strange, this is the expected behaviour of "ip add address". Follow me down the rabbit hole. The function responsible for IPv4 address parsing is get_addr_ipv4(), in lib/utils.c. As you can see, it uses strtoul to parse the IPv4 address from string to four integers, stored in the ap[] array. strtoul returns an unsigned long integer and takes three arguments: a pointer to the string to be parsed, a pointer to store the remainder of the string after the parsing, and the arithmetic base of the unsigned long int to be returned. Now, looking at the man page, if the base is zero, the number is normally parsed in decimal base, unless the string starts with "0x" (in that case the number will be parsed in base 16), or "0" (in that case the number will be parsed in base 8). This is precisely our case: as soon as you put "0" in front of one of the ipv4 address octects, ip takes it as octal. That is the reason why you can parse "07", but not "08", which is meaningless in base 8. Indeed, if you use "011", you will find it working and converted in "9" in the assigned IP address. This seems an obvious issue and trivial to fix, simply replacing "0" in strtoul with "10". However, there is an historical reason for iproute to operate in such way. Many years ago, 4.2BSD introduced the inet_aton function to parse ipv4 addresses, which worked exactly in the same way as iproute: you can specify an IPv4 address using exadecimal or octal notation, and expect it to work flawlessly. That function is now the de facto standard for the textual representation of ipv4 addresses[1], and even if there is a inet_pton POSIX equivalent which only work in base 10, we cannot easily change the behaviour of this function without expecting to break who-knows-how-many scripts out there. For this reason I'm gonna close this as NOTABUG. And thanks for making me discover this interesting story! :) [1] https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02, page 5

Open


Issue created Aug 04, 2020 by Roberto Leinardi@leinardiContributor

Unable to connect to GlobalProtect VPN using Username and PIN + Passcode

Problem description

Unable to connect to company GlobalProtect VPN using OpenConnect client.
Official GlobalProtect Linux client connects correctly.

Step to reproduce

1. run openconnect --protocol=gp vpn.mycompany.com -vvvv --dump-http-traffic --dump --authenticate -u rleinardi --certificate /etc/pki/payback/myhostname.pem
2. entered the PEM pass phrase
3. entered the PIN + Passcode (the passcode is a generated token valid only for 60s)

Expected result

The connection should be established

Actual result

After correctly entering the PIN + Passcode I am asked to authenticate again, this time using a password, but I’m not aware of any password associated to my VPN account: I only and always authenticated using Username and PIN + Passcode.
If I type again my PIN + Passcode instead of the password, the client exit without establishing a connection nor showing a specific error.

Additional info

The official GlobalConnect client version 5.1.5.0-8 is able to successfully establish a connection:

$ globalprotect 
vpn.mycompany.com - Please enter your PIN and Passcode            
username(rleinardi):    
Password:
Retrieving configuration...                                            
Discovering network...                                                 
Connecting...                                                          
Connected

Operating system and openconnect version

openconnect version:

openconnect --version
OpenConnect version v8.10
Using GnuTLS 3.6.14. Features present: TPM, TPMv2, PKCS#11, RSA software token, HOTP software token, TOTP software token, Yubikey OATH, System keys, DTLS, ESP
Supported protocols: anyconnect (default), nc, gp, pulse

operating system

$ lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	Fedora
Description:	Fedora release 32 (Thirty Two)
Release:	32
Codename:	ThirtyTwo

GlobalProtect VPN information

openconnect --protocol=gp vpn.mycompany.com --authenticate -u rleinardi --certificate /etc/pki/payback/myhostname.pem 
POST https://vpn.mycompany.com/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to [::1]:3128
Requesting HTTP proxy connection to vpn.mycompany.com:443
Enter PEM pass phrase:
Using client certificate 'myhostname.mycompany.com'
SSL negotiation with vpn.mycompany.com
Connected to HTTPS on vpn.mycompany.com with ciphersuite (TLS1.2)-(RSA)-(AES-256-GCM)
Please enter your PIN and Passcode
Password: 
POST https://vpn.mycompany.com/global-protect/getconfig.esp
Portal set HIP report interval to 60 minutes).
1 gateway servers available:
  vpn.mycompany.com (vpn.mycompany.com)
Please select GlobalProtect gateway.
GATEWAY: [vpn.mycompany.com]:vpn.mycompany.com
POST https://vpn.mycompany.com/ssl-vpn/login.esp
Got HTTP response: HTTP/1.1 512 Custom error
Unexpected 512 result from server
POST https://vpn.mycompany.com/ssl-vpn/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Enter login credentials
Password: 
POST https://vpn.mycompany.com/ssl-vpn/login.esp
GlobalProtect login returned authentication-source=RSA_RADIUS
GlobalProtect login returned usually-equals-4=4
GlobalProtect login returned usually-equals-unknown=unknown
COOKIE='authcookie=REDACTED&portal=LP_Public-N&user=rleinardi&domain=%28empty_domain%29&computer=myhostname'
HOST='vpn.mycompany.com'
FINGERPRINT='pin-sha256:REDACTED'

Edited Aug 05, 2020 by Roberto Leinardi

EDIT: I have no idea why, but if I connect to NordVPN, then disconnect, my work VPN through openconnect works as it should. I can access all work and non-work sites as intended. Maybe this will shed some light?

As the title states, I’m using openconnect on Ubuntu 20.04 to connect to my work VPN network. I’ve been running the command sudo openconnect <work_vpn_gateway> -u <username> and supplying my password generated from my RSA token for months now, and it’s been just fine.
Recently, however, I’ve been having issues. I’m still able to connect just fine using that above command, but trying to connect to any of the sites that would normally work by being on the VPN now give me the error: DNS_PROBE_FINISHED_NXDOMAIN

I’m going to list as much info as I can, and hopefully someone will point out something which I missed.

If there’s anything else that I could add which could be helpful, please let me know. I need this to function so I can do my work during the day, and I just don’t understand what caused it to suddenly stop working. I did switch from 18.04 LTS to 20.04 LTS about a week ago, but it was working for several days after that.

• This is the actual output of my VPN connect call:

  • $ sudo openconnect <work_vpn_gateway> -u <username>
    
    POST <work_vpn_gateway>
    Connected to 147.21.175.42:443
    SSL negotiation with <work_vpn_gateway>
    Server certificate verify failed: signer not found
    
    Certificate from VPN server "<work_vpn_gateway>" failed verification.
    Reason: signer not found
    To trust this server in future, perhaps add this to your command line:
        --servercert pin-sha256:Q8...noq0qrszE=
    Enter 'yes' to accept, 'no' to abort; anything else to view: yes
    Connected to HTTPS on <work_vpn_gateway>
    XML POST enabled
    Password:
    POST https://<work_vpn_gateway>/
    Got CONNECT response: HTTP/1.1 200 OK
    CSTP connected. DPD 30, Keepalive 20
    Connected as 10.7.91.214, using SSL, with DTLS in progress
    Established DTLS connection (using GnuTLS). Ciphersuite (DTLS0.9)-(RSA)-(AES-256-CBC)-(SHA1).
    Error: any valid prefix is expected rather than "dev".        # I never saw this on 18.04
    **** # ^ This is the end-state of the connect call - I should be able to now access work sites ****
    ^CSend BYE packet: Aborted by caller                          # Manual exit here
    Error: argument "via" is wrong: use nexthop syntax to specify multiple via
    
    RTNETLINK answers: No such process
    User cancelled (SIGINT/SIGTERM); exiting.
    

• My ifconfig off VPN is:

  • docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
       inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
       ether 02:42:4b:9f:73:5c  txqueuelen 0  (Ethernet)
       RX packets 0  bytes 0 (0.0 B)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 0  bytes 0 (0.0 B)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    enp59s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.1.35  netmask 255.255.255.0  broadcast 192.168.1.255
       inet6 2605:e000:150a:d279::1192  prefixlen 128  scopeid 0x0<global>
       inet6 2605:e000:150a:d279:cd37:ecd6:778a:d82c  prefixlen 64  scopeid 0x0<global>
       inet6 2605:e000:150a:d279:6145:5e5f:87ec:82e2  prefixlen 64  scopeid 0x0<global>
       inet6 2605:e000:150a:d279:5a6:71cd:fffb:ff1e  prefixlen 64  scopeid 0x0<global>
       inet6 2605:e000:150a:d279:d4f5:9c29:dc90:1ad7  prefixlen 64  scopeid 0x0<global>
       inet6 2605:e000:150a:d279:9028:f45d:3ce:ea0c  prefixlen 64  scopeid 0x0<global>
       inet6 fe80::a487:d33c:c51:409  prefixlen 64  scopeid 0x20<link>
       inet6 2605:e000:150a:d279:89d5:b1fd:857c:384e  prefixlen 64  scopeid 0x0<global>
       ether 30:9c:23:8e:fd:ce  txqueuelen 1000  (Ethernet)
       RX packets 18734  bytes 10635469 (10.6 MB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 15361  bytes 2864576 (2.8 MB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
       device interrupt 17  
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
       inet 127.0.0.1  netmask 255.0.0.0
       inet6 ::1  prefixlen 128  scopeid 0x10<host>
       loop  txqueuelen 1000  (Local Loopback)
       RX packets 213  bytes 17919 (17.9 KB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 213  bytes 17919 (17.9 KB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    wlo1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.1.17  netmask 255.255.255.0  broadcast 192.168.1.255
       inet6 fe80::75ad:b71b:40c:9240  prefixlen 64  scopeid 0x20<link>
       inet6 2605:e000:150a:d279:c527:a9fb:322e:51cf  prefixlen 64  scopeid 0x0<global>
       inet6 2605:e000:150a:d279::19a5  prefixlen 128  scopeid 0x0<global>
       inet6 2605:e000:150a:d279:502d:e2e9:87ef:e856  prefixlen 64  scopeid 0x0<global>
       ether d4:6d:6d:3e:1f:7a  txqueuelen 1000  (Ethernet)
       RX packets 2963  bytes 970984 (970.9 KB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 847  bytes 139316 (139.3 KB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0```
    
    

• When I connect to VPN, this is added to my ifconfig output

  • tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1406
       inet 10.7.91.182  netmask 255.255.255.255  destination 10.7.91.182
       inet6 fe80::95d8:44b6:3061:37fe  prefixlen 64  scopeid 0x20<link>
       unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
       RX packets 14  bytes 1882 (1.8 KB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 29  bytes 2472 (2.4 KB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    

• My /etc/resolv.conf off VPN:

  • # This file is managed by man:systemd-resolved(8). Do not edit.
    #
    # This is a dynamic resolv.conf file for connecting local clients directly to
    # all known uplink DNS servers. This file lists all configured search domains.
    #
    # Third party programs must not access this file directly, but only through the
    # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
    # replace this symlink by a static file or a different symlink.
    #
    # See man:systemd-resolved.service(8) for details about the supported modes of
    # operation for /etc/resolv.conf.
    
    nameserver 192.168.1.1
    search lan
    

• My /etc/resolv.conf when connected:

  • # This file is managed by man:systemd-resolved(8). Do not edit.
    #
    # This is a dynamic resolv.conf file for connecting local clients directly to
    # all known uplink DNS servers. This file lists all configured search domains.
    #
    # Third party programs must not access this file directly, but only through the
    # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
    # replace this symlink by a static file or a different symlink.
    #
    # See man:systemd-resolved.service(8) for details about the supported modes of
    # operation for /etc/resolv.conf.
    
    nameserver 192.168.1.1
    nameserver 147.22.178.40
    nameserver 147.22.179.9
    search lan directv.com
    

• Result of ls -al /etc/resolv.conf:

  • lrwxrwxrwx 1 root root 32 Jun 22 11:41 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

• Ouput of systemd-resolve --status off VPN:

  • Global
            LLMNR setting: no                  
    MulticastDNS setting: no                  
       DNSOverTLS setting: no                  
           DNSSEC setting: no                  
         DNSSEC supported: no                  
    Current DNS Server: 192.168.1.1         
            DNS Servers: 192.168.1.1         
            DNS Domain: lan                 
         DNSSEC NTA: 10.in-addr.arpa     
                     16.172.in-addr.arpa 
                     168.192.in-addr.arpa
                     17.172.in-addr.arpa 
                     18.172.in-addr.arpa 
                     19.172.in-addr.arpa 
                     20.172.in-addr.arpa 
                     21.172.in-addr.arpa 
                     22.172.in-addr.arpa 
                     23.172.in-addr.arpa 
                     24.172.in-addr.arpa 
                     25.172.in-addr.arpa 
                     26.172.in-addr.arpa 
                     27.172.in-addr.arpa 
                     28.172.in-addr.arpa 
                     29.172.in-addr.arpa 
                     30.172.in-addr.arpa 
                     31.172.in-addr.arpa 
                     corp                
                     d.f.ip6.arpa        
                     home                
                     internal            
                     intranet            
                     lan                 
                     local               
                     private             
                     test                
    
                         Link 4 (docker0)
                     Current Scopes: none
               DefaultRoute setting: no  
                      LLMNR setting: yes 
               MulticastDNS setting: no  
                 DNSOverTLS setting: no  
                     DNSSEC setting: no  
                   DNSSEC supported: no  
    
                            Link 3 (wlo1)
              Current Scopes: DNS        
        DefaultRoute setting: yes        
               LLMNR setting: yes        
        MulticastDNS setting: no         
          DNSOverTLS setting: no         
              DNSSEC setting: no         
            DNSSEC supported: no         
          Current DNS Server: 192.168.1.1
                 DNS Servers: 192.168.1.1
                  DNS Domain: ~.         
                              lan        
    
                         Link 2 (enp59s0)
              Current Scopes: DNS        
        DefaultRoute setting: yes        
               LLMNR setting: yes        
        MulticastDNS setting: no         
          DNSOverTLS setting: no         
              DNSSEC setting: no         
            DNSSEC supported: no         
          Current DNS Server: 192.168.1.1
                 DNS Servers: 192.168.1.1
                  DNS Domain: ~.         
                                      lan
    

• When I connect to VPN, only thing that changes is the following is added to output of systemd-resolve --status:

  • Link 12 (tun0)
       Current Scopes: DNS           
    DefaultRoute setting: yes           
            LLMNR setting: yes           
    MulticastDNS setting: no            
       DNSOverTLS setting: no            
           DNSSEC setting: no            
         DNSSEC supported: no            
    Current DNS Server: 147.22.116.240
            DNS Servers: 147.22.116.240
                         147.22.117.9  
             DNS Domain: directv.com
    

• My /etc/NetworkManager/NetworkManager.conf:

  • [main]
    plugins=ifupdown,keyfile
    
    [ifupdown]
    managed=true
    
    [device]
    wifi.scan-rand-mac-address=no
    

• On a fresh restart of systemd-resolved (sudo systemctl restart systemd-resolved) and looking at its status, nothing seems out of sorts. But when I connect to VPN (or try to access any of the work sites, even off VPN) the following shows up a bunch of times in sudo systemctl status systemd-resolved:

  • systemd-resolved[16885]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

Thank you for any help you can provide!

Based on the answer from @ktaka I don’t recommend using ip route get to validate IP addresses unless your script depends heavily on the network connection. The reason is because, if your system does not have a good internet connection or is completely disconnected from the internet, then when you use ip route get, your script will always return error code (other than 0) even the IP is correctly defined.

Solution:

I looked up the manual link given by @Rolf Rander and I was confused why my ipcalc binary on Debian 11 does not have the -c option, and also my previous ipcalc binary does not support ipv6. So, I searched on Google the author username taken from the manual page with this keyword dcantrell ipcalc and I got the official link here:

https://gitlab.com/ipcalc/ipcalc

So the above is the official ipcalc that supports both IPv4 and IPv6 IP addresses. To install this, they recommend using the modern build with meson (but they also provided old make build if you don’t want to use meson)

So, this is how I setup ipcalc on Debian 11:

Remove existing ipcalc (the existing version is not good)

apt-get -y remove ipcalc
rm -rf "/usr/bin/ipcalc"

Now install ipcalc from the official repo here:

apt -y install meson
git clone https://gitlab.com/ipcalc/ipcalc.git
cd ipcalc
meson setup build --buildtype=release
ninja -C build
cp build/ipcalc /usr/bin
apt -y remove meson

ipcalc --version

1.0.1

Now you can use this ipcalc to check both IPv4 and IPv6:

#!/bin/bash
IP="1.1.1.1"
if ipcalc -s -c $IP; then
  echo "valid IPv4 or IPv6"
else
  echo "Invalid IPv4 or Ipv6"
fi

The -s is to ignore error message, the -c is for checking without output

If you want to check specific IPv4 use -4 or use -6 to check IPv6. Example:

#!/bin/bash

# IP is a valid IPv6
IP="::1"

# But we want to check only IPv4

if ipcalc -s -4 -c $IP; then
  echo "valid IPv4"
else
  echo "Invalid IPv4"
fi

Output:

Invalid IPv4

I have been using sipcalc and ipv6calc long time ago and they can do both IPv4 and IPv6 checking, but I do like more on ipcalc because most of the output are simple and it has json output for other purposes.

EDIT

(23/10/2022):

Based on the latest comment from @ktaka, my main point was that when using ip route get without internet connection like below:

$ ip route get 192.168.0.255 ; echo $?
RTNETLINK answers: Network is unreachable
2

it is not going to return a valid IP if your system is behind firewall or you have a bad connection. The IP is valid, and it should return the success code of 0, instead of telling unnecessary things like unreachable network.

• #1

Hello all,

I have a couple of separate Proxmox clusters using Ceph, and both won’t allow me to create OSDs at the moment:

# pveceph createosd /dev/sdd
Error: any valid prefix is expected rather than «».
command ‘/sbin/ip address show to » up’ failed: exit code 1

Testing ‘ip address show’ with the correct node IP does return the correct detail. Any pointers to where I can troubleshoot next would be appreciated. The cluster’s health seems otherwise fine, as is «pveceph lspools», «ceph status» etc. There seems to be something particular about creating an OSD that cares about the hostname/ip address.

Thank you,
Chris

proxmox-ve: 6.1-2 (running kernel: 5.3.13-1-pve)
pve-manager: 6.1-5 (running version: 6.1-5/9bf06119)
pve-kernel-5.3: 6.1-1
pve-kernel-helper: 6.1-1
pve-kernel-5.0: 6.0-11
pve-kernel-4.15: 5.4-6
pve-kernel-5.3.13-1-pve: 5.3.13-1
pve-kernel-5.0.21-5-pve: 5.0.21-10
pve-kernel-4.15.18-18-pve: 4.15.18-44
pve-kernel-4.15.18-9-pve: 4.15.18-30
ceph: 14.2.6-pve1
ceph-fuse: 14.2.6-pve1
corosync: 3.0.2-pve4
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.13-pve1
libpve-access-control: 6.0-5
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-10
libpve-guest-common-perl: 3.0-3
libpve-http-server-perl: 3.0-3
libpve-storage-perl: 6.1-3
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve3
lxc-pve: 3.2.1-1
lxcfs: 3.0.3-pve60
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.1-2
pve-cluster: 6.1-3
pve-container: 3.0-18
pve-docs: 6.1-3
pve-edk2-firmware: 2.20191127-1
pve-firewall: 4.0-9
pve-firmware: 3.0-4
pve-ha-manager: 3.0-8
pve-i18n: 2.0-3
pve-qemu-kvm: 4.1.1-2
pve-xtermjs: 3.13.2-1
qemu-server: 6.1-4
smartmontools: 7.1-pve1
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.2-pve2

tim

Proxmox Retired Staff

• #2

Please post your /etc/pve/ceph.conf

• #3

Thanks Tim. I’ve attached.

• ceph.conf.txt

  1 KB

  · Views: 7

tim

Proxmox Retired Staff

• #4

try to add a public network entry to the global section of your ceph.conf:

public_network = {ip-address}/{netmask}

• #5

That’s fixed it, thank you! I’m not sure at what point the missing «public network» became a problem as I did create both clusters and all OSDs originally with the same config, but anyhow, thanks again!