Problems accessing long UNC paths on EMC VNX filer from Windows Server2008R2 after Update July 2015

After the latest set of patches from Microsoft had been installed on our production servers (Win 2008R2 Server)  we ran into problems accessing subdirectories of shares with long UNC names in our EMC VNX Filer.

The issue must be caused by one of the following patches:
KB3077657
KB3075516
KB3074886
KB3072633
KB3072630
KB3070738
KB3070102
KB3069392
KB3068457
KB3067903
KB3067505
KB3065987
KB3065822
KB3057154

The effect is that users can navigate to any UNC ressource when klicking their way through windows explorer. The same UNC path pasted into the address field causes an error.
VB Scripts accessing those ressources also fail. So does sending a PDF file (located in a subdirectory of a user's home drive) through AcrobatReader's send function.

I will investigate which of the updates causes the problem as soon as possible.

Edit 20150717 / 9:05h: Windows Server 2012R2 does not exhibit the problem.

Edit 20150717 / 11:13h: Removed all of the above form one of our 2008R2 terminal servers. Still no joy. Will remove OfficeUpdates next.

Edit 20150717 / 14:33: Temporarily solved by making the full path to the target directory browseable. Example: \\myserver\myshare\allhomes\myhome\somedir\someotherdir
Typing that path into Windows explorer resulted in an error. "allhomes" was not readable by the client. Making that readable fixed the user's problems.
Strangely enough \\myserver\myshare\allhomes\myhome worked without the modification.

Edit 20150717 / 17:32: We're still scratchig our heads about this. Our terminal servers still had the problem after uninstalling all of the above KBs. Making the whole path readable helped.
While another highly production-critical server was OK after removing them (and reboot).

Edit 20150720: We'll stick with the workaround: Make the whole path browseable. I'm not quite happy with that, but too much time has gone into that already.

Edit 20150721: Applied patches on another production machine. Also resulting in access probems. (Detail will follow)

Edit 20150722 / 14:50
Result:
EMC does not seem to have anything to to with our production problem. We're running a production-critical piece of software (and: yes, we have two them, of course) on a win2008r2 server . The software manufacturer came back to us this morning with new info:
The following patches must not be installed:

Security Update for Windows Server 2008 R2 x64 Edition (KB3067505) 

Security Update for Windows Server 2008 R2 x64 Edition (KB3057154) 

That still does not explain the initial problem we had on the terminal servers. That never should have worked in the first place. But the timing was too perfect to pass as coincidence.

The LiPo Charger that wants to burn down your house

For a tiny LiPo package, I needed a charger.
Sounds like an easy one? I beg to differ.

Rather than reinventing the wheel I thought it was a good idea to get some tiny, ready made USB charger. A suitable circuit with a MCP73831 should come cheap enough from the PR of C. For around €2.50, I thought I could expect just that.
Wrong again.

I found one that was advertised as: 3.7V Lipo Battery USB charger JST plug 500ma output. It has a charge control LED that comes up when the battery is fully charged. - Sounds good. It arrived a few weeks later.

Just to be on the safe side, I took my meter (thou shalt check voltages) and was surprised that the USB-side seemed to be shorted to the charging side of the circuit. The meter read 5V on the charging connector. Way beyond safe for LiPos.

So two minutes a little prying later, I was in. And stunned.

Inside the plug

What did they do there? Is there any design rule not violated by this piece of ****? A 2.4 Ohms SMD resistor can't possibly pass for a LiPo charging circuit. I mistook it for a short.
Carefully tracing the circuit (because my initial impression just had to be wrong), this turned out to be the schematic diagram:

This "charger" is outright dangerous. I can't even remotely meet the proper charging conditions.
I have no idea where the "3.7V" and the "500mA" in the product description might come from. Possibly from the fact that some USB ports are limited to 500mA and that the nominal voltage of a LiPo cell is 3.7V.
And what are all those unused solderpads for? Maybe the original design idea was good and some electrical engineering genius found a way to cut the cost. At the expense of a few burnt down houses.

I suppose the idea might me to babysit the charger and the pack and wait for the LED to come on. Then disconnect the pack immediately. - That just won't work for me.


Watch my rant about this piece of **** on YouTube.

Second (successful) attempt to route IP packets with ESP8266

Now that one was a piece of cake:

As suspected /app/include/lwipopts.h overruled the file I modified previously.

So with a 

#define IP_FORWARD 1

in there, the the module started forwarding packets

Ping connectivity table

PING	192.168.1.50	192.168.1.75	192.168.4.1	192.168.4.3
192.168.1.50	n/a	n/a	n/a	YES
192.168.1.75	YES	n/a	n/a	n/a
192.168.4.1	YES	n/a	n/a	YES
192.168.4.3	YES	n/a	YES	n/a

So I now could ping the Laptop (ouch: forgot to disable the firewall first) from the mobile device and vice versa.
Here is the caveat:

• I need a static route from the Laptop to the "StationMode" interface of the ESP8266. The cooler way to do that is on the default router.

Up to now this is an easy one for the ESP module. Both subnets are directly connected, so the routing decision is not really that hard. With very little tweaking, this could already be used  as an extremely simple range extender working at layer 3.
To daisy-chain / mesh more of these, I need to supply routing information to LWIP. It is not too obvious where to do that in the code or what it takes to add commands to manipulate routes through LUA.

First (failed) attempt to route IP packets with ESP8266

In every other comment on my previous projects, someone brought up the topic of mesh networking with ESP8266 modules. Gooooogling the topic, I couldn't find a project that had made into a stable release. (Drop me a line in the comments if you found/have one)

Taking things nice & slow, I started with the following setup:

Ping connectivity table

PING	192.168.1.50	192.168.1.75	192.168.4.1	192.168.4.3
192.168.1.50	n/a	n/a	n/a	n/a
192.168.1.75	YES	n/a	n/a	n/a
192.168.4.1	YES	n/a	n/a	YES
192.168.4.3	NO	n/a	n/a	n/a

So as expected, the ESP8266/NodeMCU does not forward IP packets. I had a peek at the NodeMCU sources and made the following change to /app/include/lwip/opt.h:

 /**  
  * IP_FORWARD==1: Enables the ability to forward IP packets across network  
  * interfaces. If you are going to run lwIP on a device with only one network  
  * interface, define this to 0.  
  */  
 #ifndef IP_FORWARD  
 // #define IP_FORWARD           0  
 #define IP_FORWARD           1  
 #endif  

I rebuilt the firmware, flashed it to a ESP Module and:

FAILED. No changes to the module's routing behaviour.

If anyone is more familiar with the code, don't hesitate to leave a comment.


Next Steps:

• Get packet forwarding to work
• Routes? What routes? (There is a hook for those in later versions of LWIP. Backporting possible?)

PS:
Another search of the source code shows that there is another place that sets IP_FORWARD: /app/include/lwipopts.h - I'll try that next.