The official Mikrotik router thread

Leno said:
You cant have fastrack enabled with PCC - fasttrack ignores mangle rules

Code: 
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes packet-mark=no-mark

edit : Noticed now your packet-mark=no-mark
Click to expand...

I think the internet dies as at the moment you switch it on, there are some connections already established and with no-mark - those will cause the problem I think

You can try disable your internet interfaces, enable fast track and enable the interfaces so new connections are established in the firewall table

With PCC you are marking most (if not all) traffic so there isnt really any point to have this rule
Unless you just mark your second non default connection as I described a page or 2 back

Worth a try without that fast track rule
 
Leno said:
sorry its early didnt notice this isnt the PCC script :p
Click to expand...
@PhireSide (Tagging you as well)

Here is the updated script with the PCC/nth rules

pastebin.com

# dec/12/2021 07:32:39 by RouterOS 7.1# software id = KT3Q-QGSG## model = - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
pastebin.com pastebin.com

I've disabled Fast track, the moment I enable these rules and disable the default route the Internet dies. I followed this guy's example: https://www.daryllswer.com/multi-wan-setups-with-retail-isps-part-2-implementation-using-routeros/

Fast track disabled

1639287633468.png
NAT

1639287667605.png

Mangle (Disabled to make Internet work)

1639287692329.png

Routing rules

1639287736139.png

Windows Trying to ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 192.168.1.1: Destination net unreachable.
Reply from 192.168.1.1: Destination net unreachable.
Reply from 192.168.1.1: Destination net unreachable.
Reply from 192.168.1.1: Destination net unreachable.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

My thinking
The output rules at the bottom (mangle) never get any traffic and so I think it probably has something to do with that, but I have no idea where to start debugging or what to check.

Any suggestions?

EDIT: I've tried disabling the NAT rules that force everything through my pi hole dns, I've removed the default peer dns on PPPOE and tried 1.1.1.1/8.8.8.8 in the DNS rules as I thought it might be a dns lookup issue, but that also made no difference. (That was before I tried to ping google's dns - no lookup required)

EDIT2: I've tried to change the rules to allow for one interface only, e.g only route to ISP 1, change PCM/nth rules for 1 connection, and that also did not work. I have however noticed something odd with manual routes. If I make a manul route with "main" mark (and remove default route) and other rules disabled then the Internet also does not work, so it might actually be something with the routes and not the firewall rules
 

Attachments

  • 1639287755538.png
    1639287755538.png
    70 KB · Views: 15
Last edited:
@Cactus

Can you try enable the fib on your route tables

my route tables:

Code: 
/routing table
add fib name=dummy
add fib name=wireguardmik
add fib name=rain
add fib name=nordvpn
 
Leno said:
@Cactus

Can you try enable the fib on your route tables

my route tables:

Code: 
/routing table
add fib name=dummy
add fib name=wireguardmik
add fib name=rain
add fib name=nordvpn
Click to expand...
This did not make a difference :(

I did however notice now that I have to constantly enable and disable the routing rule otherwise the Internet dies every couple of seconds (one isp only, mangle rules disabled). Something funky going on here, the default route works fine. The below should be a drop replacement for the default one. Let me go find out if ROS v7 has some routing bugs perhaps....I'll be back

EDIT: Removing the "ping" option from this stops the route from dying every couple of seconds. That's very weird.

EDIT2: Ok so with the custom routes and all mangle rules enabled, one ISP does work at a time, BUT it needs to have the "main" mark in route so it does not actually route through the correct mark. At least the connection does not die anymore with the mangle rules. Slowly getting somewhere...

1639294854890.png
 
Last edited:
Here is my simplified pcc config which works, without all the default and lan config

In practise I didnt pcc the rocketnet traffic, I just pcc 50% of the traffic to rain and the rest follows the dafult/main table routing
You will notice my main routes are higher than 1, to allow me to force traffic to a certain connection for smokeping etc
Im not load balancing at the moment as Frogfoot has had so many problems here the constant switching between them and rain was causing headaches etc, Im just using failover now

pastebin.com

pcc - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
pastebin.com pastebin.com
 
Cactus said:
This did not make a difference :(

I did however notice now that I have to constantly enable and disable the routing rule otherwise the Internet dies every couple of seconds (one isp only, mangle rules disabled). Something funky going on here, the default route works fine. The below should be a drop replacement for the default one. Let me go find out if ROS v7 has some routing bugs perhaps....I'll be back

EDIT: Removing the "ping" option from this stops the route from dying every couple of seconds. That's very weird.

View attachment 1211302
Click to expand...
You dont need check gateway on a pppoe connection, the Keepalive Timeout on the status tab takes care of that. Once the connection drops the routes etc will be removed/ignored
Core routers normally drop ICMP/ping traffic when cpu load is high so ping may fail often
 
Leno said:
Here is my simplified pcc config which works, without all the default and lan config

In practise I didnt pcc the rocketnet traffic, I just pcc 50% of the traffic to rain and the rest follows the dafult/main table routing
You will notice my main routes are higher than 1, to allow me to force traffic to a certain connection for smokeping etc
Im not load balancing at the moment as Frogfoot has had so many problems here the constant switching between them and rain was causing headaches etc, Im just using failover now

pastebin.com

pcc - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
pastebin.com pastebin.com
Click to expand...
Let me see what the difference is between yours and mine. Thanks!

EDIT: I've tried your config as well, the moment I change any route to use anything other than "main" as the routing mark everything dies. I'll try a little bit later again. Thanks for your help! :)
 
Last edited:
Leno said:
You dont need check gateway on a pppoe connection, the Keepalive Timeout on the status tab takes care of that. Once the connection drops the routes etc will be removed/ignored
Core routers normally drop ICMP/ping traffic when cpu load is high so ping may fail often
Click to expand...
Did not know this, learned something new, thanks :)
 
Edit: Seems to be working ok. Not great that OpenServe has become Frogfoot 2.0 in my area at night, but daytime seems ok.

 
Last edited:
Very recently there has been some sorcery going on with my Sonoff devices on our network.

We have a handful of Eachen/Sonoff light switches that are linked up with Google Home, and we have always had an issue with one of them (10.0.0.194 in this list) that kept on losing and requesting a DHCP lease. As of a few nights ago, all of the Sonoff/Eachen devices are now doing it! You can see the Google-Home-Mini has a lease that still has 8h17 before it expires, but everything below that is the smart home devices and they are constantly renewing their leases:

1642244891255.png

Has anyone else had something similar happen recently? They connect to a dedicated IoT SSID via an Unifi AP that runs 2.4GHz only. I can connect to this SSID with my phone or a laptop and it works just fine. It might be worth noting that i run static IP's for all the devices on the main 5GHz network, which is why the range for the switches are all from 188 and up.

At the moment I am suspecting foul play on the Unifi side of things, but I thought I'd post up here for good measure.
 

Attachments

  • 1642244676079.png
    1642244676079.png
    131.8 KB · Views: 17
PhireSide said:
Very recently there has been some sorcery going on with my Sonoff devices on our network.

We have a handful of Eachen/Sonoff light switches that are linked up with Google Home, and we have always had an issue with one of them (10.0.0.194 in this list) that kept on losing and requesting a DHCP lease. As of a few nights ago, all of the Sonoff/Eachen devices are now doing it! You can see the Google-Home-Mini has a lease that still has 8h17 before it expires, but everything below that is the smart home devices and they are constantly renewing their leases:

View attachment 1227476

Has anyone else had something similar happen recently? They connect to a dedicated IoT SSID via an Unifi AP that runs 2.4GHz only. I can connect to this SSID with my phone or a laptop and it works just fine. It might be worth noting that i run static IP's for all the devices on the main 5GHz network, which is why the range for the switches are all from 188 and up.

At the moment I am suspecting foul play on the Unifi side of things, but I thought I'd post up here for good measure.
Click to expand...

I am having the EXACT same thing happening as of a few nights ago as well, I suspect there is a server related issue on the sonoff side and that the devices are renewing their leases because they cant reach the server, but I could be wrong.

I thought it was just happening to me until I saw your post now.
 
Jason-ZA said:
I am having the EXACT same thing happening as of a few nights ago as well, I suspect there is a server related issue on the sonoff side and that the devices are renewing their leases because they cant reach the server, but I could be wrong.

I thought it was just happening to me until I saw your post now.
Click to expand...
Yes! About three or four nights ago by me as well. Would you mind sharing your setup so we can maybe see if we have some commonality between our systems?

I'm running a Mikrotik router, a Unifi AP, and 2x PiHole devices serving DNS around the house. Creating a static lease for the devices seem to do naught-all to the issue, but I haven't fiddled with Unifi settings yet (my controller runs in Docker that auto-updates so an update could have borked things).

EDIT: We aren't alone
 
Maybe a firmware update on sonoff side of things
 
PhireSide said:
Yes! About three or four nights ago by me as well. Would you mind sharing your setup so we can maybe see if we have some commonality between our systems?

I'm running a Mikrotik router, a Unifi AP, and 2x PiHole devices serving DNS around the house. Creating a static lease for the devices seem to do naught-all to the issue, but I haven't fiddled with Unifi settings yet (my controller runs in Docker that auto-updates so an update could have borked things).
Click to expand...

I'm also running a mikrotik router, and have 3 APs around the house (1x UniFi LR AP, 1x Mikrotik AP, 1x TP-Link AP) we have sonoff devices all over the house so all 3 APs have got sonoff devices connected to them (and they are all giving issues).

DHCP leases on my network are configured to last 7 days, so you can see they all have fresh IPs.

1642246086050.png


Edit: for DNS I am running software called DNSMASQ which queries both my ISPs DNS & my own DNS resolver and whichever returns the query 1st is the one that gets used, works nicely as a failover incase my ISPs DNS fails for some reason.
 
Last edited:
PhireSide said:
Official response from Ewelink:
Is this the final straw that pushes me to Home Assistant?:unsure:
Click to expand...
I flashed all my sonoff devices with tasmota.

Tasmota Documentation - Tasmota

Open source firmware for ESP devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, serial or KNX.
tasmota.github.io tasmota.github.io

It works well with Home assistant if you ever go that route
 
Cactus said:
I flashed all my sonoff devices with tasmota.

Tasmota Documentation - Tasmota

Open source firmware for ESP devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, serial or KNX.
tasmota.github.io tasmota.github.io

It works well with Home assistant if you ever go that route
Click to expand...
What do you need for that? I seem to recall reading/hearing that you need an Arduino to connect with it, with perhaps some light soldering as well?
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X