Accessing Windows 7 VPN Server When DHCP Fails (PPTP)

Standard

The Short Version: If your VPN client fails to obtain an IP address via DHPC when connecting to a Windows 7 VPN server using PPTP, it may be possible to connect to the server over RDP by accessing it at 169.254.128.230 if your client is assigned an IP in the same network range.

Last night I was logged into my Windows 7 desktop system back home, which runs my home automation software and acts as a VPN server. I recently had to setup the VPN server again and was trying to troubleshoot the problem of VPN clients not receiving DNS server addresses from the server.

At one point I changed the server configuration from providing a specific range of IP addresses to instead provide IPs via DHCP. After making this change I could still connect to the VPN but my client received a 169.254.128.x address and I could no longer access the server over RDP at the previous address.

I was accustomed to thinking of the 169.254.x.x range as being a sign of a problem and not as a useable network range so I kept trying to access the original, internal network via various methods (trying to override my VPN client assigned IP, using a virtual machine with a shared network connection but on the original network). I even tried to RDP to 169.254.128.1 but it also failed.

Finally, at some point I realized that there was an entry for a default gateway in my VPN client settings. In my case it was pointing to 169.254.128.230. I’m not sure if this is always the case.

When I entered this address into the RDP client I was able to connect and then set the server back to distributing the specific range of IP addresses that were previously defined, instead of using DHCP.

I haven’t resolved the original problem but I was able to get back into the machine and restore the VPN setting.

mControl 3 Activation Problem – License File

Standard

Our house experienced a power surge caused by a nearby lightning strike that damaged one of our A/C units along with a few other devices. Today I figured out that it damaged the network ports on the Airport Extreme Base Station along with the ethernet port on the ASUS system, which is my home automation server.

Fortunately, the ASUS box also has wireless so I was able to shift all of the network services over to the wifi adapter. I had to re-establish the built-in VPN server, among other annoyances. Since the ethernet port was no longer usable I decided to disable it in Windows 7.

Well, that caused a stupid problem.

mControl 3 has activation. I’m not a fan of activation.

I noticed the service was no longer working and wouldn’t start. When I viewed mControl’s log I saw the following message every time I attempted to start it:

The Installation Code of the license file does not match with Code 2. Please contact your System Administrator.
mServer License Code=Hacked/Hacker, Ver=.

My version isn’t hacked. I paid the commercial price (less because it was an upgrade from a previous version that I had also paid for). At first I thought that perhaps the license information was damaged but then I remembered that I had disabled the ethernet port and I noticed that there were some entries in the log during the activation check that hinted toward a check of the network device.

I re-enabled the built-in ethernet port. Sure enough, the software passed the activation check and started up. It seems to use a hardware identifier that’s part of the network card for activation.

 

 

 

 

Avoiding IP Conflicts When Using Virtual Machines

Standard

I thought I had mentioned this tip in a previous post but since a quick search didn’t turn it up I figured I’d add this as its own entry. Not long after I started using virtual machines on a regular basis at work I encountered an IP conflict with a VM and another machine on the network.

The cause was simple. The last time I had used the VM I chose to suspend its state. It retained the IP and tried to use it the next time I started it up.

The solution is also simple. I’ve used this method with both VMWare Fusion and Parallels Desktop for Mac. Every time I prepare to suspend a virtual machine I simply disconnect the VM’s network connection prior to suspending. This will cause it to release the IP. The next time the state is restored and the network is reconnected it should pull a new IP.

It’s worth mentioning that this really only applies to VMs that have IP addresses assigned via DHCP.

Xbox 360 Wireless Network Adapter Won’t Connect to Xbox Live

Standard

The Short Version: I can make it work by selecting “Connect to Xbox Live”, letting it fail the test, and then choosing the option to test the connection to Xbox Live. After it completes successfully I can then connect to Xbox Live. I never found a solution to this problem.

Rather than deal with this problem indefinitely I removed the Microsoft adapter and now I’m using an ethernet to wifi bridge device, which works perfectly.

Several months ago I moved the Xbox 360 into a different room. Rather than run another network device for the only console that doesn’t have built-in wireless (I have an older model) I decided to purchase an Xbox 360 Wireless Network Adapter.

It works, but not perfectly. I haven’t identified the cause yet. It could be a compatibility issue with my Apple Airport Extreme Base Station though it may be something very obscure. It doesn’t receive a very strong WiFi signal but I wouldn’t rate as being weak.

Whenever I start the Xbox 360 up it no longer automatically logs into Xbox Live (despite being configured to do so). In addition, it won’t connect to Xbox Live just by clicking the appropriate tile.

The only way I can make it connect using the WiFi adapter is to select the option to test the connection to Xbox Live, after it fails to connect.

After the test successfully completes I can then back up to the main menu and sign into Xbox Live without problems.

Updated 06/25/2012: I still haven’t found a permanent fix for this issue. It’s as though the USB wifi adapter simply doesn’t wake up when I turn on the Xbox 360. I have to run a connection test every time to get it working. The issue isn’t caused by the Airport Extreme Base Station. It took a hit to some ethernet ports recently and is no longer in line. I’m still experiencing the same problem with my ASUS wireless router.

Updated 12/10/2012: I sold it to a friend recently and he reports that he doesn’t have this same issue. I suspect that the wifi signal where my Xbox system is located is rather weak, which creates problems for the Xbox adapter. I’m currently using an IOGear device with the Xbox and it seems to be able to connect to Xbox Live automatically at start-up.

SMB File Sharing Stopped Working In OS X Lion (Resolved)

Standard

The Short Version: Every now and then File Sharing on the target machine running OS X Lion quits working. I must disable and then re-enable File Sharing to get it working again. So far I haven’t found a permanent fix.

Today I discovered that I could no longer access shared files on my iMac from a MacBook Pro via SMB File Sharing. Both systems are running Lion. The file sharing was working only a day prior. This problem was rather odd. I could access file shares on other machines from that Mac without a problem. I could also access that Mac via Screen Sharing using the same credentials that File Sharing wasn’t accepting.

I’m not sure what caused this problem. The only major change I made on the iMac since yesterday was to run a Full Defrag using iDefrag 2. I don’t know if this actually caused the problem (or if it even could). While troubleshooting the issue I repaired permissions on the drive, but that didn’t make a difference.

Though the short name, originally established under Snow Leopard, for the account had been working I tried using only the long name. That didn’t work either. Every time I entered my credentials the login prompt shook to indicate it didn’t work.

Finally, I just went into the File Sharing Options, unchecked SMB (AFP wasn’t checked to start with) and saved this change. This turned off all file sharing. Next, I went back into the settings and re-enabled SMB File Sharing.

It worked.

Despite the fact that the system settings weren’t any different I can once again access shared files over SMB. My best guess is that something hadn’t been fully re-enabled. Perhaps during the defrag process some permission was changed that prevented the sharing from working. By disabling and then re-enabling the service it may have re-established the appropriate file permissions. Of course, that’s just speculation.

Updated 11/24/2011: The fix wasn’t permanent. The same problem cropped up again and, as before, the same solution also corrected the problem.

Updated 06/09/2012: Yep. It still happens despite various system updates that have been released since. Every now and then I’ll attempt to connect and then find that I have to disable and re-enable the service to make it work again.

Using a Foscam Wireless/Wired IP Camera (FI8918W) with Vitamin D Video

Standard

Occasionally, in the process of setting up a new piece of equipment, I’ll tinker with configuration options if I can’t get something to work right. Later on I may forget the extra steps I made, which can be a problem when I write in a post that I have a piece of software working with a certain piece of hardware but completely forget that it didn’t work out-of-the-box.

This post has some information about setting up Vitamin D Video to work with a Foscam FI8918W. Currently, Vitamin D Video does not officially support this Foscam model. That may change – I submitted some information to Vitamin D Video this evening which might help them add official support.

Continue reading

Accessing Two Different Windows Shares With Different Credentials Simultaneously From The Same Server

Standard

Perhaps I was aware of this restriction a long time ago, when I used a Windows system as my primary desktop, but I completely forgot this. Windows does not permit accessing two different shares that use different credentials when they exist on the same system. There may be more to it than that. For example, it may only apply to a Windows user account logged into a desktop system.

Regardless of the details, I wasn’t able to access two shares on a network drive from the ASUS (Windows 7). Every time I tried to connect to the second share I’d receive a vague error message stating that the connection couldn’t be made. I knew the credentials I was using were correct.

One solution is to disconnect the first share and then connect to the other one. However, I was using that share for the Windows system backup and I didn’t want to bother with having to remove the connection and then re-establish it.

After searching a few pages and forums I came across one post in the Microsoft TechNet forums that explained a workaround. That this even works is laughable, but it really does. User Mustafa Radha explains that using the IP address for one share, and then using the network name for the other share, will work. Indeed it does.

For example, assume I’m trying to connect to a machine named “Server” with an IP address of 192.168.1.2, and it has two shares named “Photos” and “Documents”. You could access both shares at the same time by using these paths:

\\Server\Photos\
\\192.168.1.2\Documents\

Of course, you could swap the IP and name as desired.

Source: Microsoft TechNet – Connecting to multiple shares on a single server with multiple credentials? (System Error 1219)