Asus RT-AC88U with 384_9 firmware - reboot after IPSec vpn connection

[svkviz]

Hi all,

need some help as i have some problems with IPSec VPN server and macos users connecting and using samba protocol to network drive. Router reboot with log [see attached] . PPTP server working from Windows client without any problems. Can`t use it as mac os does not have pptp.


Any idea how to resolve it? Thanks a lot.

 

[L&LD]

What is the actual issue?

 

[svkviz]

What is the actual issue?

Router reboot with kernel error attached in txt file. Error occuring after ipsec vpn connection to server from macos users using samba protocol.

 

[PeterV]

Router reboot with kernel error attached in txt file. Error occuring after ipsec vpn connection to server from macos users using samba protocol.

Unfortunately, it's no errors in the log.
It's only last record with blocked ip packet and immediatelly after it - the boot records immediatelly after this unplanned reboot:
Mar 13 09:18:29 kernel: DROP IN=eth0 OUT= MAC=04:92:26:6b:ee:f8:4c:5e:0c:75:b1:2b:08:00 SRC=40.67.248.104 DST=xxx.xxx.xxx.xxx LEN=382 TOS=0x00 PREC=0x00 TTL=104 ID=370 DF PROTO=TCP SPT=443 DPT=56031 SEQ=1385321643 ACK=405997347 WINDOW=7341 RES=0x00 ACK PSH URGP=0 Blocked packet
May 5 07:05:06 kernel: klogd started: BusyBox v1.25.1 (2019-02-02 13:18:13 EST) First record in the log after restart

So, no information for the analyze

 

[svkviz]

There is reboot kernel message. No usable information from that? Hmmm will try to set logging to debug lvl.

 

[PeterV]

There is reboot kernel message. No usable information from that? Hmmm will try to set logging to debug lvl.

staring from that:
May 5 07:05:06 kernel: klogd started: BusyBox v1.25.1 (2019-02-02 13:18:13 EST)
It is a normal boot log messages, which have no any infromation, why this reboot was happend.
And it is usual first message, which was logged - the information about starting the logging daemon itself.

 

[john9527]

Am I the only one seeing this?
May 5 07:05:06 kernel: JFFS2 notice: (1) check_node_data: wrong data CRC in data node at 0x004e16a8: read 0xa808a169, calculated 0x4f59d147.

I'd start by reformating and reloading JFFS....

 

[EmeraldDeer]

staring from that:
May 5 07:05:06 kernel: klogd started: BusyBox v1.25.1 (2019-02-02 13:18:13 EST)
It is a normal boot log messages, which have no any infromation, why this reboot was happend.
And it is usual first message, which was logged - the information about starting the logging daemon itself.

I do not have expertise in this area, but:

• the JFFS2 error suggests that the filesystems had not been flushed when the boot happened
• there was a null pointer dereference in a core networking driver. This seems very odd for a router that has been around for a few years
• there are errors suggesting Ethernet port problems. There are many complaints about losing ports 5-8 on the RT-AC88U that are only resolved by a power off reboot

 

[PeterV]

I do not have expertise in this area, but:

• the JFFS2 error suggests that the filesystems had not been flushed when the boot happened
• there was a null pointer dereference in a core networking driver. This seems very odd for a router that has been around for a few years
• there are errors suggesting Ethernet port problems. There are many complaints about losing ports 5-8 on the RT-AC88U that are only resolved by a power off reboot

Yes, you right.
My mistake.
My apologize to svkviz for the wrong answer.

 

[EmeraldDeer]

So I guess the way forward is:

• Power cycle router
• Issue another reboot from the GUI
• Check that errors like "kernel: rtk port_phyEnableAll Failed!(-1)" and "JFFS2 notice: (1) check_node_data: wrong data CRC in data node" are not there
• Ensure that the firmware is the latest
• Check whether MacOS using IPSec crash is reproducible

 

[svkviz]

I had to use OpenVpn server and set macos clients to use TunnelBlick client. Working without any problems.
Yes IPSec crash is reproducible, router restarts always when client used smb://IPADDRESS after connection to IPSec vpn server.
Firmware is latest stable 384.9, also error reproducible on 384.10_beta1. Workaround for me is to use OpenVpn server connection for mac clients.
Will inspect deeper IPSec error in a few days, will try jffs format.

Thanks.