Feroze Daud's WebLog

Moved on...

Feroze Daud — Fri, 14 Aug 2009 04:55:00 GMT

At the beginning of this year, I moved onto a different company. I have joined Zillow as a Software Engineer. I will now be blogging at http://ferozedaud.blogspot.com. Hope to see you there.

Cheers!

Test-UMConnectivity Primer

Feroze Daud — Sun, 21 Dec 2008 00:41:09 GMT

Exchange 2007 Ships with a tool called test-umconnectivity that can be used to verify the health of your Exchange Unified Messaging installation.

It has a couple of modes of operation:

Local Voice

In this mode, the task will run on a machine that has the Exchange Unified Messaging role installed. It will run diagnostics against the local UM server.

The way to run this, is to invoke test-umconnectivity without any parameters.

In this mode, the task verifies that the UMService is listening and responding to incoming INVITES.

[PS] D:\users\Administrator>test-umconnectivity

UmserverAcceptingCallAnsweringMessages : True
CallAnswerQueuedMessages               : 0
CurrCalls                              : 0
UmIPAddress                            : 10.197.228.62
Latency                                : 2121
OutBoundSIPCallSuccess                 : True
EntireOperationSuccess                 : True
ReasonForFailure                       :
Identity                               : 62caff65-7a68-46ab-b2a3-ef52a31e431e
IsValid                                : True

Remote Voice

This is an end-to-end test. It verifies that the connectivity from UMServer to Gateway to PSTN is working fine. In this mode, the task does the following:

1) Makes an outbound call to a given phone number using a gateway.

2) The gateway will then send the call to the PBX.

3) The call will then come back to the gateway from the PBX.

4) The Gateway sends the call to a UM server that is linked to the gateway.

5) UM server will respond to the incoming INVITE with some DTMF tones, that are then verified by the task.

This test can be run from any machine that has the Exchange 2007 admin tools installed. It can also be run from any machine that has the Microsoft Operations Manager (MOM) installed, along with the Exchange Management Pack.

For example, I have a UM server setup with an IPGateway. I also have an autoattendant configured with an extension 74808. I want to make sure that my autoattendant is answering calls.

[PS] D:\users\Administrator>get-umipgateway

Name                 Address       HuntGroups    OutCallsAllowed Status
----                 -------       ----------    --------------- ------
UNSECURE_GATEWAY     10.198.250... {74809:UNS... True             Enabled
SECURE_GATEWAY       securegw.e... {}            True             Enabled
sipphonegw           157.56.146.19 {:UNSECURE... True             Enabled

[PS] D:\users\Administrator>get-umautoattendant

Name              UMDialPlan      PilotIdentifier SpeechEnabled Status
                                  List
----              ----------      --------------- ------------- ------
aa1               UNSECURE_DIA... {74808}         True           Enabled

[PS] D:\users\Administrator>test-umconnectivity -UMIPGateway unsecure_gateway -Phone 74808

CurrCalls              : 0
UmIPAddress            : 10.197.228.62
Latency                : 43236
OutBoundSIPCallSuccess : True
EntireOperationSuccess : True
ReasonForFailure       :
Identity               : 385bbfdf-26fc-460e-9ccb-a1f14b750c0b
IsValid                : True

The output of the command shows which UM server answered the call, the call latency, etc.

TuiLogon

In this mode, the task will test that the UM server can connect to a mailbox in a site. This is used to make sure that the UM sever has good connectivity to mailbox servers that have the mailboxes for UM enabled user that the UM server is servicing.

In order to run this command, we need a UM enabled mailbox with an extension. Also, this command needs to be run on a UMServer.

[PS] D:\users\Administrator>test-umconnectivity -tuiLogon:1 -UMDialPlan:unsecure_dialplan -phone:74808 -pin:147258

Encapsulating Enumeration

Feroze Daud — Tue, 04 Nov 2008 04:26:00 GMT

While writing a unit test for a particular feature, I was faced with an interesting problem. My unit test has different scenarios. These scenarios test that a certain data item is propagated all the way down from the called function.

For eg, I have a method that I need to test - lets call it CFoo:DomSometing().

We pass in a data item to this method - so as part of the changes I change the method to CFoo::DoSomething(int data)

I need to make sure, in my tests, that the 'data' item is properly consumed by the function.

It turns out that for different functions that I call as part of each of my scenario, the way of checking is different. For eg, for one scenario, I have to call the function 'n' times, whereas for another scenario, I have to call the function for a particular duration.

I want to encapsulate all of this, so that I can write one test function that does the following

bool RunTest ( RunTestDelegate testMethod, int data, ILoopIterator iterator)
{
    foreach (int i in iterator.GetValues())
    {
         // call the test method
         testMethod (data);
    }
}

Here, the RunTestDelegate will be used to encapsulate each method that I need to test, so that I dont have to write one RunTestXXX method per each method I want to test.

The question is: how do you implement the ILoopIterator? Clearly, the first requirement is that it should be returning an IEnumerable<int> because that is what the foreach loop is iterating over.

Also, as discussed above, we need it so that we can iterate over both a range of values, as well as for a time duration.

In order to solve this, I implemented the interface as follows:

interface ILoopIterator
{
    IEnumerable<int> GetValues();
}
class LoopIterator : ILoopIterator
{
    private int count;
    private TimeSpan duration;
    private bool isCounted;
    private LoopIterator (TimeSpan duration)
    {
        this.duration = duration;
        this.count = -1;
        this.isCounted = false;
    }
    private LoopIterator (int iterationCount)
    {
        this.count = iterationCount;
        this.isCounted = true;
        this.duration = TimeSpan.MaxValue;
    }
    public static LoopIterator CreateTimed(TimeSpan duration)
    {
        return new LoopIterator (duration);
    }
    public static LoopIterator CreateCounted(int iterationCount)
    {
        return new LoopIterator (iterationCount);
    }
    public IEnumerable<int> GetValues()
    {
        if (this.isCounted)
        {
            for (int i = 0; i < this.count; i++)
            {
                yield return i;
            }
        }
        else
        {
            int i = 0;
            DateTime end = DateTime.Now + this.duration;
            while (DateTime.Now < end)
            {
                yield return i;
                ++i;
            }
        }
    }
}

This code used the .NET/2.0 C# features - i.e generics & yield statement for implementing enumerators.

The caller will use a different factory method, depending on how he wants the iteration to be performed.

For duration based iteration, use LoopIterator .CreateTimed(TimeSpan duration)

For normal iteration (like a for loop) use LoopIterator .CreateCounted(int count)

The utility of this pattern, is that the client (which is using ILoopIterator ) does not need to change!

AutoAttendant: What do the various Greetings mean

Feroze Daud — Mon, 22 Oct 2007 20:17:00 GMT

This post is going to give an explanation of what the various greetings mean, for the autoattendant.

The posting will be divided into two sections. First, I will describe the common structure. Next, I will describe how this manifests itself at runtime for the DTMF AutoAttendant, and the ASR AutoAttendant respectively.

Greeting Configuration for the AutoAttendant

The greetings are configured for the AutoAttendant using the set-umautoattendant command in Powershell, or by using the Exchange Management Console MMC snapin that ships with Exchange Server 2007. When using set-umautoattendant, the following parameters are available to customize the greetings

Prompt	Description
InfoAnnouncementFilename	Informational Announcement
InfoAnnouncementEnabled	Informational Announcement Enabled Flag
BusinessHoursWelcomeGreetingFilename AfterHoursWelcomeGreetingFilename	Welcome Greeting Announcement
BusinessHoursWelcomeGreetingEnabled AfterHoursWelcomeGreetingEnabled	Welcome Greeting Announcement Enabled
BusinessHoursMainMenuCustomPromptFilename AfterHoursMainMenuCustomPromptFilename	Custom Menu Announcement
BusinessHoursMainMenuCustomEnabled AfterHoursMainMenuCustomEnabled	Custom Menu Enabled

If you want to set the Autoattendant greetings using the Exchange Management Console MMC snapin, then you should navigate to the Greetings tab of the autoattendant properties page.

DTMF AutoAttendant Greeting ConfigurationMain Menu Greetings.

The Greetings for the Main Menu of the autoattendant are played in the following sequence.

First, the autoattendant plays the WelcomeGreeting defined on the AutoAttendant. If no greeting is defined, then the default greeting is played. The default welcome greeting is "Welcome to Microsoft Exchange Automated Attendant".

If the call was received during Holiday Hours (as defined in the holiday schedule), then the greeting associated with that holiday is played. After this, the Informational Announcement is played (if defined).

If a custom menu is defined, then the prompt defined in the AutoAttendant's BusinessHoursMainMenuCustomPromptFilename is played. The custom menu can be defined by setting the BusinessHoursCustomMenuKeyMapping. To enable the custom menu, set the BusinessHoursCustomMenuKeyMappingEnabled property to true.

If a custom menu prompt filename is not defined, then the server will do a best effort to render a TTS (Text to Speech) greeting using the CustomMenu options that were defined.

Custom Menu TTS

When a CustomMenu prompt filename is not defined, then the system will TTS the custom menu prompt. In order to TTS the prompt, it will sort the Custom menu in increasing order by the Key that has been defined. Then it will use greeting templates defined for the language of the autoattendant to generate Greeting segments, one for each menu item. The greeting segments are then concatenated to give the final greeting.

For a normal (non-timeout) menu option, the following greeting template is used to generate the greeting segment.

For <description> Press <key>

And if you have a timeout option defined in the custom menu, then the following template is used.

Or, stay on the line for <description>

The following table shows the greeting segment that are generated from the custom menu definition.

Key	Description	Greeting Segment
1	Sales	For Sales Press One
2	Support	For SupportPress Two
Timeout	Directions	Or, stay on the line for Directions

Once we have the greeting segment, the final greeting is generated by concatenating each individual greeting segment:

For Sales Press One. For Support, Press Two. Or, stay on the line for directions.

Autoattendant Greeting Scenarios

The following section describes how the autoattendant sounds when different combinaions of greetings are configured, along with some of the other options that effect greeting playback.

Default Configuration

This is the case where an autoattendant was created, and no settings were modified on the autoattendant. The autoattendant will sound as follows:

Welcome to Microsoft Exchange Automated Attendant.

Custom Welcome Greeting configured

You can change the welcomg greeting of the autoattendant by specifying a Business/AfterHours WelcomeGreetingFilename, and setting the corresponding Business/AfterHours WelcomeGreetingEnabled flag to TRUE. Once you do this, the system will sound as follows:

Welcome to Contoso Corporation.

Custom Informational Greeting configured

You can configure an informational greeting to let the callers know about extraordinary situations like unforeseen closures etc.. This greeting can be configured by setting the InfoAnnouncementFilename & InfoAnnouncementEnabled properties of the autoattendant. If you set this greeting, then the system will sound like this:

Welcome to contoso corporation. We are closed due to year end Inventory processing.

If you set the InfoAnnouncementEnabled property value to Uninteruptible, then this greeting cannot be interrupted by the caller. This means that the entire main menu greetings will become uninterruptible. This includes the welcome greeting, informational greeting, and the holiday greeting as well.

Holiday Greetings

You can also configure a holidy schedule for the autoattendant. When a call comes in during a holiday, the autoattendant will play a greeting specified for that holiday. Normally, it doesnt make sense to have both an Informational greeting and holiday greeting active at the same time, so we will assume for this scenario, that the informational greeting is not configured.

You can specify a holday schedule and greeting for the autoattendant by setting the autoattendant's HolidaySchedule property using Powershell. Or, if you are using the MMC, you can navigate to the Times tab, and set the Holiday Schedule there.

If you specify a holiday schedule for Christmas, for example, and also specify a greeting for that holiday, then this is how the main menu will sound when a user calls in.

Welcome to Contoso Corporation. The office will be closed on the 24th and 25th of December for Christmas. Normal hours will resume from the 26th of december.

Custom Menu Greeting

If a custom menu is defined, then the next greeting that will be played is the custom menu greeting. As explained earlier, the autoattendant will use the greeting defined in the Business/AfterHoursMainMenuCustomPromptFilename. If no greeting is defined, then a TTS greeting will be played to the caller.

If you assume that the custom menu has three options: Sales, Support, Directions as described in the section above, then this is what the caller will hear when no custom menu greeting is defined:

Welcome to Contoso Corporation. For Sales Press One. For Support, Press Two. Or, stay on the line for directions.

Additionally, if Transfer to operator and directory search are enabled for the autoattendant, the autoattendant will give the caller these options as well:

Welcome to Contoso Corporation. For Sales Press One. For Support, Press Two. Or, stay on the line for directions. To contact someone, press the Pound key. To speak to an operator, press Zero.

If the call came in during a holiday, then the holiday greeting will be played after the welcome greeting. In that case, this is what the callers will hear:

Welcome to Contoso Corporation. The office will be closed on the 24th and 25th of December for christmas. Normal hours will resume from the 26th. of December.

For Sales Press One. For Support, Press Two. Or, stay on the line for directions. To contact someone, press the Pound key. To speak to an operator, press Zero.

However, if you define a greeting for the custom menu, then this is what the caller will hear:

Welcome to Contoso Corporation. The office will be closed on the 24th and 25th of December for christmas. Normal hours will resume from the 26th. of December.

To talk to our sales department, press One. For support issues, press Two. Or, you can stay on the line for directions.

If you compare this greeting flow with the flowchard given in the begining, you will noticed that the custom menu greeting did not give the caller an option for transferring to the operator, or doing directory search by pressing the Pound key. If you want to give callers this option, you must record these into your custom menu greeting.

If you dont want to give callers this option, you can disable them on the autoattendant.

PowerShell script to get the reason why a Unified Messaging worker process recycled

Feroze Daud — Fri, 16 Mar 2007 08:24:00 GMT

If you are the administrator of an Exchange Unified Messaging server, you might want to know why the UM worker process is recycling and how often. The following one line PowerShell script will print out all the reasons why the process recycled:

get-eventlog application | where { ($_.EventId -ge 1049 -and $_.EventId -le 1055) -or $_.EventId -eq 1092 } | ft -wrap

If you run this command, you will get an output like so:

Index Time          Type Source                EventID Message
----- ----          ---- ------                ------- -------
56821 Mar 12 20:35 Info MSExchange Unified M     1055 The Unified Messaging Worker Process was terminated because the confi
    9                    essaging                      gured maximum lifetime was exceeded.
56773 Mar 12 20:05 Info MSExchange Unified M     1000 The Unified Messaging Worker Process was started successfully on port
    4                    essaging                       "5065".
56772 Mar 12 20:04 Info MSExchange Unified M     1051 The Microsoft Exchange Unified Messaging service has created a new UM
    5                    essaging                       WorkerProcess because the working set (589 MB) has exceeded the conf
                                                       igured maximum: 500 MB"
52146 Mar 11 03:55 Info MSExchange Unified M     1055 The Unified Messaging Worker Process was terminated because the confi
    1                    essaging                      gured maximum lifetime was exceeded.
52099 Mar 11 03:25 Info MSExchange Unified M     1000 The Unified Messaging Worker Process was started successfully on port
    2                    essaging                       "5067".
52098 Mar 11 03:24 Info MSExchange Unified M     1051 The Microsoft Exchange Unified Messaging service has created a new UM
    1                    essaging                       WorkerProcess because the working set (777 MB) has exceeded the conf
                                                       igured maximum: 500 MB"
49992 Mar 10 02:55 Info MSExchange Unified M     1055 The Unified Messaging Worker Process was terminated because the confi
    1                    essaging                      gured maximum lifetime was exceeded.
49948 Mar 10 02:25 Info MSExchange Unified M     1000 The Unified Messaging Worker Process was started successfully on port
    6                    essaging                       "5065".
49947 Mar 10 02:24 Info MSExchange Unified M     1051 The Microsoft Exchange Unified Messaging service has created a new UM
    7                    essaging                       WorkerProcess because the working set (644 MB) has exceeded the conf
                                                       igured maximum: 500 MB"

Viewing eventlog files in the absence of resource strings.

Feroze Daud — Sat, 23 Sep 2006 05:27:00 GMT

Many a time, I had to look at eventlog files sent by a customer, or those from a test run that happened some time back. These files (.evt) are offline copies of eventlogs. To view them, you open them up with eventviewer.

However, you might sometimes notice that the display of these logs does not give the descriptive information that was logged. It will only show the parameters used when logging the message. For eg, if you create an eventlog entry with the followin format string:

"This operation failed with error %s"

then, the display will only show the parameter that was passed to the format string.

To work around this, you can use the /AUXSOURCE= flag to point eventviewer at another machine that might have the required resources to load the resource strings. This is done by invoking the eventviewer in the following manner:

mmc.exe /a eventvwr.msc /AUXSOURCE=<machine name or ip>

Attaching VS to a process on startup.

Feroze Daud — Tue, 04 Apr 2006 22:05:00 GMT

I have been stumped from time to time on how to attach VS debuggers to a process on process startup. I knew how to do it with Windbg, by setting ImageFileExecutionOptions for the target process. However I did not know how to do it for VS.

Well, I need to fret no more. A colleague forwarded me th is blog entry by Greg, in which he has some good info on how to use ImageFileExecutionOptions to attach to a process on startup.

http://blogs.msdn.com/greggm/archive/2005/02/21/377663.aspx

Ping Part IV: Adventures in Socket programming using System.Net

Feroze Daud — Thu, 27 Oct 2005 00:53:00 GMT

In this part, we will add some networking code to the code we have thus far. When we get done, we should have a working Ping utility.

Take the program that we wrote in the Ping: Part III and add the following code.

using System;

using System.Text;

using System.Globalization;

using System.Net;

using System.Net.Sockets;

using System.Net.NetworkInformation;

namespace ping

{

public class ICMP_PACKET

{

public ICMP_PACKET(Byte kind, Byte code, UInt16 id, UInt16 seq, byte[] data)

{

...

}

public ICMP_PACKET(byte[] data, int offset, int count)

{

this.i_type = data[offset++];

this.i_code = data[offset++];

this.i_cksum = ByteToUint(data, offset);

offset += 2;

this.i_id = ByteToUint(data, offset);

offset += 2;

this.i_seq = ByteToUint(data, offset);

offset += 2;

this.data = new byte[count - headerLength];

Array.Copy(data, offset, this.data, 0, this.data.Length);

}

public static UInt16 ByteToUint(byte [] networkBytes, int offset)

{

return BitConverter.ToUInt16(new byte[] { networkBytes[offset+1], networkBytes[offset] }, 0);

}

class Program

{

static void Main(string[] args)

{

if (args.Length != 1)

{

Usage();

}

if (0 == String.Compare(args[0], "/?", true, CultureInfo.InvariantCulture)

|| 0 == String.Compare(args[0], "-h", true, CultureInfo.InvariantCulture)

|| 0 == String.Compare(args[0], "-?", true, CultureInfo.InvariantCulture))

{

Usage();

}

string target = args[0];

IPAddress [] heTarget = Dns.GetHostAddresses(target);

IPAddress ipTarget = null;

foreach (IPAddress ip in heTarget)

{

if (ip.AddressFamily == AddressFamily.InterNetwork)

{

ipTarget = ip;

break;

}

IPAddress[] heSource = Dns.GetHostAddresses(Dns.GetHostName());

IPAddress ipSource = null;

foreach (IPAddress ip in heSource)

{

if (ip.AddressFamily == AddressFamily.InterNetwork)

{

ipSource = ip;

break;

}

IPEndPoint epLocal = new IPEndPoint(ipSource, 0);

Socket pingSocket = new Socket(AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Icmp);

pingSocket.Bind(epLocal);

byte [] data = Encoding.ASCII.GetBytes("1234567890abcdef");

Console.WriteLine("Ping {0}({1}) with {2} bytes of data...",target, ipTarget.ToString(), data.Length);

Console.WriteLine();

for (int i = 0; i < 3; i++)

{

ICMP_PACKET packet = ICMP_PACKET.CreateRequestPacket(111, 222, data);

IPEndPoint epRemote = new IPEndPoint(ipTarget, 0);

pingSocket.SendTo(packet.Serialize(), epRemote);

byte[] receiveData = new byte[1024];

EndPoint epResponse = (EndPoint)new IPEndPoint(0, 0);

int read = pingSocket.ReceiveFrom(receiveData, ref epResponse);

ICMP_PACKET recvPacket = new ICMP_PACKET(receiveData, 20, read);

Console.WriteLine("Reply from:{0} bytes = {1}", ((IPEndPoint)epResponse).Address.ToString(), recvPacket.PayloadLength);

}

...

}

A couple of important points that I wanted to bring to your attention:

1) I have uncommented the code which checks the validity of command-line parameters in Program::Main.

2) We have added a new constructor ICMP_PACKET(byte [], int, int). This is to parse the response returned by the server.

3) The ByteToUInt(byte [], int) method is used to convert from Network Order to Host Order. This is needed because the bytes on the wire are in Network Order, which is BigEndian

4) In Main(), when we resolve the IPAddress of the source and destination, we need to make sure that we work with the correct IP address. Since this program is limited to IPv4, we need to make sure that we do not accidently work with IPv6 addresses. The IPv6 address may be returned when the host that you are trying to resolve is IPv6 enabled.

5) When we read the response from the socket, we get back more bytes that the size of the ICMP packet sent by the server. This is because we opened the Socket with SocketType.Raw. In this mode, we will also get back the IPv4 header that is encapsulating the ICMP packet. So, when we process the response packet, we need to make sure that we skip past the IP header. That is why we skip the first 20 bytes of the packet when we try to create an ICMP_PACKET with the returned data.

If you compile and run this program, you will be able to ping a host without any problems.

As utilities go, this is a very barebones utility. It does not handle errors from the network very well. For the interested, here are some things that you can do to this to make it more robust:

Be ready to handle exceptions from Socket.SendTo() and Socket.ReceiveFrom().
The utility does not handle timeouts. It would be a simple matter to add code and set a timeout on the Receive() call. That way, if the response doesnt come back within a certain time interval, you can print an error ( or an asterisk like the Ping utility that comes with the OS).
Give a command line option to change the #bytes sent in the payload.

Well, that is it then. Now we have a working Ping utility. Hopefully you have learned how to convert a protocol specification into a working program.

Ping Part III: Adventures in Socket programming using System.Net

Feroze Daud — Mon, 24 Oct 2005 21:48:00 GMT

In Part II of this article, we saw how we are going to use the ICMP protocol to implement a simple Ping client. We also saw a skeleton of this program which showed how to translate the ICMP packet specification into a C# structure.

In this part, we will write a routine to calculate the checksum of the packet, and a routine to serialize the packet into a byte array. Recall from PartII that the request and reply packets have a particular encoding on the wire. We will have to write a routine that will encode the packet into a byte array, so that the array can be sent on the wire.

Take the skeleton that we created in Part II and add the following (lines in blue):

using System;

using System.Text;

using System.Globalization;

namespace ping

{

public class ICMP_PACKET

{

...

public ICMP_PACKET(Byte kind, Byte code, UInt16 id, UInt16 seq, byte[] data)

{

this.i_type = kind;

this.i_code = code;

this.i_id = ToNetworkOrder(id);

this.i_seq = ToNetworkOrder(seq);

this.data = data;

this.i_cksum = Checksum();

}

public static ICMP_PACKET CreateRequestPacket(UInt16 id, UInt16 seq, byte[] data)

{

return new ICMP_PACKET(8, 0, id, seq, data);

}

public static byte[] GetBytesInNetworkOrder(UInt16 number)

{

byte[] bytes = BitConverter.GetBytes(number);

if (BitConverter.IsLittleEndian)

return new byte[] { bytes[1], bytes[0] };

else

return bytes;

}

public static UInt16 ToNetworkOrder(UInt16 number)

{

byte[] networkBytes = GetBytesInNetworkOrder(number);

return BitConverter.ToUInt16(networkBytes, 0);

}

public UInt16 Checksum()

{

int cksum_buffer_length = (int)(Length / 2);

byte [] packetBytes = Serialize(this);

// first, convert the serialized bytes into a UInt16 array

// we will use the UInt16 array to do the checksum

UInt16[] checksumBuffer = new UInt16[cksum_buffer_length];

int index = 0;

int i = 0;

while (index < Length)

{

checksumBuffer[i] = BitConverter.ToUInt16(packetBytes,index);

index += 2;

++i;

}

int checksum = 0;

for (i = 0; i < checksumBuffer.Length; i++)

{

checksum += Convert.ToInt32(checksumBuffer[i]);

}

checksum = (checksum >> 16) + (checksum & 0xffff);

checksum += (checksum >> 16);

return (UInt16)(~checksum);

}

public byte[] Serialize()

{

return Serialize(this);

}

public static byte[] Serialize(ICMP_PACKET packet)

{

// first, find out how many bytes to allocate for the serialized packet

int packet_size = packet.Length;

bool isLittleEndian = BitConverter.IsLittleEndian;

UInt16 cksum = packet.i_cksum;

UInt16 id = packet.i_id;

UInt16 seq = packet.i_seq;

//allocate the byte array

byte[] packetArray = new byte[packet_size];

// now serialize the packet into the array.

int index = 0;

packetArray[index++] = packet.i_type;

packetArray[index++] = packet.i_code;

// the checksum is 16 bits.

byte[] temp = BitConverter.GetBytes(cksum);

// copy it into the packetArray at the required offset

Array.Copy(temp, 0, packetArray, index, temp.Length);

index += 2;

// similarly, copy the rest.

temp = BitConverter.GetBytes(id);

Array.Copy(temp, 0, packetArray, index, temp.Length);

index += 2;

// copy seq#

temp = BitConverter.GetBytes(seq);

Array.Copy(temp, 0, packetArray, index, temp.Length);

index += 2;

// copy payload

if (packet.PayloadLength > 0)

{

Array.Copy(packet.data, 0, packetArray, index, packet.PayloadLength);

}

return packetArray;

}

};

class Program

{

static void Main(string[] args)

{

//if (args.Length != 1)

//{

// Usage();

//}

//if (0 == String.Compare(args[0], "/?", true, CultureInfo.InvariantCulture)

//|| 0 == String.Compare(args[0], "-h", true, CultureInfo.InvariantCulture)

//|| 0 == String.Compare(args[0], "-?", true, CultureInfo.InvariantCulture))

//{

// Usage();

//}

byte [] data = new byte[32];

int j = 0;

for (int i = 0; i < 32; i++)

{

data[i] = (byte)((int)'a' + j);

j = (j + 1) % 23;

}

ICMP_PACKET packet = ICMP_PACKET.CreateRequestPacket(0x200, 0x9603, data);

byte[] serialized = packet.Serialize();

for (int i = 0; i < serialized.Length; i++)

{

Console.Write("{0:X} ", serialized[i]);

}

...

}

A couple of important points that I wanted to bring to your attention:

1) I have commented out the code which checks the validity of command-line parameters. While we are developing this application, we will sometimes be running this program with no command line arguments, so I didn’t want that code there. We will put it back in later.

2) As you might recall, the Platform/CPU stores data in a certain order. This is called Endianness. Intel (X86) platform, on which I am writing this program is Little-Endian. However it turns out that the byte-order on the network is always Big-Endian. Hence we need to convert multi-byte numbers from LittleEndian to Big-Endian before we send them on the network. Therefore, I have written the functions GetBytesInNetworkOrder() and ToNetworkOrder() to do the conversion from Little-Endian to Big-Endian.

3) The functions Serialize() and Checksum() are used to serialize the packet into a byte array, and calculate the checksum respectively. Note that as per the RFC, while calculating the checksum, we should assume that the i_cksum field of the packet structure has a value of zero. Once the checksum is calculated, we write the value into the structure, and then serialize the structure to get the final bytes on the wire.

4) In Part II of this series, I showed you the network trace of the Ping.exe routine that comes with the OS. In this part, I created a request packet with the same data, to make sure that our serialization routine and checksum routines are right. You can compile the program, and run it to verify.

D:\ping>bin\debug\ping.exe

8 0 B5 58 2 0 96 3 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 7

5 76 77 61 62 63 64 65 66 67 68 69

If you compare this output with the Ethereal trace of the actual Ping command that I ran in Part II, you will see that they match. This tells us that the Checksum and serialization routines that we wrote are correct.

Ping Part II: Adventures in Socket programming using System.Net

Feroze Daud — Sun, 23 Oct 2005 18:24:00 GMT

If you see the ping utility that comes with your OS, you will notice that it has many options. However, the one we are going to develop will just take one argument:

C:\ping>ping <hostname> | <ipaddress>

Example: ping www.contoso.com

Example: ping 127.0.0.1

Let us start out by looking at requirements of the Ping client. Basically, the task of the tool is to find out if a specified server is alive, and on the network. The way it achieves this is by sending an “echo” packet to the server. The server responds with an “echo” response. If the server responds within a certain time interval, then we can assume that there is network connectivity from the client to the server. If it doesn’t respond, then it could indicate a variety of things that could be wrong, for eg:

The destination server is not up.
The destination server is up but does not have networking enabled.
The destination server is up and on the network, but is configured to drop Ping requests
Etc.

We will not concern ourselves with “why” a server is not responding to the Ping request, as it could be another topic in itself.

Where was I? Oh yeah, the Ping client. It so happens that we have a protocol (ICMP) that has the echo request and reply operations that we need to implement the Ping client. Read the ICMP RFC to get information about all the features offered by the ICMP protocol. As we know, the ICMP protocol is at the same layer as the IP protocol in the OSI layering scheme.

For the ping utility, we will be using the ICMP Echo Request and response messages. The client will send the ICMP echo request message, and the server will reply with an Echo response message. If you look at the Rfc, it describes how an RFC message looks like:

Offset	Field Name	Size (octets)	Description
0	Type	1	Specified type of the operation. It should be set to 8 for request message and 0 for reply messages
8	Code	1	This field is Zero.
16	Checksum	2	One’s complement checksum of the ICMP message
32	Identifier	2	Used to correlate request and reply
48	Sequence Number	2	Used to correlate request and reply
64	Data	Variable	Optional data to be sent with the request. This must be sent back by the server.

Looking at the table above, we can come up with a C# class that corresponds to what the packet will look like:

public class ICMP_PACKET

{

public Byte i_type; // type of message

public Byte i_code; // sub code

public UInt16 i_cksum; // ones complement checksum of header

public UInt16 i_id; // identifier

public UInt16 i_seq; // sequence number

public Byte[] data;

}

I used Ethereal to sniff the network while doing a Ping, to see what a Ping request/response looks like on the wire. The request packet looks like this:

0020 59 99 08 00 b5 58 02 00 96 03 61 62 63 64 65 66 Y....X.. ..abcdef

0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 ghijklmn opqrstuv

0040 77 61 62 63 64 65 66 67 68 69 wabcdefghi

Let us dissect the packet:

i_type = 0x08 ( Echo Request)

i_code = 0x00

i_cksum = 0xb558

i_id = 0x0200

i_seq = 0x9603

data = 32 bytes ( abcedf…. )

The ICMP echo reply looks as follows:

0020 59 9a 00 00 bd 58 02 00 96 03 61 62 63 64 65 66 Y....X.. ..abcdef

0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 ghijklmn opqrstuv

0040 77 61 62 63 64 65 66 67 68 69 wabcdefghi

Let us dissect the packet:

i_type = 0x00 ( Echo Reply)

i_code = 0x00

i_cksum = 0xbd58

i_id = 0x0200

i_seq = 0x9603

data = 32 bytes ( abcedf…. )

Given what we have learned so far, we can now come up with a skeleton for the program that we will develop:

using System;

using System.Text;

using System.Globalization;

namespace ping

{

public class ICMP_PACKET

{

Byte i_type; // type of message

Byte i_code; // sub code

UInt16 i_cksum; // ones complement checksum of header

UInt16 i_id; // identifier

UInt16 i_seq; // sequence number

Byte[] data;

private const int headerLength = 8;

// Total size of the packet (header + payload)

public int Length

{

get { return HeaderLength + PayloadLength; }

}

// Size of the packet header (excluding data)

public int HeaderLength

{

get { return headerLength; }

}

// Size of the payload

public int PayloadLength

{

get { return (data == null) ? 0 : data.Length; }

}

public byte PacketType

{

get { return i_type; }

}

public byte Code

{

get { return i_code; }

}

public UInt16 Identifier

{

get { return i_id; }

}

public UInt16 SequenceNumber

{

get { return i_seq; }

}

public ICMP_PACKET(Byte kind, Byte code, UInt16 id, UInt16 seq, byte[] data)

{

this.i_type = kind;

this.i_code = code;

this.i_id = id;

this.i_seq = seq;

this.data = data;

this.i_cksum = 0;

}

public static ICMP_PACKET CreateRequestPacket(UInt16 id, UInt16 seq, byte[] data)

{

return new ICMP_PACKET(8, 0, id, seq, data);

}

};

class Program

{

static void Main(string[] args)

{

if (args.Length != 1)

{

Usage();

}

if (0 == String.Compare(args[0], "/?", true, CultureInfo.InvariantCulture)

|| 0 == String.Compare(args[0], "-h", true, CultureInfo.InvariantCulture)

|| 0 == String.Compare(args[0], "-?", true, CultureInfo.InvariantCulture))

{

Usage();

}

static void Usage()

{

Console.WriteLine("ping <hostname> | <ipaddress>");

Console.WriteLine("\tExample: ping www.contoso.com");

Console.WriteLine("\tExample: ping 127.0.0.1");

Environment.Exit(0);

}

PING: Adventures in Socket programming using System.Net

Feroze Daud — Thu, 20 Oct 2005 19:18:00 GMT

After a long hiatus, I am back to posing to my blog. I am going to start out with a series on Socket programming.

In this series, I will show you how to implement a simple Ping client using classes from the System.Net.Sockets namespace. It should be an exciting journey.

For starters, you can familiarize yourself with the RFC for ICMP (Internet Control Message Protocol) which is the protocol used by the PING client. The RFC for that is here: (http://www.ietf.org/rfc/rfc0792.txt).

Until next time,

Cheers.

Decoding Printer Tracking Technology

Feroze Daud — Tue, 18 Oct 2005 23:56:00 GMT

In a previous blog post, I wrote about how printer manufacturers are embedding tracking information in their printers.

Well, today, via Slashdot, I learned that folks at EFF have figured out the encoding in atleast one printer (those made by Xerox).

The following link has more details... http://www.eff.org/news/archives/2005_10.php#004063

Tracing in System.Net (contd..)

Feroze Daud — Fri, 23 Sep 2005 02:54:00 GMT

Durgaprasad, the test lead for System.Net has a very informative entry on using Tracing facilities in whidbey.

http://blogs.msdn.com/dgorti/archive/2005/09/18/471003.aspx

Enabling Tracing for System.Net

Feroze Daud — Thu, 12 May 2005 22:09:00 GMT

In whidbey, System.Net has a cool retail tracing implementation. It writes most calls made to public API's to a TraceListener. You can setup your own tracelisteners, or use the config file to setup a default listener.

This facility is very useful in debugging problems with applications.

Here is the example config file which enables Verbose tracing.

<?xml version="1.0" encoding="UTF-8" ?>

<configuration>
<system.diagnostics>
<trace autoflush="true" />

<sources>
<source name="System.Net">

  <listeners>
   <add name="System.Net"/>
  </listeners>
</source>
<source name="System.Net.Sockets">
  <listeners>
   <add name="System.Net"/>
  </listeners>
</source>
<source name="System.Net.Cache">
  <listeners>
   <add name="System.Net"/>
  </listeners>
</source>
</sources>
        <sharedListeners>
                <add
                  name="System.Net"
                  type="System.Diagnostics.TextWriterTraceListener"
                  initializeData="System.Net.trace.log"
                />
        </sharedListeners>
<switches>
                <add name="System.Net" value="Verbose" />
  <add name="System.Net.Sockets" value="Verbose" />
  <add name="System.Net.Cache" value="Verbose" />
</switches>
</system.diagnostics>
</configuration>

NOTE: If you are doing logging inside of the ASP.NET process, make sure to give the ASP.NET process identity WRITE permissions to the directory where you want the log to be written.

HttpWebRequest and Host Headers

Feroze Daud — Thu, 31 Mar 2005 23:46:00 GMT

A user posted on the newsgroups asking about how to set Host headers in HttpWebRequest.

HttpWebRequest does not allow the host header to be set by the user. It is set automatically from the URI supplied to HttpWebRequest constructor.

However, it turns out that there is a roundabout way to accomplish this. This is shown in the following reply to the original post:

http://groups-beta.google.com/group/microsoft.public.dotnet.framework/browse_thread/thread/17c5369520221c8/4e768c733ad2f451?q=HttpWebRequest+and+Host+Header&rnum=1#4e768c733ad2f451

This solution works, but there is a subtle difference in the request sent on the wire. To illustrate that, look at the following program:

using System;
using System.Net;

public class EP {
public static void Main()
{
  test("http://www.company.com/test.aspx");
  test("http://www.contoso.com/test.aspx");

}

public static void test(string uri)
{
WebRequest req = WebRequest.Create(uri);
req.Proxy = new WebProxy("http://myserver", false);

WebResponse resp = req.GetResponse();

resp.Close();
}
}

To get this program to work, you need to do the following:

Have a server named "myserver" on which you get IIS/ASP.NET running. If you dont want to run ASP.NET that is fine as well.
On the server, go into the IIS console, and create two websites. Set the host header on the first website to be www.company.com and the other to be www.contoso.com
Compile and run the above program.

If you look at the request sent on the wire, you will notice that this program sends the following request to the server "myserver"

GET http://www.contoso.com/test.aspx HTTP/1.1
Host: http://www.contoso.com

Whereas the actual request you want sent is:

GET /test.aspx HTTP/1.1
Host: www.contoso.com

NOTE: Even though the request URI sent on the wire is an absolute URI, and is different from what should actually be sent if the client had control of the host header, it will still work on the server, because as per RFC/2616, a server is supposed to honor all requests which use an absolute URI instead of a relative URI to identify the resource.