Minecraft Local Server Discovery – Can’t find LAN games?

I had a problem where I couldn’t find LAN games automatically on my local network in Minecraft.  Turns out that the problem was due to the interface priority on my network interfaces, and Minecraft was binding to the wrong interface!

Minecraft uses UDP multicast (on 224.0.2.60, port 4445) to advertise local games.  If you have more than one network adapter on your machine (in my case, a VirtualBox Host-Only adapter), it’s possible that Minecraft has bound to the wrong adapter.

You can reveal this with netsh interface ip show joins – if you see the join on 224.0.2.60 on the wrong interface, that’s your problem.  Here’s how to fix it.

Open an administrative Powershell prompt.  Run get-netipinterface and review.  You should see two entries for the offending adapter.  Look at the InterfaceMetric value for that adapter and for the adapter you want to be the default.  In my case, both were 25.

You can now adjust the interface metric for the offending adapter to be higher than the correct adapter;

get-netipinterface | where-object { $_.InterfaceAlias -like "VirtualBox*" } | set-netipinterface -interfacemetric 40

And voila!  Minecraft local server discovery works again!

Powershell Remoting for Non-Domain Test Machines

NOTE – This isn’t particularly secure, but it works.  It’s a bit better than configuring WinRM in unencrypted mode though.

Got some non-domain joined Windows machines and you want to get WinRM running in a hurry so you can do some stuff remotely?  Do this.

On the server (the thing you are remoting to);

Invoke-WebRequest -Uri https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1 -OutFile ConfigureRemotingForAnsible.ps1
.\ConfigureRemotingForAnsible.ps1
winrm quickconfig

That script is taken from Ansible, and configures a host with a self-signed SSL cert for use with WinRM.  The final line then configures up the WinRM listeners and firewall rules.

Then, on the client (the thing you’re remoting from);

# enter local admin creds here
$creds = get-credential  

$so = New-PSSessionOption -SkipCACheck -SkipCNCheck
Invoke-Command -Computername YOURSERVERHERE -UseSSL -SessionOption $so -Credential $creds -ScriptBlock { get-childitem env: }

You should see a dump of the local environment variables on the target machine, indicating that the invoke worked.  You can now do whatever Powershell remoting stuff you want to do.

Note, this doesn’t actually check the CA cert provided, so you can be MITM’ed and have your credentials captured.  For better security you should use a properly signed certificate on the server and trust it on the client correctly, but this will work fine for a home setup where you’re in control of all the layers (network, client and server).

Good luck.

Bash on Ubuntu on Windows 10 – Teething Issues

Just set up the new Bash on Windows 10 feature that comes with the Anniversary Update.  It’s not bad.  But there’s a few annoying things it does that grind my gears.

The default umask is 0000

Yeah.  That’s what I said.  This means all files you create from the Bash shell are read/write/execute to EVERYBODY.  Not smart.  SSH hates that.

echo "umask 0022" >> /etc/profile

To fix that one.

Sudo doesn’t inherit root’s HOME

This causes many commands (pip for example) to dump files into your user directory as root, resulting in an inability to modify files in your own homedir.  Not great.

Add the following in your /etc/sudoers somewhere;

Defaults always_set_home

More as I come across it.