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.

CaptiveIntraweb: New firmware, new scripts & new videos

Providing Android compatibility (while IOS workes always worked) turned out to be easy in the end. So it is time for a 1.0 release of the project files:

• Find an all-in-one package with scripts, html-pages and firmware in the master-branch of my github repository.

• In this video, you see me setting up the Olimex MOD-WIFI-ESP8266-DEV module. As described earlier these modules come with 2MBytes of flash memory.

• While in that video, you see me using the portal on an IOS and an Android device to show the now fixed Android support.

CaptiveIntraweb now running on Olimex MOD-WIFI-ESP8266-DEV

I finally found the time to try the new firmware on one of the two Olimex MOD-WIFI-ESP8266-DEV boards.

• I decided to mount the headers upside-down to have the silkscreen readable when I have it plugged into the breadboard.
• Flashing the firmware worked as expected. (GPIO0 / Pin21 hardwired to GND - That's ok, trust me.)
• Formatting the i2c flash file system tool longer than expected. That worried me for a second or two.

The board then came back:

 NodeMCU 0.9.5/AReResearch build 20150318 powered by Lua 5.1.4  
 lua: cannot open init.lua  
 > file.format()  
 format done.  
 >   
 ----------------------------  
 No files found.  
 ----------------------------  
 >   
 > r,u,t=file.fsinfo() print("Total : "..t.." bytes\r\nUsed : "..u.." bytes\r\nRemain: "..r.." bytes\r\n") r=nil u=nil t=nil  
 Total : 1513781 bytes  
 Used : 0 bytes  
 Remain: 1513781 bytes  
 >   

Woooooha! 1.5MBytes of free space! Just think of the possibilities!

Next thing was to try the CaptiveIntraweb scripts. So I uploaded the files, ran "ap-mode.lua" to set the WiFi parameters and had another look at the remaining file system space:

 ----------------------------  
 about.htm    : 511 bytes  
 ap-mode.lua   : 89 bytes  
 counter.txt   : 1 bytes  
 dns-liar.lua  : 1352 bytes  
 index.htm    : 459 bytes  
 init.lua    : 46 bytes  
 instruct.htm  : 1075 bytes  
 kg-small.png  : 6037 bytes  
 server.lua   : 3144 bytes  
 ttt.htm     : 19471 bytes  
 wumpus.htm   : 13825 bytes  
 ----------------------------  
 Total file(s)  : 11  
 Total size   : 46010 bytes  
 Total : 1513781 bytes  
 Used : 50702 bytes  
 Remain: 1463079 bytes  

Still plenty of space remaining. I then restarted the module and:

Beauty! No trouble at all. (see edit below)

Edit: I might have a minor problem writing the counter.txt file to the local file system. The games loaded unreliably, so I commented out the code for the counter and the system was sometimes back to the expected speed. I couldn't find a change in the nodeMCU firmware to account for that. - This needs a closer look.

Two OLIMEX MOD-WIFI-ESP8266-DEV boards in the mail

When a CaptiveIntraweb experimenter from Chicago pointed out that he had problems with Olimex ESP8266 modules, we looked into the problem and it seemed like a file system related issue.
The cool thing is that these modules come with 2MByte of i2c flash, rather than the usual 512k. And that might just be the source of the problem.

I wasn't aware these modules existed and immediately ordered a pair. Despite the fact that the German postal service is on strike, the modules arrived on Saturday.

Nice silkscreen 

The weekend was rather busy, so I couldn't test drive the modules. From the first look, I am impressed by the build quality and the nicely readable silkscreen. So impressed in fact, that I'll mount the headers upside-down to have an unobstructed view of the print.

One thing I didn't like at first glance was that to change to flash mode, I need to change soldered jumpers. With the number of tries I need to get things right, I considered mounting a switch.

A closer look at the schematic revealed this:

Now that's nice circuit design! I can still use a jumper cable on the breadboard to tie GPIO0 to GND manually to reflash the firmware. 

I will try that tonight and let you know how it went.

It went better than I expected. See here.