We first attempted a metric change to the wireless adapter to have higher priority, thinking that it would fall back to the wired interface for anything inaccessible by the wireless adapter (similar to a load balancer – of sorts). That didn’t work as I expected so we were back to square one.

The solution I am cooking up is an attempt to remedy that.

Windows computers have long been able to create static routes that define IP rules for traffic to be handled in a specific way. Thankfully you can also specify which adapter can take user specified routes out of the box.

First of all, we need to know some information about the interfaces available on your computer. To do that, open a command prompt (in administrator mode on Vista and Win7) and type “ipconfig /all”, press Enter and you should be presented with something similar to what’s below.

Take note of the IP address and Gateway of your Wireless Network Connection. In my case above, the Wireless IP is 192.168.100.100 and the Gateway is 192.168.100.1, whereas the Wired IP is 192.168.100.102 and has the same gateway. If your wireless connects to a different AP than what is on your wired network, you will probably be on a different gateway for each adapter.

Next, we need a bit of information from the current routing table. To see your current routing table, open a command prompt (in administrator mode on Vista and Win7) and type “route print”, press Enter and you should be presented with something similar to what’s below.

The first section printed out will be your Interface List. You need to take note of the Interface Number your intended forced traffic will be going over (in this case, the WLAN adapter is #10). You should also look below the Interface List to the IPv4 Route Table. Take note of the Gateway for your WLAN card. You’ll need to know what IP address your WLAN card is using to determine that information, which is why we looked that up previously.

Lastly, You’ll need to determine the IP addresses of the services you are trying to access. If it’s a DNS name, you can resolve it by pinging the canonical name. For demonstration purposes we’ll use the IP address and subnet of my ISP, Dalton Utilities. Their subnet is 205.144.208.0/20, or expanded for use in the command we’re going to use a host of 205.144.208.0 with a subnet mask of 255.255.240.0.

Now we can get into the actual static routing!

The information needed for the ROUTE command, is DESTINATION (use the host address), SUBNETMASK (255.255.255.255 if just a single IP address), GATEWAY (from the adapter you are using), METRIC (we’re not going to specify one), and INTERFACE (for our example, it’s “10″ from the WLAN adapter using the route print command above). We will also add a -p switch at the end to make this persistent (to add it to the Windows registry so it can be enabled on a restart).

The command we will be executing for our example follows:

route add 205.144.208.0 mask 255.255.240.0 192.168.100.1 if 10 -p

Type “route print” again to verify the route is in the list under persistent routes, and begin utilizing your new static route over your secondary interface!

How are you using this information? Tell me below.

In my example, the USB Installer is on Drive D:\, and the operating system is installed  to the desired Drive C:\.

Step 1 — Open a command prompt with administrative privileges. To do so, open the Start Menu, and type “CMD” in the search prompt. Right-Click on the resulting program and “Run as Administrator”. This will invoke UAC as configured.

Step 2 — In the command prompt, type the following command:

bcdboot C:\Windows /s C:

Step 3 — Open up Disk Manager. To do so, right click on the “Computer” hotlink in the start menu (or your “My Computer” if you’ve added it to the desktop) and select “Manage”. Again, this will invoke UAC as configured. On the Explorer Window you are presented with, the left pane will contain Disk Manager. Click it once to open it to the main pane.

Step 4 — Mark the C:\ Partition as Active by right clicking on the graphical map and selecting “Mark Partition as Active..” from the context menu.

Step 5 — Unmount the USB drive (Eject first), and reboot. All Done!

Step 1 – Collect the iso images.

Step 2 – Install Virtual Drive that can read .iso images. I use VirtualCloneDrive from Elaborate Bytes. Freeware that works well. I’ve also used Daemon Tools in the past.

Step 3 – Partition and format your hard drive. Partition an 8GB section of the hard drive you’re planning to use and format it with the FAT32 file system.

Step 4 – Mount the ISO and copy the files to the newly created partition using XCOPY

xcopy [SOURCE]:\* [DESTINATION]:\* /e

Step 5 – Mark the partition as active. Right click on your Computer and select “Manage”. Go to Disk Management, right click on your new partition, select “Mark Partition as Active”.

Step 6 – Reboot and select your USB Hard Drive as your boot device. All BIOSes are different so the process is not documented here.

You will need to follow up with my next post to complete the whole process and be able to disconnect your hard drive.

That was the problem I ran into with one of my community sites. I was getting daily notifications of “new users” most of which were obvious combinations of a first-name/last-name dictionary attack, using out-of-country email addresses or free domain email addresses that require no invite, from IP addresses of non-community origin. I needed to remove the annoyance of these persistent email notifications. The solution was to eliminate access to the site from outside my community.

Step one was determining IP addresses. For my situation, I wanted to limit access to the entire United States. I did some searching and found a US zone file at IPdeny.com. Here is a listing of all countries they have zone files for. Step two was formatting the zone information such that it could be parsed through an Apache .htaccess file. I copied the zone information into a text document (using Notepad++), added the Limit clause to the top with the order clause below it, and set up a macro to add the allow from before each IP address on every line. After a portion of time, my macro completed and I added a deny from all line, and closed the Limit tag.

The result looked like this:

<Limit GET HEAD POST>
order deny,allow
allow from 3.0.0.0/8
allow from 4.0.0.0/8
…
allow from 216.255.192.0/19
allow from 216.255.240.0/20
deny from all
</LIMIT>

At that point it was just a matter of saving the document out to my .htaccess file and testing. To do so, I searched the document for my IP block and commented it out with a ‘#’. I got a 403 Forbidden page, so I uncommented my IP block and tried again. PRESTO! Works like a charm.

A couple of other things you may want to do would include blocking a single country (instead of allowing a single country like I did) or to allow additional IPs through, in the case of someone unable to access using the list you obtained. To block a single country, you would change the “allow from” statements to “deny from” statements and use the IP addresses from that specific country. Some people would only like to block the most notorious countries (Nigeria, for example). In order to add a single IP address you create a new line, and put the IP address with a /32 on the end. You can add as many “allow from” or “deny from” IPs to this list as you desire.

After some searching across the web I found that there wasn’t a very good write up on the step by step procedure to enable a TFTP daemon on Ubuntu (my choice for linux servers). I had actually messed around with the tftpd package, but in the little bit I was able to find I determined I wanted to use the ‘atftp’ and ‘atftpd’ packages available in Ubuntu’s universe repositories due to more adoption in instructions that were available. In what I’ve been able to determine, both the server daemon (atftpd) and the client program (atftp) are necessary on the server (computer). The reasoning, as best as I’ve been able to determine, is that the server (daemon) only makes the files available. The client (program) does all of the “work” in negotiating connections between each other, so a client (program) is necessary on both the server (computer) and the client (computer). I hope that made sense.

So that you have a baseline of expectations, I’ll be open with the specs and configuration of the server I’m using:

• Ubuntu Server 10.4 Lucid Lynx x86 (32 bit)
• Dual 1.4Ghz Pentium3 CPUs
• 512MB RAM
• Running as Guest OS on VMWare ESXi 3.5 Update5

Now, let’s get atftpd installed.

1. Get Root.

   sudo -i

2. Install atftpd.

   apt-get install atftpd

3. Edit atftpd’s configuration.

   pico -w /etc/default/atftpd

   change “USE_INETD=true” to “USE_INETD=false”

   ctrl+x, enter, y

4. Start atftpd.

   invoke-rc.d atftpd start

5. Add the tftp directory.

   cd /srv

   mkdir tftp

   chmod 777 tftp

   chown nobody:nogroup tftp

6. Restart atftpd.

   /etc/init.d/atftpd restart

7. Install the client (program).

   apt-get install atftp

8. Done!

At this point, use your favorite SCP client (program) to upload any firmware files to the /srv/tftp folder. Once it is uploaded, point the tftp location in your firmware update process to your newly deployed tftpd server. Easy enough!

Thanks for visiting, if you have any questions feel free to comment below and I’ll do my best to reply and help you out.

If you run into this same issue with a memory error and the following error in the server console window:

workthreadpool.cpp (296) : Assertion Failed:CWorkThreadPool::StopWorkThreads: Some threads required forcible termination.

The fix is to update your cfg/mani_admin_plugin/gametypes.txt with the one generated here at the Mani Admin Plugin’s site.

It took me a bit to find this fix, so hopefully the search engines were nice to you and directed you here.

1. sudo -i
2. apt-get update
3. apt-get upgrade
4. apt-get install build-essential binutils linux-headers-$(uname -r)
5. mount /dev/scd0 /cdrom
6. cp -a /cdrom/VMwareTools* /tmp/
7. cd /tmp/
8. tar -vxzf VMwareTools*.gz
9. cd vmware-tools-distrib/
10. ./vmware-install.pl

CD-ROM mount point may vary. Accept all defaults for vmware-install perl script.

This post won’t outline how to use Synergy, but rather just how to take care of the little things that will keep it from being a good experience on Windows Vista/7. I’m writing the rest of this post for those that are already familiar with Synergy, and instructions are targeted at Windows 7 Professional users.

Anyways, I was running into problems with my Synergy client on my home-office setup. I have a laptop docked with a second monitor for my office computer (operating as the Synergy client), and then a single monitor rig in portrait-orientation for my home computer (operating as the Synergy server). I use Display Fusion, which runs as an administrator-level service on my desktop, and I use the multi-monitor taskbar available on the paid version of the software. I was unable to use the Synerg-ized mouse to select a window on that Display Fusion taskbar, and considering that was my 24” monitor where a lot of my work takes place it would be a huge problem if the laptop didn’t have a keyboard. On top of that, every time the client computer would prompt for UAC approval for various things, I would lose the ability to use my G5 mouse and G15 keyboard on my office laptop.

I knew you could auto-elevate privileges, but just hadn’t taken the time to do it. Let’s get that out of the way, as that’s the first thing I noticed in the problems I was having.

Step 1. Open secpol.msc

Step 2. Set UAC Behavior for Administrators to ‘Elevate without prompting’

Next up is configuring Synergy to run as Administrator. I want to note that this was my initial guess as to why it wasn’t allowing me to Auto-start on computer start, however even after forcing it to run as Administrator and installing the Auto-start service, it still wasn’t working. I found out this is due to the way the System user interacts (or rather doesn’t) with the user’s desktop.

Step 3. Run Synergy as Administrator.

Right click on the shortcut for Synergy, and click the Advanced… button. Check the “Run as administrator” box.

Step 4. Auto-start Synergy on Log-in

Step 5. Start Synergy!

Follow these steps on both the server and client if they’re both Windows 7 machines, it’s just that simple.

Things I knew I wanted:

• Exchange Support
• WiFi and/or Mobile Internet that does not suck.
• Decent Camera (the BB8830 doesn’t have a camera)

The only decent mobiles out there that had Exchange Support for email were Windows Mobile 6.1 powered phones. I was also looking to not appear too greedy, so I tried to keep the budget for the new phone under $150. With our provider, the only real option at this point was the Samsung Omnia. I wasn’t upset with that, because it appeared to have fairly good user ratings. I received the phone and was pleased. It connected to Exchange without any trouble, it had an 802.11 radio, and a fantastic camera with more features stock than the iPhone.

Every few weeks I am the On-Call technician for the ISP/hosting company I work for. I’d like to be able to attach my cell phone to my laptop and be able to handle 95% of the work that I would typically be responsible for while on-call, which only requires a stable internet connection for RDP or SSH. I began to look for tethering options and came across WMWifiRouter in my searches. I was a bit skeptical because my wireless network has a reputation for disabling certain “features” that may allow the user to do more than they want to provide, but I gave it a go. Here were the necessary steps to make this work for my phone:

1. Enable Internet Connection Sharing on your windows mobile phone.
2. Restart the phone.
3. Install WMWifiRouter.
4. Restart the phone.
5. Run WMWifiRouter.
6. Connect to the wireless ad-hoc network it creates (see image) from your laptop or other wireless device.

From there, you should be able to browse the internet, download files, run a speed test, and connect to your office VPN to scare the night technician by printing to the network printer.

I did some searching and there wasn’t anything super awesome out there that would keep me away from using the command line interface of VLC. So, the first step was to install vlc. I also use screen so I can log out of my SSH session and just use the web interface available on VLC, so I’ll include steps for using screen.

sudo apt-get install vlc screen

During or after installing vlc, you might as well set up the port forwarding on your router for access to the web interface. Log into your router and open up port 8080 to your server. If you are not trying to stream over the internet or don’t have a persistant dynamic or static IP address, you can skip this step. Check http://www.portforward.com/english/routers/port_forwarding/routerindex.htm for information on how to port forward on your router.

The next step was to get into screen and start the media daemon.

screen
 vlc -I http

You can then press ‘CTRL’+'A’ followed by pressing ‘D’ to detach from your screen instance and log out of your server (this is the glory of screen). You can reconnect to screen later by entering ‘screen -r’ at the shell of your server. I use screen for all of my console-based server daemons or anything I want to have run while disconnected from the SSH session I’m in (HLDS, SRCDS, VLC, ‘apt-get upgrade’, ‘tail -f’).

Then browse to your server by going to http://your.server.ip:8080/ . You should be greeted with an html representation of the VLC interface you may be familiar with on your computer. It will look something like this:

At this point you can toggle the Stream Output by clicking on the icon that has three staggered arrows pointing to the right (on the default theme). From here you want to check the ‘UDP’ box enter your external IP and a port (default is port 1234 on VLC UDP client) to use for streaming. This method makes it easiest for connecting the client side for streaming, which in most cases is ideal. If you’re going to set this up for less savvy users simplifying their end makes it easier on you as the admin, TRUST ME.

Next, open up UDP ports 1234 on the client router forwarding it to the viewing computer again this won’t be necessary over LAN and won’t be possible from a NAT’d server. Start VLC on the client computer and open Network Stream (CTRL+N) and click OK.

Back on the Web Interface, open the file and play it. If you don’t have any port forwarding or NAT issues, you’re done!

UNLESS-
The first 2 episodes I have are not encoded with anything special, so I was able to stream them without adding any extra codecs to my server. However, episode 3 needed xvid codecs.

Here’s the steps to add the “non-free” w32codecs:

sudo wget http://www.medibuntu.org/sources.list.d/hardy.list -O /etc/apt/sources.list.d/medibuntu.list

sudo apt-get update && sudo apt-get install medibuntu-keyring && sudo apt-get update

sudo apt-get install w32codecs

Restart the vlc daemon and you’ll be able to play xvid (and I assume divx as well).