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.jg
dhcp.crc / dhcp.jg
hotspot.crc / hotspot.jg
icons.crc / icons.png
mpls.crc / mpls.jg
ppp.crc / ppp.jg
roteros.crc / roteros.jg
roting4.crc / roting4.jg
secure.crc / secure.jg
wlan6.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.
One of the problems in our house is that all PVC conduits embedded in the walls and floors have concrete in them.
It means that when you pull out a cable, you can never get a cable back in (I tried that with the phone cables), and that empty PVC conduits cannot be used at all.
This might be an option to get ethernet to the places that have coax wiring (like the TV outlets)
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.
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.
Cool tool that shows the asymmetric timing character of networks (usually because the send and receive paths are different): [Wayback] Splitting the ping
split-ping is a tool that can tell you what direction packet latency or loss is on. This is handy for network debugging and locating congestion.
The blog above explains the reason and details in great depth. Recommended reading.
* Like ping, but sends packets isochronously (equally spaced in time) in
* each direction. By being clever, we can use the known timing of each
* packet to determine, on a noisy network, which direction is dropping or
* delaying packets and by how much.
*
* Also unlike ping, this requires a server (ie. another copy of this
* program) to be running on the remote end.
The reason is that [Wayback] fritzcap (written in Python) sometimes crashes while doing the conversion of a phone recording, so then only the .pcap file is available. I still want to figure this out, but given my health situation, I might not be able to in time.
"hey @nickoneill, what's your wifi?" "We don't have wifi." "What? You don't have wifi?!" "No, we don't have wifi" … "Goddamnit, Nick." pic.twitter.com/7LO6DoePsO
Wireguard seems more light-weignt and secure than OpenVPN and IPsec. So I’m anxious to know how it is supposed to work for road warriors that often depend on receiving DHCP addresses into the network of the VPN server.
Some links that hopefully get me started to install a Wireguard VPN server and provide services to road warrior clients.
First the Twitter thread that got me investigating:
The Wiert Corner - irregular stream of stuff 