My RB5009UPr router has some default filter rules and one that “drops all [traffic] not coming from LAN”.
;;; defconf: drop all not coming from LAN
chain=input action=drop in-interface-list=!LAN log=no log-prefix=""
I noticed that the rule is constantly dropping some packets.
By enabling logs for the rule, I can see the following message every second.
19:25:14 firewall,info input: in:lo out:(unknown 0), connection-state:new proto UDP, 0.0.0.0:68->255.255.255.255:67, len 328
19:25:15 firewall,info input: in:lo out:(unknown 0), connection-state:new proto UDP, 0.0.0.0:68->255.255.255.255:67, len 328
It seems that the loopback interface is sending DHCP requests every second, and since this interface is not in the LAN interface list, it is being dropped.
[@RB5009] > /tool sniffer quick port=67 interface=lo
INTERFACE TIME NUM DIR SRC-MAC DST-MAC SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU
lo 0.594 1 -> 00:00:00:00:00:00 FF:FF:FF:FF:FF:FF 0.0.0.0:68 (bootpc) 255.255.255.255:67 (bootps) ip:udp 342 2
lo 0.594 2 <- 00:00:00:00:00:00 FF:FF:FF:FF:FF:FF 0.0.0.0:68 (bootpc) 255.255.255.255:67 (bootps) ip:udp 342 2
lo 1.599 3 -> 00:00:00:00:00:00 FF:FF:FF:FF:FF:FF 0.0.0.0:68 (bootpc) 255.255.255.255:67 (bootps) ip:udp 342 2
The router’s DHCP client service is disabled.
[@RB5009] > ip dhcp-client/print
Flags: X - DISABLED
# INTERFACE USE-PEER-DNS ADD-DEFAULT-ROUTE
;;; defconf
0 X sfp-sfpplus1 yes yes
Now, I’m trying to understand why the loopback interface is sending so many DHCP packets, but couldn’t find any configurations or services that might be trying to obtain a DHCP lease.
Actually … after you do any kind of manual configuration (and you know which of interfaces will be connected to WAN) it’s useless to have detect-internet enabled in any way. Because the only thing it could potentially do is screw your config.
The addition of “detect internet” was an unfortunate decision some time ago, probably made in an attempt to make MikroTik routers easier to config (or even do full out-of-the-box automatic config).
It basically failed to do so, and now what remains is mainly a nuisance.
Unfortunately we cannot expect it to be removed in an update, because it is actually possible to make it do something useful (with additional manual config): it can be used to automatically switch to a backup internet connection in some cases.
So it is probably here to stay, as useless, annoying and dangerous as it is…
Indeed MT failed to provide a good explanation so far. Below is my impression of it (it’s limited as I disable the feature as soon as I remember doing it, which is around 2 seconds after I log in).
From how it works (and from rare occasions when some MT staffer described some of it in some random forum post), it seems that it’s supposed to detect which of its interfaces connects to internet … and manipulate interface lists (WAN, LAN) accordingly. Which, together with default firewall setup which extensively relies on those interface lists, is supposed to help clueless user to connect to internet while keeping this user (and device) reasonably safe.
One big problem with the concept is this: interfaces are logical interfaces, carrying IP configuration (to put it simple). Which in default config means: ether1 and bridge. Or, if device has wireless and Quickset profile is set to some WISP CPE mode, additionally wifiX or wirelessX interface. But: if one has a device with 5 ports, (static) config makes ether2-ether5 members of bridge (i.e. switched). So if one connects internet link to ether1 and PC to ether2, then detect-internet may figure out that ether1 is WAN and bridge (together with ether2) is LAN (and everything will be fine). But if one connects internet to ether5 and PC to ether2, detect-internet will detect bridge as WAN interface (that’s fine), but PC will be switched to internet (so router will do neither routing nor firewalling) because traffic between PC and anything else will skip all IP processing.
No to mention that detect-internet generally takes some time (seconds? tens of seconds?) to detect anything and meanwhile device may be running wrong configuration even if detect-internet eventually decides correctly.
