AC86U system log flooded by "kernel: [BLOCKED - INBOUND]" items

[brec]

Here's a small sample:

Aug 11 04:37:38 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=34:a3:95:8c:4b:38:00:01:5c:9d:b2:46:08:00 SRC=139.59.58.115 DST=47.33.58.100 LEN=40 TOS=0x00 PREC=0x00 TTL=234 ID=13715 PROTO=TCP SPT=42091 DPT=20183 SEQ=3722723616 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Aug 11 04:37:50 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=34:a3:95:8c:4b:38:00:01:5c:9d:b2:46:08:00 SRC=45.129.33.5 DST=47.33.58.100 LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=60398 PROTO=TCP SPT=48293 DPT=51080 SEQ=2417366530 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Aug 11 04:37:59 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=34:a3:95:8c:4b:38:00:01:5c:9d:b2:46:08:00 SRC=45.129.33.152 DST=47.33.58.100 LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=61517 PROTO=TCP SPT=51989 DPT=9851 SEQ=687991890 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Aug 11 04:38:02 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=34:a3:95:8c:4b:38:00:01:5c:9d:b2:46:08:00 SRC=138.68.94.142 DST=47.33.58.100 LEN=40 TOS=0x00 PREC=0x00 TTL=239 ID=42557 PROTO=TCP SPT=50861 DPT=28331 SEQ=3920687858 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Aug 11 04:38:10 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=34:a3:95:8c:4b:38:00:01:5c:9d:b2:46:08:00 SRC=223.71.167.163 DST=47.33.58.100 LEN=44 TOS=0x00 PREC=0x00 TTL=110 ID=41064 PROTO=TCP SPT=23032 DPT=5800 SEQ=3398061016 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B4) MARK=0x8000000
Aug 11 04:38:13 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=34:a3:95:8c:4b:38:00:01:5c:9d:b2:46:08:00 SRC=106.12.70.112 DST=47.33.58.100 LEN=40 TOS=0x00 PREC=0x00 TTL=233 ID=17167 PROTO=TCP SPT=53864 DPT=1485 SEQ=4037115046 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Aug 11 04:38:13 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=34:a3:95:8c:4b:38:00:01:5c:9d:b2:46:08:00 SRC=45.145.67.14 DST=47.33.58.100 LEN=40 TOS=0x00 PREC=0x00 TTL=239 ID=59297 PROTO=TCP SPT=44940 DPT=4160 SEQ=1540410757 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Aug 11 04:38:15 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=34:a3:95:8c:4b:38:00:01:5c:9d:b2:46:08:00 SRC=159.65.154.48 DST=47.33.58.100 LEN=40 TOS=0x00 PREC=0x00 TTL=234 ID=34191 PROTO=TCP SPT=52388 DPT=15608 SEQ=883524371 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Aug 11 04:38:25 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=34:a3:95:8c:4b:38:00:01:5c:9d:b2:46:08:00 SRC=193.93.62.61 DST=47.33.58.100 LEN=40 TOS=0x00 PREC=0x00 TTL=239 ID=40347 PROTO=TCP SPT=41953 DPT=7799 SEQ=2260908424 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000
Aug 11 04:38:33 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=34:a3:95:8c:4b:38:00:01:5c:9d:b2:46:08:00 SRC=51.91.158.178 DST=47.33.58.100 LEN=40 TOS=0x00 PREC=0x00 TTL=237 ID=1043 PROTO=TCP SPT=43958 DPT=15332 SEQ=3168732563 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000

On the time dimension it's not really a "flood" since items appear only every few seconds, not continuously. Still, it makes for huge blocks of these items when the log is opened for viewing. Because of the "kernel" I'm guessing it's the built-in firewall generating them. Regardless, unless they're useful in some way I should know about, I'd like to know if they can be suppressed.

I have the same question about these items:

Aug 11 04:29:12 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Aug 11 04:29:12 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Aug 11 04:29:12 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Aug 11 04:29:12 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Aug 11 04:29:12 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Aug 11 04:29:13 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Aug 11 04:29:13 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Aug 11 04:29:13 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Aug 11 04:29:13 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Aug 11 04:29:13 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Aug 11 04:29:13 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:A1:AE:C3:4E:6C, status: 0, reason: Class 3 frame received from nonassociated station (7)

I don't have even a guess as to what's generating those, but the MAC is that of my iPhone.

 

[Adamm]

On the time dimension it's not really a "flood" since items appear only every few seconds, not continuously. Still, it makes for huge blocks of these items when the log is opened for viewing. Because of the "kernel" I'm guessing it's the built-in firewall generating them. Regardless, unless they're useful in some way I should know about, I'd like to know if they can be suppressed.

These are Skynets blocked IP logging, this can be disabled in your settings at the expense of the stats feature (and useful debugging!)

 

[brec]

These are Skynets blocked IP logging, this can be disabled in your settings at the expense of the stats feature (and useful debugging!)

Ah! Now I'm curious as to why they say "kernel:" rather than "Skynet:"?

 

[Adamm]

Ah! Now I'm curious as to why they say "kernel:" rather than "Skynet:"?

Because technically IPTables is generating the log entry (Skynet creates IPTables rules to handle both blocking and logging).

 

[pattiri]

I don't have even a guess as to what's generating those, but the MAC is that of my iPhone.

Try restarting your iphone.

 

[dave14305]

I don't have even a guess as to what's generating those, but the MAC is that of my iPhone.

Is the MAC address a clone on the WAN page?

 

[brec]

Try restarting your iphone.

Done. But looking afterwards reveals that I happened to pick a bunch of log items with my iPhone's MAC, but there are other similar groupings with other MACs repeated in a bunch.

 

[brec]

Is the MAC address a clone on the WAN page?

No, it's the MAC address of my iPhone. But see also my reply just previous to this one. I haven't noticed the MAC clone on my WAN page in log items.

 

[dave14305]

No, it's the MAC address of my iPhone. But see also my reply just previous to this one. I haven't noticed the MAC clone on my WAN page in log items.

I just don’t think you should expect to see your iPhone MAC address on an incoming block. Somehow the router thinks the iPhone MAC is your router MAC.

 

[brec]

I just don’t think you should expect to see your iPhone MAC address on an incoming block. Somehow the router thinks the iPhone MAC is your router MAC.

It’s not in an incoming block. At the end of my OP I asked about a different kind of items, wlceventd. The iPhone MAC was in the cluster of those that I happened to post.

 

[kernol]

It’s not in an incoming block. At the end of my OP I asked about a different kind of items, wlceventd. The iPhone MAC was in the cluster of those that I happened to post.

The wlceventd logging issue has many threads - try this link for answers ..
https://www.snbforums.com/search/12800/?q=WLCEVENTD&o=date

Short answer - in Asus closed code they left the logging at "debug" level for this issue ... so we all ignore them - and preferably use Scribe add-on [available in amtm] to drop them in their own log so can easily be ignored and no longer clutter Syslog.

 

[CaptnDanLKW]

From time to time my iPhone also causes an unusually large amount of wlceventd events, honestly after a reboot or IOS upgrade. Sometime it calms down, sometimes it doesn't. I realize it has nothing to do with the router - it's just logging low level Wi-Fi events. I also don't see anything apparently wrong with my iPhone's network stability.

That said, if it doesn't calm down I'll 'Forget' the network and connect back. This always stops the noise. It's like IOS detects or learns something about location/proximity to the associated AP and decides it needs to adjust something with the signal... This is all assumed of course, no-one know what these devices' network stacks really do.