I'm curious, why RouterOS gives such exports... It usually uses names or [find ...]
I closed Winbox and the "Connections" list was empty but the packets still kept coming. I think there's something wrong with the web interface, in Winbox the tables contain a lot more information:
IP: 100.77.229.92
Port: 5678
Donât know the IP address, the port is apparently used for Router OSâ neighbor discovery feature (see this thread). I disabled it in âIP - Neighbors - Discovery Settings - Interface = noneâ, now there's only one more spike left that happens once a minute: An IPv6 address, which, according to google, is a âlink-local multicast addressâ. The other thread says that you can disable that too but the command doesnât work (âunexpected end of commandâ) and thereâs no âDiscoverâ option I can set to ânoâ.
Why was it even using the LTE connection for that in the first place, instead of the wired LAN connection?
I have to look at jaclazâ suggestions for the firewall filter more closely tomorrow.
Neighbor discovery uses interface list, that specifies, which interfaces should be used to send/receive discovery packets. Probably it wasn't set correctly and used your LTE interface.
Do you use IPv6 at all? If not, just disable it in IPv6->Settings. There is also an option to disable link-local addresses.
In some cases the * followed by a number can be some kind of "dynamic" something, but I don't think that it applies to dhcp clients too. 
It could well be some artifact of the lte connection, if there is an apn and it is connected, likely it automagically creates a dhcp client, what it is strange is that it exports this way (but on GUI it is shown correctly as being on interface lte1).
It was set to âstaticâ, no option to set it to LTE, only âLANâ, âWANâ, âallâ,⌠I enabled it again but with âLANâ, so far I havenât seen it use LTE again but I still want to disable it, just in case. Do you know if itâs sufficient to disable the default route for the LTE interface, as xrlls suggested?
No, I donât use IPv6. I ticked âdisable IPv6â but still got a single packet to an IPv6 address Iâd seen before. No second one over LTE so far but once in a while an IPv6 address still shows up in the packet sniffer on ether1 and the bridge. Thatâs weird. Should I also disable âIPv6 Forwardâ?
It says that itâs going to expire in 20.5 hours, maybe thatâs why it doesnât show up permanently? I did disable the LTE interface at one point (possibly about 3.5 hours ago), enabling again probably started the DHCP client too.
'static' includes LTE interfaces, that's why it was using your LTE interface for discovery. Go to Interfaces -> 'Interface list' tab to see all interface lists and interfaces they include, you can set everything there. I usually create a separate 'discover' list, add all needed interfaces, that should be discoverable, and then just choose this list in neighbor discovery.
I've suggested almost the same - ensure that there are no routes to your LTE interface, it should be enough. I also have blocking firewall rules, but they always show 0 bytes, so they just act as the last protection.
So, what the problem? On ether1 it's ok, you only needed to avoid it on LTE interface. Or it also shows up on LTE interface? Disabling IPv6 forward won't harm.
Does this have an effect? Disconnect from packet domain service.
/interface/lte/at-chat input="AT+CGATT=0" lte1
With 4G and newer there's a general problem: everything, including SMSes, depend on data bearer being established. And in 3gpp nomenclature, data bearer is the "virtual" chanel carrying data (as opposed to voice channel which existed up to and including 3G ... which carried voice and SMSes as well).
So when disabling data throughly, like by executing AT+CGATT=0 , one also cuts the transport for SMSes.
With 4G and newer, the only way of preventing (too much) data flow without effectively switching data card off is to block unwanted data to pass ... and that's where firewall and routing work fine.
And one might want to create a special interface list just for that. Reasons:
- interface list WAN might contain some other WAN interface (either ether or wireless) and one doesn't want to block that WAN
- one might be tempted to use interface lte directly in the firewall filter rules. But if one wants to allow traffic via that interface, it's then necessary to disable many rules. If one uses interface lsit, it's enough to remove lte interface from that list and any firewall rule referring to that lsit doesn't affect traffic via lte interface any more (but then one woudl have to add lte interface to WAN interface list to allow proper functions - both firewall filtering as well as NAT).
I'm not 100% sure the goal here.
But another approach is you can put the modem into serial mode via LTE settings, which disable the lte interface entirely, but provide a serial port, so there be no potential for internet traffic but /tool/sms should still work.
Tried this, no effect, interface still works.
AT+CGATT=0 doesn't have any effect either.
May be it depends on specific model.
Did you reboot after changing it? I think switching LTE mode from auto/mbim/serial requires a reboot.
Otherwise, @mkx is right... SMS uses data, and with right firewall rules you should be able block internet traffic from router/LAN.
Ohh, my bad. Yes, after reboot it has become inactive. Sorry.
Well, It should prompt for reboot IMO...
1 Like
How does it solve Android? If i remember correctly I can disable data service and still receive sms.
I'd say it disables routing via LTE interface.
It's similar (but not the same) as when device has WiFi connection established. And then there's the "data connection optimization" where it probably does some dual-wan magic to distribute traffic over both WiFi and mobile.
Unless one clicks that airplane icon ... in which case it probably detaches from network (or even powers off the LTE module).
Sorry about the double and triple comments. Do you still get a notification if I use the general âreplyâ and quote multiple replies?
Great idea, thanks!
I created a new list (+) in Interfaces - Interfaces List - Lists with nothing included or excluded, then added that (+) to the general list once for the bridge (and also for wifi but disabled that entry for now).
Just tried to remove the LTE APN (no âdisableâ option) and it doesnât allow me to do that either:
Couldnât remove LTE APN - not permitted (9)
There is a ticked setting in the APN: âUse Network APNâ
Would disabling that work maybe? Otherwise, firewall filter it is, unless someone else has got a different idea.
I disabled IPv6, so still getting packets through that is ⌠weird.
The default is "use-network-apn=yes" or that checkbox ticked as most (but not all) SIM's provide automagically the "right" APN.
But you can untick that item (or set "use-network-apn=no") and provide manually an APN.
If you set "use-network-apn=no" but not provide the APN manually you are preventing the lte from getting an internet connection (the lte interface won't get an IP address, etc.).
Whether this will affect SMS sending or not, it is to be seen.
Disable internet access through the sim card, so I wonât have to pay extra for that extra, but still allow SMS to be sent through the same sim card.
How does that effect how SMS are sent and what mode is it in by default?
Iâve been using a USB modem for now through its serial port and Iâve noticed that it becomes quite unstable after a day or two. Havenât been able to test the kit for longer periods of time yet but I do hope that e.g. mbim mode is a lot more reliable.
@teslasystems As you already tried that command, have you also tried sending an sms yet? Did it work?
Makes sense. Done. Thanks for the warning!