OpenWrt Forum Archive

Topic: davidc502 1900ac 3200acm builds

The content of this topic has been archived between 26 Feb 2018 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

Hello David!

How are you?

I just have a small question.
Is it possible to build a firmware with LEDE Stable but jsut upgrade the kernel and use instead Kernel 4.4 with 4.9?
But the rest is the same?
Is it possible and if so and it works I can set it to build the firmware with the 4.9?

Thanks,
Patrik

@davidc502 - mc (MIdnight Commander) hasn't been in the last 2 builds (I'm now running r5422) - possibly longer as I only install it when I need it.

Assuming it didn't break in the build phase, please can we have it back? Pretty please? wink

Thanks

pirretub wrote:
makedir wrote:

No. The 70mbit is already the cap, by the CPU. OpenVPN has cpu0 or 1 capped at 100% at around 70mbit/s, regardless if you put cryptodev in the config or not on this model. I am wondering whats causing this behavior: https://i.imgur.com/SIy1SOH.png not sure if it is related, but it looks like it. The connection with the VPN server stays, but the routing doesnt work anymore (randomly) and leads to timeout on the clients. I have looked on the OpenVPN output with a debug value of 7. It reads/writes to the socket, but it's somehow blocked by the router so the problem seems to be with the NAT (iptables) of this rom. Already open connections also will work on the clients, but no new connections anymore after this happens. Eventually it will timeout though and work again, but this seems to be the TCP timeout value.

Sorry i need to understand this now, first off, are we talking about a WRT3200ACM here or which do you have? I migh have missed that.
What are you saying? That one of the CPU's is always at 100 and the other is whatever is needed to top the connection?
cipher AES-256-CBC, auth SHA512, using cryptodev, without it goes up, but not by much - I'm topping my connection at 93mbit/s (and my connection is 100) and not even using 30%(at least that's what "top" says, 27percent load at full blast) of the CPU here... Without cryptodev i do get 7percent difference. Unless i'm not getting some information. I'm not sure but that's what i'm getting here.
Yes, as i refered i did have exactly the same problem untill i removed those modules and made the iptables rules...
Not sure why, but removing it helped.
Just cat the firewall file and let me take a look maybe i can help? Also cat rt_tables or route and maybe trace a packet? Also cat the OVPN log. First we gotta check that the router traffic is going really throught the VPN. Then think about the rules for the clients to use it over lan.
Maybe this is a little offtopic here in the builds thread, if that's the case i'm sorry.
Thanks

1. no, wrt1200ac
2. no, auth SHA256, cipher AES-128-GCM
3. GCM gives more bandwidth than CBC (is less CPU intensive), same for keysize 128 than 256
4. that cant be true what you say. the wrt3200 is roughly the same CPU than the wrt1200, but like 200MHZ higher clocked, that cant result in 20mbit more and 70% less CPU
5. "Yes, as i refered i did have exactly the same problem" not really? in your first post you said your VPN connection was dropping (TLS handshake issues), mine is 100% stable

Heres my firewall rules for openvpn:

route-up.sh:
ip route flush table $TABLE
ip route add default via $route_vpn_gateway table $TABLE dev $dev
iptables -w -t nat -A POSTROUTING -o $dev -j SNAT --to $ifconfig_local

route-down.sh:
ip route flush table $TABLE
iptables -w -t nat -D POSTROUTING -o $dev -j SNAT --to $ifconfig_local

firewall:
iptables -w -A forwarding_rule -i br-lan -o tun+ -j ACCEPT
iptables -w -t mangle -A PREROUTING -s 10.0.0.0/24 -j MARK --set-mark 2

routing:
ip rule add prio 32764 fwmark 2 table vpn1
ip rule add prio 32763 fwmark 3 table vpn2

davidc502 wrote:

The build finished yesterday afternoon, and I just uploaded to the server.

Nice work! Thank you!

new build running grate. thanks Do we have to have qos and sqm? Can you drop qos and keep sqm I can not think of any reason to use qos over sqm.

brackenhill_mob wrote:

@davidc502 - mc (MIdnight Commander) hasn't been in the last 2 builds (I'm now running r5422) - possibly longer as I only install it when I need it.

+1

I've found a device killing my 3200ACM. It'c Meizu M5c.
I have logread -f running on my ssh session right when device was connected to 5ghz.
A log below

Sun Nov 26 18:18:03 2017 kern.err kernel: [185052.590260] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:03 2017 kern.err kernel: [185052.596314] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:03 2017 kern.err kernel: [185052.600981] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:07 2017 kern.err kernel: [185056.580093] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:07 2017 kern.err kernel: [185056.586058] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:07 2017 kern.err kernel: [185056.590700] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:11 2017 kern.err kernel: [185060.564141] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:11 2017 kern.err kernel: [185060.570131] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:11 2017 kern.err kernel: [185060.574772] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:14 2017 kern.err kernel: [185064.533580] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:14 2017 kern.err kernel: [185064.539565] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:14 2017 kern.err kernel: [185064.544225] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:18 2017 kern.err kernel: [185068.514012] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:18 2017 kern.err kernel: [185068.519980] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:18 2017 kern.err kernel: [185068.524644] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:22 2017 kern.err kernel: [185072.501950] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:22 2017 kern.err kernel: [185072.507920] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:22 2017 kern.err kernel: [185072.512567] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:33 2017 kern.err kernel: [185082.801277] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:33 2017 kern.err kernel: [185082.807259] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:33 2017 kern.err kernel: [185082.811918] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:37 2017 kern.err kernel: [185086.795745] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:37 2017 kern.err kernel: [185086.801740] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:37 2017 kern.err kernel: [185086.806399] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:41 2017 kern.err kernel: [185090.785682] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:41 2017 kern.err kernel: [185090.791680] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:41 2017 kern.err kernel: [185090.796425] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:45 2017 kern.err kernel: [185094.787623] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:45 2017 kern.err kernel: [185094.793613] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:45 2017 kern.err kernel: [185094.798342] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:49 2017 kern.err kernel: [185098.787649] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:49 2017 kern.err kernel: [185098.793687] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:49 2017 kern.err kernel: [185098.798361] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:53 2017 kern.err kernel: [185102.783160] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:18:53 2017 kern.err kernel: [185102.789135] ieee80211 phy1: return code: 0x001d
Sun Nov 26 18:18:53 2017 kern.err kernel: [185102.793797] ieee80211 phy1: timeout: 0x001d
Sun Nov 26 18:18:57 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED f4:37:b7:xx:xx:xx
Sun Nov 26 18:18:57 2017 daemon.info hostapd: wlan1: STA f4:37:b7:xx:xx:xx IEEE 802.11: disassociated due to inactivity
Sun Nov 26 18:18:58 2017 kern.err kernel: [185107.627403] ieee80211 phy1: cmd 0x9143=GetSeqno timed out
Sun Nov 26 18:18:58 2017 kern.err kernel: [185107.632953] ieee80211 phy1: return code: 0x1143
Sun Nov 26 18:18:58 2017 kern.err kernel: [185107.637658] ieee80211 phy1: timeout: 0x1143
Sun Nov 26 18:19:02 2017 kern.err kernel: [185111.635071] ieee80211 phy1: cmd 0x9122=UpdateEncryption timed out
Sun Nov 26 18:19:02 2017 kern.err kernel: [185111.641312] ieee80211 phy1: return code: 0x1122
Sun Nov 26 18:19:02 2017 kern.err kernel: [185111.645951] ieee80211 phy1: timeout: 0x1122
Sun Nov 26 18:19:02 2017 kern.err kernel: [185111.650249] wlan1: failed to remove key (0, f4:37:b7:xx:xx:xx) from hardware (-5)
Sun Nov 26 18:19:02 2017 daemon.info hostapd: wlan1: STA f4:37:b7:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Nov 26 18:19:06 2017 kern.err kernel: [185115.574166] ieee80211 phy1: cmd 0x9125=BAStream timed out
Sun Nov 26 18:19:06 2017 kern.err kernel: [185115.579712] ieee80211 phy1: return code: 0x1125
Sun Nov 26 18:19:06 2017 kern.err kernel: [185115.584352] ieee80211 phy1: timeout: 0x1125
Sun Nov 26 18:19:09 2017 kern.err kernel: [185119.551203] ieee80211 phy1: cmd 0x9125=BAStream timed out
Sun Nov 26 18:19:09 2017 kern.err kernel: [185119.556802] ieee80211 phy1: return code: 0x1125
Sun Nov 26 18:19:09 2017 kern.err kernel: [185119.561459] ieee80211 phy1: timeout: 0x1125
Sun Nov 26 18:19:13 2017 kern.err kernel: [185123.477147] ieee80211 phy1: cmd 0x9143=GetSeqno timed out
Sun Nov 26 18:19:13 2017 kern.err kernel: [185123.482701] ieee80211 phy1: return code: 0x1143
Sun Nov 26 18:19:13 2017 kern.err kernel: [185123.487361] ieee80211 phy1: timeout: 0x1143
Sun Nov 26 18:19:17 2017 kern.err kernel: [185127.472346] ieee80211 phy1: cmd 0x9125=BAStream timed out
Sun Nov 26 18:19:17 2017 kern.err kernel: [185127.477894] ieee80211 phy1: return code: 0x1125
Sun Nov 26 18:19:17 2017 kern.err kernel: [185127.482548] ieee80211 phy1: timeout: 0x1125
Sun Nov 26 18:19:17 2017 kern.alert kernel: [185127.487107] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
Sun Nov 26 18:19:17 2017 kern.alert kernel: [185127.495354] pgd = d4760000

Connection was reset.
makedir wrote:
pirretub wrote:
makedir wrote:

No. The 70mbit is already the cap, by the CPU. OpenVPN has cpu0 or 1 capped at 100% at around 70mbit/s, regardless if you put cryptodev in the config or not on this model. I am wondering whats causing this behavior: https://i.imgur.com/SIy1SOH.png not sure if it is related, but it looks like it. The connection with the VPN server stays, but the routing doesnt work anymore (randomly) and leads to timeout on the clients. I have looked on the OpenVPN output with a debug value of 7. It reads/writes to the socket, but it's somehow blocked by the router so the problem seems to be with the NAT (iptables) of this rom. Already open connections also will work on the clients, but no new connections anymore after this happens. Eventually it will timeout though and work again, but this seems to be the TCP timeout value.

Sorry i need to understand this now, first off, are we talking about a WRT3200ACM here or which do you have? I migh have missed that.
What are you saying? That one of the CPU's is always at 100 and the other is whatever is needed to top the connection?
cipher AES-256-CBC, auth SHA512, using cryptodev, without it goes up, but not by much - I'm topping my connection at 93mbit/s (and my connection is 100) and not even using 30%(at least that's what "top" says, 27percent load at full blast) of the CPU here... Without cryptodev i do get 7percent difference. Unless i'm not getting some information. I'm not sure but that's what i'm getting here.
Yes, as i refered i did have exactly the same problem untill i removed those modules and made the iptables rules...
Not sure why, but removing it helped.
Just cat the firewall file and let me take a look maybe i can help? Also cat rt_tables or route and maybe trace a packet? Also cat the OVPN log. First we gotta check that the router traffic is going really throught the VPN. Then think about the rules for the clients to use it over lan.
Maybe this is a little offtopic here in the builds thread, if that's the case i'm sorry.
Thanks

1. no, wrt1200ac
2. no, auth SHA256, cipher AES-128-GCM
3. GCM gives more bandwidth than CBC (is less CPU intensive), same for keysize 128 than 256
4. that cant be true what you say. the wrt3200 is roughly the same CPU than the wrt1200, but like 200MHZ higher clocked, that cant result in 20mbit more and 70% less CPU
5. "Yes, as i refered i did have exactly the same problem" not really? in your first post you said your VPN connection was dropping (TLS handshake issues), mine is 100% stable

Heres my firewall rules for openvpn:

route-up.sh:
ip route flush table $TABLE
ip route add default via $route_vpn_gateway table $TABLE dev $dev
iptables -w -t nat -A POSTROUTING -o $dev -j SNAT --to $ifconfig_local

route-down.sh:
ip route flush table $TABLE
iptables -w -t nat -D POSTROUTING -o $dev -j SNAT --to $ifconfig_local

firewall:
iptables -w -A forwarding_rule -i br-lan -o tun+ -j ACCEPT
iptables -w -t mangle -A PREROUTING -s 10.0.0.0/24 -j MARK --set-mark 2

routing:
ip rule add prio 32764 fwmark 2 table vpn1
ip rule add prio 32763 fwmark 3 table vpn2

MrGenie wrote:

best encryption I get with
cipher AES-256-CBC
auth none
comp-lzo no
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
this gets me 100Mbps

4- It is possible and i'm not the only one getting this speeds. And yes the CPU load is not 100%, And it is actually far from that.
5-Yes, once i figure out the TLS Auth i did not get internet on the clients. Than when i removed the extras.
Your configs looks fine, have you tried to remove the iptables mods already and only leaving the original?

Hi,
after a while on stock firmware I've decided to test your latest build from 24.11.2017.
I've met some problems:

1. most of my devices cannot connect on 2.4 wireless until I select legacy mode. On N mode only a bunch esp8266 are connecting (with wmm disabled, they cannot connect when wmm is enabled).
Wifi driver is default from the build and cipher is forced AES, everithing else is default.

2. when I try to flash back to stoc firmware i was successful with sysupgrade -n -F .... but there is no intenet on WAN port (ISP dhcp configuration). Flashing back to davidc build wanport works like a charm ...

Can anyone help resolving those issues?

Please excuse my bad english.

Edit:  Forgot to mention that i'm using wrt3200acm EU version.

(Last edited by grubia on 26 Nov 2017, 18:28)

@pirretub when I do a speedtest (speedtest http://speedtest.net/) and have htop opened on the router, cpu (openvpn process) will cap at 100% with a bandwidth of 70mbit/s, regardless if cryptodev used or not). I just had 30 minutes rock stable connections on my laptop, and then, puff... a few minutes ago, all timeouts again happening opening new tabs on chrome. VPN connection is open, no issues. This doesnt seem to be a problem of OpenVPN but with the router (nat, iptables, firewall, whatever).

:screen (openvpn): /usr/sbin/openvpn --config /tmp/ipvanish/fra-a40.ovpn --dev tun0
Sun Nov 26 16:10:16 2017 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6
Sun Nov 26 16:10:16 2017 OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sun Nov 26 16:10:16 2017 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Sun Nov 26 16:10:16 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Nov 26 16:10:17 2017 Initializing OpenSSL support for engine 'cryptodev'
Sun Nov 26 16:10:17 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:17 2017 Socket Buffers: R=[163840->163840] S=[163840->163840]
Sun Nov 26 16:10:17 2017 UDP link local: (not bound)
Sun Nov 26 16:10:17 2017 UDP link remote: [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:17 2017 TLS: Initial packet from [AF_INET]81.171.85.30:1194, sid=88894593 b70725ff
Sun Nov 26 16:10:17 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Nov 26 16:10:17 2017 VERIFY OK: depth=1, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=IPVanish CA, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 VERIFY X509NAME OK: C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 VERIFY OK: depth=0, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', remote='link-mtu 1570'
Sun Nov 26 16:10:17 2017 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-GCM', remote='cipher AES-256-CBC'
Sun Nov 26 16:10:17 2017 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'
Sun Nov 26 16:10:17 2017 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Sun Nov 26 16:10:17 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA
Sun Nov 26 16:10:17 2017 [fra-a40.ipvanish.com] Peer Connection Initiated with [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:18 2017 SENT CONTROL [fra-a40.ipvanish.com]: 'PUSH_REQUEST' (status=1)
Sun Nov 26 16:10:18 2017 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 198.18.0.1,dhcp-option DNS 198.18.0.2,rcvbuf 262144,explicit-exit-notify 5,route-gateway 172.21.32.1,topology subnet,ping 20,ping-restart 40,ifconfig 172.21.32.109 255.255.254.0,peer-id 6'
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: timers and/or timeouts modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: explicit notify parm(s) modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sun Nov 26 16:10:18 2017 Socket Buffers: R=[163840->327680] S=[163840->163840]
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --ifconfig/up options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: route options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: route-related options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: peer-id set
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: adjusting link_mtu to 1625
Sun Nov 26 16:10:18 2017 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 16:10:18 2017 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 16:10:18 2017 TUN/TAP device tun0 opened
Sun Nov 26 16:10:18 2017 TUN/TAP TX queue length set to 100
Sun Nov 26 16:10:18 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Nov 26 16:10:18 2017 /sbin/ifconfig tun0 172.21.32.109 netmask 255.255.254.0 mtu 1500 broadcast 172.21.33.255
Sun Nov 26 16:10:18 2017 Initialization Sequence Completed
Sun Nov 26 17:10:17 2017 TLS: soft reset sec=0 bytes=376258769/-1 pkts=395962/0
Sun Nov 26 17:10:17 2017 VERIFY OK: depth=1, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=IPVanish CA, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 VERIFY X509NAME OK: C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 VERIFY OK: depth=0, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', remote='link-mtu 1570'
Sun Nov 26 17:10:17 2017 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-GCM', remote='cipher AES-256-CBC'
Sun Nov 26 17:10:17 2017 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'
Sun Nov 26 17:10:17 2017 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Sun Nov 26 17:10:17 2017 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 17:10:17 2017 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 17:10:17 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA

You can see, nothing bad happens with the VPN connection. Theres just the 60mins TLS reset, all working fine.

Client config:

client
dev tun
proto udp
remote 81.171.85.30 1194
engine cryptodev
resolv-retry infinite
nobind
persist-key
ca /etc/openvpn/keys/ca.ipvanish.com.crt
auth-user-pass /etc/openvpn/keys/user_ipvanish.auth
verify-x509-name fra-a40.ipvanish.com name
script-security 2
route-noexec
route-up /etc/openvpn/up/route-up.sh
down /etc/openvpn/down/down.sh
comp-lzo no
verb 3
ncp-disable
auth SHA256
cipher AES-128-GCM
keysize 128
tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-DSS-WITH-AES-128-CBC-SHA:TLS-RSA-WITH-AES-128-CBC-SHA

I actually noticed this behavior in the logs of dnsmasq:

Sun Nov 26 18:09:24 2017 daemon.warn odhcpd[1500]: DHCPV6 SOLICIT IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /etc/hosts - 4 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/odhcpd - 2 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq-dhcp[2566]: read /etc/ethers - 0 addresses
Sun Nov 26 18:09:24 2017 daemon.warn odhcpd[1500]: DHCPV6 SOLICIT IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:25 2017 daemon.warn odhcpd[1500]: DHCPV6 REQUEST IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /etc/hosts - 4 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/odhcpd - 3 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq-dhcp[2566]: read /etc/ethers - 0 addresses

It seems to restart iself always a new client/pc boots or connects to wifi...why? It could be that whenever this happens it somehow breaks everything. This wasnt the case in my old OpenWRT build. Can I deactivate this somehow?

(Last edited by makedir on 26 Nov 2017, 18:12)

makedir wrote:

@pirretub when I do a speedtest (speedtest http://speedtest.net/) and have htop opened on the router, cpu (openvpn process) will cap at 100% with a bandwidth of 70mbit/s, regardless if cryptodev used or not). I just had 30 minutes rock stable connections on my laptop, and then, puff... a few minutes ago, all timeouts again happening opening new tabs on chrome. VPN connection is open, no issues. This doesnt seem to be a problem of OpenVPN but with the router (nat, iptables, firewall, whatever).

:screen (openvpn): /usr/sbin/openvpn --config /tmp/ipvanish/fra-a40.ovpn --dev tun0
Sun Nov 26 16:10:16 2017 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6
Sun Nov 26 16:10:16 2017 OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sun Nov 26 16:10:16 2017 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Sun Nov 26 16:10:16 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Nov 26 16:10:17 2017 Initializing OpenSSL support for engine 'cryptodev'
Sun Nov 26 16:10:17 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:17 2017 Socket Buffers: R=[163840->163840] S=[163840->163840]
Sun Nov 26 16:10:17 2017 UDP link local: (not bound)
Sun Nov 26 16:10:17 2017 UDP link remote: [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:17 2017 TLS: Initial packet from [AF_INET]81.171.85.30:1194, sid=88894593 b70725ff
Sun Nov 26 16:10:17 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Nov 26 16:10:17 2017 VERIFY OK: depth=1, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=IPVanish CA, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 VERIFY X509NAME OK: C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 VERIFY OK: depth=0, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', remote='link-mtu 1570'
Sun Nov 26 16:10:17 2017 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-GCM', remote='cipher AES-256-CBC'
Sun Nov 26 16:10:17 2017 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'
Sun Nov 26 16:10:17 2017 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Sun Nov 26 16:10:17 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA
Sun Nov 26 16:10:17 2017 [fra-a40.ipvanish.com] Peer Connection Initiated with [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:18 2017 SENT CONTROL [fra-a40.ipvanish.com]: 'PUSH_REQUEST' (status=1)
Sun Nov 26 16:10:18 2017 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 198.18.0.1,dhcp-option DNS 198.18.0.2,rcvbuf 262144,explicit-exit-notify 5,route-gateway 172.21.32.1,topology subnet,ping 20,ping-restart 40,ifconfig 172.21.32.109 255.255.254.0,peer-id 6'
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: timers and/or timeouts modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: explicit notify parm(s) modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sun Nov 26 16:10:18 2017 Socket Buffers: R=[163840->327680] S=[163840->163840]
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --ifconfig/up options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: route options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: route-related options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: peer-id set
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: adjusting link_mtu to 1625
Sun Nov 26 16:10:18 2017 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 16:10:18 2017 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 16:10:18 2017 TUN/TAP device tun0 opened
Sun Nov 26 16:10:18 2017 TUN/TAP TX queue length set to 100
Sun Nov 26 16:10:18 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Nov 26 16:10:18 2017 /sbin/ifconfig tun0 172.21.32.109 netmask 255.255.254.0 mtu 1500 broadcast 172.21.33.255
Sun Nov 26 16:10:18 2017 Initialization Sequence Completed
Sun Nov 26 17:10:17 2017 TLS: soft reset sec=0 bytes=376258769/-1 pkts=395962/0
Sun Nov 26 17:10:17 2017 VERIFY OK: depth=1, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=IPVanish CA, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 VERIFY X509NAME OK: C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 VERIFY OK: depth=0, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', remote='link-mtu 1570'
Sun Nov 26 17:10:17 2017 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-GCM', remote='cipher AES-256-CBC'
Sun Nov 26 17:10:17 2017 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'
Sun Nov 26 17:10:17 2017 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Sun Nov 26 17:10:17 2017 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 17:10:17 2017 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 17:10:17 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA

You can see, nothing bad happens with the VPN connection. Theres just the 60mins TLS reset, all working fine.

Client config:

client
dev tun
proto udp
remote 81.171.85.30 1194
engine cryptodev
resolv-retry infinite
nobind
persist-key
ca /etc/openvpn/keys/ca.ipvanish.com.crt
auth-user-pass /etc/openvpn/keys/user_ipvanish.auth
verify-x509-name fra-a40.ipvanish.com name
script-security 2
route-noexec
route-up /etc/openvpn/up/route-up.sh
down /etc/openvpn/down/down.sh
comp-lzo no
verb 3
ncp-disable
auth SHA256
cipher AES-128-GCM
keysize 128
tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-DSS-WITH-AES-128-CBC-SHA:TLS-RSA-WITH-AES-128-CBC-SHA

I actually noticed this behavior in the logs of dnsmasq:

Sun Nov 26 18:09:24 2017 daemon.warn odhcpd[1500]: DHCPV6 SOLICIT IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /etc/hosts - 4 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/odhcpd - 2 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq-dhcp[2566]: read /etc/ethers - 0 addresses
Sun Nov 26 18:09:24 2017 daemon.warn odhcpd[1500]: DHCPV6 SOLICIT IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:25 2017 daemon.warn odhcpd[1500]: DHCPV6 REQUEST IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /etc/hosts - 4 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/odhcpd - 3 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq-dhcp[2566]: read /etc/ethers - 0 addresses

It seems to restart iself always a new client/pc boots or connects to wifi...why? It could be that whenever this happens it somehow breaks everything. This wasnt the case in my old OpenWRT build. Can I deactivate this somehow?

Okay so i updated the build today.
I was having this problem as you did. No internet on the clients.
I uninstalled the iptables mods but still no internet on clients, and the router internet was working. i assigned tun0 to a firewall zone, and i restarted the firewall. So apparently restarting the firewall in Luci is not the same as "etc/init.d/firewall reload" doing this in luci worked for me.
Not sure what is going on in here but it's weird.
I hope this helps you

(Last edited by pirretub on 26 Nov 2017, 23:30)

I am wondering, if maybe something is restarting the firewall (and dnsmasq) at random times, which will break the VPN or rendering it unstable, because if something restarts the firewall this will break the SNAT rules of OpenVPN. If so, this is an unwanted behavior and has to stop, at least for my setup. I want the firewall never to be reload actually, it would break things. But I also have to find out, whats causing the router literally to crash for the tun device, if I do a "ping -s 1480 8.8.8.8 -I tun0". This may be part of the problem too, that some package sizes big enough will trigger this crash too.

Hi,
After upgrading to "r5422", has anyone had an issue when trying to connect using SSH?
I found that i had to go into the "administration" section and change a setting before it allowed me to log in via SSH.

UI access was fine.

Upgraded WRT1200ACv1 & WRT1200ACv2.

(Last edited by jefftk99 on 27 Nov 2017, 02:51)

with Lede Reboot SNAPSHOT r5422-9fe59abef8
I just got after about 8 hours of uptime

Sun Nov 26 18:05:09 2017 kern.err kernel: [29036.334111] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:05:09 2017 kern.err kernel: [29036.340013] ieee80211 phy0: return code: 0x001d
Sun Nov 26 18:05:09 2017 kern.err kernel: [29036.344588] ieee80211 phy0: timeout: 0x001d
Sun Nov 26 18:05:13 2017 kern.err kernel: [29040.266053] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:05:13 2017 kern.err kernel: [29040.271978] ieee80211 phy0: return code: 0x001d
Sun Nov 26 18:05:13 2017 kern.err kernel: [29040.276544] ieee80211 phy0: timeout: 0x001d
Sun Nov 26 18:05:17 2017 kern.err kernel: [29044.180725] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:05:17 2017 kern.err kernel: [29044.186586] ieee80211 phy0: return code: 0x001d
Sun Nov 26 18:05:17 2017 kern.err kernel: [29044.191165] ieee80211 phy0: timeout: 0x001d
Sun Nov 26 18:05:17 2017 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5

Initially I just lost both 2.4GHz and 5GHz wifi, then reconnected, but very soon the router wrt3200acm  rebooted itself...
Which gives me an idea that the problem is not with firmware, but probably with updated LEDE software?

(Last edited by vadimtk on 27 Nov 2017, 04:06)

vadimtk wrote:

with Lede Reboot SNAPSHOT r5422-9fe59abef8
I just got after about 8 hours of uptime

Sun Nov 26 18:05:09 2017 kern.err kernel: [29036.334111] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:05:09 2017 kern.err kernel: [29036.340013] ieee80211 phy0: return code: 0x001d
Sun Nov 26 18:05:09 2017 kern.err kernel: [29036.344588] ieee80211 phy0: timeout: 0x001d
Sun Nov 26 18:05:13 2017 kern.err kernel: [29040.266053] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:05:13 2017 kern.err kernel: [29040.271978] ieee80211 phy0: return code: 0x001d
Sun Nov 26 18:05:13 2017 kern.err kernel: [29040.276544] ieee80211 phy0: timeout: 0x001d
Sun Nov 26 18:05:17 2017 kern.err kernel: [29044.180725] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 18:05:17 2017 kern.err kernel: [29044.186586] ieee80211 phy0: return code: 0x001d
Sun Nov 26 18:05:17 2017 kern.err kernel: [29044.191165] ieee80211 phy0: timeout: 0x001d
Sun Nov 26 18:05:17 2017 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5

Initially I just lost both 2.4GHz and 5GHz wifi, then reconnected, but very soon the router wrt3200acm  rebooted itself...
Which gives me an idea that the problem is not with firmware, but probably with updated LEDE software?

Good question.......... 

On the last build I didn't have any issues running the previous firmware, so I put it in with the wifi driver for this build "assuming" it would continue.

Well... Now i have an issue.

WRT1900AC1, running r5032.
I configure out router reboots from time to time, then i have streamed torrent download (traffic is not so heavy, about 500k, but connection count is, about 150) from wan to 5G radio.
Looking into collectd, there are no temperature, system load or memory issues.

Did anyone meet this issue as well?
Do you have any ideas why it's happened?

PS: Is latest 4.4 version (5113) still support reg hack? If it is, i'll try to update to it.

Never had these errors until I upgraded with with Lede Reboot SNAPSHOT r5422-9fe59abef8
driver name: mwlwifi
chip type: 88W8964
hw version: 7
driver version: 10.3.4.0-20170810
firmware version: 0x09030007

Sun Nov 26 16:51:44 2017 kern.err kernel: [67582.681114] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 26 16:51:48 2017 kern.err kernel: [67586.760811] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:51:52 2017 kern.err kernel: [67590.774086] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 26 16:51:56 2017 kern.err kernel: [67594.858712] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:00 2017 kern.err kernel: [67598.872649] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:04 2017 kern.err kernel: [67602.886118] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:08 2017 kern.err kernel: [67606.935977] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:12 2017 kern.err kernel: [67610.950475] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:16 2017 kern.err kernel: [67614.964408] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:20 2017 kern.err kernel: [67619.100377] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:24 2017 kern.err kernel: [67623.114318] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:28 2017 kern.err kernel: [67627.128238] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:33 2017 kern.err kernel: [67631.143802] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:37 2017 kern.err kernel: [67635.160133] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:41 2017 kern.err kernel: [67639.173211] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:50 2017 kern.err kernel: [67649.093923] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:54 2017 kern.err kernel: [67653.117878] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:52:58 2017 kern.err kernel: [67657.131813] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:53:03 2017 kern.err kernel: [67661.167758] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:53:07 2017 kern.err kernel: [67665.183696] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:53:11 2017 kern.err kernel: [67669.199655] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:53:20 2017 kern.err kernel: [67679.086807] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:53:24 2017 kern.err kernel: [67683.101455] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:53:28 2017 kern.err kernel: [67687.115403] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:53:33 2017 kern.err kernel: [67691.129340] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 26 16:53:37 2017 kern.err kernel: [67695.171288] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:53:41 2017 kern.err kernel: [67699.187219] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:53:45 2017 kern.err kernel: [67703.205162] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:53:49 2017 kern.err kernel: [67707.221112] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:53:53 2017 kern.err kernel: [67711.234714] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:53:57 2017 kern.err kernel: [67715.248996] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:54:01 2017 kern.err kernel: [67719.268796] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:54:05 2017 kern.err kernel: [67723.288873] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:54:09 2017 kern.err kernel: [67727.304813] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:54:13 2017 kern.err kernel: [67731.318796] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:54:17 2017 kern.err kernel: [67735.332278] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 26 16:54:17 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:17 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:17 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:17 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:21 2017 kern.err kernel: [67739.462638] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:54:25 2017 kern.err kernel: [67743.476587] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:54:29 2017 kern.err kernel: [67747.490532] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:54:33 2017 kern.err kernel: [67751.510482] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:54:37 2017 kern.err kernel: [67755.530425] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:54:41 2017 kern.err kernel: [67759.550365] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:54:45 2017 kern.err kernel: [67763.566322] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 26 16:54:49 2017 kern.err kernel: [67767.652237] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 26 16:54:49 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:49 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:49 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:49 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:49 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:49 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:49 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:49 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:49 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:54:53 2017 kern.err kernel: [67771.725306] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:54:57 2017 kern.err kernel: [67775.739610] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:01 2017 kern.err kernel: [67779.760078] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:05 2017 kern.err kernel: [67783.778016] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:09 2017 kern.err kernel: [67787.791958] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:13 2017 kern.err kernel: [67791.805903] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:17 2017 kern.err kernel: [67795.819852] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:21 2017 kern.err kernel: [67799.833028] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 26 16:55:25 2017 kern.err kernel: [67803.877531] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:55:29 2017 kern.err kernel: [67807.891668] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:55:33 2017 kern.err kernel: [67811.905495] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:55:37 2017 kern.err kernel: [67815.921555] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:41 2017 kern.err kernel: [67819.934838] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:45 2017 kern.err kernel: [67823.953456] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:49 2017 kern.err kernel: [67827.965398] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:53 2017 kern.err kernel: [67831.979365] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:55:57 2017 kern.err kernel: [67836.003268] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:55:57 2017 daemon.notice netifd: wan6 (1818): Command failed: Request timed out
Sun Nov 26 16:56:01 2017 kern.err kernel: [67840.033216] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:56:05 2017 kern.err kernel: [67844.047175] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:56:09 2017 kern.err kernel: [67848.063114] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:56:14 2017 kern.err kernel: [67852.136252] ieee80211 phy0: cmd 0x9143=GetSeqno timed out
Sun Nov 26 16:56:18 2017 kern.err kernel: [67856.154988] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:56:22 2017 kern.err kernel: [67860.168936] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:56:26 2017 kern.err kernel: [67864.186879] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Sun Nov 26 16:56:30 2017 kern.err kernel: [67868.208845] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 26 16:56:34 2017 kern.err kernel: [67872.240756] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:56:38 2017 kern.err kernel: [67876.254444] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:56:42 2017 kern.err kernel: [67880.270642] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:56:46 2017 kern.err kernel: [67884.284023] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 26 16:56:50 2017 kern.err kernel: [67888.300219] ieee80211 phy0: cmd 0x9125=BAStream timed out

Will install the latest firmware and monitor. Note my system did not crash and it is not under load.

Edit: Was the mwlwifi driver build 466368f or d5c5b05?

(Last edited by Spamtree on 27 Nov 2017, 05:58)

Dave - thanks for the great firmware and your patience with everyone here. As a retired educator. - I can appreciate your dedication to learning and assisting others in doing so as well. The latest build is simply great.
For those who might need a guide / tutorial for TorGuard VPN on OpenWrt/ Lede - you can go to TorGuard Forum  where I just posted tutorial / guide. The title of the tutorial is - 

LEDE - OPENWRT TORGUARD VPN SETUP
by directnupe  - this guide was put together with the assistance of TorGuard Technical Support. So - VPN is guaranteed  to work if you follow the instructions step by step. I put this together as I could not find a TorGuard OpenWrt / Lede OpenVpn Guide anywhere.
Happy Holidays to All In Peace and Grace,

DIT

davidc502 wrote:
tapper wrote:

Hi will there be a new build with kernel 4.9.65?

The build finished yesterday afternoon, and I just uploaded to the server.

@starcms

Please test to see if AMSDU is disabled now on the 1200.

Sorry, been busy.  Will test tonight when I get home from work and report back.

directnupe wrote:

Dave - thanks for the great firmware and your patience with everyone here. As a retired educator. - I can appreciate your dedication to learning and assisting others in doing so as well. The latest build is simply great.
For those who might need a guide / tutorial for TorGuard VPN on OpenWrt/ Lede - you can go to TorGuard Forum  where I just posted tutorial / guide. The title of the tutorial is - 

LEDE - OPENWRT TORGUARD VPN SETUP
by directnupe  - this guide was put together with the assistance of TorGuard Technical Support. So - VPN is guaranteed  to work if you follow the instructions step by step. I put this together as I could not find a TorGuard OpenWrt / Lede OpenVpn Guide anywhere.
Happy Holidays to All In Peace and Grace,

DIT

Thank you for your efforts.  Would you mind if I put the VPN Setup on the website?

If I might ask a question:  What speeds are you able to obtain using VPN?

makedir wrote:

@pirretub when I do a speedtest (speedtest http://speedtest.net/) and have htop opened on the router, cpu (openvpn process) will cap at 100% with a bandwidth of 70mbit/s, regardless if cryptodev used or not). I just had 30 minutes rock stable connections on my laptop, and then, puff... a few minutes ago, all timeouts again happening opening new tabs on chrome. VPN connection is open, no issues. This doesnt seem to be a problem of OpenVPN but with the router (nat, iptables, firewall, whatever).

:screen (openvpn): /usr/sbin/openvpn --config /tmp/ipvanish/fra-a40.ovpn --dev tun0
Sun Nov 26 16:10:16 2017 WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6
Sun Nov 26 16:10:16 2017 OpenVPN 2.4.4 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sun Nov 26 16:10:16 2017 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Sun Nov 26 16:10:16 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Nov 26 16:10:17 2017 Initializing OpenSSL support for engine 'cryptodev'
Sun Nov 26 16:10:17 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:17 2017 Socket Buffers: R=[163840->163840] S=[163840->163840]
Sun Nov 26 16:10:17 2017 UDP link local: (not bound)
Sun Nov 26 16:10:17 2017 UDP link remote: [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:17 2017 TLS: Initial packet from [AF_INET]81.171.85.30:1194, sid=88894593 b70725ff
Sun Nov 26 16:10:17 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Nov 26 16:10:17 2017 VERIFY OK: depth=1, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=IPVanish CA, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 VERIFY X509NAME OK: C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 VERIFY OK: depth=0, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 16:10:17 2017 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', remote='link-mtu 1570'
Sun Nov 26 16:10:17 2017 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-GCM', remote='cipher AES-256-CBC'
Sun Nov 26 16:10:17 2017 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'
Sun Nov 26 16:10:17 2017 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Sun Nov 26 16:10:17 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA
Sun Nov 26 16:10:17 2017 [fra-a40.ipvanish.com] Peer Connection Initiated with [AF_INET]81.171.85.30:1194
Sun Nov 26 16:10:18 2017 SENT CONTROL [fra-a40.ipvanish.com]: 'PUSH_REQUEST' (status=1)
Sun Nov 26 16:10:18 2017 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 198.18.0.1,dhcp-option DNS 198.18.0.2,rcvbuf 262144,explicit-exit-notify 5,route-gateway 172.21.32.1,topology subnet,ping 20,ping-restart 40,ifconfig 172.21.32.109 255.255.254.0,peer-id 6'
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: timers and/or timeouts modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: explicit notify parm(s) modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sun Nov 26 16:10:18 2017 Socket Buffers: R=[163840->327680] S=[163840->163840]
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --ifconfig/up options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: route options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: route-related options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: peer-id set
Sun Nov 26 16:10:18 2017 OPTIONS IMPORT: adjusting link_mtu to 1625
Sun Nov 26 16:10:18 2017 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 16:10:18 2017 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 16:10:18 2017 TUN/TAP device tun0 opened
Sun Nov 26 16:10:18 2017 TUN/TAP TX queue length set to 100
Sun Nov 26 16:10:18 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Nov 26 16:10:18 2017 /sbin/ifconfig tun0 172.21.32.109 netmask 255.255.254.0 mtu 1500 broadcast 172.21.33.255
Sun Nov 26 16:10:18 2017 Initialization Sequence Completed
Sun Nov 26 17:10:17 2017 TLS: soft reset sec=0 bytes=376258769/-1 pkts=395962/0
Sun Nov 26 17:10:17 2017 VERIFY OK: depth=1, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=IPVanish CA, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 VERIFY X509NAME OK: C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 VERIFY OK: depth=0, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=fra-a40.ipvanish.com, emailAddress=support@ipvanish.com
Sun Nov 26 17:10:17 2017 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', remote='link-mtu 1570'
Sun Nov 26 17:10:17 2017 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-GCM', remote='cipher AES-256-CBC'
Sun Nov 26 17:10:17 2017 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'
Sun Nov 26 17:10:17 2017 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Sun Nov 26 17:10:17 2017 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 17:10:17 2017 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Sun Nov 26 17:10:17 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA

You can see, nothing bad happens with the VPN connection. Theres just the 60mins TLS reset, all working fine.

Client config:

client
dev tun
proto udp
remote 81.171.85.30 1194
engine cryptodev
resolv-retry infinite
nobind
persist-key
ca /etc/openvpn/keys/ca.ipvanish.com.crt
auth-user-pass /etc/openvpn/keys/user_ipvanish.auth
verify-x509-name fra-a40.ipvanish.com name
script-security 2
route-noexec
route-up /etc/openvpn/up/route-up.sh
down /etc/openvpn/down/down.sh
comp-lzo no
verb 3
ncp-disable
auth SHA256
cipher AES-128-GCM
keysize 128
tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-DSS-WITH-AES-128-CBC-SHA:TLS-RSA-WITH-AES-128-CBC-SHA

I actually noticed this behavior in the logs of dnsmasq:

Sun Nov 26 18:09:24 2017 daemon.warn odhcpd[1500]: DHCPV6 SOLICIT IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /etc/hosts - 4 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/odhcpd - 2 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Sun Nov 26 18:09:24 2017 daemon.info dnsmasq-dhcp[2566]: read /etc/ethers - 0 addresses
Sun Nov 26 18:09:24 2017 daemon.warn odhcpd[1500]: DHCPV6 SOLICIT IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:25 2017 daemon.warn odhcpd[1500]: DHCPV6 REQUEST IA_NA from 000100011d5daf05bc5ff43529ed on br-lan: ok fd5a:67cc:9f9e::11/128
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /etc/hosts - 4 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/odhcpd - 3 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq[2566]: read /tmp/hosts/dhcp.cfg02411c - 2 addresses
Sun Nov 26 18:09:25 2017 daemon.info dnsmasq-dhcp[2566]: read /etc/ethers - 0 addresses

It seems to restart iself always a new client/pc boots or connects to wifi...why? It could be that whenever this happens it somehow breaks everything. This wasnt the case in my old OpenWRT build. Can I deactivate this somehow?

Hey bro, i was doing a iptables -S here and i saw a lot of rules by conntrack to prevent VPN leakage, which might be conflicting with your rules. You might wanna check that.

davidc502 wrote:
directnupe wrote:

Dave - thanks for the great firmware and your patience with everyone here. As a retired educator. - I can appreciate your dedication to learning and assisting others in doing so as well. The latest build is simply great.
For those who might need a guide / tutorial for TorGuard VPN on OpenWrt/ Lede - you can go to TorGuard Forum  where I just posted tutorial / guide. The title of the tutorial is - 

LEDE - OPENWRT TORGUARD VPN SETUP
by directnupe  - this guide was put together with the assistance of TorGuard Technical Support. So - VPN is guaranteed  to work if you follow the instructions step by step. I put this together as I could not find a TorGuard OpenWrt / Lede OpenVpn Guide anywhere.
Happy Holidays to All In Peace and Grace,

DIT

Thank you for your efforts.  Would you mind if I put the VPN Setup on the website?

If I might ask a question:  What speeds are you able to obtain using VPN?

Hey david, thanks for all the work, i'm pretty much able to max my connection, depending on the VPN servers the max i've got untill today was 95mbits/s/50mbits/s upload(my connection is 100/50) at 35percent CPU load using Cryptodev on a WRT3200ACM.
Sometimes what happens is that i max the VPN server, so i search for one with low usage.
NordVPN, cipher AES-256-CBC, auth SHA512:
https://s8.postimg.org/umioh921h/Screenshot_20171127-184809.png
I'm quite wondering if i'm the only one getting a good perfomance like this?

(Last edited by pirretub on 27 Nov 2017, 19:01)

@pirretub what? mine is this if it helps anything:

root@wrtarm:~# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N MINIUPNPD
-N forwarding_lan_rule
-N forwarding_rule
-N forwarding_vpn_rule
-N forwarding_wan_rule
-N input_lan_rule
-N input_rule
-N input_vpn_rule
-N input_wan_rule
-N output_lan_rule
-N output_rule
-N output_vpn_rule
-N output_wan_rule
-N reject
-N zone_lan_dest_ACCEPT
-N zone_lan_forward
-N zone_lan_input
-N zone_lan_output
-N zone_lan_src_ACCEPT
-N zone_vpn_dest_ACCEPT
-N zone_vpn_dest_REJECT
-N zone_vpn_forward
-N zone_vpn_input
-N zone_vpn_output
-N zone_vpn_src_REJECT
-N zone_wan_dest_ACCEPT
-N zone_wan_dest_REJECT
-N zone_wan_forward
-N zone_wan_input
-N zone_wan_output
-N zone_wan_src_REJECT
-A INPUT -i lo -m comment --comment "!fw3" -j ACCEPT
-A INPUT -m comment --comment "!fw3: user chain for input" -j input_rule
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A INPUT -i br-lan -m comment --comment "!fw3" -j zone_lan_input
-A INPUT -i eth1.2 -m comment --comment "!fw3" -j zone_wan_input
-A INPUT -i tun0 -m comment --comment "!fw3" -j zone_vpn_input
-A INPUT -i tun1 -m comment --comment "!fw3" -j zone_vpn_input
-A FORWARD -m comment --comment "!fw3: user chain for forwarding" -j forwarding_rule
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A FORWARD -i br-lan -m comment --comment "!fw3" -j zone_lan_forward
-A FORWARD -i eth1.2 -m comment --comment "!fw3" -j zone_wan_forward
-A FORWARD -i tun0 -m comment --comment "!fw3" -j zone_vpn_forward
-A FORWARD -i tun1 -m comment --comment "!fw3" -j zone_vpn_forward
-A FORWARD -m comment --comment "!fw3" -j reject
-A OUTPUT -o lo -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -m comment --comment "!fw3: user chain for output" -j output_rule
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -o br-lan -m comment --comment "!fw3" -j zone_lan_output
-A OUTPUT -o eth1.2 -m comment --comment "!fw3" -j zone_wan_output
-A OUTPUT -o tun0 -m comment --comment "!fw3" -j zone_vpn_output
-A OUTPUT -o tun1 -m comment --comment "!fw3" -j zone_vpn_output
-A forwarding_rule -i br-lan -o tun0 -j ACCEPT
-A forwarding_rule -i br-lan -o tun1 -j ACCEPT
-A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset
-A reject -m comment --comment "!fw3" -j REJECT --reject-with icmp-port-unreachable
-A zone_lan_dest_ACCEPT -o br-lan -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3: user chain for forwarding" -j forwarding_lan_rule
-A zone_lan_forward -s 10.0.0.11/32 -m comment --comment "!fw3: 11 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.22/32 -m comment --comment "!fw3: 22 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.239/32 -m comment --comment "!fw3: 239 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.240/32 -m comment --comment "!fw3: 240 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.241/32 -m comment --comment "!fw3: 241 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.242/32 -m comment --comment "!fw3: 242 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.243/32 -m comment --comment "!fw3: 243 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.244/32 -m comment --comment "!fw3: 244 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.245/32 -m comment --comment "!fw3: 245 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.246/32 -m comment --comment "!fw3: 246 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -p tcp -m tcp --dport 80 -m set --match-set tcomv4 dst -m comment --comment "!fw3: tcom http allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -p tcp -m tcp --dport 443 -m set --match-set tcomv4 dst -m comment --comment "!fw3: tcom https allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -p tcp -m comment --comment "!fw3: PC reject" -j zone_wan_dest_REJECT
-A zone_lan_forward -p udp -m comment --comment "!fw3: PC reject" -j zone_wan_dest_REJECT
-A zone_lan_forward -m comment --comment "!fw3: forwarding lan -> wan" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_input -m comment --comment "!fw3: user chain for input" -j input_lan_rule
-A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_lan_input -m comment --comment "!fw3" -j zone_lan_src_ACCEPT
-A zone_lan_output -m comment --comment "!fw3: user chain for output" -j output_lan_rule
-A zone_lan_output -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_src_ACCEPT -i br-lan -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
-A zone_vpn_dest_ACCEPT -o tun0 -m comment --comment "!fw3" -j ACCEPT
-A zone_vpn_dest_ACCEPT -o tun1 -m comment --comment "!fw3" -j ACCEPT
-A zone_vpn_dest_REJECT -o tun0 -m comment --comment "!fw3" -j reject
-A zone_vpn_dest_REJECT -o tun1 -m comment --comment "!fw3" -j reject
-A zone_vpn_forward -m comment --comment "!fw3: user chain for forwarding" -j forwarding_vpn_rule
-A zone_vpn_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_vpn_forward -m comment --comment "!fw3" -j zone_vpn_dest_REJECT
-A zone_vpn_input -m comment --comment "!fw3: user chain for input" -j input_vpn_rule
-A zone_vpn_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_vpn_input -m comment --comment "!fw3" -j zone_vpn_src_REJECT
-A zone_vpn_output -m comment --comment "!fw3: user chain for output" -j output_vpn_rule
-A zone_vpn_output -m comment --comment "!fw3" -j zone_vpn_dest_ACCEPT
-A zone_vpn_src_REJECT -i tun0 -m comment --comment "!fw3" -j reject
-A zone_vpn_src_REJECT -i tun1 -m comment --comment "!fw3" -j reject
-A zone_wan_dest_ACCEPT -o eth1.2 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_wan_dest_ACCEPT -o eth1.2 -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_dest_REJECT -o eth1.2 -m comment --comment "!fw3" -j reject
-A zone_wan_forward -j MINIUPNPD
-A zone_wan_forward -m comment --comment "!fw3: user chain for forwarding" -j forwarding_wan_rule
-A zone_wan_forward -p esp -m comment --comment "!fw3: Allow-IPSec-ESP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -p udp -m udp --dport 500 -m comment --comment "!fw3: Allow-ISAKMP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_wan_forward -m comment --comment "!fw3" -j zone_wan_dest_REJECT
-A zone_wan_input -m comment --comment "!fw3: user chain for input" -j input_wan_rule
-A zone_wan_input -p udp -m udp --dport 68 -m comment --comment "!fw3: Allow-DHCP-Renew" -j ACCEPT
-A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment "!fw3: Allow-Ping" -j ACCEPT
-A zone_wan_input -p igmp -m comment --comment "!fw3: Allow-IGMP" -j ACCEPT
-A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_wan_input -m comment --comment "!fw3" -j zone_wan_src_REJECT
-A zone_wan_output -m comment --comment "!fw3: user chain for output" -j output_wan_rule
-A zone_wan_output -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
-A zone_wan_src_REJECT -i eth1.2 -m comment --comment "!fw3" -j reject
makedir wrote:

@pirretub what? mine is this if it helps anything:

root@wrtarm:~# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N MINIUPNPD
-N forwarding_lan_rule
-N forwarding_rule
-N forwarding_vpn_rule
-N forwarding_wan_rule
-N input_lan_rule
-N input_rule
-N input_vpn_rule
-N input_wan_rule
-N output_lan_rule
-N output_rule
-N output_vpn_rule
-N output_wan_rule
-N reject
-N zone_lan_dest_ACCEPT
-N zone_lan_forward
-N zone_lan_input
-N zone_lan_output
-N zone_lan_src_ACCEPT
-N zone_vpn_dest_ACCEPT
-N zone_vpn_dest_REJECT
-N zone_vpn_forward
-N zone_vpn_input
-N zone_vpn_output
-N zone_vpn_src_REJECT
-N zone_wan_dest_ACCEPT
-N zone_wan_dest_REJECT
-N zone_wan_forward
-N zone_wan_input
-N zone_wan_output
-N zone_wan_src_REJECT
-A INPUT -i lo -m comment --comment "!fw3" -j ACCEPT
-A INPUT -m comment --comment "!fw3: user chain for input" -j input_rule
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A INPUT -i br-lan -m comment --comment "!fw3" -j zone_lan_input
-A INPUT -i eth1.2 -m comment --comment "!fw3" -j zone_wan_input
-A INPUT -i tun0 -m comment --comment "!fw3" -j zone_vpn_input
-A INPUT -i tun1 -m comment --comment "!fw3" -j zone_vpn_input
-A FORWARD -m comment --comment "!fw3: user chain for forwarding" -j forwarding_rule
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A FORWARD -i br-lan -m comment --comment "!fw3" -j zone_lan_forward
-A FORWARD -i eth1.2 -m comment --comment "!fw3" -j zone_wan_forward
-A FORWARD -i tun0 -m comment --comment "!fw3" -j zone_vpn_forward
-A FORWARD -i tun1 -m comment --comment "!fw3" -j zone_vpn_forward
-A FORWARD -m comment --comment "!fw3" -j reject
-A OUTPUT -o lo -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -m comment --comment "!fw3: user chain for output" -j output_rule
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -o br-lan -m comment --comment "!fw3" -j zone_lan_output
-A OUTPUT -o eth1.2 -m comment --comment "!fw3" -j zone_wan_output
-A OUTPUT -o tun0 -m comment --comment "!fw3" -j zone_vpn_output
-A OUTPUT -o tun1 -m comment --comment "!fw3" -j zone_vpn_output
-A forwarding_rule -i br-lan -o tun0 -j ACCEPT
-A forwarding_rule -i br-lan -o tun1 -j ACCEPT
-A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset
-A reject -m comment --comment "!fw3" -j REJECT --reject-with icmp-port-unreachable
-A zone_lan_dest_ACCEPT -o br-lan -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3: user chain for forwarding" -j forwarding_lan_rule
-A zone_lan_forward -s 10.0.0.11/32 -m comment --comment "!fw3: 11 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.22/32 -m comment --comment "!fw3: 22 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.239/32 -m comment --comment "!fw3: 239 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.240/32 -m comment --comment "!fw3: 240 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.241/32 -m comment --comment "!fw3: 241 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.242/32 -m comment --comment "!fw3: 242 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.243/32 -m comment --comment "!fw3: 243 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.244/32 -m comment --comment "!fw3: 244 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.245/32 -m comment --comment "!fw3: 245 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -s 10.0.0.246/32 -m comment --comment "!fw3: 246 allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -p tcp -m tcp --dport 80 -m set --match-set tcomv4 dst -m comment --comment "!fw3: tcom http allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -p tcp -m tcp --dport 443 -m set --match-set tcomv4 dst -m comment --comment "!fw3: tcom https allow" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -p tcp -m comment --comment "!fw3: PC reject" -j zone_wan_dest_REJECT
-A zone_lan_forward -p udp -m comment --comment "!fw3: PC reject" -j zone_wan_dest_REJECT
-A zone_lan_forward -m comment --comment "!fw3: forwarding lan -> wan" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_input -m comment --comment "!fw3: user chain for input" -j input_lan_rule
-A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_lan_input -m comment --comment "!fw3" -j zone_lan_src_ACCEPT
-A zone_lan_output -m comment --comment "!fw3: user chain for output" -j output_lan_rule
-A zone_lan_output -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_src_ACCEPT -i br-lan -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
-A zone_vpn_dest_ACCEPT -o tun0 -m comment --comment "!fw3" -j ACCEPT
-A zone_vpn_dest_ACCEPT -o tun1 -m comment --comment "!fw3" -j ACCEPT
-A zone_vpn_dest_REJECT -o tun0 -m comment --comment "!fw3" -j reject
-A zone_vpn_dest_REJECT -o tun1 -m comment --comment "!fw3" -j reject
-A zone_vpn_forward -m comment --comment "!fw3: user chain for forwarding" -j forwarding_vpn_rule
-A zone_vpn_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_vpn_forward -m comment --comment "!fw3" -j zone_vpn_dest_REJECT
-A zone_vpn_input -m comment --comment "!fw3: user chain for input" -j input_vpn_rule
-A zone_vpn_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_vpn_input -m comment --comment "!fw3" -j zone_vpn_src_REJECT
-A zone_vpn_output -m comment --comment "!fw3: user chain for output" -j output_vpn_rule
-A zone_vpn_output -m comment --comment "!fw3" -j zone_vpn_dest_ACCEPT
-A zone_vpn_src_REJECT -i tun0 -m comment --comment "!fw3" -j reject
-A zone_vpn_src_REJECT -i tun1 -m comment --comment "!fw3" -j reject
-A zone_wan_dest_ACCEPT -o eth1.2 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_wan_dest_ACCEPT -o eth1.2 -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_dest_REJECT -o eth1.2 -m comment --comment "!fw3" -j reject
-A zone_wan_forward -j MINIUPNPD
-A zone_wan_forward -m comment --comment "!fw3: user chain for forwarding" -j forwarding_wan_rule
-A zone_wan_forward -p esp -m comment --comment "!fw3: Allow-IPSec-ESP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -p udp -m udp --dport 500 -m comment --comment "!fw3: Allow-ISAKMP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_wan_forward -m comment --comment "!fw3" -j zone_wan_dest_REJECT
-A zone_wan_input -m comment --comment "!fw3: user chain for input" -j input_wan_rule
-A zone_wan_input -p udp -m udp --dport 68 -m comment --comment "!fw3: Allow-DHCP-Renew" -j ACCEPT
-A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment "!fw3: Allow-Ping" -j ACCEPT
-A zone_wan_input -p igmp -m comment --comment "!fw3: Allow-IGMP" -j ACCEPT
-A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_wan_input -m comment --comment "!fw3" -j zone_wan_src_REJECT
-A zone_wan_output -m comment --comment "!fw3: user chain for output" -j output_wan_rule
-A zone_wan_output -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
-A zone_wan_src_REJECT -i eth1.2 -m comment --comment "!fw3" -j reject

Yes, if you've made your own VPN rules, you might check that out and get rid of some of those as they might be conflicting when the comment is 'conntrack' and there are VPN rules, then you just reload/restart the firewall with your own rules this should work, just an example you found in your file:

-A zone_vpn_forward -m comment --comment "!fw3: user chain for forwarding" -j forwarding_vpn_rule
-A zone_vpn_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_vpn_forward -m comment --comment "!fw3" -j zone_vpn_dest_REJECT
-A zone_vpn_input -m comment --comment "!fw3: user chain for input" -j input_vpn_rule
-A zone_vpn_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_vpn_input -m comment --comment "!fw3" -j zone_vpn_src_REJECT
-A zone_vpn_output -m comment --comment "!fw3: user chain for output" -j output_vpn_rule
-A zone_vpn_output -m comment --comment "!fw3" -j zone_vpn_dest_ACCEPT
-A zone_vpn_src_REJECT -i tun0 -m comment --comment "!fw3" -j reject
-A zone_vpn_src_REJECT -i tun1 -m comment --comment "!fw3" -j reject
-A zone_wan_dest_ACCEPT -o eth1.2 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_wan_dest_ACCEPT -o eth1.2 -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_dest_REJECT -o eth1.2 -m comment --comment "!fw3" -j reject

(Last edited by pirretub on 27 Nov 2017, 19:07)

Sorry, posts 4101 to 4100 are missing from our archive.