Posted: Sat Apr 17, 2021 9:30 Post subject: New Build - 04/17/2021 - r46380
[WARNING]: This thread is only for feedback on this beta release for developers and the community's benefit.
DO NOT flash this beta release unless you understand the risks involved and device specificrecovery methods.
Avoid discussions! Create threads for questions, general problems or use search; this thread is not for support.
Please list router model & revision, operating & wireless mode(s) and exact filename/firmware image flashed.
Issues:
• Show us your findings with steps to reproduce, configuration, output, logs and important information below!
Important:
• For issues provide applicable info: 'dmesg', 'cat /tmp/var/log/messages', syslog, klog, serial, strace, tcpdump, wireshark etc.
• Any firewall NAT or WAN issues, show output: 'iptables -vnL', 'iptables -t nat -vnL', 'iptables -t mangle -vnL' and /tmp/.ipt file.
• Search SVN tickets & discuss in forum before opening. Before reporting: reset & manually set up, not restore from a backup.
• Please include operating & wireless modes (e.g. Gateway, Router, AP, CB, WDS, Mesh) & relevant configuration information.
Upgraded: DD-WRT v3.0-r46329
Reset: No not this time
Status: Up and running for 24 hours, basic setup as Gateway, static leases, 2.4 GHz and 5 GHz working (vanilla firmware), OpenVPN client and OpenVPN server working, WireGuard client and Server working
Status: Working Fine running vanilla firmware type for 2.4ghz & 5ghz, Samba Share still needs user, Guest access not working
Just updated the build, will update if any errors are observed.
android not connecting to 5ghz AC/n mixed on dd-wrt, channel 40 domain India. Changing setting to vanilla enables all android devices to connect. rest all setting from guides by egc & msoengineer.
Thank you BrainSlayer for Wonderful firmware.
Netgear WNDR3700 V4
DD-WRT v3.0-r46380 std (04/17/21)
Linux 3.18.140-d5 #113227 Sat Apr 17 04:33:51 +07 2021 mips
GUI install over r45735 / no reset
used as switch / OVPN server / samba share 32GB ext4 --- all ok
uptime 5:51
Router/Version: Netgear XR500
Current firmware: DD-WRT v3.0-r46380 std (04/17/21)
File/Kernel: Linux 4.9.265 #133 SMP Sat Apr 17 00:48:49 +07 2021 armv7l
Previous: r46329 (04/13/21)
Upgrade method: cli
Reset: Did not reset
Mode/Status: Success, so far so good
Issues/Errors: None as of yet
Linksys EA8500
DD-WRT v3.0-r46380 std (04/17/21)
Linux 4.9.265 #131 SMP Fri Apr 16 16:38:08 +07 2021 armv7l
GUI install over r44786 ... no reset and surprised all startup commands & firewall is entacted and worky fine
used as switch / OVPN server / samba share 16GB ext4 --- all ok
VLAN on two wired ports and only reason DNSMasq is enabled - Additional Dnsmasq Options =
interface=vlan15
dhcp-option=vlan15,3,192.168.1.5
dhcp-range=vlan15,192.168.1.6,192.168.1.10,255.255.255.0,12h
mainly used to tinker with broken routers thats why its 192.168.1.x subnet
all else in DNSMasq is disabled ... setup just like a WAP with guest net
------------
played a bit with its 5GHz radio set to:
Firmware Type: VANILLA
AC/N-Mixed
Wide HT40
CH: 48 ...Lower
WiFi SweetSpots on moto edge+ phone shows 383~400 Mbps
../Status_Wireless.asp shows TX & RX at 400 ...so guess it's ok
prolly put on main EA8500 soon.
Router: TL-WDR3600 v1
Firmware: tl-wdr3600_us-webflash.bin (v3.0-r46380 std)
Kernel: Linux 3.10.108-d10 #78633 Sat Apr 17 02:30:13 +07 2021 mips
Status: working
Reset: No
Notes on configuration:
Client
Errors:
1. 5Ghz wireless light is not on (2.4Ghz light works)
Router Model / Version: Linksys EA8500
Previous Firmware:DD-WRT v3.0-r46329 std (04/13/21)
Current Firmware: DD-WRT v3.0-r46380 std (04/17/21)
Kernel: Linux 4.9.265 #131 SMP Fri Apr 16 16:38:08 +07 2021 armv7l
Reset: No
Mode: Wireless - Client, Operating - Gateway
Setup: SFE, NTP, DDNS (inadyn-Entware), DNSMasq (GUI+ additional options on USB, Syslog, SSH,FreeRadius, Telnet, USB, ProFTPD (with users), Samba (with users), CoovaChilli (with local users & radius), WiFiDog, Remote Access (HTTPS & SSH), Startup Script (For DNSMasq & inadyn)
Uptime: up 3 days, 7:31, load average: 0.00, 0.00, 0.00
Temperature: CPU 55.539 °C / wlan0 47 °C / wlan1 48 °C
Status: OK
Issues: I'm having an issue with runnig WiFiDog successfully. By default the "SSL PeerVerification" parameter is enabled and is looking for certs to verify the auth server in the "/etc/ssl/certs/" directory which doesn't exist. To troubleshoot I modified the "SSLCertPath" parameter to "/jffs/etc/ssl/certs/" and copied the cert from my auth server and placed it in the same directory. I still received the same error as below in my debug log.
For reference I'm including the parameters that are responsible for this below.
a) The parameter is enabled by default which causes the WifiDog client not to connect with the auth server and
b) When trying to configure the right information for the parameter it still doesn't seem to work.
For my second point the mistake can be mine as I might not have named the certificate correctly. The WifiDog Client requires that I name the certificate using its hash value.
I'm able to resolve the issue by specifically adding the "SSLPeerVerification No" parameter in the config file. Withouth this the WifiDog client will not start successfully.
Tickets(#7395,#7396,#7397) related to the WiFiDog Client from last build (r46329) have been fixed. Please see my post for that build for details and links to the tickets.
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Wed Apr 21, 2021 17:27 Post subject:
your config does not contain the cert path. so config is wrong _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Thanks for your response BS. I didn't include the config file with the modifications, I only inlcuded the default config file which was giving the error in the log. I had mentioned that I modified my config file in my post but still received the same results. My apologies for not including the modified config file. Please see below.
FirewallRuleSet validating-users {
FirewallRule allow to 0.0.0.0/0
}
FirewallRuleSet known-users {
FirewallRule allow to 0.0.0.0/0
}
FirewallRuleSet unknown-users {
FirewallRule allow udp port 53
FirewallRule allow tcp port 53
FirewallRule allow udp port 67
FirewallRule allow tcp port 67
}
FirewallRuleSet locked-users {
FirewallRule block to 0.0.0.0/0
}
Debug Log
Code:
[7][Wed Apr 21 13:41:33 2021][4718](../../src/simple_http.c:160) wolfSSL Context locked
[6][Wed Apr 21 13:41:33 2021][4718](../../src/simple_http.c:200) Loading SSL certificates from /jffs/etc/ssl/certs/
[3][Wed Apr 21 13:41:33 2021][4718](../../src/simple_http.c:203) Could not load SSL certificates (error -244)
[3][Wed Apr 21 13:41:33 2021][4718](../../src/simple_http.c:207) Make sure that SSLCertPath points to the correct path in the config file
[3][Wed Apr 21 13:41:33 2021][4718](../../src/simple_http.c:208) Or disable certificate loading with 'SSLPeerVerification No'.
[7][Wed Apr 21 13:41:33 2021][4718](../../src/simple_http.c:210) Unlocking wolfSSL Context
[7][Wed Apr 21 13:41:33 2021][4718](../../src/simple_http.c:210) wolfSSL Context unlocked
[3][Wed Apr 21 13:41:33 2021][4718](../../src/simple_http.c:253) Could not get wolfSSL Context!
[3][Wed Apr 21 13:41:33 2021][4718](../../src/ping_thread.c:185) There was a problem pinging the auth server!
[7][Wed Apr 21 13:41:33 2021][4718](../../src/firewall.c:139) Marking auth server down
I'm also including info on how I named the certificates below. I used the "openssl x509 -noout -fingerprint -sha256 -inform pem -in [certificate-file.crt]" command to generate the fingerprint. I generated the sha-1, sha-256 and md5 fingerprints just to be sure.
Let me know if there is any additional info I can provide.
Update: The config file was correct but I messed up the names of the certificates during copy and paste. Certificate verifications works now! Awesome! My apologies and thanks for the follow-up.
Regarding the other issue I mentioned in my post, can we set the default of the "SSLPeerVerification" to No? Or maybe find some other solution that would allow for this option to be changed. By default it is set to yes and when the WifiDog client starts it looks for the certs in the "/etc/ssl/certs/" directory which doesn't exist. This causes WifiDog not to work. I can only fix this by manually modifying the config file.
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Thu Apr 22, 2021 9:18 Post subject:
okay. i changed the default path to /jffs/etc/certs btw for future versions.
i hope its working now. the original version did not support tls 1.2 which i added in this version. i can also add tls 1.3 support, but it will blow up the code alot _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
okay. i changed the default path to /jffs/etc/certs btw for future versions.
i hope its working now. the original version did not support tls 1.2 which i added in this version. i can also add tls 1.3 support, but it will blow up the code alot
I'll do the test and let you know for the next build. For tls 1.3 I'll get back to you on that. Don't want to blow up anything at the moment. Thanks once again!