What's new

[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

  • SNBForums Code of Conduct

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

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

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

...I just updated to 23E1 (dirty flashed) on two AC68U's. ...my network map only shows the other AC68U on both units.
Simply give it some time to populate the list - look again tomorrow and you will see! :rolleyes:
 
Code:
WARNING: Bad encapsulated packet length from peer (3338), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Connection reset, restarting [0]

Got multiple such notifications in the log over just the last 2 minutes and i confirmed with my brother that he wasn't trying to connect to the network. Seems someone attacking my server. I have disabled openvpn as of now. Connection wasn't successful though.

Any clues as to how they found I have a server running?

Edit: The ip was apparently from Chicago.

Edit2: Apparently the attack only went on for 2min 20seconds and the duration only had a repitition of these lines. No penetration. probably.
 
Last edited:
Hi @john9527,

WAN Uptime seems to be broken in Dual WAN, it seems 22E4 was the last working version (went back as far as 23B2 and it was not working).

I know I was supposed to be testing this, with the whole VPN issues I never got a chance to look at it but still thought you should know.

S
-
 
WAN Uptime seems to be broken in Dual WAN, it seems 22E4 was the last working version (went back as far as 23B2 and it was not working).
'broken' doesn't say really tell me anything. I put some changes for some timer problems I was able to create/test in Dual WAN mode in V23. Frankly, if it the timer doesn't work for Dual WAN, I'll probably just disable it if Dual WAN is active in the next release.

EDIT: Also, did you set Redirect to error page to both conditions, 'Link or WAN down' on the WAN page? It's a bit convoluted, but if you are running Dual WAN that is the redirect setting you should use.
 
Last edited:
'broken' doesn't say really tell me anything
100% True, my bad! Both WAN Uptime counters (Total/Current) are 0(hh/mm/ss), and I see the "WAN is down" legend as well

I've just double checked and the "Redirect to error page" is indeed in "Link or WAN down" (web_redirect=3)
 
Code:
WARNING: Bad encapsulated packet length from peer (3338), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Connection reset, restarting [0]

Got multiple such notifications in the log over just the last 2 minutes and i confirmed with my brother that he wasn't trying to connect to the network. Seems someone attacking my server. I have disabled openvpn as of now. Connection wasn't successful though.

Any clues as to how they found I have a server running?
Edit2: Apparently the attack only went on for 2min 20seconds and the duration only had a repitition of these lines. No penetration. probably.

@john9527 John, would changing the default openvpn port help with these sort of attacks?
 
Code:
WARNING: Bad encapsulated packet length from peer (3338), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Connection reset, restarting [0]

Got multiple such notifications in the log over just the last 2 minutes and i confirmed with my brother that he wasn't trying to connect to the network. Seems someone attacking my server. I have disabled openvpn as of now. Connection wasn't successful though.

Any clues as to how they found I have a server running?

Edit: The ip was apparently from Chicago.

Edit2: Apparently the attack only went on for 2min 20seconds and the duration only had a repitition of these lines. No penetration. probably.

there's people who do portscans to see if they can get to something. I run openvpn on mine too on a non standard port and even then I see these lines occur in my syslog every once in a while. As long as the person trying to connect does not have the certificates needed they won't get far.

Changing the port does not solve this unfortunately.
 
Last edited:
Off Topic

Newegg is offering a refurbished RT-AC68P for $69.99 in their NewEgg Early Access Shell Shocker promo. Available now, 10/11/17 through 11:59pm PT, Promo Code EMC SRDBB4.
 
Last edited:
Thanks for the recommendation, if I enable the encrypt channel option in extra HMAC auth (which I assume is tls-crypt), will it offer the same benefits?
It is in fact tls-crypt and it'll be better, but not backwards compatible and you will need v2.4 in your clients
 
It is in fact tls-crypt and it'll be better, but not backwards compatible and you will need v2.4 in your clients

Well enabling tls crypt led to the following error every damn time:

tls-crypt unwrap error: packet too short
TLS Error: tls-crypt unwrapping failed from
Fatal TLS error (check_tls_errors_co), restarting

Couldn't really find anything helpful for these errors, if you have an idea about them please do comment. I have the latest ios client and cipher negotiation was working previously so guess it is v2.4.
tls auth is working properly though.

EDIT: Probably I'm wrong and ios openvpn client hasn't been updated to 2.4 :/
 
Last edited:
Updated to 23E1 on both RT-ac66u and RT-ac68u
Found the following errors tossed on the 66
Notes
66u is in Media Bridge x.x.x.2
68 is AP x.x.x.1
Both routers were factory defaulted

Mar 12 09:00:27 nmbd[340]: [2017/03/12 09:00:27, 0] nmbd/nmbd_nameregister.c:register_name_response(130)
Mar 12 09:00:27 nmbd[340]: register_name_response: server at IP x.x.x.1 rejected our name registration of WORKGROUP<1d> IP x.x.x.2 with error code 6.
Mar 12 09:00:27 nmbd[340]: [2017/03/12 09:00:27, 0] nmbd/nmbd_become_lmb.c:become_local_master_fail2(411)
Mar 12 09:00:27 nmbd[340]: become_local_master_fail2: failed to register name WORKGROUP<1d> on subnet x.x.x.2. Failed to become a local master browser.
Mar 12 09:00:27 nmbd[340]: [2017/03/12 09:00:27, 0] nmbd/nmbd_namelistdb.c:standard_fail_register(304)
Mar 12 09:00:27 nmbd[340]: standard_fail_register: Failed to register/refresh name WORKGROUP<1d> on subnet x.x.x.2
 
Updated to 23E1 on both RT-ac66u and RT-ac68u
Found the following errors tossed on the 66
Notes
66u is in Media Bridge x.x.x.2
68 is AP x.x.x.1
Both routers were factory defaulted

Mar 12 09:00:27 nmbd[340]: [2017/03/12 09:00:27, 0] nmbd/nmbd_nameregister.c:register_name_response(130)
Mar 12 09:00:27 nmbd[340]: register_name_response: server at IP x.x.x.1 rejected our name registration of WORKGROUP<1d> IP x.x.x.2 with error code 6.
Mar 12 09:00:27 nmbd[340]: [2017/03/12 09:00:27, 0] nmbd/nmbd_become_lmb.c:become_local_master_fail2(411)
Mar 12 09:00:27 nmbd[340]: become_local_master_fail2: failed to register name WORKGROUP<1d> on subnet x.x.x.2. Failed to become a local master browser.
Mar 12 09:00:27 nmbd[340]: [2017/03/12 09:00:27, 0] nmbd/nmbd_namelistdb.c:standard_fail_register(304)
Mar 12 09:00:27 nmbd[340]: standard_fail_register: Failed to register/refresh name WORKGROUP<1d> on subnet x.x.x.2
Haven't see that one before....do you have both routers set to act as 'Master browser'? In fact, I'm not sure that the Master browser designation will work when the router is configured as a MB or AP. Maybe someone can confirm that will work?
 
Haven't see that one before....do you have both routers set to act as 'Master browser'? In fact, I'm not sure that the Master browser designation will work when the router is configured as a MB or AP. Maybe someone can confirm that will work?

This may have been during the time of converting to a media bridge. I have yet to see it again after a few reboots. I could try and replicate but not worried about it.

On another note, who is this

Dec 31 16:00:12 kernel: ipt_account 0.1.21 : Piotr Gasidlo <quaker@barbara.eu.org>, http://code.google.com/p/ipt-account/

As it appears in each reboot

Dec 31 16:00:12 kernel: Netfilter messages via NETLINK v0.30.
Dec 31 16:00:12 kernel: nf_conntrack version 0.5.0 (2048 buckets, 16384 max)
Dec 31 16:00:12 kernel: ipt_time loading
Dec 31 16:00:12 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Dec 31 16:00:12 kernel: net/ipv4/netfilter/tomato_ct.c [Feb 27 2017 00:07:27]
Dec 31 16:00:12 kernel: ipt_account 0.1.21 : Piotr Gasidlo <quaker@barbara.eu.org>, http://code.google.com/p/ipt-account/
Dec 31 16:00:12 kernel: NET: Registered protocol family 1
Dec 31 16:00:12 kernel: NET: Registered protocol family 10
Dec 31 16:00:12 kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team
 
On another note, who is this

Dec 31 16:00:12 kernel: ipt_account 0.1.21 : Piotr Gasidlo <quaker@barbara.eu.org>, http://code.google.com/p/ipt-account/
It's the guy that maintains the ipt_account code. Have you not seen similar messages before for other Linux modules, i.e.
Code:
Jan  1 00:00:12 kernel: 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
Jan  1 00:00:12 kernel: All bugs added by David S. Miller <davem@redhat.com>
 
On another note, who is this

Dec 31 16:00:12 kernel: ipt_account 0.1.21 : Piotr Gasidlo <quaker@barbara.eu.org>, http://code.google.com/p/ipt-account/

As it appears in each reboot
There are a couple of places where people who worked on parts of the kernel code 'signed' their work. I particularly like the second line of this one :)

Dec 31 17:00:15 kernel: 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
Dec 31 17:00:15 kernel: All bugs added by David S. Miller <davem@redhat.com>

EDIT: @ColinTaylor beat me to it :D
 

Latest threads

Sign Up For SNBForums Daily Digest

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