What's new

Voxel Custom firmware build for R9000/R8900 v. 1.0.4.74HF

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Voxel

Part of the Furniture
Continuation of:

https://www.snbforums.com/threads/custom-firmware-build-for-r9000.40125/
. . .
https://www.snbforums.com/threads/custom-firmware-build-for-r9000-r8900-v-1-0-4-72hf.88144/
https://www.snbforums.com/threads/custom-firmware-build-for-r9000-r8900-v-1-0-4-73hf.89539/

New version of my custom firmware build: 1.0.4.74HF.

Changes (vs 1.0.4.73HF):

1. Toolchain: GCC is upgraded 13.2.0->14.1.0.
2. Toolchain: Go is upgraded 1.22.2->1.22.3.
3. dropbear package is upgraded 2022.83->2024.85 (fixing CVE-2023-48795).
(score 5.9. Medium)​
4. unbound package (used in stubby) is upgraded 1.19.3->1.20.0 (fixing CVE-2024-33655).
(score 3.7, Low)​
5. OpenSSL v. 1.1.1 package is upgraded to OpenSSL v. 3.0.x 1.1.1w->3.0.13.
6. curl package is upgraded 8.7.1->8.8.0.
7. libubox package is upgraded 2024-01-26->2024.03.29.
8. libcap-ng package is upgraded 0.8.4->0.8.5.
9. libgpg-error package is upgraded 1.48->1.49.
10. e2fsprogs package is upgraded 1.47.0->1.47.1.
11. iperf3 package is upgraded 3.16->3.17.1.
12. nano package is upgraded 7.2->8.0.
13. pciutils package is upgraded 3.11.1->3.12.0.
14. iw package is upgraded 6.7->6.9.
15. Add 'libatomic' package.
16. Multiple packages: fix compilation by gcc 14.1.0 compiler.
17. Host tools: upgrade e2fsprogs to 1.47.1.
18. Host tools: upgrade UPX to 4.2.4.

The link is:

https://www.voxel-firmware.com (thanks to vladlenas for his help with hosting).

NOTE:
The most important changes in this release are an update of OpenSSL v. 1.1.1 to OpenSSL v. 3.0.x and updating the GCC compiler to version 14.1.0.

Voxel.
 
Last edited:
Hi Voxel, appreciate your work. I've been using your r9000 build for years. I noticed the opkg feed url is currently 404-ing causing opkg update to fail. Is there any other feed that could be used that is still actively maintained?
Thx.

1000028470.jpg
 
Hi Voxel, appreciate your work. I've been using your r9000 build for years. I noticed the opkg feed url is currently 404-ing causing opkg update to fail. Is there any other feed that could be used that is still actively maintained?
Thx.

View attachment 59006
What's your goal? If it is to install packages from Entware, you should call /opt/bin/opkg. According to my README.

In your case you are calling /bin/opkg, which is only used for other purposes.

Voxel.
 
Thanks Voxel, I could've swore I was able to call it directly before. I think it's my mistake because I need to be accessing over SSH and I lost my key so I've been telnetting in the meantime.

My larger goal is to mount my cd/dvd drive over usb, to be picked up as a network share over SMB or SSH for my AppleTV with an app called Infuse (may be far fetched...just testing the waters).

It looks like someone had success mounting with openwrt but I don't think all the kmod packages exist for this platform. I was able to install usbutils, but not sure how to use them...is this possible on this firmware?
 
My larger goal is to mount my cd/dvd drive over usb, to be picked up as a network share over SMB or SSH for my AppleTV with an app called Infuse (may be far fetched...just testing the waters).

Your goal is sufficiently

(1) amusing to me
(2) interesting
(3) has practical application for other firmware users
It looks like someone had success mounting with openwrt but I don't think all the kmod packages exist for this platform. I was able to install usbutils, but not sure how to use them...is this possible on this firmware?

Do not try to solve this goal by such means. It can be solved at the level of firmware kernel reconfiguration.

Try this SnapShot version:


R9000-V1.0.4.74.1HF.log:
1. ethtool package is upgraded 6.7->6.9.
2. Add support for CD/DVD-ROM mounting.

But mounting the CD/DVD-ROM is so far only from the command line (ssh/telnet), something like:

mkdir /mnt/cdrom
mount /dev/sr0 /mnt/cdrom -o utf8


The rest is for your purposes: it's homework for you.

Voxel.
 
So I have a strange problem that has persisted for awhile. I'm not sure exactly which firmware where it all changed but it was I believe when openvpn was updated from 2.3 and beyond. I can connect to the router via openvpn client with TAP but TUN from computer and my phone no longer work. I was sifting through my emails of old smart_phone.ovpn files. There's subtle changes like the cipher being AES-128-CBC back in one of them. So I'm guessing this happened around 2019. Last night I decided to update from 1.0.4.66HF to this newest firmware update. Again tap is no issues and tun is a no go. Changed ports, edited the openvpn script tried different ciphers. Triple checked all the settings. Ports are all good. UDP/TCP neither work.

The error from the log is not much of a help

2024-06-03 10:19:12 us=468000 TCP: connect to [AF_INET]104.205.240.24:1194 failed: Unknown error
2024-06-03 10:19:12 us=468000 SIGUSR1[connection failed(soft),init_instance] received, process restarting
2024-06-03 10:19:12 us=468000 MANAGEMENT: >STATE:1717431552,RECONNECTING,init_instance,,,,,

Any help and ideas would be greatly appreciated!
 
I can connect to the router via openvpn client with TAP but TUN from computer and my phone no longer work. I was sifting through my emails of old smart_phone.ovpn files. There's subtle changes like the cipher being AES-128-CBC back in one of them.

I tested again the OpenVPN server on R9000 with TUN smartphone adapter. Everything works without any problems. I connected to the router, all pings work.

From the log of client:

. . .
2024-06-05 12:45:59 us=343000 ciphername = 'CHACHA20-POLY1305'
. . .
2024-06-05 12:46:00 us=656000 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 1024 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
. . .

Note the cipher used: it is CHACHA20_POLY1305.

Using AES-128-CBC in the old configs you found is not correct. You need to download a new smartphone config from the WebGUI of your R9000.

Voxel.
 
Yes, for sure that was more of a reference to when this stopped working for me. I'm using the new configs

This is the smart_phone.ovpn with certificates removed.

client
dev tun
proto udp4
remote fudgie.myvnc.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
<ca>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</ca>
<cert>
Certificate:


-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----

-----END RSA PRIVATE KEY-----
</key>
CHACHA20-POLY1305
data-ciphers CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
compress lz4-v2
verb 7
 
Your config is similar to mine with differences:

I use port 12973 (default) and verb level 5 (default).

You are using port 1194, which is known as the port for OpenVPN and is widely used around the world. It is probably blocked somewhere on purpose on the path from the client to the server.

In general, a tip: try your config for a smartphone 'as is' on say a Windows PC as a client and see the connection process with logs.

Voxel.
 
I only changed the port recently, i used to always use 12976 TCP, so then I went TCP 1194, didn't work then I tried UDP lately. My work computer I can connect via tap, when I try the tun connection its just no go. Same time out as the phone.

Below is on the computer. Basically the exact output i get from my phone. And I just switched to port 12973 .

Wed Jun 5 13:31:31 2024 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Wed Jun 5 13:31:31 2024 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1535,tun-mtu 1500,proto UDPv4,comp-lzo,cipher CHACHA20-POLY1305,auth [null-digest],keysize 256,key-method 2,tls-client'
Wed Jun 5 13:31:31 2024 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1535,tun-mtu 1500,proto UDPv4,comp-lzo,cipher CHACHA20-POLY1305,auth [null-digest],keysize 256,key-method 2,tls-server'
Wed Jun 5 13:31:31 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]104.205.240.24:12973
Wed Jun 5 13:31:31 2024 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Jun 5 13:31:31 2024 UDPv4 link local: (not bound)
Wed Jun 5 13:31:31 2024 UDPv4 link remote: [AF_INET]104.205.240.24:12973
Wed Jun 5 13:31:31 2024 MANAGEMENT: >STATE:1717615891,WAIT,,,,,,
Wed Jun 5 13:32:31 2024 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Jun 5 13:32:31 2024 TLS Error: TLS handshake failed
Wed Jun 5 13:32:31 2024 TCP/UDP: Closing socket
Wed Jun 5 13:32:31 2024 SIGUSR1[soft,tls-error] received, process restarting
Wed Jun 5 13:32:31 2024 MANAGEMENT: >STATE:1717615951,RECONNECTING,tls-error,,,,,
 
You have no response from the OpenVPN server, i.e. your R9000, during the handshake attempt.

My log looks the same if:

(1) OpenVPN server is not enabled at all or​
(2) OpenVPN server and OpenVPN client (on the smartphone) have different ports like 1194 on the server and 12973 on the smartphone, or​
(3) The protocol used is UDP on the smartphone and is TCP on your R9000.​

So there is just no connection on UDP port 12973 of your smartphone with your R9000.

You need to carefully check the WebGUI on your R9000, step by step to avoid the above, reboot your R9000, then (if that doesn't help) enter by telnet/ssh into the console of your R9000 and verify that OpenVPN is indeed running

ps | grep openvpn

results should be like this:

1717655823553.png


then there in the console look at the config for your server, this is the file /tmp/openvpn/server_tun.conf

cat /tmp/openvpn/server_tun.conf

And copy/paste this file here.

Voxel.
 
Thanks Voxel. I'm flying today. So I will load up the laptop later. Connect via tap, I have telnet enabled already and I will post as you requested and post the results of both.
 
You have no response from the OpenVPN server, i.e. your R9000, during the handshake attempt.

My log looks the same if:

(1) OpenVPN server is not enabled at all or​
(2) OpenVPN server and OpenVPN client (on the smartphone) have different ports like 1194 on the server and 12973 on the smartphone, or​
(3) The protocol used is UDP on the smartphone and is TCP on your R9000.​

So there is just no connection on UDP port 12973 of your smartphone with your R9000.

You need to carefully check the WebGUI on your R9000, step by step to avoid the above, reboot your R9000, then (if that doesn't help) enter by telnet/ssh into the console of your R9000 and verify that OpenVPN is indeed running

ps | grep openvpn

results should be like this:

View attachment 59233

then there in the console look at the config for your server, this is the file /tmp/openvpn/server_tun.conf

cat /tmp/openvpn/server_tun.conf

And copy/paste this file here.

Voxel.
ok got connected. Rebooted router.

Seems the tun adapter is not up


8213 root 4060 S /usr/sbin/openvpn /tmp/openvpn/server_tap.conf
31372 root 368 S grep openvpn



root@R9000:/$ cat /tmp/openvpn/server_tun.conf
dh /tmp/openvpn/dh1024.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/server.crt
key /tmp/openvpn/server.key
server 10.0.1.0 255.255.255.0
dev tun21
proto udp4
port 12973
keepalive 10 120
verb 7
mute 5
log-append /tmp/openvpn_tun_log
writepid /tmp/openvpnd_tun.pid
status /tmp/openvpnd_tun.status
mtu-disc yes
topology subnet
script-security 2
cipher AES-128-CBC
data-ciphers CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
auth sha1
tls-server
client-to-client
duplicate-cn
remote-cert-tls server
reneg-sec 0
disable-occ
compress lz4-v2
push "compress lz4-v2"
fast-io
push "dhcp-option DNS 10.0.0.1"
client-connect "/tmp/openvpn/push_routing_rule tun"
sndbuf 786432
rcvbuf 786432
push "sndbuf 786432"
push "rcvbuf 786432"
 
dev tun21
cipher AES-128-CBC
tls-server
remote-cert-tls server
reneg-sec 0
disable-occ

These lines are different from what the /etc/init.d/openvpn script creates in my firmware.

It is especially wrong to use tun21 instead of tun0, because it is implied that tun0 is what will be created and there are certain rules for it in the firmware programs and scripts, but not for tun21.

Also, I was talking about

cipher CHACHA20-POLY1305

and you have

cipher AES-128-CBC

It looks like you are using your own custom script /etc/init.d/openvpn which is the cause of the OpenVPN TUN issues.

I have no idea how you have it implemented, but your own changes are the cause of the issue.

Fix your erroneous changes or just delete them and everything should work.

Voxel.
 
We may have a misunderstanding. The changes I have been making are only these past few days trying to figure out the issue. The last few versions this hasn't been working 1.0.4.15, 1.0.4.50 1.0.4.66 and the current. I don't always update to each firmware change.

I will revert everything back to how it was and try again.
 
Back to square one. here's the outputs

root@R9000:/$ ps | grep openvpn
15666 root 3984 S /usr/sbin/openvpn /tmp/openvpn/server_tap.conf
15667 root 3240 S /usr/sbin/openvpn /tmp/openvpn/server_tun.conf
19802 root 368 S grep openvpn


root@R9000:/$ cat /tmp/openvpn/server_tun.conf
dh /tmp/openvpn/dh1024.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/server.crt
key /tmp/openvpn/server.key
server 10.0.1.0 255.255.255.0
dev tun0
proto udp4
port 12973
keepalive 10 120
verb 5
mute 5
log-append /tmp/openvpn_tun_log
writepid /tmp/openvpnd_tun.pid
status /tmp/openvpnd_tun.status
mtu-disc yes
topology subnet
script-security 2
cipher CHACHA20-POLY1305
data-ciphers CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
auth sha1
#tls-server
#tls-client
client-to-client
duplicate-cn
remote-cert-tls server
compress lz4-v2
push "compress lz4-v2"
fast-io
push "dhcp-option DNS 10.0.0.1"
client-connect "/tmp/openvpn/push_routing_rule tun"
sndbuf 786432
rcvbuf 786432
push "sndbuf 786432"
push "rcvbuf 786432"

and the smart_phone.ovpn with certs removed

client
dev tun
proto udp4
remote fudgie.myvnc.com 12973
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
<ca>

</ca>
<cert>


</cert>
<key>

</key>
cipher CHACHA20-POLY1305
data-ciphers CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
compress lz4-v2
verb 5


Trying to connect on the laptop heres the end of the log

Fri Jun 07 14:04:26 2024 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Fri Jun 07 14:04:26 2024 MANAGEMENT: >STATE:1717790666,RESOLVE,,,,,,
Fri Jun 07 14:04:26 2024 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Fri Jun 07 14:04:26 2024 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1535,tun-mtu 1500,proto UDPv4,comp-lzo,cipher CHACHA20-POLY1305,auth [null-digest],keysize 256,key-method 2,tls-client'
Fri Jun 07 14:04:26 2024 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1535,tun-mtu 1500,proto UDPv4,comp-lzo,cipher CHACHA20-POLY1305,auth [null-digest],keysize 256,key-method 2,tls-server'
Fri Jun 07 14:04:26 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]104.205.240.24:12973
Fri Jun 07 14:04:26 2024 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Jun 07 14:04:26 2024 UDPv4 link local: (not bound)
Fri Jun 07 14:04:26 2024 UDPv4 link remote: [AF_INET]104.205.240.24:12973
Fri Jun 07 14:04:26 2024 MANAGEMENT: >STATE:1717790666,WAIT,,,,,,
Fri Jun 07 14:05:26 2024 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Jun 07 14:05:26 2024 TLS Error: TLS handshake failed
Fri Jun 07 14:05:26 2024 TCP/UDP: Closing socket
Fri Jun 07 14:05:26 2024 SIGUSR1[soft,tls-error] received, process restarting
Fri Jun 07 14:05:26 2024 MANAGEMENT: >STATE:1717790726,RECONNECTING,tls-error,,,,,
Fri Jun 07 14:05:26 2024 Restart pause, 5 second(s)
Fri Jun 07 14:05:31 2024 Re-using SSL/TLS context
Fri Jun 07 14:05:31 2024 LZ4v2 compression initializing
Fri Jun 07 14:05:31 2024 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Fri Jun 07 14:05:31 2024 MANAGEMENT: >STATE:1717790731,RESOLVE,,,,,,
Fri Jun 07 14:05:31 2024 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Fri Jun 07 14:05:31 2024 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1535,tun-mtu 1500,proto UDPv4,comp-lzo,cipher CHACHA20-POLY1305,auth [null-digest],keysize 256,key-method 2,tls-client'
Fri Jun 07 14:05:31 2024 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1535,tun-mtu 1500,proto UDPv4,comp-lzo,cipher CHACHA20-POLY1305,auth [null-digest],keysize 256,key-method 2,tls-server'
Fri Jun 07 14:05:31 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]104.205.240.24:12973
Fri Jun 07 14:05:31 2024 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Jun 07 14:05:31 2024 UDPv4 link local: (not bound)
Fri Jun 07 14:05:31 2024 UDPv4 link remote: [AF_INET]104.205.240.24:12973
Fri Jun 07 14:05:31 2024 MANAGEMENT: >STATE:1717790731,WAIT,,,,,,


on my cell phone getting the same timeout.

I also noticed that the port for the TAP service is open when I check with nmap and the tun service is filtered. I swapped the ports around just to see if the same was the case (it was) and then put them back to how they were.
 
Last edited:
I will revert everything back to how it was and try again.
You have not been successful in this unfortunately.

Your custom changes to server_tun.conf

1717832332154.png



What did you add that line for? With this additional option in the OpenVPN server configuration, my client-server connection fails as well.
Remove your changes in the config generation for the server please.

P.S.

This discussion already looks like it has nothing to do with firmware, sorry. I would suggest you to create a separate thread.
Other users may think that this version contains bug on my part, which I do not believe to be true.

Voxel.
 
Last edited:
remote-cert-tls

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions

The replacement option, --remote-cert-tls is a macro which sets the --remote-cert-ku and --remote-cert-eku to appropriate values, depending on whether you to check if the remote provided certificate is a server certificate or client certificate.

I can't say that I'm an OpenVPN expert, but by using this option for the OpenVPN server, unless I'm mistaken, you are requiring that OpenVPN clients have server certificates, not client certificates. Which is not right.

Voxel.
 
Thanks Voxel. I appreciate you looking into this for me. I will start a new thread as even with those lines removed it's still unresolved and I'm just timing out trying to connect.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top