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.

Adding Mikrotik DDSN as a Subdomain

Illustration

If you need remote access, one of things you’ll notice about Mikrotik devices is there is no support for DDNS. Yes, you could always create a script for it but there is nothing built-in.

However, Mikrotik does offer quite similar functionality out-of-box for a year now. In Cloud menu you just select DDNS enabled and Mikrotik your public IP will be located at <serial>.sn.mynetname.net. It is not as nice as having custom name with DynDNS, but usable nonetheless.

However, if you have your own domain, you can make it a bit more friendlier. Find where you can edit DNS entries at your registrar (Manage Domain with DreamHost) and add a new CNAME entry. For name you can put whatever you want and for value put Mikrotik’s DNS name (<serial>.sn.mynetname.net).

After a few minutes (damn DNS propagation :)) you’ll see your DNS entry working.

PS: You can verify status with nslookup myname.mydomain.com.

Cananka, the Raspberry Pi HAT: Problems

Illustration

[This the last post in the series.]

Mistakes? I’ve made a few…

The very first one was noticed after I’ve already sent order to OSH Park. For back-powering isolation where 2 A are needed, I used the same footprint as for 100 mA DC-to-DC voltage regulator. There is no chance of getting a part that would support 2 A in such a small package. I’ve replaced it with properly sized 1x1" isolated voltage regulator and contacted OSH Park support. As my original order was not sent to fabrication facility yet, I got it swapped with a new design without any additional cost. OSH Park support rocks!

While waiting for a board, I continued going over the design and thus I’ve noticed I’ve forgotten to pull-up the reset line. Uncaught it would cause chip not to function so respin was definitely needed. Additionally I’ve changed layout of board a a bit alongside making a slightly bigger cuts to allow for official case to carry the board. I find it amusing that HATs made in accordance with official specification don’t fit the official case. :)

What I didn’t catch was that my new DC-to-DC brick needs a bit bigger holes. It was possible to get DC-to-DC converter in the board but with a lot of elbow grease. Definitely not what you would want. I also didn’t notice I had damn pinout backward on one side of the chip. And guess what, since I’ve already sent for revision B to be manufactured, I couldn’t change it before revision C.

I did try to mod-wire the revision A of the board but important traces to cut were under the DC-to-DC brick itself so there was no approaching them - not with tight drill holes I had. Fortunately I was able to jump the missing reset line and thus have a proof of concept all is working well.

Revision B arrived when I was already preparing for next revision due to already mentioned faults and thus I have just populated the “cheap” part of the board. It made no sense to mount $25 DC-to-DC voltage regulator if I know it is not going to work. Revision C did have few other changes to silk-screen and other minor changes. Most notable change, outside of DC-to-DC pinout correction, was changing EEPROM to be write protected when WP jumper was soldered over.

Original suggested EEPROM circuit makes write-protection to be default. This means you need to connect the jumper to write chip and then desolder it later to make it read-only. I find it much easier on me if all chips start with being writable and then you make solder bridge to make them read-only. Additionally, as chip has internal pull-up, this means you save a resistor. :)

As revision C came, all seemed great until I tried power-back circuit - it didn’t work. Short troubleshooting later I’ve noticed my reading of remote on/off functionality was lacking a bit and thus I was missing connection of that pin to ground. With that single change power-back started working perfectly. Of course that meant revision D had to be made.

D? No issues what-so-ever. :)

Isolating Mikrotik LAN Ports

Illustration

For a home project of mine, I have decided on Mikrotik’s hEX PoE lite due to its awesome capability to power other devices.

Outside of PoE, I needed a standard Internet router - WAN on port 1 and LAN on other ports - but with a twist. I wanted to have LAN ports isolated from each other while still being able to access WAN. Something that on almost any wireless box you get as a checkbox turned out to be a actually non-existent.

However, beauty of a bit more manageable and complicated device is that you can define a lot of functionality yourself. For this particular scenario, solution was in adjusting the firewall.

To setup firewall, the easiest way is to connect via WinBox and go into New Terminal. There we can just execute following commands:

/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"

First two allow any established and related connection unconditionally. Third one allows anything going out to WAN interface. Packets coming into that interface will have to be either established or related so there is no reason for another accept there. Final rule is to drop all other traffic.

With just these four rules, all LAN ports are isolated while still being capable of Internet acess.