Isolating Mikrotik LAN Ports With Queue Support

When I last time did LAN port isolation, it seemingly ended with a success. And yes, I have ran with that config for a while without problems. However, at one point, I decided to implement bandwidth limits per port using queues. However, a speed test has shown that while download speed looking from WAN side was throttled, my maximum upload speed wasn’t observed.

I won’t get too much into why it is so. It’s sufficient to say you cannot set upload speed on interface if it is a slave. Guess what, interfaces belonging to a bridge are slaves. It doesn’t matter if you place each interface in its separate bridge - as was my first attempt - while your upload will be throttled, your download limiting will not work.

The only configuration I’ve found working was to have each interface manage its own network - thus each being the master.

The easiest way to configure this is to enter commands into New Terminal from WinBox. I will write commands assuming all bridges, their ports, and each mentioned section are completely empty as we start.

First we need to give a separate IP to each interface facing our internal LAN:

/ip address
add address=192.168.1.1/24 interface=ether2 network=192.168.1.0 disabled=no
add address=192.168.2.1/24 interface=ether3 network=192.168.2.0 disabled=no
add address=192.168.3.1/24 interface=ether4 network=192.168.3.0 disabled=no
add address=192.168.4.1/24 interface=ether5 network=192.168.4.0 disabled=no

Next we define multiple DHCP pools - in this case 4 of them:

/ip pool
add name=pool1 ranges=192.168.1.10-192.168.1.99
add name=pool2 ranges=192.168.2.10-192.168.2.99
add name=pool3 ranges=192.168.3.10-192.168.3.99
add name=pool4 ranges=192.168.4.10-192.168.4.99

Of course, adding a separate DHCP server for each of these pools is needed:

/ip dhcp-server
add name=server1 interface=ether2 address-pool=pool1 disabled=no
add name=server2 interface=ether3 address-pool=pool2 disabled=no
add name=server3 interface=ether4 address-pool=pool3 disabled=no
add name=server4 interface=ether5 address-pool=pool4 disabled=no

DHCP network for each follows:

/ip dhcp-server network
add address=192.168.1.0/24 gateway=192.168.1.1 netmask=24
add address=192.168.2.0/24 gateway=192.168.2.1 netmask=24
add address=192.168.3.0/24 gateway=192.168.3.1 netmask=24
add address=192.168.4.0/24 gateway=192.168.4.1 netmask=24

Quick stop to verify routes is in order. Assuming you all is done correctly four new dynamic routes should appear (it is ok for disconnected ports to have distance 255):

/ip route print
 Flags: X - disabled, A - active, D - dynamic,
 C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
 B - blackhole, U - unreachable, P - prohibit
  #      DST-ADDRESS     PREF-SRC         GATEWAY      DISTANCE
  0 ADS  0.0.0.0/0                        192.168.0.1         1
  1 ADC  192.168.1.0/24  192.168.101.250  ether2              0
  2  DC  192.168.2.0/24  192.168.102.250  ether3            255
  3 ADC  192.168.3.0/24  192.168.103.250  ether4              0
  4 ADC  192.168.4.0/24  192.168.104.250  ether5              0
  5 ADC  192.168.0.0/24  192.168.0.14     ether1              0

Assuming you don’t have NAT masquarade setup from before, let’s setup one now. If you do have it already in IP Firewall NAT, simply skip this step:

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1 disabled=no               

After all this we can finally add traffic limiting queues. In my case the first two ports didn’t have any limits, third had 1 Mbit/s upload and download, and the last interface had 128 kbits/s upload and 256 kbits/s download:

/queue simple
add name=queue1 target=ether2 max-limit=0/0
add name=queue2 target=ether3 max-limit=0/0
add name=queue3 target=ether4 max-limit=1M/1M
add name=queue4 target=ether5 max-limit=128k/256k

To isolate LAN ports we again use the firewall rules allowing the new connections only toward ether1 (WAN) interface:

/ip firewall filter
add action=accept chain=forward connection-state=established comment="Allow established"
add action=accept chain=forward connection-state=related comment="Allow related"
add action=accept chain=forward out-interface=ether1 comment="Allow WAN"
add action=drop chain=forward comment="Drop everything else"

PS: There is quite nice guide at Networking For Integrators. They use a quite similar approach for the purpose of segregating multiple networks.

The Grand Tour

It took them a while.

Yes, finally the Top Gear Grand Tour guys are back and those fortunate enough to either have Amazon prime or torrent can watch the first episode of the brand new show.

Is it same as Top Gear? It is precisely far enough to be legally safe. There is no Stig - instead of him there is a Nascar driver that wouldn’t shut up. There is no lap board - although there is an LCD screen with times on it.

However, based on the intro and the first episode, interesting parts are still in. There are still (super)car-based competitions with fun scoring systems, crazy challenges, testing track located in England, a lot of bantering, and an overall interesting show.

Captain slow, Hamster, and the old Ape are back.

RetroHat

Raspberry Pi is often used for retro-arcade machines. It really fits well there: low power usage, reasonable emulation software support (it is based on Linux after all), more then capable processor, and really cheap price ($35). It is hard to beat this.

What surprised me is that I couldn’t find proper Raspberry Pi HAT that could be used to treat buttons as a keyboard. Yes, there are guides how to setup buttons, but they don’t do auto-detection and require a bit too much setup for my taste.

There are also USB devices to which you can connect buttons but I find them a bit annoying to deal with in physical sense. While they do offer huge amounts of buttons, them sticking out of Raspberry’s side is always ugly to see.

What I wanted to build was maximum amount of buttons I can get away with using only natural HAT connections and without the need for any driver not available out-of-box. Of course, it should be a proper HAT with EEPROM, auto-configuring everything needed as soon as machine is booted.

First of all, with number of available pins on HAT connector it became clear there is a hard maximum at 24 buttons. Assuming 2 players, that comes to a joystick and 8 buttons (A, B, X, Y, L, R, Start, and Select) per player.

As HAT gives you quite respectable surface to work with, connectors for these buttons could also include a LED support at the cost of few resistors. Moreover, a discrete (fused) connector for both 5 V and 3.3 V rail was added. While neither is intended for heavy use, it comes in handy for powering various extra components in your retro-cabinet.

For keyboard emulation, this HAT uses a built-in support for GPIO keys. As long as you connect momentary button between GND (-) and pull-up input (S) it will detect each press as the transition from high to low and simulate the appropriate button. Default keyboard configuration is selected in such manner that player 1 configuration matches default RetroPie settings while all keys for player 2 are assigned numbers 0 to 9.

Of course, you can configure all this just by modifying retrohat.dts, a file whose creation took probably more time than board design, soldering, and everything else. But it was worth it to get auto-configuration running once EEPROM is programmed. To get more information on how to program the auto-configuration EEPROM, you can either go over read-me file or check how I did it for Cananka.

In any case, check project’s page for a short description and to find link to source files so you can build your own.

Enabling HTTPS on MikroTik

Mikrotik and its WinBox interface are virtually inseparable. Most people use it without thinking of any other option. However, Mikrotik supports also has (quite a good) HTTP interface and it also supports a (disabled by default) HTTPS access.

Enabling HTTPS is unfortunately not a straightforward experience.

The easiest way to configure this is to enter commands into New Terminal from WinBox. I will simply repeat commands needed instead of going through the screens. Commands are actually quite descriptive and easy to “translate” into GUI actions if that is your preference.

For HTTPS to work we need to create two certificates, master and apprentice. Ok, actually we need root and HTTPS certificate but master and apprentice sounds much cooler ;):

/certificate
add name=root-cert common-name=MyRouter days-valid=3650 key-usage=key-cert-sign,crl-sign
sign root-cert
add name=https-cert common-name=MyRouter days-valid=3650
sign ca=root-cert https-cert

With certificate signed, we just need to assign it to www-ssl service and enable it, while disabling non-https variant:

/ip service
set www-ssl certificate=https-cert disabled=no
set www disabled=yes

And that’s it. Now you can access your router via HTTPS.

PS: Never use unencrypted interface like HTTP or FTP toward your router. Your password will travel plain-text and risk is not worth 5 minutes it takes to enable TLS encryption.

OshPark Vs PCB:NG

For feeding my electronics addition I mostly use OshPark. They have quick turnaround, excellent user service, and price is quite acceptable.

However, they are not the only game in town. Probably the best alternative if you are willing to wait a bit is unsurprisingly in China. Yes, I am speaking about Seeed Studio’s Fusion PCB. It is not exactly comparable to OshPark but it is close enough for many purposes. And it is excellent choice if you need different PCB colors - something OshPark doesn’t offer.

But times are changing and there is a new challenger on US soil - PCB:NG. They are PCB assembly house - something that is a bit too pricey in low quantities and something I personally never needed. But they do offer a possibility to order only PCBs.

PCB specifications are quite high-end: ENIG finish (I love this), 4/4 mil traces (vs 6/6 for OshPark), 8 mil vias (vs 13 mil), and they generally support cutouts and slots (although no promises here). As I generally don’t go lower than 8/8, I find them working equally well for my use case.

Price is $6 per inch for 6 boards, compared to $5 per inch for 3 boards OshPark offers - quite similar if you only need a few but PCB:NG wins at higher quantities.

Order process is simple enough and I had no issues with DipTrace 3.0 produced gerbers - something that might fail occasionally with OshPark (e.g. my PCB bear). I would say parser is definitely more forgiving with PCB:NG. I kept all file names setup as for OshPark and there were no issues. Your mileage might vary but I don’t expect anything unsurmountable as you can correct auto-detection yourself. And no, neither PCB:NG nor OshPark support RAR.

First thing you’ll notice when you get a board is attention to packing. There is a nice layering of red paper between each board and there is virtually no chance of them scraping one another. While I am not sure that matters as I never had any issues with loose boards arriving from OshPark, this does look a bit nicer.

What you will see after unpacking is a dark red colored board. I have ordered two within a few weeks and shade is a bit different. It is similar experience to year’s back when OshPark was testing other factories - I am sure shade will become constant very soon if it is not already. Just be mindful if you need exactly the same shade to order all boards at the same time.

All boards come fully broken out - unlike with OshPark where you can still see breakout tab pieces. Tabs themselves seem nicely defined and PCB:NG puts less of them than OshPark. Generally I have less work filing the rough edges then with OshPark. Somebody less nitpicky would be able to use them without filing altogether.

Silkscreen is not bad but white on red makes it less visible than white on dark purple OshPark uses. If you need good silkscreen visibility (e.g. user visible panels) you should probably go with OshPark.

I am not sure whether it was a fluke or standard practice but PCB:NG placed their custom markings on my silkscreen. This is something done by Seeed Studio and most low-cost services as it makes their process a bit easier. OshPark doesn’t do it and I was surprised when I saw PCB:NG doing it. However, on my second board I had no custom markings so they seem to have abandoned this vandalism.

When it comes to copper quality I can really say nothing bad about either PCB:NG or OshPark. Both have nice ENIG finish, neither had issue with traces or solder masks, both can handle hand lead-free soldering without much trouble. If there wasn’t a color difference, I wouldn’t be able to tell them apart.

For me it comes to two things. If board is meant for user visible panel (e.g. end panel for plastic enclosures) I find purple, almost black, OshPark gives fantastic look to a final device.

Where PCB:NG wins is price. As soon as you go over 3 boards OshPark offers, you are better off using PCB:NG. And, if you want some assembly, there is no content at all. PCB:NG is the one that offers low volume assembly.

As I usually do extremely low volume orders (often making just one or two devices) I will probably stick with OshPark. There is something to be said about familiarity. However, PCB:NG is a high-quality contender and worth trying out (remember 4/4 mil traces) - even at a fraction higher cost for a small volume.