OpenVPN server still doesn't launch. Does anyone also encounter this on this build?
<Kong> wrote:
No softether is full of security issues, I have added IPSec much easier to setup, more secure and much faster.
He already say no, and that IPSec is his choice.
Maybe Ipsec is his choice but until now no one could figure out how to make it work.
Well in latest build it is be broken, just tried to setup from scratch, but the busybox change for cp also fucks up freeradius setup ATM. Thus radius is broken right now and therefore ipsec cannot be set up. Other than that the webif help exactly explains how it needs to be setup, it is that simple.
Thank you <kong> for confirming this. I have been trying to get to the user gen-cert part in FreeRadius when experimenting IPSec - it simply freezes the webif. For your info, that process did not work for me even in the 1/3 build — presumably before the BusyBox change.
Do you plan to work around the CP change or wait for BusyBox to fix their release upstream?
Router: Netgear R7000
Firmware: DD-WRT v3.0-r34790M kongac (02/04/2018)
Kernel: Linux 4.4.114 #507 SMP Sun Feb 4 17:22:38 CET 2018 armv7l
Status: Working
Reset: No
Previous: 34780M
Errors: No
CPU Temperature : 48.0 °C / WL0 41.8 °C / WL1 43.8 °C
Working very well :
Router mode : DHCP
STP Disable
DNSMasq
Encrypt DNS
Cache DNSSEC data
Validate DNS Replies (DNSSEC)
Local DNS
No DNS Rebind
Query DNS in Strict Order
SPI Firewall
Usb
Nas, Samba, JFFS2,
MAC Filter
wl0, wl1
Vpn (OpenVPN Client)
Kong and BS: Thanks for all your good work!
without VPN
with VPN
Last edited by Bernadoe on Wed Feb 07, 2018 15:13; edited 4 times in total
OpenVPN server still doesn't launch. Does anyone also encounter this on this build?
<Kong> wrote:
No softether is full of security issues, I have added IPSec much easier to setup, more secure and much faster.
He already say no, and that IPSec is his choice.
Maybe Ipsec is his choice but until now no one could figure out how to make it work.
Well in latest build it is be broken, just tried to setup from scratch, but the busybox change for cp also fucks up freeradius setup ATM. Thus radius is broken right now and therefore ipsec cannot be set up. Other than that the webif help exactly explains how it needs to be setup, it is that simple.
Thank you <kong> for confirming this. I have been trying to get to the user gen-cert part in FreeRadius when experimenting IPSec - it simply freezes the webif. For your info, that process did not work for me even in the 1/3 build — presumably before the BusyBox change.
Do you plan to work around the CP change or wait for BusyBox to fix their release upstream?
I'll just set ENABLE_FEATURE_CP_LONG_OPTIONS in our busybox make rule, for all targets except micro. This way no matter what they do, it will work.
But regarding the 01/03 build, it takes much longer now to create certs unlike previous version, new openssl requires certs with higher crypto strength and creating the certs takes quite some time now, which makes the webif look like it is stuck, but it is not. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Device is AC68U, I'm using wireless repeater mode, the last working build for NTP was 34015.
Try using IP addresses instead of FQDN.
Already tried that
(Also, if that was the problem, the workaround wouldn't work.)
How long did you wait? in bridge mode it is possible, that first round of ntp update will timeout before the connection is up, but since it runs every hour you should see an update later on.
I didn't wait long, because in previous versions always worked at boot without workarounds.
Maybe you could add a delayed first run?
Device is AC68U, I'm using wireless repeater mode, the last working build for NTP was 34015.
Try using IP addresses instead of FQDN.
Already tried that
(Also, if that was the problem, the workaround wouldn't work.)
How long did you wait? in bridge mode it is possible, that first round of ntp update will timeout before the connection is up, but since it runs every hour you should see an update later on.
I didn't wait long, because in previous versions always worked at boot without workarounds.
Maybe you could add a delayed first run?
I have this problem with client Bridge E3000 on BS builds, add the following to startup commands (administration, commands, paste the below commands and save startup), should solve your issue :
Posted: Mon Feb 05, 2018 17:16 Post subject: Re: New Kong's test build: DD-WRT 34790M - 2018/02/04
Just upgraded last night on R8000 for this build and had no issues.
In fact I got my policy routing to work finally thanks to the proper ip {route} binary so I can split route through expressvpn and direct to internet properly.
Also Openvpn server works like a charm for me.
PS I do not use the routers wi-fi
Router: Netgear r8000
Firmware: : DD-WRT v3.0-r34790M kongac (02/04/1
Kernel: Linux 4.4.114 #507 SMP Sun Feb 4 17:22:38 CET 2018 armv7l
Status: Works like a charm!
Reset: never
Errors: none
There is one thing worth noting, but I am not sure if it is related to this build at all.
Usually when you do policy routing everyone says to disable sTP and shortcut forwarding engine.
Well, in my case once policy routing started working ( i.e. I could create rules in this build, vs the generic dd-wrt build which has the crappy ip binary), iMessages and FaceTime stopped working on some laptops routed through the main routing table.
I ended up turning on STP and shortcut fwd on a whim, and it started working.
I find it confusing that some people say that those two don't work with policy routing, though I am perfectly fine with them on and in fact I needed them to get FaceTime and iMessages working on all laptops.
Your reports for Broadcom units are greatly appreciated !
Router:
Firmware:
Kernel:
Status:
Reset:
Errors:
This build thread is for reporting successes and problem with loading this experimental test build. This is important info for developers and users. Always state your hardware and SPECIFIC build (e.g. 29440_NEWD-2_K2.6_mega-nv64k.bin). Do not ask questions about your specific router or how to configure it in this thread; create your own thread to discuss any specific problems you have or need resolved. Please also do not respond to such questions. This thread is to report info, not to seek it. Posts that do not add to understanding this build will be deleted. Make sure you know how to flash properly and the risk before using this build. It is important to adhere to these requirements, to keep this thread from becoming impossibly long and useless. If you don't know what build to flash and how to flash properly and have a means of recovery if things should go wrong, do NOT flash this experimental test build.
Joined: 03 Jan 2017 Posts: 49 Location: Lindau, Germany
Posted: Mon Feb 05, 2018 17:59 Post subject: Re: New Kong's test build: DD-WRT 34790M - 2018/02/04
Router: Netgear R7000 (Router) and R6300v2 (Repeater Bridge)
Firmware: DD-WRT v3.0-r34790M kongac
Kernel: Linux 4.4.114 #507 SMP Sun Feb 4 17:22:38 CET 2018 armv7l
Status: Up and running for 1 day
Reset: No, just ddup --flash-latest from 34015 and reboot
Errors: minidlna is broken
R7000:
Router Mode with DNSMasq and DHCP
SFE enabled for test (not really required for 50 mbit/s)
DNScrypt with several servers, DNSSEC enabled
SPI Firewall with custom settings
USB with HDD and printer, NAS, Samba, miniDLNA (but broken)
wl0, wl1 and guest wlan with second dnsmasq instance and hotspot (chillispot)
VPN server and SSH server
Entware with pixelserv and other nice stuff
custom cron script (logging and dyndns)
R6300v2:
Repeater Bridge in "standard" config
WLAN (5G) seems more stable than the version 34320: The wnce4004 connects again. I will see how the wnce4004 behaves on this version.
I'll just set ENABLE_FEATURE_CP_LONG_OPTIONS in our busybox make rule, for all targets except micro. This way no matter what they do, it will work.
But regarding the 01/03 build, it takes much longer now to create certs unlike previous version, new openssl requires certs with higher crypto strength and creating the certs takes quite some time now, which makes the webif look like it is stuck, but it is not.
Oh, did you you mean it is an intended change on their part? A bit reckless it seems on changing behavior of a common flag like this.
Onto the cert-creation part - I was actually refer strictly to the "User" gen-cert part. The "Server" gen-cert part worked fine (it took a long time, but didn't make the webif unresponsive). The "User" gen-cert part rendered webif unresponsive, and the corresponding 'openssl' process it spawn had kept on going for a whole morning (~4-5 hours) on my R7000 when I killed it (it was using very low CPU% as shown on top though, contrast to the "Server" gen-cert phase where ~50% - presumably one whole core on that unit - was used).
Are you saying the FreeRadius part will work again despite the above observation, with your new BusyBox build?
Joined: 13 Jun 2006 Posts: 1608 Location: SE Michigan USA
Posted: Mon Feb 05, 2018 18:58 Post subject:
Installed r34790 on Netgear r8000. Up for less then 1/2 hour so too soon to know long term.
Router: Netgear r8000
Firmware: DD-WRT v3.0-r34790M kongac (02/04/1
Kernel: Linux 4.4.114 #507 SMP Sun Feb 4 17:22:38 CET 2018 armv7l
Status:Up and running
Reset: no
Errors: A few wireless rx and tx errors at startup it appears. They do not increase during running.
Router: Netgear R7000
Firmware: DD-WRT v3.0-r34790M kongac 02/04/18
Kernel: Linux 4.4.114 #507 SMP Sun Feb 4 17:22:38 CET 2018 armv7l
update: 34780 (~1 day of uptime) --> 34790
status: operational
reset: no
errors: none so far
My setup is very simple: 2.4 GHz only + some physically connected via unmanaged switch + QoS for buffer bloat (WTB/FQ_CODEL). No USB, no VPN, no entware, etc.
Will post back to update after a few days.
uptime: 2 day, 23:08
Received (RX) 569,095 OK, no error
Transmitted (TX) 541,443 OK, no error
Last edited by thunderhead on Thu Feb 08, 2018 19:29; edited 2 times in total
Joined: 18 Feb 2007 Posts: 87 Location: Bern, Switzerland
Posted: Tue Feb 06, 2018 0:30 Post subject: Buffalo WZR-1750DHP
Router: Buffalo WZR-1750DHCP
Firmware: DD-WRT v3.0-r34790M kongac (02/04/18)
Kernel: Linux 4.4.114 #507 SMP Sun Feb 4 17:22:38 CET 2018 armv7l
Status: Up and running
Reset: No
Errors: WAN Connection Type "Mobile Broadband" isn't working anymore (like with 34015M, 34320M, 34780M)
Posted: Tue Feb 06, 2018 2:23 Post subject: Re: New Kong's test build: DD-WRT 34790M - 2018/02/04
Quote:
Just upgraded last night on R8000 for this build and had no issues.
In fact I got my policy routing to work finally thanks to the proper ip {route} binary so I can split route through expressvpn and direct to internet properly.
Also Openvpn server works like a charm for me.
PS I do not use the routers wi-fi
Router: Netgear r8000
Firmware: : DD-WRT v3.0-r34790M kongac (02/04/1
Kernel: Linux 4.4.114 #507 SMP Sun Feb 4 17:22:38 CET 2018 armv7l
Status: Works like a charm!
Reset: never
Errors: none
There is one thing worth noting, but I am not sure if it is related to this build at all.
Usually when you do policy routing everyone says to disable sTP and shortcut forwarding engine.
Well, in my case once policy routing started working ( i.e. I could create rules in this build, vs the generic dd-wrt build which has the crappy ip binary), iMessages and FaceTime stopped working on some laptops routed through the main routing table.
I ended up turning on STP and shortcut fwd on a whim, and it started working.
I find it confusing that some people say that those two don't work with policy routing, though I am perfectly fine with them on and in fact I needed them to get FaceTime and iMessages working on all laptops.
>>>>Let me clarify another thing: I just played with the router and noticed that policy based routing doesn't clear itself if the openvpn connection drops. Every time I apply settings or change something, it adds yet another ip rule to the rule table as it re-established connection to openvpn. All of them point to table 10, and it keeps growing on every reconnect/config reload:
0: from all lookup local
32764: from 192.168.200.128/25 lookup 10
32765: from 192.168.200.128/25 lookup 10
32766: from all lookup main
32767: from all lookup default
and on the above comment Shortcut forwarding keeps turning itself off, and I think it has nothing to do with my iMessages/facetime issues. I think it is just some sort of a routing confusion when I vpn out with a Mac and come back. takes about 20 minutes to start working again it seems.
Posted: Tue Feb 06, 2018 2:35 Post subject: Re: New Kong's test build: DD-WRT 34790M - 2018/02/04
atod-wrt wrote:
Quote:
Just upgraded last night on R8000 for this build and had no issues.
In fact I got my policy routing to work finally thanks to the proper ip {route} binary so I can split route through expressvpn and direct to internet properly.
Also Openvpn server works like a charm for me.
PS I do not use the routers wi-fi
Router: Netgear r8000
Firmware: : DD-WRT v3.0-r34790M kongac (02/04/1
Kernel: Linux 4.4.114 #507 SMP Sun Feb 4 17:22:38 CET 2018 armv7l
Status: Works like a charm!
Reset: never
Errors: none
There is one thing worth noting, but I am not sure if it is related to this build at all.
Usually when you do policy routing everyone says to disable sTP and shortcut forwarding engine.
Well, in my case once policy routing started working ( i.e. I could create rules in this build, vs the generic dd-wrt build which has the crappy ip binary), iMessages and FaceTime stopped working on some laptops routed through the main routing table.
I ended up turning on STP and shortcut fwd on a whim, and it started working.
I find it confusing that some people say that those two don't work with policy routing, though I am perfectly fine with them on and in fact I needed them to get FaceTime and iMessages working on all laptops.
>>>>Let me clarify another thing: I just played with the router and noticed that policy based routing doesn't clear itself if the openvpn connection drops. Every time I apply settings or change something, it adds yet another ip rule to the rule table as it re-established connection to openvpn. All of them point to table 10, and it keeps growing on every reconnect/config reload:
0: from all lookup local
32764: from 192.168.200.128/25 lookup 10
32765: from 192.168.200.128/25 lookup 10
32766: from all lookup main
32767: from all lookup default
and on the above comment Shortcut forwarding keeps turning itself off, and I think it has nothing to do with my iMessages/facetime issues. I think it is just some sort of a routing confusion when I vpn out with a Mac and come back. takes about 20 minutes to start working again it seems.
Ok. Nailed it:
In /tmp/openvpncl/route-down.sh
should add a line like :
ip rule del from `cat /tmp/openvpncl/policy_ips` table 10
think that should fix it.
Question is can I do this myself somehow or it needs to be added to the build?
[works only if one line in policy. may need to write a for loop for multiple lines I suppose]
Posted: Tue Feb 06, 2018 15:21 Post subject: Asus RT-AC68U A1
Router: Asus RT-AC68U (H/W Ver: A1)
Firmware: DD-WRT v3.0-r34790M kongac (02/04/18)
Previous: DD-WRT v3.0-r34320M kongac (01/03/18)
Kernel: Linux 4.4.114 #507 SMP Sun Feb 4 17:22:38 CET 2018 armv7l
Previous: Linux 4.4.109-rc1 #482 SMP Wed Jan 3 15:42:11 CET 2018 armv7l
Status: ok
Reset: no (ddup --flash-latest)
Errors: no
Uptime: 21:03
