Archive for the ‘routers’ Category
Posted by jpluimers on 2023/04/13
MikroTik switches and routers are very flexible to configure, as everything is done through [Wayback/Archive] RouterOS settings.
This means that given enough ports, you can split a physical switch into logical switches. This can be very convenient when you run multiple networks without VLAN.
Earlier this week, I already wrote about Torching a specific port on a MikroTik switch or router running RouterOS which involved turning off hardware acceleration off for specific ports in order to have the flow through the underlying switch chip prohibiting torch and filter features.
For splitting noticing which ports are connected to which switch chip is also important: splitting works best if you can configure each logical switch to exclusively use network ports on one switch chip.
This post was to both research how to configure this, and if my MikroTik devices would allow for hardware acelleration.
Here are some links that should help me with configuring (via [Wayback/Archive] mikrotik split switch in two – Google Search):
–jeroen
Read the rest of this entry »
Posted in Development, Hardware, MikroTik, Network-and-equipment, Power User, RouterOS, routers, Scripting, Software Development | Leave a Comment »
Posted by jpluimers on 2023/04/11
On most recent [Wayback/Archive] RouterOS configurations of MikroTik Routers and Switches, running [Wayback/Archive] Torch a port will show zero traffic when they are part of a bridge configuration. The same holds for the Packet Sniffer.
The reason is that these bridges have hardware acceleration turned on, which makes all traffic go through the switch chip instead of the device CPU. Torch works on the CPU level, so won’t show hardly any traffic except for some configuration stuff (depending on the combination of switch chip and CPU type).
This is not documented in the Torch documentation, but it is documented in the Packet Sniffer documentation.
Further reading:
- [Wayback/Archive] Manual:Troubleshooting tools – Torch – MikroTik Wiki
- [Wayback/Archive] Manual:Tools/Packet Sniffer – MikroTik Wiki
Note: Unicast traffic between Wireless clients with client-to-client forwarding enabled will not be visible to sniffer tool. Packets that are processed with hardware offloading enabled bridge will also not be visible (unknown unicast, broadcast and some multicast traffic will be visible to sniffer tool).
- [Wayback/Archive] mikrotik nonhardware bridge – Google Search (yes that was a typo, but Google still got good results)
- [Wayback/Archive] Can not see trafic in TORCH – MikroTik
As the ethernet ports are marked as S(laves) in the tables, I would assume that they are member ports of bridges and “hardware acceleration” is enabled (the value of hw in the respective rows of /interface bridge port is set to yes). So any frames which pass through these ports to other ports of the same switch chip are counted by the switch chip counters, but as they never get to the CPU, the torch cannot see them.
- [Wayback/Archive] mikrotik torch ip ports of bridge – Google Search
- [Wayback/Archive] Manual:Layer2 misconfiguration; Packet flow with hardware offloading and MAC learning – MikroTik Wiki
Consider the following scenario, you setup a bridge and have enabled hardware offloading in order to maximize the throughput for your device, as a result your device is working as a switch, but you want to use Sniffer or Torch tools for debugging purposes, or maybe you want to implement packet logging.
- [Wayback/Archive] Manual:Layer2 misconfiguration; Packet flow with hardware offloading and MAC learning; Configuration – MikroTik Wiki
/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 hw=yes interface=ether1 learn=yes
add bridge=bridge1 hw=yes interface=ether2 learn=yes
- [Wayback/Archive] Manual:Layer2 misconfiguration; Packet flow with hardware offloading and MAC learning; Problem – MikroTik Wiki
When running
Sniffer or
Torch tool to capture packets you might notice that barely any packets are visible, only some unicast packets, but mostly broadcast/multicast packets are captured, while the interfaces report that much larger traffic is flowing through certain interfaces than the traffic that was captured.
Since RouterOS v6.41 if you add two or more Ethernet interfaces to a bridge and enable Hardware Offloading, then the switch chip will be used to forward packets between ports. To understand why only some packets are captured, we must first examine how the switch chip is interconnected with the CPU, in this example we can use a block diagram from a generic 5-Port Ethernet router:
For this device each Ethernet port is connected to the switch chip and the switch chip is connected to the CPU using the CPU port (sometimes called the
switch-cpu port).
For packets to be visible in Sniffer tools, the packet must be sent from an Ethernet port to the CPU port, this means that the packet must be destined to the CPU port (destination MAC address of the packet matches the bridge’s MAC address) or the packet’s MAC address has not be learnt (packet is flooded to all ports), this behavior is because of
MAC learning·
The switch chip keeps a list of MAC addresses and ports called the
Hosts table· Whenever a packet needs to be forwarded, the switch chip checks the packet’s destination MAC address against the hosts table to find which port should it use to forward the packet.
If the switch chip cannot find the destination MAC address, then the packet is flooded to all ports (including the CPU port). In situations where packet is supposed to be forwarded from, for example, ether1 to ether2 and the MAC address for the device behind ether2 is in the hosts table, then the packet is never sent to the CPU and therefore will not be visible to
Sniffer or
Torch tool..
- [Wayback/Archive] Manual:Layer2 misconfiguration; Packet flow with hardware offloading and MAC learning – MikroTik Wiki
Packets with a destination MAC address that has been learned will not be sent to the CPU since the packets are not not being flooded to all ports. If you do need to send certain packets to the CPU for packet analyser or for Firewall, then it is possible to copy or redirect the packet to the CPU by using ACL rules. Below is an example how to send a copy of packets that are meant for 4C:5E:0C:4D:12:4B:
/interface ethernet switch ruleadd copy-to-cpu=yes dst-mac-address=4C:5E:0C:4D:12:4B/FF:FF:FF:FF:FF:FF ports=ether1 switch=switch1
Note: If the packet is sent to the CPU, then the packet must be processed by the CPU, this increases the CPU load.
- [Wayback/Archive] mikrotik torch mac address – Google Search
–jeroen
Posted in Development, Hardware, MikroTik, Power User, RouterOS, routers, Scripting, Software Development | 1 Comment »
Posted by jpluimers on 2022/08/12
From [Wayback Archive.is blog — Why has the URL “archive-li” changed to…:
Why has the URL “archive-li” changed to “archive-ph”, and will this affect saved bookmarks at any time in the future?
Anonymous
This is temporary and only for some countries. All 7 domains work, so you do not need to change the bookmarks.
In The Netherlands all Archive Today domains redirect to archive.ph using a HTTP 302 redirect.
This caused trouble at my home location, but not at my brother, so I searched for local issues.
In the end, it was because I have dual WAN as network load balancing at home.
TL;DR
Modifying the routing table so traffic for 54.37.18.234 goes to WAN1 was my solution.
Finding the destination address
Read the rest of this entry »
Posted in .NET, Development, Hardware, Network-and-equipment, Power User, PowerShell, routers, Scripting, Software Development | Leave a Comment »
Posted by jpluimers on 2022/08/05
I tried the solution in [Wayback/Archive.is] Fritz!box 7590 interface extremely slow : fritzbox (remove the some 30-40 unused machines from the network overview), but it didn’t matter: since Fritz!OS 7.x, the Fritz!Box 7490 UI is just very very slow: each page takes 10+ seconds to load.
Hopefully I can get rid of these and move to pfSense based hardware eventually.
–jeroen
Posted in Fritz!, Fritz!Box, Hardware, Network-and-equipment, pfSense, Power User, routers | Leave a Comment »
Posted by jpluimers on 2022/03/08
Since this is what I use to VPN home:
pfSense is a free and open source firewall and router that also features unified threat management, load balancing, multi WAN, and more
[Wayback] Download pfSense Community Edition: [Wayback] pfSense-CE-2.5.1-RELEASE-amd64.iso.gz
–jeren
Posted in Internet, pfSense, Power User, routers | Leave a Comment »
Posted by jpluimers on 2022/01/20
For quite some time now, Chrome (think years) refuses to prompt for saving passwords whereas Firefox and Safari do prompt and save them, even for site types that it used to save passwords for in the past.
It has been annoying enough for too long now that I tried to do better than the Google searches I used back when I saw this happen first.
Below are some links based on new searches (starting with [Wayback] adding a password in chrome settings – Google Search); hopefully I can try them after I made a list of sites that Chrome does not show the password save prompt for.
Solutions I tried that failed (but maybe useful for others):
Solutions still to try:
Read the rest of this entry »
Posted in Chrome, Chrome, Communications Development, Development, Encryption, ESXi6, ESXi6.5, ESXi6.7, Firefox, Fritz!, Fritz!Box, Fritz!WLAN, Google, https, HTTPS/TLS security, Internet, Internet protocol suite, Let's Encrypt (letsencrypt/certbot), Power User, routers, Safari, Security, TCP, TLS, Virtualization, VMware, VMware ESXi, Web Browsers, Web Development | Leave a Comment »
Posted by jpluimers on 2021/12/31
A few notes:
- WinBox configuration files are under
%APPDATA%\Mikrotik\Winbox
- The subdirectory
sessions contains binary *.viw files that seem to represent “view” configurations (the positions, dimensions and other properties of the open Windows in a Winbox session) where the * of the name seems to be an IPv4 address of a machine.
- Directories named like
6.40.3-2932358209 and 6.43.13-695307561 contain configuration files that seem to determine what WinBox features a certain RouterOS version should reveal; files in those directories seem to always be these:
advtool.crc / advtool.jgdhcp.crc / dhcp.jghotspot.crc / hotspot.jgicons.crc / icons.pngmpls.crc / mpls.jgppp.crc / ppp.jgroteros.crc / roteros.jgroting4.crc / roting4.jgsecure.crc / secure.jgwlan6.crc / wlan6.jg
- There are binary files
Addresses.cdb and settings.cfg.viw
- A text file named
sessionpath contains the expanded path %APPDATA%\Mikrotik\Winbox\sessions
The *.crc files contain a CRC code, presumably on the contents of the correspoding *.jg file. The *.jg files seem to contain some kind of JSON.
Some links I found:
–jeroen
Posted in Development, Internet, MikroTik, Power User, RouterOS, routers, Scripting, Software Development | Leave a Comment »
Posted by jpluimers on 2021/12/13
I wanted access to a supposedly reset a MikroTik [WayBack] MikroTik CRS109-8G-1S-2HnD-IN, but the default credentials did not work. Somehow, keeping the reset button pushed for almost 20 seconds also did not reset+reboot it.
Luckily, the default PIN code was still 1234 ([WayBack] Manual:LCD TouchScreen: PIN code – MikroTik Wiki) so I could reset it ([WayBack] Manual:LCD TouchScreen: Reboot and Reset Configuration – MikroTik Wiki).
After this, I changed credentials and PIN, documented configuration and credentials, and ensured there is a back-up of that documentation available.
Note: fiddling with power and reset button might have worked, though it is odd the CRS109 documentation does not mention this. PIN code worked faster, so that’s what solved my issue first.
Related:
–jeroen
Posted in Hardware, Internet, MikroTik, Network-and-equipment, Power User, routers | Leave a Comment »
Posted by jpluimers on 2021/09/24
In the past I had these manual scripts to power-cycle a hung RaaspberryPi device:
/interface ethernet poe set ether5 poe-out=off
/interface ethernet poe set ether5 poe-out=forced-on
or on one line:
/interface ethernet poe set ether5 poe-out=off; /interface ethernet poe set ether5 poe-out=forced-on
I am going to try this script for the port having a Raspberry Pi on it (note: this requires a 48V power brick for the Mikrotik!) on RouterOS version 6.48.3 (stable):
/interface ethernet
set [ find default-name=ether5 ] comment="RaspberryPi" poe-out=\
forced-on power-cycle-ping-address=192.168.124.38 power-cycle-ping-enabled=\
yes power-cycle-ping-timeout=2m
The above has not worked for a long time as per [Wayback] No POE Power Cycle @ hEX POE – MikroTik:
But it might be fixed as of [Wayback] RouterOS version v6.47.3[stable] as per [Wayback] MikroTik Routers and Wireless – Software: 6.47.3 (2020-Sep-01 05:24):
…
*) poe – fixed “power-cycle” functionality on RB960GSP;
…
Similar issues exist on RB760iGS/Hex S, and there the fix requires new hardware in addition to firmware as per [Wayback] POE OUT issue on ether5 rb760igs (no power) – MikroTik
Note that I did disassemble both of these routers for inspection and there are obvious changes to the hardware to correct the PoE problems – most notably a completely different relay, capacitor and some minor circuit design changes.
If it still fails, I might try
[Wayback] No POE Power Cycle @ hEX POE – MikroTik: workaround script
:local ipPing ("x.x.x.x")
:local pingip
#
# pingip below RUNS and sets the variable
# to number of successful pings ie 3 means 3 of 45 success
# can also use ($pingip > 1) or ($pingip >= 1) both TESTED
# ($pingip >= 1) means if only 1 or 0 pings do the IF, not the ELSE
#
:log info ("ping CHECK script IS RUNNING NOW")
# first delay 90 b4 ping test incase this is running at POWER UP
:delay 90
:set pingip [/ping $ipPing count=45]
:if ($pingip <= 3) do={ :log warning (">95% lost ping LOSS to isp GW IP x.x.x.x via ether5 so DO POE powerCYCLE")
/interface ethernet poe set ether5 poe-out=off
:delay 12
/interface ethernet poe set ether5 poe-out=auto-on
:delay 10
:log warning ("ether5 POE HAS BEEN TURNED BACK ON")
:delay 90
/system script run emailPOEresult
} else={
:log warning ("PoeCyclePINGcheck ELSE ran so no ping loss detected by script")
}
Based on:
Read the rest of this entry »
Posted in Development, Hardware Development, Internet, MikroTik, Power User, Raspberry Pi, routers | Leave a Comment »
The Wiert Corner - irregular stream of stuff 