WD My Book Live and SSDP/UPnP

Sometimes you need a basic NAS.  We didn't want DLNA, we didn't want a Media Server, we didn't need automatic configuration of Network stuff.

So, through the GUI, we turned everything off.  Then a few days later, I'm scanning the network for excessive broadcast traffic and two of my top talkers are the darned WD My Book's.

They were hitting the network every X number of seconds with SSDP packets.  And it wasn't just a little bit, since they were my top talkers.

But, there isn't anything in the GUI about turning it off.

After googling around a bit, I discovered the disablelocalssdp switch in Twonky.... but alas that didn't help because I wasn't even running the Twonky service.

So, the WD runs a Debian Linux and I came across this post:

http://linuxadministration.us/?p=43

This told me where the config file was for Debian..

So, I cat'd the /etc/default/upnp_nas file and alas there was a switch:

UPNPNAS_ENABLED=TRUE

Well, I changed it to UPNPNAS_ENABLED=FALSE

and rebooted the NAS...

No more SSDP packet mess coming off the WD boxes anymore.  Yay!!!

Oh yea, to get into the Linux of the WD Live, go to this page:

http://ip_of_your_nas/UI/ssh

and then enable SSH.  Use PuTTY to ssh into your box and I used VI to edit the config file.

Cheers,
Clyde

XP as a terminal server using RemoteApp for a seemless timesheet

One day, one of our Vice-Presidents gets fed up with Microsoft Access 97 performance over a VPN.  Yea, I know.  Running Access over VPN connections is slooooooow.  But, the timesheet application is written in Access 97 and it connects to all our custom accounting applications which are also written in Access 97.  And the VP needs to be able to complete his timesheet in a reasonable amount of time.  Speed up the story... can't rewrite the application or migrate to Web front end with SQL backend.  So what is a IT Manager to do?

How about dedicating an old workstation to running the Access 97 timesheet application?

Yea, there are ways to allow multiple terminal server sessions on an XP box but I don't really want to break Microsoft licensing.  Oh yea, and I'd like a seemless application rather than a remote desktop that users will have to figure out.

Here's what works for now:

1.  On the old workstation running Windows XP, turn on remote desktop.  Plenty of instructions on web on how to do that.

2.  Install KB961742-v3.  I know it says that it is for Windows 7 XP mode, but hey, it works on a physical box too.

3.  Use this Remote App tool on the XP box to configure the Remote App.  Thanks Kim Knight!

4.  Use that app to also create the rdp file.

Okay it works... but the only problem?  Remote App sessions are set to never terminate by default.  They simply disconnect.  But on XP this is a problem because then no local users can use the machine or the next person to use the RemoteApp has to boot the previous user.

It took a while to find, but Windows Server 2008 has a Group Policy to set a timeout to terminate disconnected sessions.  Well, if you take apart the .admx file, you can pull out the registry setting that needs to be changed.

As a shot, I applied that registry setting to the XP box and Voila!

The registry setting is:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

"MaxDisconnectionTime"=dword:0000ea60

The value is the timeout in seconds * 1000.  Google it and you'll find out more than you need to know.

So now, after 20-40 seconds the XP machine terminates the disconnected session and the machine is back to normal as far as being able to be used by a user on the console or the next Timesheet session.

Now my VPN users can use the seemless timesheet application and the only network traffic over the VPN is the KVM traffic.  So it is nice and speedy.  I only have a handful of people on the VPN at a time, so they'll have to deconflict usage of the timesheet.

Cheers and Good Luck,
Clyde

The Thomas Approach

Okay... so, it has been a looong time since contributing to the oracle of the internet.  But here goes again.

Google Drive and SonicWall NSA2400 with firmware 5.8.1.5 wasn't working.

I checked the App Rules Advanced and ensured that Google Drive was open (and logged.)

But that didn't help.  I had been watching the logs for hours and working with my coworker to replicate the problem.

I did a packet capture and tried to analyze the dropped packets.  At least I determined that the SonicWall was dropping them.  But the only reason code I could go on was this:

Ethernet Header

 Ether Type: IP(0x800), Src=[00:a0:c8:51:16:0e], Dst=[00:17:c5:10:b3:21]

IP Packet Header

 IP Type: TCP(0x6), Src=[74.125.129.117], Dst=[192.168.9.141]

TCP Packet Header

 TCP Flags = [ACK,], Src=[443], Dst=[55345], Checksum=0xc08c

Application Header

 HTTPS

Value:[0]

DROPPED, Drop Code: 39, Module Id: 26, (Ref.Id: _4703_uyHtJcpfngKrRmv) 1:1)

So, I looked up Drop Code 39 and Module Id of 26 here:
https://www.fuzeqna.com/sonicwallkb/consumer/kbdetail.asp?kbid=10141

Network Module - Enforced firewall rule.  I poured over all my firewall rules and couldn't find anything applicable.  I again examined everything I could in the App Control Advanced.  But nothing.

I watched the logs again and again.  More packet captures.  Nothing enlightening.  I flashed the firmware to 5.8.1.8.  Still no joy.

Finally, I thought of my friend Brian's son.  His son Tom is very good at brute forcing things.  He is not afraid to push any and all buttons.  So, that is what I did.  Any option that either I didn't understand well or thought might be somehow related, I flipped the switch and had my co-worker test.

So 20 minutes later using the newly named "Thomas approach", we found it.  The checkbox is in the Content Filter and is named "Enable HTTPS Content Filtering."  We had it checked and when you uncheck it, for some reason that I'm sure is explainable, Google Drive sync's properly.

The only reason I thought to uncheck this box is because of the disclaimer that it "silently" blocks when enabled.  I'm guessing that means that it doesn't get logged too.

Well, hopefully, this helps someone save some time.  I don't do it often, but it is kind of funny.  When all logic (perceived) fails, try the Thomas Approach.

Cheers

SharePoint 2007 to 2010 upgrade woes

My initial setup was MOSS 2007 with a Web Front End and a SQL 2008 backend.

I read and read... and I tested an upgrade to 2010 in a test environment. Everything worked fine that I could tell.

So, counter to multiple vendors telling me not to do an in place upgrade, I went ahead and did it.

Upgrade went mostly flawlessly. Three things to note though:

1. Search Crawls weren't working after the upgrade. Solution: Central Administration -> Search Administration.... click on the name for the default content access account and put in the password. Although it is managed as a managed service account.... there was no impact to changes there.

Once I put in the password on the

Search Administration page, everything started working.

2. Search Crawls weren't indexing pdf's anymore. Had to add some registry settings that mirrored the MOSS 2007 settings. Followed the guide here: http://nickgrattan.wordpress.com/2010/06/14/adobe-pdf-ifilter-indexing-with-sharepoint%c2%a02010/

Thanks Nick.

3. This was the big one. No matter what I did, I could not get to the Central Admin site unless I used the start menu on the WFE. That link actually uses a power shell command to invoke the Central Admin site. But that just wasn't right.

Well, it turns out that I had configured MOSS 2007 to use Kerberos and it was working great for 2+ years. Upgrading to 2010 broke that when it came to authenticating to the Central Admin site.

The solution was ultimately to add two SPNs to the service account that runs the web application for the Central Admin site. So now instead of two SPNs:

HTTP/servername:port

HTTP/servername.fqdn:port

I have two more:

HTTP/servername

HTTP/servername.fqdn

So, it looks like somehow, the port isn't used as much anymore. Although, I left those two SPNs in there just in case.

After 3+ hours of working with Microsoft, we finally got it. Hopefully it'll save you a few minutes.

Cheers,

Clyde

Yet another booger of a Malware.

So, I'm not really a good malware remover guy. But, alas, even with protections in place and administrative priveledges removed... I still end up with some folks with malware. I got a panic call from one of my users. His "work" computer... which is really his laptop... is "reporting" infections all over the place. I thought I had trained him well... in the sense that his first reaction was to shut down his computer without hitting any screens. I think he might have clicked the wrong thing and sure enough something really nasty is installed.

So, I pull out the trusty thumbdrive with Malwarebytes' mbam software on it... http://www.malwarebytes.org/mbam.php

And, it won't run. So the malware knew how to disable that. So, I try to pull up the task manager, but the malware had disabled that too.

I went back to my thumbdrive and looked for process explorer: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx but I guess I left it off my thumbdrive. So, I pulled out my trusty leatherman and pulled out the hard drive.

Took the drive back to my bench machine. Downloaded mbam, updated and disconnected from the network just in case. Attached the drive using a USB to IDE converter. And now, I'm running mbam against the drive. Sure enough, 17 objects infected so far. And the realtime anti-virus kicked off once when mbam triggered on a file. I'll post back when and if I get a name.

Sometimes, booting to another machine is handy. But, I can't help but think that if the drive had been encrypted... which makes more security sense... I would have been screwed for scanning it on another machine.

All for now. Cheers.

P.S. Okay... well... according to mbam.... the drive 16 instances of Trojan.Dropper, 1 Trojan.Downloader, and 1 Trojan.Fakealert.

Luckily recovered a bricked Linkstation Pro

It all started when I was trying to backup my data on my NAS. I have a Buffalo Linkstation Pro with 250GB drive. Well, the USB drive was recognized but alas, the NAS would not backup to the external USB drive.

So, I figured I'd update my firmware. And, I was lazy. So I downloaded the newest firmware from Buffalo's website. I was sitting in my lazy boy and decided I'd flash the firmware over the wireless. I know! I know! Bad idea. Well, having flashed a lot of things over the years, I got a little complacent. And, I figured, what's the worst that could happen?

Well, the firmware just took forever and wouldn't ever complete. Then I got a little impatient. Who would have thought a firmware would be so large. Anyway, I power cycled the thing... against my better judgement because it would not do anything anymore.

Then, the moment of truth. Power cycle resulted in a nasty beeping post sound and a flashing red light. Looked up the flash code and sure enough, it was a "E04 - flash error." Great!

So, I put it away for the day... I didn't have my USB to SATA adapter at home. Next night, I figured I'd at least recover my data from the drive... I was orignally trying to back it up, right? So I read some articles/posts on the web and it looked like Buffalo might have taken some steps to prevent just plugging in the drive to a linux box. But the version I have, LinkStation Pro (LS-250GL) might not have any issues. I plugged it in to my USB to SATA drive enclosure and then plugged it into my Ubuntu laptop. Three windows popped up... awesome! One of the windows was the mounted partition of the data. So I copied off my data.

Next night, I decided to try this procedure. And, I decided to not go with wireless for this round... duh! Bummer... LS flash program from Buffalo wouldn't detect the NAS. Ran a ping scanner and it wasn't on an alternate IP. Set the subnet to 192.168.11 but still couldn't find the bloody thing. Hit the reset button on the back.... held the reset button on back... held reset on power on... lots of different sounds but no joy. Finally stumbled upon this. Talked about a arm9 box... what's that? Dunno. But, maybe the Linkstation would network boot.

Sure enough, I ran a TFTP server on 192.168.1.1 and power cycled the Linkstation and it took a load from the TFTP server. Then I was able to get the Buffalo firmware updater to "find" the NAS. Then it took the firmware perfectly. It was nice and quick (compared to wireless.) Booted up the NAS, configured a static IP, setup some shares and I'm back in business.

I still need to transfer my data back to the NAS and see if I can get the backup function to work... but at least I didn't have to throw away a perfectly good box.

A big thanks goes out to all those life hackers out there that helped get this thing back running.

Cheers,
Clyde

Don't forget your modem can be a router too!

Well, I spent a few hours last night setting up my webcam to be viewable from the internet. I have a Panasonic BL-C131A and so far I like it a lot. I had it working from my internal network just fine but I decided that I'd like to be able to access it from the internet.

So I set up port forwarding on my Vonage router which sits right behind my DSL modem. I tested from the internet and darn it... it wouldn't work.

So I thought.... maybe the ISP was blocking port 80 to prevent web serving from home. So, I changed the port on the webcam and confirmed it worked from the inside network. Changed the port forwarding on the Vonage router. And tried again. It still wouldn't work.

I couldn't tell if the Vonage router wasn't port forwarding or if maybe my "test" from the internet had a firewall that was blocking streaming or something to that effect. Oh yea, and the Vonage router has something that says "WAN blocking..." What is that? The help says that it blocks incoming from the WAN. Too general of a help file really doesn't help me here. So, I experimented with the setting and it didn't make any difference.

So I went to Shields Up to do a port scan on my home router. I only set it to scan the specific port I was interested in. Well, it reported that the port was "Stealth." I was stumped.

But then I happened to notice that my Vonage router had a 192.168 for a WAN IP. Ah hah. Another NAT and maybe another source for my problem.

So, I logged into my DSL modem and realized that I needed to get traffic from the WAN through. So, I turned off NAT. Because, really, I don't want two firewalls to deal with on my home connection. But, that broke everything and I didn't feel like figuring out why. Probably has something to do with a static route that might need to be set up.

I turned NAT back on and then found that the DSL modem also had a port forwarding option. So, I setup a port forward to forward to my Vonage router to work in conjunction with a port forward to my webcam.

Tested it... and voila... finally.

Lesson learned.... - sometimes modems are really routers. Too bad it took me a couple of hours to figure that out.

Cheers for now!
Clyde