Release [Test] Asuswrt-Merlin 384.19 - OpenVPN test builds

[FLA_NL]

Ok, but initially everthing is ok and the server is properly started it seems. I can download the openvpn files. Only after a while the message appears possibly triggered by those errors. The server itself is not restarting. Btw, The restart that you see in my log I triggered myself to get the startup sequence logged for the server.

 

[RMerlin]

Ok, but initially everthing is ok and the server is properly started it seems. I can download the openvpn files. Only after a while the message appears possibly triggered by those errors. The server itself is not restarting. Btw, The restart that you see in my log I triggered myself to get the startup sequence logged for the server.

Try switching to TCP as someone suggested. This looks like a bug with OpenVPN itself, so it's outside of my control.

 

[FLA_NL]

Try switching to TCP as someone suggested. This looks like a bug with OpenVPN itself, so it's outside of my control.

Sorry it was kinda late yesterday, I changed it this morning and it seems more stable, but it is just running like this only for an hour.... I will get back to it later on to confirm the workaround worked. Too bad I couldn't find it myself... I did do some searching but things got a bit over my head. But thanks for your help!

 

[FLA_NL]

This seems to be the proper workaround. No error messages in the logs, and the message in the GUI stays away. Thanks again!

 

[maghuro]

@RMerlin
My jffs became unusable after alpha 4. I formated it after install alpha 4, but from time to time it becomes read only, saying that is full. And it isn't. I've only a couple of mb used.
Solution? Full power cycle.

Log; https://pastebin.com/XjzZPLnn

I think it isn't anything wrong with my disk:

 amtm-disk-check.log has this content:                                                                                                               START FILE, --- lines are not part of file                                ---------------------------------------------------                                                                                                 Sun Aug  2 13:05:53 IST 2020 Probing 'ext4' on device /dev/sda1           Running disk check v2.9, with command 'e2fsck -p' on /dev/sda1            AC86U-USB: recovering journal                                             AC86U-USB: clean, 634/245760 files, 572265/982134 blocks                  Sun Aug  2 13:05:55 IST 2020 Disk check done on /dev/sda1                 ---------------------------------------------------                       END FILE

 

[Torson]

@RMerlin
My jffs became unusable after alpha 4. I formated it after install alpha 4, but from time to time it becomes read only, saying that is full. And it isn't. I've only a couple of mb used.
Solution? Full power cycle.

Log; https://pastebin.com/XjzZPLnn

I think it isn't anything wrong with my disk:

 amtm-disk-check.log has this content:                                                                                                               START FILE, --- lines are not part of file                                ---------------------------------------------------                                                                                                 Sun Aug  2 13:05:53 IST 2020 Probing 'ext4' on device /dev/sda1           Running disk check v2.9, with command 'e2fsck -p' on /dev/sda1            AC86U-USB: recovering journal                                             AC86U-USB: clean, 634/245760 files, 572265/982134 blocks                  Sun Aug  2 13:05:55 IST 2020 Disk check done on /dev/sda1                 ---------------------------------------------------                       END FILE

I had the same jffs related errors in the log after upgrading to alpha 3.
The amtm-disk-check shows information related to the integrity of the attached USB file system which is different than jffs. That was unaffected by the upgrade.

NOTE:
Before the upgrade df -h showed the jffs partition as:

/dev/mtdblock8

After the upgrade it became:

/dev/mtdblock9

...and it's size was 48MB before and it is 47MB after the upgrade - that explains the change @RMerlin alluded to and probably the issues some of us have had.

 

[RMerlin]

Thanks everyone for the focused testing. 384.19 beta is now available for wider testing.