While travelling and visiting a family members home recently, I ran into an issue with their modem not allowing me to connect with my laptop.  Turns out that their provider had MAC filtering on their system.

A MAC Address is a unique number (hexadecimal) that most every network adapter has.  When you plug in a cable to a router and then to your computer, the first communication that occurs is the two devices declaring who they are by stating their MAC address (Ok, this is a big simplification, but no need to digress to far).  MAC addresses are intended to be globally unique, and as such are divided into two: The manufacturer ID and a manufacturer assigned ID.  This  helps guarantee that all MAC addresses are unique.

MAC filtering is a security measure some routers or ISPs use to limit access to the network. By stating that only computers with a certain MAC address are allowed onto the network, you can add an additional layer of security.  Most wireless routers have this feature (a good idea if you're paranoid and already set up a password on your wireless network [WHICH EVERYONE SHOULD DO]). Many non-wireless routers have this feature also.  And occasionally, ISP's enable this feature on their networks.

This is a problem that I rarely (actually, only once before) have run into.  It used to be simple for me to overcome, as I used to take a wireless router with me also, and that would easily allow for overriding of the MAC address though a configuration screen.  However, with the proliferation of wireless routers I stopped bringing my own and instead just jump on the local network.

Luckily, there is a way to spoof your MAC address.

There's a couple programs out there to do it for you (google will help, but I haven't tried any of them so can't recommend them) but I prefer to get my hands dirty, so with no further ado, how to spoof your MAC address:

Windows Vista:

NOTE: This requires modifying your registry.  If you do NOT know what you are doing, DO NOT DO THIS.  If you mess up your registry, your computer may not boot at all.  

First, you'll need to know the adapter you are changing your mac address for.  The easiest way to make sure you have the correct one is to open a command prompt and type:

net config rdr

You'll see a line that says "NetBT_Tcpip_{XXXXXXX....}.  This is the GUID of your adapter (A GUID is a Globally Uniqued IDentifier).  Copy this number, (between the curly brackets)  In this example, the GUID is 6F3A69A0-81B8-42B4-A38D-06ECC66485CC

Next you'll need to edit the registry.  In the command prompt, type:

REGEDIT

Once in the registry editor, navigate to the key:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}

Underneath this key are lots of sub keys.  To find the one you want (with that key selected) press Ctrl+F and search for the GUID.  You should find it as a value for a key named NetCfgInstanceId.  Inside this key, add a new string value with a name of NetworkAddress and set the value to the MAC Address you want (no dashes).

Once that is done, you can reboot or disable/re-enable  the network device in Device manager.

To revert back, simple delete the key you added (NetworkAddress).

Hope that helps

When we fist decided to implement a blog on our site, we figured it would be quick and easy to roll our own, and for the most part it was.  After all, a blog is only composed of a handful of tables, each with a spattering of columns.  You have the blog itself, then you have comments.  That's the long and short of blogging.

At least at first glance.

After you get the blogs up, you certainly want to implement trackbacks and pingbacks.  If you don't know what these are, they are simply a way of interlinking sites, so that if I comment on a blog at foobar.com, they can add a link back to my site, saying comments were made there.

Trackbacks are relatively straight forward as they are simply HTTP calls made in a REST fashion (spec can be found here)

Pingbacks are only slightly more involved.

Enter the XmlRpc Spec

Pingbacks are entriely built arond the Xml-Rpc specificaion, which is exactly what it sounds like, remote procedure calls via Xml, a simpler version of SOAP if you will (I'll leave the Xml-Rpc vs SOAP vs REST argument for another day).  I'll be the first to admit, somehow up to this point in my programming experience, I had somehow avoided interfacing with Xml-Rpc directly. So I did what I always do when confronted with a new spec, I read the manual.

This is a point that I want to stress.  I know a lot of developers who can churn out code to email someone without having read one single RFC concerning SMTP, MIME or any other similiar technology.  This is a sure way to limit your usefullness as a programmer.  Along with learning a language a year, coders should also strive to understand the undelying concepts of the systems they are working with.

But I digress.  To return to point, I went and read the spec, which on the surface seemed pretty simple.  Since I didn't know how to implement it myself and it seemed rather simple, I decided to take a crack at implementing my own library.

In the beginning, there's the XML

Since Xml-Rpc utilizes HTTP for the request/response, and since the HttpWebRequest method is built into the .Net libraries already, I decided to start with the xml.  The spec site gives a very verbal breakdown of how the xml is structured, but it is missing a schema definition file, so that's where I began.  This can be found here.

Once I have the xsd defined, I used XSD.exe tool that comes with Visual Studio to create the first version of the classes to serialize the documents.  The XSD.exe tool is an extremely valuable tool, but, generally, we only use it to get a base to work from.  You can find the results of this generation here.

In the next part, I'll go over the changes to the Xml

NOTE:

We've released this project under the LGPL and you can download it at codeplex, BXmlRpc.  The current generated documentation can be found at http://bxmlrpc.bambitinc.com/Documentation/