Issue description:

Hello! A few days ago, our official pack server started crashing whenever someone is near a Mekanism machine (tested with a Metallurgic Infuser and Enrichment Chamber). At first we thought that it was all due to Mekanism, but today we figured out that it doesn't happen when the crafting recipes in JEI bug out, as it sometimes happens with the 1.11.2 version. Then we tried changing the JEI version on the client back to the version where all was fine, but it didn't help. Either way, by the crash log we can tell that it has something to do with Mekanism.

Version (make sure you are on the latest version before reporting):

Forge: 13.20.0.2315
Mekanism: 9.3.2.307
JEI (if it actually has to do with it) 4.5.0.289

If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)

https://paste.ee/p/a1wzk

Do you have a full log by any chance? There might be more warnings/errors/debugs on the way describing what has happened.

No, that's it.

Some quick analysis (technical stuff following):
A machine tries to send data, including it's security data (based on the data which is being send).
Security data is as follows:
securityMode (int)
hasOwner (boolean)
ownerUUID (String)
lastKnownUsername (String)
hasFrequency (boolean)
dataName (String)
ownerUUID (String)
lastKnownusername (String)
publicFrequency (boolean)
override (boolean)
and more frequency related stuff.

The issue is that the lastKnownUsername, returned by the Minecraft UsernameCache is null, which can't be send by the PacketHandler.
Quickfix for the network data is checking if the lastKnownUsername is null and replace it with an empty string. However, this has probably a huge consequence on the clientside, as it expects an username to display.

Yes, the clients near the machines get kicked from the server, but the world is fine.

It seems very strange that the User Name is null; unless you've somehow reset the usernamecache.json file and the owner has not logged in since.

@EmosewaGamer any idea who placed the machine(s) in the area? Or if some kind of Mechanical User was used?

@thommy101 do you know if the lastKnownUsername field is used for anything other than displaying to the client? I would imagine rendering would be able to handle an empty string. That said, it would probably be better to send a string like <Unknown Username> to the client in cases like these.

Well everyone has placed down their own machines obviously. There are no situations with machines placing them.

@thiakil I do not know the exact purposes of the lastKnownUsername, I do know that Minecraft only caches it for a certain amount of time, after that time it's cleared from the usernamecache.json file.

Snippet of one of my usernamecache file (debugging, so random usernames, no real ones)
[{"name":"Player140","uuid":"23d7e7bc-6e91-3bb0-aef5-04f8d5ce94c1","expiresOn":"2017-07-20 20:21:31 +0200"},{

After the expiration, it could return null or requests a new entry, not sure about that.

That looks like usercache.json, the Forge class Mek appears to use has its own file usernamecache.json which on mine does not contain any expiries (and the forge class only saves the key/value pair)

You're right.. Looked at the wrong file

Well we had the mod removed for 2 days and then we re-added it. All was fine the first day, but the second day people started getting the same problem, but with a different cause:
https://paste.ee/p/HQaNP