Moving away from Teamviewer on older Windows systems

Problem:  You have an old XP (!) or Windows 7 box.  Teamviewer no longer supports your OS, and/or is endlessly bugging you with "Commercial Use Detected!" nag-boxes.

Solution:  Try AnyDesk.

Why?

•  It's free.

•   It has a portable version - you can try it without installing a thing.

•  It works on old operating systems (including XP (!))

•  It's pretty nice.

Some features are pay-only, any the subscriptions ain't cheap.  But, so far, I've not found anything the free version lacks that I need.

This saved a very old PC of mine after Teamviewer stopped supporting old boxen.  I need this ancient PC to run a prehistoric printer, with neither being supported by newer software.  AnyDesk saved it when Teamviewer stopped connecting in v15.

Kodi randomly leaves full-screen mode to smaller window at top-left-hand side of screen (especially on Intel NUC), leaving it locked up under Windows 10

Problem: Per title.  Affected was Kodi Leia, but can happen to any Kodi.  May also happen to other media players.

 

Explanation:  This is a manifestation of the EDID issue (also known as the "quarter screen issue") where:

•  Windows is losing the EDID for the display device (TV, projector) when the display is shut off or disconnected.

•  Windows then resizes the screen resolution to the "default" display device, which forces Kodi to resize as well.  This usually makes the Kodi display lower resolution (i.e. smaller).

•  When the display is turned back on / reconnected, Windows re-acquires the EDID and changes back to the original resolution.  

Kodi does not handle this gracefully.  

The result is that Kodi gets "stuck" in the lower resolution, which manifests itself as a smaller (i.e. lower-resolution) window at the top-left corner of the screen.  

Some people find that although Kodi is resized, it is still responsive, and so can be restored to full-screen mode via keystrokes.  In my case, it also locks up, forcing me to kill and restart it each time.

 

This may or may not affect a HTPC directly connected to a TV.  It may also seem to occur randomly, not every time.

The problem does appear to be exacerbated when:

•  The HTPC is an Intel NUC; and/or

•  There is a receiver between the HTPC and the display device; and/or

•  The receiver is relatively old.

Keeping the receiver on full-time might not help since older receivers might interfere with EDID acquisition even when active.

This does not seem to occur on Android since Android doesn't handle EDID the same way.   So if I had kept my Shield instead of getting a NUC, I probably wouldn't have this issue.(*)

Solution: Buy a "EDID emulator" device (like this one or this one).  I tried the second one and it seems to have fixed the issue.

You can also get a "Dr. HDMI".  This is the same thing but more expensive.

These devices lock the EDID to >one< resolution only.  So be sure the purchase the one that matches the intended resolution of your TV, projector or monitor.

(*) I exchanged the Shield for the NUC because the Shield didn't correctly support analog 7.1 audio.

VPN kill switch for single machine or IP address range on pfsense

There are obviously LOTS of ways to do this in pfsense.  This is just the way that I found, which seems to work.

This rule should prevent an individual machine from "talking" using the default non-VPN WAN connection.  This will prevent it from sending any traffic if the VPN goes down.

 Go to Firewall/Rules/Floating

• Action: Block
• Quick: Checked
• Interface: WAN
• Direction: any
• Address family: IPv4
• Protocol: Any
• Source: Single host or alias / [set local IP address of host here i.e. 192.168.1.100]
• Destination: any
• Description: enter any description here [i.e. "Block this IP from using non-VPN WAN"] 
• Click "Save"
  

Obvious notes:

-  This only really works if the machine in question uses a static IP address.

-  You can define multiple rules for different devices.

-  You can set the rule to block a range of IP addresses by using "Network" instead of "Single host".

This approach does not use policy-based routing and does not decide which machines use the VPN and which don't.  It just forces all traffic from a machine through the VPN, else the traffic gets blocked.

Speed change between Netgear R7000 / DD-WRT and Core I7-7500U / pfsense routers using PIA AES-256

This was a quick test only, using a popular torrent client.  

The Netgear is a recent (faster) example running the latest DD-WRT.  The pfsense box is an eBay i7-7500U special with the latest pfsense.

Speeds are peak speeds through Private Internet Acccess (PIA) using AES-256 / SHA256 on their "Next Gen" network.  There were no changes to the rest of the setup between the two trials.

Results:

• Netgear: 4 MiB/s 
• i7-7500U: 38 MiB/s

That's almost a 10x improvement.

Note I couldn't get these speeds using all torrents, as some of the sources are limited. 

However, I know that the Netgear can't exceed 5 MiB/s no matter what, while the i7 definitely can do 38 MiB/s.  It's possible the i7 might be able to go even faster.

From this, it does appear obvious that the Netgear is quite limited with respect to VPN crypto. 

Obviously the i7 is vast overkill.  I got it since the price difference between the i3 and i5 was nominal and I really only feel like doing this once.  See here for tips on buying such a box.

My experience with Montana Mailbox / DYK Post

First parcel, no issues.  Took a little while to get the incoming ticket, but didn't think anything of it - I figured the delivery had been slow, and I didn't care.  Picked it up at DYK without any issues.

Second parcel was Amazon, so I had a delivery date.  It took Montana Mailbox 7 working days (12 calendar days) to issue the incoming ticket. 

I wanted the parcel earlier, so I sent an email 4 working days after delivery, to see if Montana could expedite it.  I never got a reply.  I was hoping to get at least a "Sorry, we can't help with that", but nada.

MM is undoubtedly big, but I can't see them having a 7-day incoming queue.  So they obviously prioritize commercial traffic over individual parcels, meaning one-off packages will take however long they take.

It then took another 9 days for DYK to just pick it up, plus an additional 2 days to get it to the correct office.  So about 15 working days, or 23 days total, until it arrived.

Again, DYK is not likely to have a 9-day queue, especially when they pick up every day.  It may be the package got held up in Customs, which can happen to any package.

So, while the Montana Mailbox / DYK Post teamup seems a good service, do NOT use it for anything time-sensitive.  Or, if you do, allow at least 10 working days after delivery for Montana Mailbox to issue your incoming ticket, and another 10 working days for DYK to have it ready to pick up.

Wi-Fi interference on MX Revolution mouse

Check the wireless channel settings on your 2.4 GHz router.

I had been messing with my network and had set one of my routers to 2.4 GHz channel 3, which resulted in significant interference (skipping, lagging) on my MX Revolution mouse.  Resetting the router to "Auto" fixed it improved it somewhat.

Additionally, putting both my wireless APs on the same channel seemed to improve things as well.  They naturally did this themselves on their "Auto" setting, so I'm guessing it's somehow OK.

This might apply to any 2.4 GHz peripheral, but especially older ones that don't use Bluetooth.  My MX is old and is non-Bluetooth.

Alternatively:

-  If your router is set to "Auto", try setting it to a fixed channel;

-  Try moving the mouse receiver closer to the mouse; and/or

-  Try moving the router further away from the mouse.

These did not help my situation but are always worth a try.

Is Link Aggregation / LAG / LACP actually faster?

Simple answer:  

•  From a server to multiple clients, YES.

•  From a server to a single client, NO.

Why:  LAG/LACP does not combine several gigabit connections into a single fat connection. 

This is because all traffic for a single IP address has to go through one physical connection.  It's just too complex to do it any other way. 

So, a 4-port LAG is not a party line, where everyone can hear everyone else.  It's one person with 4 phones talking to four separate people each holding 1 phone - none of which can hear each other.

This means that a 4-port NAS can shove out 4 Gbps in total - but only 1 Gbps to each individual client.

(Yes, there are rare exceptions - just enough to make it unclear if LAG to a single client is really faster or not.  But it's not.)

This doesn't make LAG useless.  It just means it's only useful where you have several clients connecting to the NAS simultaneously.  A single client can't take advantage of the LAG, but multiple clients can.

This also applies if you connect two NAS devices together via LAG, and transfer / migrate / replicate data between them.  Each one is a single client, and so can only receive a single lane of data (1 Gbps) - not the 4 Gbps you might expect.