spooked by frequent notify_rc restart_firewall events

[Natty]

I'm trying to work out why today the syslog has many rc_service entries such as this:

May 6 09:35:01 rc_service: amas_lib 368:notify_rc restart_firewall
May 6 09:35:02 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 6 10:19:37 rc_service: amas_lib 12463:notify_rc restart_firewall
May 6 10:19:38 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 6 10:20:32 rc_service: amas_lib 368:notify_rc restart_firewall
May 6 10:20:34 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)​

and this:

May 6 13:23:58 rc_service: amas_lib 4728:notify_rc restart_firewall
May 6 13:23:59 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 6 13:25:45 rc_service: amas_lib 368:notify_rc restart_firewall
May 6 13:25:46 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)​

and this:

May 6 15:52:43 rc_service: amas_lib 22659:notify_rc restart_firewall
May 6 15:52:44 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 6 15:53:44 rc_service: amas_lib 368:notify_rc restart_firewall
May 6 15:53:45 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)​

I haven't changed any any settings today, and there havent been any such events in the past 3 days. Last night I changed Roaming Assistant from -55 (default) to -70, as several iPhones seem to be connecting and disconnecting frequently. The firewall remains unchanged, set to Enabled, DoS set to No, URL, Keyword and Network Services Filters all disabled. Is something messing with my RT-AC66U-B1 running 384.17 in router mode?

 

[dave14305]

amas_lib suggests AiMesh. Do you have AiMesh?

 

[Natty]

amas_lib suggests AiMesh. Do you have AiMesh?

Operation Mode is set as Wireless router mode / AiMesh Router mode (Default)

There are no other AiMesh devices in my network. Wireless APs are connected via ethernet. The APs are running a recent build of DD-WRT, providing assigned SSIDs (all different) and using fixed wireless channels to avoid overlap. The RT-AC66U-B1 wireless is also configured on fixed channels. As far as I'm aware, AiMesh is not used. Could there be something funky going on with neighbouring networks?

Those restart_firewall events keep coming:

May 6 18:31:18 rc_service: amas_lib 9356:notify_rc restart_firewall
May 6 18:31:19 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 6 18:31:53 rc_service: amas_lib 368:notify_rc restart_firewall
May 6 18:31:54 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 6 18:36:41 rc_service: amas_lib 10069:notify_rc restart_firewall
May 6 18:36:42 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 6 18:37:55 rc_service: amas_lib 368:notify_rc restart_firewall
May 6 18:37:56 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)

May 6 19:58:11 rc_service: amas_lib 19962:notify_rc restart_firewall
May 6 19:58:12 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 6 19:59:05 rc_service: amas_lib 368:notify_rc restart_firewall
May 6 19:59:06 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)​

Do the numbers after amas_lib mean anything?

 

[dave14305]

Do the numbers after amas_lib mean anything?

I believe they are process IDs. So you can run:

ps w | grep amas_lib

And see if the numbers are still current.

 

[Natty]

ps w | grep amas_lib

username@RT-AC66U_B1-F108:/tmp/home/root# ps w | grep amas_lib
368 username 5624 S amas_lib
477 username 5624 S amas_lib
6083 username 1436 S grep amas_lib​

368 seems to be a common denominator. Does any of this provide any further clues about why these events are happening?

 

[Natty]

One other thing I did yesterday, before this issue kicked off, was to connect one of my desktop PCs directly via ethernet into the switch on a nearby AP on the network. I manually reserved a new static IP address in LAN - DHCP Server. This client already had a DHCP address reservation for its wireless MAC address. The ethernet MAC address is different to the wireless MAC address. Both reserved IP addresses are added to the Client List in AiProtection - Parental Controls - Time Scheduling, to prevent the desktop PC in question from acessing the internet during scheduled intervals. No other AiProtection features are in use, as I'd rather not trust Trend Micro.

In the Network Map - Client List, the desktop PC in question is shown with a number 2 over its graphical icon. When hovering the cursor over, a balloon pop-up says "2 clients are connecting to RT-AC68U through this device". The client's wireless interface is switched off while connected via ethernet. That is probably all fine and as it should be. Not sure if it is relevant to today's issue with restart_firewall events.

 

[Natty]

More clues ..? When I connected by ssh earlier, the following rc_service logs were recorded:

May 6 22:27:53 rc_service: httpds 242:notify_rc restart_time;restart_leds;restart_usb_idle;restart_firewall;restart_bhblock;
May 6 22:27:54 kernel: klogd started: BusyBox v1.25.1 (2020-04-25 22:25:08 EDT)
May 6 22:27:54 hour_monitor: daemon is starting
May 6 22:27:54 hour_monitor: daemon terminates
May 6 22:27:55 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 6 22:29:31 dropbear[5959]: Password auth succeeded for 'username' from 192.168.XX.XX:61975​

Maybe connecting by ssh triggered the restart of many things including firewall, followed by "apply nat rules". Or it could be coincidence? Connecting a second time logged only a single dropbear entry.

Any ideas as to why all these rc_service restart logs have started appearing and why nat rules keep being applied repeatedly?

​

 

[dave14305]

More clues ..? When I connected by ssh earlier, the following rc_service logs were recorded:

May 6 22:27:53 rc_service: httpds 242:notify_rc restart_time;restart_leds;restart_usb_idle;restart_firewall;restart_bhblock;
May 6 22:27:54 kernel: klogd started: BusyBox v1.25.1 (2020-04-25 22:25:08 EDT)
May 6 22:27:54 hour_monitor: daemon is starting
May 6 22:27:54 hour_monitor: daemon terminates
May 6 22:27:55 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 6 22:29:31 dropbear[5959]: Password auth succeeded for 'username' from 192.168.XX.XX:61975​

Maybe connecting by ssh triggered the restart of many things including firewall, followed by "apply nat rules". Or it could be coincidence? Connecting a second time logged only a single dropbear entry.

Any ideas as to why all these rc_service restart logs have started appearing and why nat rules keep being applied repeatedly?

​

This particular log looks like you pressed Apply on the Administration/ System page in the GUI. Was it you?

 

[Natty]

Ah, yes, that one would be me turning on ssh. I get a similar set of log entries when I set Enable SSH to No.

Another event happened today, at a time when nobody would have been connected as admin into the router. A scheduled reboot had occured at 4am, so this one is a in fresh session compared to yesterday.

May 7 09:46:07 rc_service: amas_lib 374:notify_rc restart_firewall
May 7 09:46:09 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)​

Might this be a normal process happening as a consequence of a setting I have previously made (e.g. DHCP reservation or Roaming Assistant threshold), or a minor bug that can be safely ignored, or could it be a result of attempted hack in to the router?