Mikrotik RouterBoard - Kid Control

[Kid Control](https://help.mikrotik.com/docs/spaces/ROS/pages/129531911/Kid+Control) is Mikrotik's name for a parental control layer offered in RouterOS. I'm currently using it as a defense-in-depth/belt-and-braces approach to ensure the kids' screen time isn't getting excessive, as unfortunately it seems Apple's Screen Time and/or app/device restrictions just cannot be relied upon. They also give a quick *additional* level of restriction that can be called upon as a threat/persuasion to GET OFF THAT PHONE - "cutting off 'the wifi'" is a nuclear option I'll admit, but it can get results. There were a few additional complications setting Kid Control up on my network however, as it's *entirely predicated upon the Mikrotik device being the default internet gateway for the kids' devices* - i.e. being the "ISP router". On my network, the RB2011 does not play that role; if we refer to a cut-down version of my network diagram, just showing the relevant "infrastructure": ```mermaid architecture-beta service internet(affinity:cloud) group home(affinity:house)[Home] group study[Study] in home service ispr(affcircle:c-firewall) [ISP Router] in study group mik(affcircle:c-router)[RB2011] in study service gbe(affcircle:c-switch-blue)[GbE] in mik service hun(affcircle:c-switch-green)[100Mbps] in mik service studywifi(affcircle:c-wireless-green)[WiFi AP] in study group closet[Closet] in home group closetap(affcircle:c-switch) [ClosetAP] in closet service closetswitch(affcircle:c-switch-blue)[Switch] in closetap service closetwifi(affinity:wifi)[WiFi] in closetap internet:B -- T:ispr ispr:L -[GbE]- R:gbe ispr:R -[GbE study to closet backbone]- L:closetswitch gbe:L -- R:hun junction huns in study hun:L -- R:huns huns:B -[100Mbps]- T:studywifi ``` Up until now, every networked device has been handed a DHCP lease (or been manually configured) with the "ISP Router"'s IP address as its Default Gateway. The change I have now made (after dogfooding with my own devices for a while) is that "kid-controllable" devices now get handed a slightly different DHCP lease (adjusted on a one-by-one basis from the RouterBoard web UI) that specifies the RB2011's own IP address as the default gateway:

Where `use-me-as-your-default-gateway` is just a __DHCP Option__ as follows:

And the RB2011 _itself_ has been configured with a default route to the ISP Router:

## Creating a blockable path through the RouterBoard But unfortunately that's *not enough*. Out of the box, the RouterBoard simply *will not* forward packets from those specially-configured (aka "kid") devices. So some firewall configuration is needed. While this is all completely logical, and [beautifully explained](https://help.mikrotik.com/docs/spaces/ROS/pages/250708066/Firewall) in the [Mikrotik documentation](https://help.mikrotik.com/docs/spaces/ROS/pages/328227/Packet+Flow+in+RouterOS), it took a while to figure out... ### Special addresses for the special devices I've [long been a proponent](https://blog.themillhousegroup.com/2011/04/ultimate-ubuntu-build-server-guide-part_25.html) of using a `10.a.b.c`-style network for the extra degrees of freedom those `a`,`b` and `c` bytes give you. Now here's a case where it nicely pays off. Eagle-eyed readers will have already spotted that the `john-iphone` DHCP lease shown above was assigned the IP address `10.248.0.110` whereas other equipment on my network lives at `10.240.0.x`. That extra bit: ``` 10.240d = 00001010 11110000 10.248d = 00001010 11111000 ``` ... combined with a bit-mask of `/13`, i.e. the leftmost 13 bits in `10.248`, give us a telltale for "kid" devices that need special treatment, namely: ### Allow their traffic to be forwarded across the router Both these firewall rules are dead simple, but they need to be there, so I'm just showing them in the Firewall summary view as there is literally nothing else to them.

This first rule just says that if a packet arrives from one of those `10.248.0.0/13` devices, and it's *not destined for the Mikrotik itself* (i.e. the chain is `forward`, not `input`) then `accept` it rather than continuing firewall rule processing, which would eventually hit the last rule (not shown), and throw the packet away. ### Allow their traffic to be forwarded across the router The second rule is more subtle but just as necessary. Without it, packets from kid devices addressed to the wider Internet will be forwarded "over" the Mikrotik, sent to the ISP Router due to the default route in the Mikrotik, head to the Internet due to the default route in the ISP Router, and response packets make their way back via the same path due to the magic of NAT - *except for the final hop* back to the original kid device, because the Mikrotik doesn't know what to do with the response. So we configure a "Source-NAT" rule for our kid devices, that says that the RB2011 will "masquerade" on behalf of them; and thus it will know what to do with those response packets when they arrive back from the internet - send them back to the original kid device:

... And now that we've got packets flowing across the router, Kid Control rules can be layered on top to stop them again 😂

Bravia, Bravia, wherefore art thou Bravia

Just a quick post that might help anyone with a Sony Bravia X70G/X70xxG family LCD TV.

We just upgraded our 12-year old 40" Bravia to the KD-55X7000G model, which I got almost-new for half price, because I can't resist a bargain. It's not a very high-end TV, but it's got Netflix etc and it puts out a good picture. The operating system is described as "Linux", and it's functional* and snappy, which is all I really want. As a reluctant "Smart TV" purchaser, I'd rather a "dumb" smart TV than one that shows me advertisements.

One of the ways it is unacceptably dumb though, is doing DHCP while it's doing something else. Yes, a TV capable of showing 4K content at 60Hz (that's 4096x2160 * 60 = 530,841,600 pixels per second if you're counting) can't handle obtaining a new DHCP lease - an exchange of 2 simple UDP datagrams over the network.

This was manifesting itself very annoyingly during Netflix sessions. The pattern would be: we'd turn on the TV, then get sidetracked for a bit, then finally settle down and watch a 22-minute episode of "Superstore" on Netflix. All fine. Then, reliably as clockwork, if we decided to watch a second episode, at some point during the show we'd get a "can't access Netflix servers" error, which was completely unrecoverable. Even a swift reboot of the TV wouldn't be enough - leaving it off for about five minutes seemed to be required to flush out the problem.

It turned out that I hadn't explicitly added the TV's MAC address to my dnsmasq configuration, so it was being given an IP address with the default lease time of one hour. Now dnsmasq is pretty smart and won't assign a different IP address to a device once it's seen it (unless it absolutely has to) so it wasn't even anything as nasty as the TV getting a different IP. No, it was simply asking to renew the lease. Obviously the straw that broke the camel's back.

So the "solution" I'm using (and has been flawless so far) is to:

1. give the TV a static IP address; and
2. give it a 24 hour lease time

24 hours is more than enough time to cover any foreseeable Netflix binge and the TV will do a DHCPDISCOVER on boot the next time anyway, so we're covered nicely.

(*) Oh there is one other thing - the TV unfathomably doesn't seem to be able to set its clock from the network - I'm looking at fixing that soon, fingers crossed...

Fixing internet access failures after upgrading to MacOS 10.14 Mojave

I innocently upgraded my 2012 Macbook Pro to Mojave (10.14) from High Sierra (10.13) purely because HomeBrew was refusing to let me install any new goodies on such an old OS. The upgrade itself was painless and everything seemed to be in good shape until I tried to access the wider Internet (access to my own local network was completely fine).

Now Internet access problems are extra-infuriating, because "Googling for the solution" instantly becomes far more of a palaver. An interesting quirk of this particular issue was that using my iPhone's "Personal Hotspot" worked perfectly with the Mac. Only accessing the internet directly through the home WiFi was problematic, and other devices were of course completely fine.

So to recap the scenario (and hopefully give this post some Google-ju to help anyone else in this situation), here's what we had:

• Macbook Pro was running OSX High Sierra (10.13) with no prior network problems
• Network has been carefully set up and tuned for "meshed" operation
• Local DNS services provided by DNSMasq running on a Raspberry Pi
• DHCP services provided by DNSMasq, handing out fixed addresses to "known" devices like the Macbook Pro
• All local network services working fine - e.g. accessing router admin webpages
• Internet access when tethered to an iPhone works fine (Mac gets assigned 172.20.10.2, iPhone is 172.20.10.1)
• Internet access through wired Ethernet (via a Thunderbolt adapter) works fine
• Internet access on home Wifi completely fails; no DNS, no ping, no browsing

After a frustrating day, I decided to blow through the Mojave upgrade in case it had been fixed in Catalina (10.15) ... it hadn't.

I went through probably a dozen different iterations/versions of the "recreate your network stack"/reboot/reset PRAM and/or SMC cycle; nothing was helping, and I was still mystified by how the wired Ethernet was working immaculately while the WiFi failed to get "out" of the local network.

Comparing settings with my wife's Macbook that had perfect Wifi yielded nothing, so just for the hell of it, I decided to check the gateway router's settings one last time to see if for some reason I had a special route or firewall rule set for the Macbook Pro's Wifi IP address (10.240.0.72) only, which would explain why the wired connection (10.240.0.77) had no problems. It wouldn't normally be something I'd do, but given the output of traceroute was showing that the hop to the gateway was working in all cases, I had to start suspecting that the MacOS internal routing of packets was not faulty ...

And lo and behold, WHAT IS THIS? On my (ISP-provided) TP-Link router's Security/DoS prevention page, a place I have rarely if ever visited ... My laptop's Wifi IP address has been automatically added to a blocklist for attempted DoSing of my network ... from the inside ?!?!

I removed the blocklist entry and instantly everything worked perfectly. Oh dear. I have no idea when my laptop started absolutely hammering pings/UDP/TCP SYNs but it must have been at some point during or immediately after the upgrade to Mojave, and the router did what it was configured (completely by default) to do when it saw more than 3600 packets/sec coming from my laptop. Wow.

Reading the rather scant documentation for this router feature indicates that it uses up (extremely precious) router CPU so I've turned this feature totally off - internal DoS prevention seems like a waste of time to me.

Addendum: Disabling SPI and DoS detection/prevention has massively sped up using the router's web UI so I can only imagine it's working wonders for the overall performance. So I guess it's been a win ... overall 😕

Home-Grown Mesh Networking Part 2 - When It Doesn't Work ...

A few months ago I shared some tips on using existing Wifi gear to make your own mesh network.

Turns out though, it might not be as easy as I initially made out. In particular, I was noticing the expected switchover as I walked down the corridor in the middle of my house:

... was simply not happening. I would be "stuck" on Channel 3 (red) or Channel 9 (green) based on whatever my Mac had woken up with.

Lots of Googling later, and the simplest diagnostic tool on the Mac turns out to be Wireless Diagnostics -> Info - take a snapshot, turn off that AP, and wait for the UI to update. Then stick them side by side and eyeball them:

I wasted quite some time following a wild goose because of the differing Country Codes - it's not really something you can change in most consumer AP/routers so I thought I was in trouble, until I discovered that "X1" really just means "not broadcast" so I decided to ignore it, which turns out to be fine.

Now the other thing that was most definitely not fine was the different Security policies. I thought I had these set up to match perfectly, but as you can see, MacOS thought different (pun not intended).

When is WPA2 Not WPA2?

The D-Link AP (on Channel 9, on the right in the above screenshot) was supposedly in "WPA2 Personal" mode but the Mac was diagnosing it as just WPA v1. This is most definitely enough of a difference for it to NOT seamlessly switch channels. Even more confusingly, some parts of the MacOS network stack will report this as WPA2. It's quite tricky to sort out, especially when you have access points of different vintages, from different manufacturers, who use different terminology, but what worked for me (on the problematic D-Link) was using Security Mode WPA-Personal together with WPA Mode WPA2 plus explicitly setting the Cipher Type to AES and not the default TKIP and AES:

This last change did the trick for me, and I was able to get some automatic channel-switching, but the Mac was still holding on to the Channel 3 network for much longer than I would have liked. I could even stand in the same room as the Channel 9 AP (i.e. in the bottom-left corner of the heat map above) and not switch to Channel 9.

Performance Anxiety

The clue, yet again, is in the Info window above. In particular, the Tx Rate field. It would seem that rather than just naïvely choosing an AP based on signal strength, MacOS instead (or perhaps also) checks the network performance of the candidate AP. And look at the difference between the newer dual-band Linksys on Channel 3 (145 Mbps) and the D-Link on Channel 9 (26 Mbps)!

There are plenty of ways to increase your wireless data rate, the most effective being switching to be 802.11n exclusively, as supporting -b and -g devices slows down the whole network, but (as usual) I hit a snag - my Brother 2130w wireless (-only) laser printer needs to have an 802.11g network. As it lives in the study, a couple of metres from the D-Link AP, I'd had the D-Link running "mixed mode" to support it.

Printers were sent from hell to make us miserable

As it turns out, the mixed-mode signal from the Linksys at the other end of the house is good enough for the printer (being mains-powered it's probably got very robust WiFi) and so I could move the D-Link to "n-only". But there was a trick. There's always a trick ...
You need to make sure the printer powers up onto the 802.11g network - it doesn't seem to be able to "roam" - which, again, makes sense - it's a printer. It knows to join a network called MILLHOUSE and will attempt to do so - and if the "n-only" network is there, it'll try to join it and never succeed.
So powering down the n-only AP, rebooting the printer, checking it's online (ping it), then powering the n-only AP back up again should do the trick.

Summary

Moving the D-Link AP to n-only doubled the typical Tx Rate at the front of the house to around 50 Mbps, the result being that the Mac now considers Channel 9 to be good enough to switch to as I move towards that end of the house. It still doesn't switch quite as fast as I'd like, but it gets there, and doesn't drop any connections while it switches, which is great.

Here's the summary of the setup now:

	Living Room	Study
Device	Linksys X6200	D-Link DIR-655
IP Address	10.240.0.2	10.240.0.3
Channel	3	9
Mode	b/g/n	n-only
Band	2.4 GHz	2.4 GHz
Bandwidth	20 MHz	20 MHz
Security	WPA2 Personal	WPA Personal (sic)
WPA Mode	n/a	WPA2 Only
Cipher Type	n/a	AES Only

Stand by for even more excruciating detail about my home network in future updates!

Home-grown mesh networking

With many people now working from home every day, there's a lot more interest in improving your home WiFi coverage; and a lot of people's default answer to this question is "get a mesh network". The thing is, these things are expensive, and if you've upgraded your home network and/or WAN connection in the last 10 years (and have the bits left in a drawer somewhere) you probably actually have everything you need to build your own mesh network already.
Here's what you need to do (presented in the order that should cause minimal disruption to your home network):

Establish which router you want to be the "master"

This may be the only router currently running, the best-positioned Wifi-wise, the one with the WAN connection, all of the aforementioned, or something else.

Configure the master AP

• We'll reflect this router's status with its static IP address; ending in .1
• If you rely on a router to provide DHCP, make it this one
• Set your Wifi channel to 1,2 or 3 (for non-US locations) and do not allow it to "hop" automatically
• I'll refer to this channel as C_M
• If possible, set the Wifi transmit power to LOW

Configure your (first) slave AP

• Give it a static IP address ending in .2 (or .n for the nth device)
• Disable DHCP
• Set your Wifi channel to C_M +5 (for non-US locations) (e.g. 6 if C_M is 1) and do not allow it to "hop" automatically
• The logic behind this is to avoid overlapping frequencies
• Let's call this channel C_S
• If possible, set the Wifi transmit power to LOW
• Set your SSID, WPA scheme and password exactly as per the master

Connect master and slave via wired Ethernet

Oh and if neither of those devices is your WAN connection device, then that needs to be wired to this "backbone" too. This is super-important for good performance. If an AP can only get to the internet via Wifi, it'll be battling its own clients for every internet conversation. The Googleable name for this is "wired backhaul" or "Ethernet backhaul" and it's well worth drilling some holes and fishing some cable to get it. Don't skimp on this cable either - go for Cat6, even if your devices only (currently) go to 100Mbps.

Tune it

Grab a Wifi analyser app for your phone - IP Tools and Farproc's Wifi Analyser work well on Android. Your best option on iOS is called Speed Test - Wifi Signal Strength by Xiaoyan Huang.
Using the signal strength view, start walking from your master device towards your first slave. You should see the signal strength on channel C_M start dropping and the strength of C_S increase. Now if you've got some control over Wifi transmit strength, this is where you can "tune" the point at which your portable Wifi devices will start looking around for a "better option" - typically at around -70 to -75dBm. Remember, you actually want them to start getting "uncomfortable" quite quickly, so that they begin scanning earlier, and find the better option before you even notice any glitch. That's why we dropped our signal strength when we set the APs up - we don't want them to be too "sticky" to any given AP.

A real-life example

Prior warning - I'm a geek, so my network configuration might be a little more involved than yours, but the basics remain the same.
I have 4 devices of interest:

• WAN Modem - a TP-Link Archer v1600v that has a broken* Wifi implementation, so is just being used as a WAN Modem
• DHCP Server - a Raspberry Pi running dnsmasq - a bit more flexible than what's in most domestic routers
• Living area AP - a Linksys X6200 router/AP
• Home office AP - a D-link DIR-655 router/AP

You'll note that those APs are most definitely not state-of-the-art. When you use wired backhaul, you really don't need anything very fancy to get a strong mesh network!
Here's how they are physically laid out:

Pink lines are Gigabit Ethernet running on Cat6 cables. The red arrow is the WAN connection, which arrives at the front of the house and is terminated in the home office. That long curved pink line is the "backhaul" - it leaves the home office through a neat RJ45 panel in the skirting board, runs under the house, and surfaces through another RJ45 panel in the back of a closet in the bathroom - a little unusual, but there is power available and it is excellently positioned to cover the living area of the house as you can probably see.
Here's the configuration:

• WAN Modem - Static IP 10.240.0.1
• DHCP Server - Static IP 10.240.0.200, hands out addresses with network gateway set to 10.240.0.1
• Living area AP - Static IP 10.240.0.2, Wifi channel 3, transmit power LOW
• Home office AP - Static IP 10.240.0.3, Wifi channel 9, transmit power LOW

And that's it!
I've done a little visualisation of the signal strength using my pet project react-chromakeyed-image (more on that in another post):

You can see that the whole house is now bathed in a good strong signal, from either the living area (red) AP or the home office (green) and the only questionable area is on one side of that other front room (bottom of image), which is a playroom and doesn't need strong Wifi anyway.
(*) It actually seems to be that IPv6 advertisements can't be turned off and it advertises the "wrong" DNS addresses.

Raspberry Pi 3 Model B+

My Synology NAS is coming up to 10 years of age, and asking it to do all its usual functions, plus run a few solid Java apps:

• Serviio media server
• OpenHAB 2 home automation server
• Jenkins continuous integration server

... was all a bit much for its 700MHz ARM processor, and particularly its 256Mb of RAM. Jenkins was the final straw, so I was looking around for other low-power devices that could run these apps comfortably. One gigabyte of RAM being a definite requirement. My Googling came up with Raspberry Pi devices, which surprised me as I'd always considered them a little "weak" as general purpose servers, more for doing single duties or as clients.

But that was before I knew about the Raspberry Pi 3, Model B+. This little rocket boots up its Raspbian (tweaked Debian) OS in a few seconds, has 1Gb of RAM and a quad-core 1.4GHz ARM processor that does a great job with the Java workloads I'm throwing at it. And look at the thing - it's about the size of a pack of cards:

A quad-core server with 1Gb of RAM, sitting on 3TB of storage. LEGO piece for scale. I wonder what 1998-me would have made of that!

With wired and wireless Ethernet, scads of USB 3.0 ports and interesting GPIO pin possibilities, this thing is ideal for my home automation projects. And priced so affordably that (should it become necessary) running a fleet of these little guys is quite plausible. If like me, you had thought the Raspberry Pi was a bit of a toy, take another look!