Windows CE Networking Team WebLog

Kerberos cannot resolve netapi32.dll in CE5.0 after QFE updates

cenet — Fri, 16 May 2008 19:37:00 GMT

If you install the recent CE 5.0 QFE's AND try to build Kerberos.dll, you will run into a bug that unfortunately was introduced in this QFE. Check out customer thread alerting us to it here.

Short summary is that customer is seeing:

"Warning: Unable to do imports from kerberos.dll to NETAPI32.dll - will late bind"

Root cause:

To fix a problem with how Kerberos resolves domain names (basically turning REDMOND domain into a DC controller mydomain-controllername.redmond.microsoft.com), Kerberos was changed to call into the official NetApi32 DsGetDcName instead of using a private interface. This meant that kerberos has a dependency on Netapi32.dll being in the image which previously it did not. Customers never think about dependency logic (or hardly ever) because Microsoft runs a large suite of tests to make sure that if component A relies on component B being in the image it explicitly sets it (Kerberos needing Netapi32 in this case) and we fix these issues before releasing the product.

In this case, because it was a QFE we don't usually add dependencies like this, so we didn't catch the dependency prior to QFE release.

The customer workaround is straightforward. Basically set SYSGEN_NETAPI32=1 (I'm not sure what exactly this translates to in the IDE catalog, probably something like "Domain Discovery"). You only need to do this if you include Kerberos component, which most devices do not. As near as I can tell, the only way you get kerberos is of course if you manually include it, or if you bring in the voipPhone local authentication plugin (SYSGEN_VOIPPHONE_LAP).

We apologize for the inconvenience. We're going to be releasing the same QFE effectively in CE6.0 and we will fixup the dependencies prior to releasing that QFE.

John

Inspect incoming SIP headers in RTC CE 6.0 R2 release

cenet — Tue, 13 May 2008 22:22:00 GMT

There are many scenarios where inspecting incoming SIP messages for custom headers is useful. Many servers add their custom headers for custom functionalities like custom ring tones, shared line functionality, privacy, etc. and hence having the ability to inspect incoming SIP messages is very useful. In CE 6.0 R2 release, RTC supports the capability of inspecting incoming SIP messages.

The incoming SIP messages that can be inspected are those that generate an RTC EVENT. All Event interfaces can now be queried for the interface: IRTCSIPEvent, which exposes the following g API:

HRESULT GetSIPMessage(

[out] IRTCSIPMessage ** ppMessage

);

If the event indeed was generated because of an incoming SIP message, then the above API will return a valid IRTCSIPMessage interface, else the error RTC_E_NO_SIP_MESSAGE will be returned and the incoming pointer will be set to NULL in that case.

Interfaces that can be queried for IRTCSIPEvent are:

IRTCRegistrationStateChangeEvent

IRTCSessionStateChangeEvent

IRTCSessionOperationCompleteEvent

IRTCMessagingEvent

IRTCInfoEvent

IRTCReInviteEvent

IRTCSessionReferStatusEvent

IRTCSessionReferredEvent

IRTCSubscriptionStateChangeEvent

IRTCSubscriptionNotificationEvent

IRTCUnsolicitedNotificationEvent

IRTCSessionConsultantReferredEvent

IRTCSessionNotificationEvent

A few examples of cases where RTC events are generated due to incoming SIP messages and for which, those incoming SIP messages can be inspected are:

1. REGISTRATION success, registration failure response from the server, etc.

2. Incoming INVITEs for different types of RTC sessions, incoming INFO, MESSAGE types

3. Incoming PRACK messages

4. Incoming notifications for subscriptions

5. Etc.

Adding custom SIP headers using RTC, in CE 6.0 R2 release.

cenet — Tue, 13 May 2008 18:09:00 GMT

Adding custom SIP headers using RTC, in CE 6.0 R2 release.

In CE 6.0 R2, RTC now supports the capability of adding custom headers to outgoing REQUEST messages, for RTC sessions and RTC subscriptions. Here is how once can do it.

After CE 6.0 R2 release, IRTCSession interface and IRTCSubscription can now be queried for the interface: IRTCSIPObject. This interface supports the following 2 functions:

HRESULT SetAdditionalHeaderValues(

[in] BSTR bstrHeaderValuePairs

);

HRESULT GetAdditionalHeaderValues(

[out] BSTR* pbstrHeaderValuePairs

);

SetAdditionalHeaderValues function can be used to add additional custom headers to outgoing REQUEST style messages, of the IRTCSession and IRTCSubscription, on which it gets called.

So, in case of IRTCSession, those messages would be:

INVITE, PRACK(in case PRACK is supported) and final ACK during session setup or mid –session(for cases like Hold).

CANCEL or BYE message when the session is cancelled or terminated.

In case of IRTCSubscription, the message will be SUBCRIBE.

To stop sending custom headers, SetAdditionalHeaderValues can be called again with a NULL value.

GetAdditionalHeaderValues API can be used to get back the header pair value string that is set by the SetAdditionalHeaderValues API.

Note: These APIs give direct control in modifying outgoing SIP messages and hence should be used with “extreme” caution. RTC does not validate the contents of the custom headers added, nor does it check the format of these custom headers. Adding improper custom header values can cause the remote side of the RTC session or subscription to reject SIP messages, which can lead to unexpected application behavior.

Old Man Spaith is out of ideas

cenet — Mon, 10 Mar 2008 01:08:00 GMT

I just checked out the blog and realized it's been ~1.5 months since the last post, which is lame. I have a dilemna since I've run out of tricks/advice that I think are useful, for now at least. I can either write nothing or do something random, like put up a picture of my dog, Daisy. It never would've occurred to me to do this, even in desperation for posts, on what I think of as a work-blog until I checked out the main feed at blogs.msdn.com. I was amazed at the number of personal, totally random, stuff up there.

My compromise is that I'll just link to pictures of Daisy rather than wasting bandwidth for people here for work. So check out Daisy Spaith on my Toastmasters blog, www.mySpaith.com. (I guess given MS investment in Facebook I should've named SpaithBook, but I put it up before that and mySpaith is better anyway.)

I wish I could say we had made CE networking technologies so easy and awesome for our developers that we could turn the CENet blog into the "dogs of the CE Networking team" site. We know we're not there yet. Please keep the questions coming in the newsgroups and we'll do our best to help. Thanks for your continued support through the years. I'll try to come up with better stuff so we can avoid the self-indulgent posts like this I promise.

-- Old Man Spaith (just turned 31, it's down hill from here)

Problems building svsutil.hxx in Windows Mobile SDK

cenet — Tue, 22 Jan 2008 19:42:00 GMT

If you try to build svsutil.hxx on certain versions of the Windows Mobile SDK, you may run into build errors. I know it's on WM5 SDK at a minimum, I don't know about WM6 SDK.

The error you'll see will complain about the methods int operator==(int iBit) and int operator==(SVSBitField &bf) in the class SVSBitField in particular. What happened is that the compiler got a bit more picky at some point but the SDK headers weren't updated to reflect this in the given SDK version. We have fixed this in latest & greatest svsutil.hxx.

If you run into this, what you'll need to do is change the initial
for (int i = 0 ; i < m_iWLength - 1 ; ++i) {

So that the 'int i' is outside the for loop, namely:

int i;
for (i = 0 ; i < m_iWLength - 1 ; ++i) {

Our apologies to anyone who hits this.

John

Controlling VOIP interfaces on Windows Mobile devices

cenet — Wed, 16 Jan 2008 23:43:00 GMT

RTC 1.5 can be restricted to use only certain types of interfaces (Wifi, Ethernet, etc.) on Windows Mobile devices. Same restriction cannot be applied on Windows CE, as RTC uses connection manager functionality to do that, which is not available on Windows CE.

RTC can be restricted using the following reg keys. These reg keys need to be set before RTC gets initialized.

HKLM\Comm\RTC\AdapterTypes

One can list all the allowed interfaces as numerical keys:

e.g. 1

ETC.

The value of each key should be an ORed value of the connection manager interface type and sub-type

e.g. If one wants to allow Ethernet interface only.

The connection manager interface type to use will be CM_CONNTYPE_NIC (0x2)

The connection manager sub-interface type to use will be CM_CONNSUBTYPE_NIC_ETHERNET (0x1)

The Ored value = (0x2 << 16) | 0x1 = 0x20001

So the reg key will look like:

HKLM\Comm\RTC\AdapterTypes\1 (DWORD with value 0x2001)

Similarly, if Wifi is also desired,

The connection manager interface type to use will be CM_CONNTYPE_NIC (0x2)

The connection manager sub-interface type to use will be CM_CONNSUBTYPE_NIC_WIFI (0x2)

The ored value = 0x2 << 16 | 0x2 = 0x20002

So the reg keys will look like:

HKLM\Comm\RTC\AdapterTypes\1 (DWORD with value 0x2001) ß for Ethernet

2(DWORD with value 0x2002) ß For Wifi

Pluggable video codec for RTC 1.5 stack

cenet — Tue, 15 Jan 2008 02:45:00 GMT

RTC 1.5 (CE 6.0 R 2 release) supports Point to Point Video calling. However, the stack does not ship any built-in video codecs. Instead it supports a pluggable video codec architecture through which, one can add their own video codecs.

Below are the steps one needs to take to plug-in a video codec into the RTC stack.

1. Implement your video codec in form of a DShow filter. Here is a MSDN link that explains How to write a DShow filter.

2. On the device, set the following reg keys before RTC is initialized:

HKEY_LOCAL_MACHINE\Comm\RTC\Video\Codecs\<key set#>

*Note: <key set#> can be any name (e.g. 1,2,3 or codec name itself)

*Note: For latest and up to date pluggable video codec reg keys listed below, please visit the MSDN link here .

Name	Type	Description
EncoderFilter	REG_SZ	Specifies the COM CLSID of the encoding IBaseFilter.
DecoderFilter	REG_SZ	Specifies the COM CLSID of the decoding IBaseFilter.
DecoderMediaSubtype	REG_SZ	Specifies the media subtype GUID of the format of the incoming data. Examples of incoming data format include H263 and H264.
CodecType	REG_SZ	Specifies the codec type. Always set the data to `Filter`. There is no default value.
CodecRank	REG_DWORD	Sets the relative priority of the codec. The data is an integer between 0 and 100. The highest priority is 0 and the lowest is 100.
CodecName	REG_SZ	Specifies the name of the codec sent in the Session Description Protocol (SDP) payload. For example, the codec name could be `H263-1998`. The name must contain fewer than 32 characters.
PayloadType	REG_DWORD	Specifies the RTP payload type associated with the codec. For example …
ClockRate	REG_DWORD	Indicates the clock rate of the codec as it appears in the `a=rtpmap` line of the SDP . For many codecs the correct data is 90,000.

Note: If a codec needs to be represented by multiple payload types (as some codec do), then a separate key set needs to be added for each payload type. RTC supports plugging in a maximum of 7 such key sets (7 separate payload types).

3. If your codec supports custom codec properties, which needs to be negotiated through SDP using FMTP lines, then the codec can put its FMTP string in the following reg key:

HKEY_LOCAL_MACHINE\Comm\RTC\Video\Codecs\<key set#>

Name

Type

Description

SDPFmtp

REG_SZ

Indicates the format specific parameters FMTP of the codec as it appears in the SDP a=fmtp line of the SDP. If SDPFmtp is not set, no FMTP lines will be sent.

This data indicates only the parameters themselves. SDP automatically fills in the following text:a=fmtp:<RTP Payload Type #>

RTC will read the reg key during initialization, and will add it to the outgoing SDP as is, as FMTP properties of the codec. If no reg key is specified, no FMTP lines will get published in SDP for the codec.

4. RTC also supports passing of incoming FMTP property string to the plugged in codec, so that the codec can make a decision if it supports those properties or not. The pluggable codec needs to implement the following interface: IRTCSDPValidator to accept incoming FMTP strings from the SDP. The following reg keys needs to be set for the codec, to let RTC know of the interface:

HKEY_LOCAL_MACHINE\Comm\RTC\Video\SdpValidators

Name	Type	Description
<Codec Name>	REG_SZ	Specifies the CLSID that implements this object.

e.g.

Name	Description
H263-1998	{D018239F-4022-4c15-BC87-03CCADC1A4E3}

Note: An IRTCSDPValidator registry value is not required. If a codec does not implement this registry key, the codec accepts all SDP.

5. Implement interfaces that allow adding and removing custom RTP headers.

RTC uses RTP as the media transport protocol for video. RTP allows adding codec specific headers for each RTP payload. Since this header is codec specific, RTC provides a mechanism so that pluggable codecs can add/remove these custom RTP headers during the encode/decode process.

Implement the interface IRTCPluggableVideoEncoder to add custom RTP header and the interface IRTCPluggableVideoDecoder to remove custom RTP headers. Publish these interfaces in the reg key:

HKEY_LOCAL_MACHINE\Comm\RTC\Video\Codecs\<key set#>

Name	Type	Description
EncoderPlugin	REG_SZ	Specifies the COM CLSID of the IRTCPluggableVideoEncoder interface. Set H.263 to {A7D8A6EF-575B-4750-A727-04234A70D9DE} to use the Microsoft provided implementation of this interface. Set H.264 to {92A200F8-0981-11DC-813E-B77255D89593} to use the Microsoft provided implementation of this interface.
DecoderPlugin	REG_SZ	Specifies the COM CLSID of the IRTCPluggableVideoDecoder interface. Set H.263 to {0CE193DF-27F0-48c7-92F7-75CA7A5965E6} to use the Microsoft provided implementation of this interface. Set H.264 to {86546C00-0981-11DC-88BE-AE7255D89593} to use the Microsoft provided implementation of this interface.

*Note: The Microsoft implementation of the above interfaces for H263 and H264 video codecs can be found at CE OS installation location: public\fp_voip\oak\codecs\H263Parse and public\fp_voip\oak\codecs\H264Parse respectively.

Now that we know how to write a pluggable video codec and add it to RTC, let’s see how RTC will use the codec and all other interfaces by the codec module:

1. As soon as RTCClient object is initialized, RTC goes through the all reg keys defined above to check for any pluggable video codecs. If the reg keys are set, RTC will check, verify and load the codec for future use.

2. When a user makes an outgoing video using RTC, then:

a. All pluggable video codecs that are successfully loaded by RTC, will get published in the outgoing SDP.

b. If the codec has set the SDPFmtp reg key to specify its FMTP properties, then RTC will add that string in the outgoing SDP for the respective video codec.

3. When an incoming video call is received by RTC, then:

a. For each video codec published in the incoming SDP, RTC will try to match it with its plugged in codecs. If any of the codec name matches, then RTC checks to see if the codec implements IRTCSDPValidator interface. If it does, then RTC will call the CheckAcceptableFmtp function of the interface with the incoming FMTP string, to let the codec check if it can support those properties. If the function returns S_OK, RTC considers that codec is capable of handling the incoming FMTP properties, and it proceeds with the call as usual. Any other return value is considered a failure. If there is no codec match, RTC will reject the call.

b. If the codec does not implement IRTCSDPValidator, then RTC assumes that the codec is capable of handling any incoming FMTP property, and will proceed with the call as usual (generally by triggering an event of an incoming video call)

4. Once the call has been established:

a. During the encode process, RTC will call the appropriate filter APIs to encode the raw video frames. After that, RTC will call the IRTCPluggableVideoEncoder interface API to let the codec generate custom RTP header for the encoded frame. Please see the MSDN page for more details on the interface.

b. During the decode process, RTC will first call the IRTCPluggableVideoDecoder interface API to let the interface extract the encoded frame from RTP payload. Once an entire encoded frame is extracted, RTC will then call the filter APIs to decode the raw video frames. Please see the MSDN page for more details on the interface.

Sample Code for Local Audio Mixing using RTC 1.5 (CE 6.0 R2 Release)

cenet — Thu, 10 Jan 2008 03:26:00 GMT

Sample code for local audio mixing to achieve 3 way/N way calling.

In CE 6.0 R2 release, RTC 1.5 started supporting local audio mixing. Local audio mixing can be enabled by using the flag RTCIF_ENABLE_GLOBAL_MEDIA_MIXING during RTCClient object initialization. Here is the code example (ignoring error handling):

Initialize RTC to enable local media mixing:

hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);

hr = CoCreateInstance(CLSID_RTCClient,

NULL,

CLSCTX_INPROC_SERVER,

IID_IRTCClient,

(LPVOID *)&gpRTCClient );

IRTCClient2 *piRTC2 = NULL;

hr = gpRTCClient->QueryInterface(IID_IRTCClient2, (void**)&piRTC2);

hr = piRTC2->InitializeEx(RTCIF_ENABLE_GLOBAL_MEDIA_MIXING);

Once media mixing is enabled, audio for all calls will be locally mixed. Consider the following example to see how 3-way /N way calling can be achieved:

Consider two audio calls between a caller (Endpoint 1) and two other callers (Endpoint 2 and 3). Without local media mixing, 2 and 3 can talk to 1, but not to each other on the existing calls. When local audio mixing is enabled on endpoint 1, endpoint 1 mixes the audio stream as described below, which will enable 3-way conferencing, and all three can talk to each other.

· Endpoint 1 mixes its own audio (1) with the audio that it receives from endpoint 3 (3) and sends it to endpoint 2. Similarly,

· Endpoint 1 mixes its own audio (1) with the audio that it receives from endpoint 2 (2) and send it to endpoint 3.

This way, endpoint 2 can listen to endpoint 3, and endpoint 3 can also listen to endpoint 2.

Since Endpoint 1 is the mixer, the conferencing is dependent on endpoint 1. If endpoint 1 disconnects any of the calls, then Endpoint 2& 3 won’t be able to talk to each other.

Here is a code example (ignoring error conditions for simplicity)

Establishing a 3 way call:

Step 1: Endpoint 1 Calling Endpoint 2

hr = gpRTCClient->CreateSession(RTCST_PC_TO_PC, NULL, NULL, 0, &pSessionEndpoint2);

if (SUCCEEDED(hr))

{

hr = pSessionEndpoint2->AddParticipant(bstrEndpoint2URI, bstrEndpoint2Name, NULL);

}

After this, RTC will post a session connected event, once the call has been established between endpoin1 and endpoint 3.

Step 2: Endpoint 1 putting Endpoint 2 on Hold, before calling Endpoint 3

IRTCSessionCallControl* pSessionEndpoint2CallCtrl = NULL;

// Query for the IRTCSessionCallControl interface.

HRESULT hr = pSessionEndpoint2->QueryInterface (IID_IRTCSessionCallControl,

(void**) & pSessionEndpoint2CallCtrl);

hr = pSessionEndpoint2->get_State(&enState);

if(enState != RTCSS_CONNECTED)

{

ASSERT(0);

// Handle error!!

}

pSessionEndpoint2CallCtrl->Hold(lCookie);

Step 3: Endpoint 1 Calling Endpoint 3

hr = gpRTCClient->CreateSession(RTCST_PC_TO_PC, NULL, NULL, 0, &pSessionEndpoint3);

if (SUCCEEDED(hr))

{

hr = pSessionEndpoint3->AddParticipant(bstrEndpoint3URI, bstrEndpoint3Name, NULL);

}

Step 4: Endpoint 1 Unholds Endpoint 2 to establish 3 way conference

IRTCSessionCallControl* pSessionEndpoint2CallCtrl = NULL;

// Query for the IRTCSessionCallControl interface.

HRESULT hr = pSessionEndpoint2->QueryInterface (IID_IRTCSessionCallControl,

(void**) & pSessionEndpoint2CallCtrl);

hr = pSessionEndpoint2->get_State(&enState);

if(enState != RTCSS_HOLD)

{

ASSERT(0);

// Handle error!!

}

pSessionEndpoint2CallCtrl->UnHold(lCookie);

After Step 4, all 3 endpoints can talk to each other. Please note that Step 2 and Step 4 (putting Endpoint 1 call on Hold and then UnHold) are optional steps. RTC 1.5 will allow making call to Endpoint 3 while call to Endpoint 2 is active. But this kind of calling is not normal in the telephony world.

If Endpoint 1 wants to talk to Endpoint 2 exclusively, it can simply put Endpoint 3 call on Hold, and similarly it can put Endpoint 1 call on Hold if it wants to talk to Endpoint 3 exclusively.

Also note that even though media is mixed for both calls, All APIs related to each call (like RTCSession and RTCParticipant APIs) will only act on the respective individual calls. For e.g.

Example 1: pSessionEndpoint2->Terminate(RTC_TERMINATE_REASON) will just disconnect Endpoint 2 and not Endpoint 3.

Example 2: pPartEndpoint2->SendDTMF(RTC_DTMF) will send DTMF tones only to Endpoint 2, and not to Endpoint 3,

etc.

However, APIs like CRTCClient::put_Volume(RTC_AUDIO_DEVICE enDevice, long lVolume) will affect both calls.

Thanks and happy coding!!

What is new in RTC 6.0 R2 release?

cenet — Wed, 09 Jan 2008 02:10:00 GMT

Following are the new features in RTC 6.0 R2 release:

1. Local audio mixing capability (enabling 3 way VOIP calling)
2. Point to Point Video Calls
3. Pluggable Video Codec capability
4. Ability to inspect SIP headers for certain SIP messages
5. Ability to add custom headers to certain outgoing SIP Messages
6. Attended Call Transfer facility
7. Call Park/Pickup facility

All the above features, except video, are available through VOIP default sysgen, i.e. SYSGEN_VOIP. Point to Point Video

feature is selectable using SYSGEN_VOIP_VIDEO sysgen.

As time permits, I and my team will blog out each feature in more details.

For now, you can get some details about local audio mixing through the following link:
http://download.microsoft.com/download/0/7/4/0748b074-ed6c-461f-bcd0-e35d047bc1f8/Windows%20Embedded%20CE%206.0%20R2%20Release%20Notes.htm#WN7

Thanks and happy new year to all!!
Rajesh

The History of the DCOM Remoting Addon Pack

cenet — Wed, 09 Jan 2008 00:54:00 GMT

I recently wrote about the recent DCOM Remoting Addon pack being available.

Since I'm running out of things to write about, I'll explain the geeky details of how the DCOM addon pack came to be. This post is for the very bored only or those who are intrigued by the Windows CE Build Process. There are no profound insights on COM or any other subject, for that matter.

First we had to figure out what to do with DCOM remoting. We had to either re-port Windows Vista COM or else remove DCOM remoting from the product. Even though CE is componentized and we could have warned that this component was insecure & should be avoided almost always, NT4 vintage DCOM was *so* insecure that this wasn't enough. After all, how often do you click through the obnoxious warnings that software pops up?

This was a no win situation. Even if we wanted to spend the effort to re-port COM, the amount of time needed to do the work and then get it stable (think about how key COM is to the system) didn't allow us to go down this path. At the same time we knew we had some OEMs who desperately needed DCOM remoting.

So the Group Program Manager, who makes a lot more money than I do for good reason, helped push through the idea of an addon pack. DCOM remoting would be available only in CE6 if you downloaded a separate product. The addon pack made our security people happy. Since you have to go to a website to get the bits, you can't accidentally click on some buttons and end up with it. It also lets us warn you point blank on the download site what you're getting into in a way less likely to be missed than warning popup box #73.

From the website:

<
"the component contains known MSRC class critical bulletins. Installing the supplemental pack ... is discouraged, and Microsoft assumes no liability if this pack is deployed."
>

How does the DCOM addon pack work? Ironically for all the time I spent in meetings discussing various aspects of it from biz/legal/security, the actual dev work was straightforward. On NT4, DCOM has the concept of loadable transport DLL's to actually do the heavy lifting of talking to the transport layer. rpcltscm.dll & rpcltscm.dll.

The way PB builds MS doesn't ship these DLL's but instead rpcltscm.lib and rpcltscm.lib, and under the covers OEMs are building the DLL themselves. We have config files that allow us to specify which files (in this case in public\dcom\oak\lib\<CPU>\...) are shipped out to customers. So I changed the logic in them so that rpcltscm.lib & rpcltscm.lib were no longer shipped, even though they were still building. I also changed a few configuration files to add some comments should some geek poke around the build and try to add the DLLs manually. Check out public\dcom\oak\lib\(dcom.reg & dcom.bib) if you want to see Spaith's warnings.

There was the extra step here of making sure that DCOM didn't have any direct calls to Winsock or other networking layer technology to do an end-round the transport DLL layer. It doesn't. I was impressed with the cleanliness of the design. I anticipated whacking out winsock calls thrown all over the place and had given myself a lot more time on the schedule than I actually needed. Of course a lot of other work that I underestimated ended up filling the free time I had!

So the addon pack is basically just an MSI installer, various EULA's (the most important piece from a biz perspective), and the libraries.

At the time of shipping this I joked about trying to get a ship-it award, which would be riduculous given that I hardly spent a few weeks on this. (Other ship-its have taken me +1 year of work). The Group PM said in all seriousness he'd try to make it happen, but I think it's best to let it drop.

John

DCOM Remoting on Windows CE 6.0

cenet — Fri, 04 Jan 2008 23:53:00 GMT

As I wrote here, in Windows CE 6.0 we removed DCOM remoting - that is the ability to create and host COM objects across a network. We did this due to security. Our DCOM is built on NT4 vintage code and there was no way we could patch up our implementation to meet security requirements. The desktop faced a similar problem post-NT4 and also came to the conclusion they couldn't do a patch up, so they had to redo lots of their DCOM.

Note this is all embedded CE only - Windows Mobile doesn't even have cross-proc COM objects, much less remoting.

I'm happy to announce that an add on kit to CE6 is available here that will allow OEMs to get DCOM remoting in their image.

As the docs call out but I will emphasize here, this is ONLY for completely closed networks. I'm thinking of a factory floor as the main example (and they're the main ones who want this). This is not safe for the Internet of course or anywhere that untrusted machines may get on a network due to security worries.

While we can't make any official statements about future products on the blog, I'll say unofficially that we are most likely not going to be doing another remoting addon pack for Windows CE 7.0. We wanted to provide some sort of stop gag solution as Web Services for Devices for instance (available in CE 6.0 R2) or other technologies become available.

UTF-8 in ASP pages on Windows CE

cenet — Fri, 14 Dec 2007 22:53:00 GMT

My "stuff to blog about" well has pretty much run dry, as anyone who follows this blog knows. Fortunately there's always a customer running into something that I've never thought about something to inspire me. Bad for the poor customer hitting the issue, but good for the rest of us.

A customer wasn't able to make ASP pages from CE Web Server work when the pages were UTF-8. The same page had worked fine as ANSI. The error they got was when setting <% Response.Expires = -1 %> in their page.

-----------------START

The HTTP headers are already written to the client. HTTP header

modifications must be made before writing page content

ASP scripting compilation error: '80020009'

Description:

In file: /Test/default.asp

On line: 1

-----------------END

ASP aficionados, can you guess what was happening?

What happens is UTF-8 puts special characters in the first bytes of a file indicating to an editor that it is UTF-8. When our ASP interpreter parses out a page, it sees those UTF-8 characters and (unfortunately) doesn't know about UTF-8 and assumes its ASP body that needs to be sent out. Once ASP body has been sent, you're not allowed to send HTTP headers anymore, which is why the Expires=-1 wasn't working.

I had the customer remove the special bytes and also look into the Response.Charset() to make sure the browser knew the encoding of the file (always a good idea with non-ANSI anyway).

GPSID: Problem & workaround on recent WM6 release

cenet — Thu, 06 Dec 2007 19:14:00 GMT

Background
A number of customers on a recent WM6 versions have run into a problem where GPSGetPosition returns ERROR_INVALID_PARAMETER always, even on apps that worked fine in the past. The newsgroup thread is here.

The device I've reproed and tested on was an HTC P3300, but based on newsgroup thread I think other devices may have been affected also.

I have determined the cause and a workaround for the problem. It'll take a while to get a real fix, but we're working on that too.

Underlying Cause
In a future Windows Mobile, we're exposing extensions to the GPS_POSITION and GPS_DEVICE structures. GPSID is actually aware of the extended structure already - in WM6 AKU0.4 & above, also known as 18120+ builds. The reason being that GPS chips can do some "magic" with this stuff even before we actually expose the structures to app developers. (It's a very long story, if you're not a GPS OEM you don't care.) Because the structure is larger, it means the sizeof() checks on it have changed but sizeof(GPS_POSITION) that you're passing in has not changed because you're using the same GPS_POSITION as always. The MS GPSID allows the old struct size for legacy.

What complicates things is that OEMs are allowed to replace GPSID on their device, because they may want to tweak it in order to work with their GPS chips. I don't have the source, but I'm almost positive what's happening is that an OEM GPSID is checking only against the extended GPS_POSITION size and hence is failing when it gets the original GPS_POSITION.

Workaround
Your application can lie about how big a structure it is passing in to worakround this. So if your application gets ERROR_INVALID_PARAMETER, it can pass in the sizes of the new struct. Here's code below. I tested this with an HTC 3300 and was successfully able to get my lat/long using this. GPSGetDeviceState has similar issue so I'm including code for it, too.

// Retrieves GPS location data and prints it to the screen.
void GetLocationAndPrint(HANDLE hGPS) {
    BYTE gpsPositionRaw[376];
    GPS_POSITION *pGpsLocation = (GPS_POSITION*)gpsPositionRaw;

    pGpsLocation->dwVersion = GPS_VERSION_1;
    pGpsLocation->dwSize    = sizeof(gpsPositionRaw);

    DWORD dw = GPSGetPosition(hGPS,pGpsLocation,1000,0);
    if (dw != ERROR_SUCCESS) {
        wprintf(L"GPSGetPosition() fails, GLE = 0x%08x\r\n",dw);
        DebugBreak();
        return;
    }

PrintGPSPosition(pGpsLocation);
}

void GetDeviceStateAndPrint(void) {
BYTE gpsDeviceRaw[332];

    GPS_DEVICE *pGpsDevice = (GPS_DEVICE *)gpsDeviceRaw;
    pGpsDevice->dwVersion = GPS_VERSION_1;
    pGpsDevice->dwSize = sizeof(gpsDeviceRaw);

    DWORD dw = GPSGetDeviceState(pGpsDevice);
    if (dw != ERROR_SUCCESS) {
        wprintf(L"GPSGetDeviceState() fails, GLE = 0x%08x\r\n",dw);
        DebugBreak();
        return;
    }
    PrintGPSDeviceState(pGpsDevice);
}

Going Forward
This is clearly a stop-gag solution. There's no way that we expect our customers to recompile existing apps for a new WM release, especially considering how hard it is to get applications signed/tested/deployed. I have alerted the OEM to the problem and am coordinating with them on rolling out a fix. I'll provide an update when I can.

Once again I apologize for the pain that this has caused and the delay.

John

Memory Corruption, Compiler Bug, Or Not?

cenet — Tue, 23 Oct 2007 04:16:00 GMT

While tracking down some memory corruption issues, I noticed in one function that a parameter on the stack was always getting set to the value 2, even though it was a pointer. I could see it turn red in the memory view window as its value changed. I thought I had identified a compiler bug. But no, it was not a compiler bug. It was actually a mismatch between the optimizing compiler and the debugger. The x86 optimizer knew that the memory for the stack variable was referenced only one time and then was enregistered, so its stack memory could be used for another local variable. The debugger’s local variable display did not realize this and continued to display the memory value for the local variable – confusing.

On ARM, a similar situation can arise since the first 4 registers (R0, R1, R2 and R3) are used as function parameters. The debugger doesn’t track when a function parameter gets moved to a “permanent” register (R6 for instance) and continues to display the function parameter register’s value as the local variable’s value.

About Harish

cenet — Wed, 17 Oct 2007 02:53:00 GMT

Hi, my name is Harish Srinivasan. I work in the Windows CE Core Networking team. I own IPsec, IKE and several other networking components.

Windows CE and the Serial Carrier Detect Signal

cenet — Tue, 24 Jul 2007 22:49:00 GMT

The Windows CE serial port based networking components have an historical affinity for the RS232 Carrier Detect (CD) signal. A key feature of Windows CE 1.0 was automatic synchronization of email and contacts when docked (ActiveSync). The device needed to detect when it was docked, and it needed to wake up when docked. Since this scenario was originally serial port based, CD was used as both the wake-source interrupt and the signal to start the ActiveSync application on the device.

The corresponding components (mostly Unimodem and PPP) in Windows NT/XP/Vista do not rely on CD, so many scenarios that work between non-CE devices do not work the same when a CE device is involved. It is often due to one of the following reasons:

1. The cable being used does not include the Carrier Detect line.

2. The platform specific serial port device driver does not properly report CD status. The serial driver’s SL_GetModemStatus indicates CD state with the MS_RLSD_ON flag for the Win32 serial port API function GetCommModemStatus(). EV_RLSD is used to indicate a change in state of the CD signal.

3. The hardware does not implement the CD signal. If this is the case, then a valid workaround is for the serial port device driver to always indicate that CD is asserted by always setting MS_RLSD_ON in its SL_GetModemStatus function.

Privacy support in RTC 1.5

cenet — Thu, 07 Jun 2007 20:51:00 GMT

RTC 1.5 supports privacy for SIP. It implements a subset of RFC 3323, RFC3324, RFC 3325 and can create messages that do not divulge personal identity information.

Windows CE and WM6 has the following privacy constants describing different privacy policy. By default, RTC doesn't have Privacy policy set, i.e. RTCSP_PRIVACY_NONE is used.

RTCSP_PRIVACY_NONE = 0x00000000

RTCSP_PRIVACY_LOCAL = 0x00000001

RTCSP_PRIVACY_PROXY_HEADER = 0x00000002

RTCSP_PRIVACY_PROXY_SESSION = 0x00000004

RTCSP_PRIVACY_ALL = 0x0000000F

Check the following link for more info on these constants:

http://msdn2.microsoft.com/en-us/library/aa922722.aspx

There are two levels of privacy support in RTC:

1.Session level - the privacy setting is done for an IRTCSession.

Interface, IRTCSessionSIPPrivacy, adds privacy support for all SIP traffic for a session. It can be created by calling QueryInterface on the IRTCSession object. The application can call IRTCSessionSIPPrivacy::put_SIPPrivacyType to set the privacy policy by using predefined privacy constants.

Example:

            CComPtr<IRTCSessionSIPPrivacy>   cpPrivacy;
            hr = cpNewSession->QueryInterface(
                IID_IRTCSessionSIPPrivacy,
                reinterpret_cast<void**>(&cpPrivacy)
                );

            if (SUCCEEDED(hr))
            {
               hr = cpPrivacy->put_SIPPrivacyType(RTCSP_PRIVACY_LOCAL);
              if (FAILED(hr))
                {
                    ....
                }
            }

2.Client level - the privacy is set for an IRTCClient

Interface, IRTCClientSIPPrivacy, adds privacy support for all SIP traffic for a an IRTCClient. It can be created by calling QueryInterface on the IRTCClient object. This interface also has a function,put_SIPPrivacyType, to set the privacy policy on a client. The privacy policy can be set after an IRTCClient is initialized and before the client is shut down. So it's possible for the application to add an UI to let the user change the privacy policy when the client is alive.

RTC's VOIP delay

cenet — Thu, 07 Jun 2007 10:09:00 GMT

This blog explains the different components that contribute to the audio delay in a VOIP call, and then discusses RTC's VOIP delay numbers.

When any VOIP call made between any 2 VOIP entities, the end-to-end delay for the VOIP call can be categorized as following:

a. VOIP Sender side delay

b. Propagation delay on the wire between 2 VOIP entities.

c. VOIP receiver side delay

Since our focus is delay characteristics of a device running RTC, let's ignore the propagation delay for now.

On VOIP sender side, the following component contributes to delay in general:

1. Audio Driver capture delay.

2. VOIP stack send delay (RTC media stack send delay)

3. (OS network + network driver) send delay

On VOIP receiver side, the following component contributes to the delay:

4. (OS network + network driver) receive delay

5. VOIP stack receive delay (RTC media stack send delay)

6. Audio Driver playback delay

As you can see, besides VOIP (RTC) stack delay, the end-to-end delay is also dependent on the network driver as well as the audio driver of the devices, which can vary from device to device.

Let us now look at RTC numbers with respect to the above categories.

For RTC, when a peer-to-peer VOIP call is made between 2 CEPCs (x86 machines running CE) sitting side-by-side in a lab, and using G711 codec, the total end-to-end delay measured was around 70msec.

RTC’s send delay (i.e. time spent by an audio packet within RTC media stack only, after RTC receives it from the waveIn and just before RTC submits the packet to socket layer to transmit over the wire) was measured around 2 to 3 msec

RTC’s receive delay (i.e. time spent by an audio packet within RTC media stack only, after RTC receives it from the socket layer and just before it submits the packet to wave API layer to play) is around 35 to 38 msec. The receive delay is more because RTC has an audio healer algorithm to dejitter and heal received audio data.

So the total RTC delay (send + receive) is around 38 to 40 msec.

The rest of the time (70 – 40 = 30 msec) is spent in the network + audio driver.

Since a human ear can tolerate a delay of around 200 mec, there is plenty of room for propagation delay.

How to make RTC VOIP functionality work with Vonage?

cenet — Wed, 30 May 2007 09:19:00 GMT

RTC uses standard based SIP signaling and RTP/RTCP media streams to provide VOIP functionality. To verify this, I carried out a little experiment to see if RTC works with existing VOIP services like Vonage. Guess what? It did :).

Here are the steps to configure RTC to make it work with Vonage. Please note that these are trial & error steps and the experiment was mainly to validate RTC's implementation with a consumer VOIP service. I tried this in 2006 and hence these steps may change if Vonage changed its configuration (server address/port, authentication, transport protocol, etc.) since then:

1. Use your Vonage client account information to create the RTC profile. Here is the sample profile that I used:

<user name = 'Vonage User' account='<11 digit phone number>' password='<password>' uri='sip:<11 digit phone number>@216.115.20.41' allowedauth='digest'/>

</sipsrv>

</provision>

Fill in <11 digit phone number> and <password> with the information that you have from Vonage.

216.115.20.41 is the Vonage proxy/registrar server address that I saw was being used for my account. Verify if this is still valid or if you have a DNS name for the Vonage server, put that info instead of the IP address.

2. Use UDP as the transport protocol (Set in the profile above)

3. Use symmetric UDP for SIP signaling. i.e. During RTC initialization, use the following initialization RTC flag: RTCIF_ENABLE_SYMMETRIC_UDP_SIGNALING

a. Use static local source port (5060) to listen to all incoming request i.e. During RTC initialization, use the following flag during initialization: RTCIF_PREFER_STATIC_PORT_FOR_SYMMETRIC_UDP

4. Used digest as authentication protocol (Set in the profile above)

5. Use server destination port as 5061 (Set in the profile above)

And Voila! RTC works with Vonage. I experimented before and after NAT case and it worked for both.

Please note: The above test was a pure proof of concept, to test RTC's standardized SIP implementation withh existing services like Vonage. The scenario is neither officially supported by Microsoft nor Vonage.

NETUI and Disabling Prompts for Credentials by the Redirector

cenet — Sat, 26 May 2007 19:08:00 GMT

One of the questions that I've seen asked, time and time again, is "How do you disable the username and password dialog that is generated by such and such Microsoft provided component?"

The answer to all great questions is that it usually depends. In particular it depends on how this said Microsoft component generates its UI. In the specific case of this blog posting, I'm going to talk about one of these components and one of the methods you could use to disable various UI.

The Redirector component on Windows CE almost always refers to the client-side Server Message Block (SMB) network filesystem. This component can display a number of UI forms, Message Boxes, Username and Password Dialogs, etc. It puts up these UI forms by making calls into another component called NetUI, which is used by many Microsoft provided components to display UI. The NetUI module is provided as public sample code with Platform Builder and it is available for the user to modify.

The following MSDN article discusses how to modify/make changes to NetUI.

http://msdn2.microsoft.com/en-us/library/ms904254.aspx

When the Redirector component displays a Username and Password Dialog in Windows CE 6.0 it does so by calling CallGetUsernamePassword. This method is defined in netui.h.

If you wanted to fail the Username and Password dialog silently in the Redirector component then you would want to set the return value of CallGetUsernamePassword to FALSE. CallGetUsernamePassword is defined in $(_WINCEROOT)\public\common\oak\inc\netui.h. If you investigate netui.h you can see that there is logic that handles displaying UI from both Usermode and Kernel. What is important to know is that you must change the final calls that both Usermode and Kernel mode will eventually call. Reading the code in netui.h one can find dependencies on netui_kernel.h and netui_user.h.

Looking to netui.h and netui_user.h we can see:

CallGetUsernamePassword calls CallUGetUsernamePassword.

CallUGetUsernamePassword calls GetUsernamePassword.

GetUsernamePassword is found in getuser.c in the netui directory:

$(_WINCEROOT)\public\common\oak\drivers\netui.

Here you can modify GetUsernamePassword to return FALSE, effectively removing the username and password dialog from being displayed.

Hopefully this illustration helps you disable or improve the default UI that comes with other Microsoft components.

Real Time Communication (RTC) support on CE and Windows Mobile platforms

cenet — Wed, 23 May 2007 21:03:00 GMT

There were many queries about using RTC on Windows Mobile platform. With this blog, I will try to clarify on which platforms RTC is available and supported.

So far, RTC has always shipped as a part of the general embedded CE release. It is supported as a part of CE releases only. Until WM6, RTC was never available on Windows Mobile platform. Copying CE released binaries on Windows Mobile is unsupported. There may also be licensing issues with that.
On some Windows Mobile 6 SKUs, VOIP (Voice over IP) is supported. This functionality is based on RTC. So, RTCDll.dll (RTC binary) will be available on some of the WM 6 SKUs. However, on these SKUs, RTC is not released as an SDK, but solely to provide the VOIP functionality. So if an application wishes to use RTC on these SKUs, it is free to do so, but that scenario won’t be supported by Microsoft.

Hope this will clarify some questions around RTC support on CE as well as Windows Mobile platforms.

- Rajesh

PCMCIA Problems on Windows CE Devices.

cenet — Mon, 07 May 2007 20:40:00 GMT

I wrote the first PCMCIA driver for Windows CE in 1995. At the time, CE had not been ported to the PC, so we had to rely on reference platforms and prototypes to debug. Some problems were not software related.

The first Windows CE reference platform was called PeRP (Pegasus Reference Platform, Pegasus was the code name for Windows CE 1.0). The designer did not understand how the software would use the PCMCIA memory mapped regions. He thought he would be thrifty and “save” three gates by making a byte appear at every DWORD address. This is why the CE 1.0 Card Services API included such functions as CardReadAttrByte and CardWriteIOByte. A vestige of this design decision remained until CE 5.0 in CardMapWindow’s pGranularity parameter. On the PeRP, pGranularity would be set to 4 or sizeof(DWORD). On all other platforms it is 1.

The next Microsoft developed reference platform was called the Odo (after a Star Trek character). It had a pluggable CPU architecture so we could test the various processors supported by CE at the time. Those in charge of the decision were sometimes too quick to approve a new CPU board. In their view, I guess booting CE to the shell was good enough. The PCMCIA support always seemed to get overlooked. I was left scrambling to figure out another reason why PCMCIA was failing on yet another Odo CPU board. I became quite adept at setting up the logic analyzer for monitoring the PCMCIA bus, and adept at reading the traces. Sometimes this wasn’t enough.

On one flavor of MIPS CPU board for Odo, some cards would work fine, and others would get recognized, but then could not be used in I/O mode. By simply reading some of the PCMCIA lines with a multi-meter we found that the power lines had not even been attached! The cards were being powered by the address lines! This of course limited the amount of power available to the card. Any card requiring more than a certain amount of power would not work in I/O mode. A card in memory mode (the initial mode a card is in when first inserted) has minimal power requirements since the attribute memory is usually a small ROM. I/O mode usually requires much more power. The amount of power varies from one card to another. This is why some worked and others did not.

I have encountered many similar power related problems. Much of the time the root cause is that the batteries cannot supply enough power for the card. A closely related problem is that the device on battery power cannot power a card to operating voltage in enough time. That is why there is the power-on delay registry setting. Often, plugging in the A/C power adapter provides enough power in these cases.

Another interesting problem had nothing to do with the PCMCIA controller hardware implementation and nothing to do with power. In version 1.0, CE did not support 16 bit I/O on PCMCIA. When support for it was added, there were some platforms that had problems. When I finally put the logic analyzer to work, I discovered that accesses to some byte-wide registers were not appearing in the trace. There were only 16 bit accesses. Configuring the software for the platform to report support for only 8 bit PCMCIA I/O obviously worked since the platform worked with CE 1.0. A visit to the MIPS architecture manual revealed the reason – MIPS has no instructions for byte-wide memory accesses! On MIPS, you either support 16 bit PCMCIA access or 8 bit, but not both. The same MIPS instruction is used for both; the PCMCIA subsystem generates an 8 bit access on the PCMCIA bus if it is configured for 8 bit. Many card designs are modeled from PC (x86) architecture designs and so they freely allow mixed 8 and 16 bit I/O accesses, often to the same register. Because of this a MIPS based device almost always has to support 8 bit only PCMCIA I/O.

How to drop a (Microsoft Generated) debug DLL into a Windows CE device?

cenet — Tue, 10 Apr 2007 02:21:00 GMT

Sometimes on the newsgroups I tell an OEM that's having problems with some component to "Drop DEBUG DLL foo into the release directory and turn on full DEBUGOUT and get me the output." Most Windows CE components have pretty good debug-time logging so a lot of times a customer can see the exact cause of the problem spit out in DEBUGOUT.

But how do you get this DEBUG DLL and its output? RETAIL DLLs don't have this, of course. The easiest way is if you can build a fully DEBUG version of the OS and boot it while connected to Platform Builder, then you're pretty much done. Just turn on appropriate debug zones for the component you need. This is recommended since it's one less step.

However there are scenario where you not have enough RAM/ROM to take a fully DEBUG OS. In this case you want to just drop on the DEBUG dll that you're interested in but have everything else be RETAIL. To do this:

1) Build the complete platform for both DEBUG and RETAIL OS.

2) Open RETAIL project in PB, then open a build window. In CE 6.0 this is Tools->Open Release directory in Build Window, menu and wording may be slightly different in different versions.

3) This will put you into the release directory for the RETAIL build. The release directory is just the dir where all your intermediate DLLs/PDBs/etc get dumped prior to creating a ROM image. Create a new directory here, ORG, and copy ModuleYouWantDebugOutFor.* to ORG.

4) If you "cd ..", the DEBUG directory will also be present. (I'm assuming you haven't customized releasedir position in anyway). copy ..\<debugDir>\ModuleYouWantDebugOutFor.* to RETAIL releasedirectory.

5) Now in PB, run Build->Make Run-Time Image. (Again, wording may change slightly across releases.) This automatically puts the DLL you want DEBUG into the ROM image.

6) Before you ship this ROM image to the world you need to remove the DEBUG bits from it. Ideally you have a formal build process of generating DLLs from a "clean" source, not developer's machine, but in case you don't be aware of this issue.

Note that not all CE Components have DEBUG messages, but most do.

Happy debugging!

[Author: John Spaith]

Creating MPPE Attributes in an EAP Extension

cenet — Thu, 05 Apr 2007 21:24:00 GMT

When an EAP extension succesfully completes authentication, it can fill in the PPP_EAP_OUTPUT pUserAttributes field with MPPE key information for use by other networking components. For example, RAS can use those keys for data encryption, and WPA/WPA2 will use them for the 4-way handshake on an 802.11 link.

The PPP_EAP_OUTPUT pUserAttribute field points to an array of RAS_AUTH_ATTRIBUTE structures, terminated by an array element with raaType = raatMinimum. Documentation on the format of the RAS_AUTH_ATTRIBUTE structure can be found at http://msdn2.microsoft.com/en-gb/library/aa363535.aspx.

For MPPE Keys, there will be 2 elements in the array of RAS_AUTH_ATTRIBUTES: one for the send key and one for the receive key. For the MPPE Key attributes, the PVOID Value field of the RAS_AUTH_ATTRIBUTE will point to a structure that is described in http://msdn2.microsoft.com/en-us/library/aa363636.aspx. See the section labeled "eatVendorSpecific".

Below are some sample utility functions that can assist in the creation of the data structures that contain these keys.

struct RAS_AUTH_ATTRIBUTE_VALUE
{
    BYTE VendorId[4];    // network byte order
    BYTE VendorType;
    BYTE Length;         // number of bytes from VendorType to the end of the value
    BYTE VendorValue[1]; // Length-2 bytes long
};
      
DWORD
MyEapUtilAuthAttributeInsertVSA(
    OUT RAS_AUTH_ATTRIBUTE *    pAttribute,
    IN  DWORD                   VendorId,
    IN  BYTE                    VendorType,
    IN  PBYTE                   pVendorValue,
    IN  BYTE                    cbVendorValue)
//
//    Insert a vendor specific attribute into the location pointed to by pAttribute.
//
{
      DWORD  dwResult = NO_ERROR;

      ASSERT(cbVendorValue < 254);

      pAttribute->raaType = raatVendorSpecific;
      pAttribute->dwLength = offsetof(struct RAS_AUTH_ATTRIBUTE_VALUE, VendorValue) + cbVendorValue;
      pAttribute->Value = LocalAlloc(LPTR, pAttribute->dwLength);
      if (pAttribute->Value == NULL)
      {
            dwResult = ERROR_OUTOFMEMORY;
      }
      else
      {
            struct RAS_AUTH_ATTRIBUTE_VALUE *pAttributeValue = (struct RAS_AUTH_ATTRIBUTE_VALUE *)pAttribute->Value;

            VendorId = htonl(VendorId);
            memcpy(&pAttributeValue->VendorId[0], &VendorId, sizeof(VendorId));
            pAttributeValue->VendorType = VendorType;
            pAttributeValue->Length = 2 + cbVendorValue; // 1 byte for VendorType, 1 byte for Length, then cbVendorValue bytes of VendorValue
            memcpy(&pAttributeValue->VendorValue[0], pVendorValue, cbVendorValue );
      }
      return dwResult;
}

RAS_AUTH_ATTRIBUTE *
MyEapUtilAuthAttributeArrayAlloc(
      DWORD nAttrs)
//
//  Allocate an array of sufficient size to hold the requested number
//  of authentication attributes.
//
{
      RAS_AUTH_ATTRIBUTE *pAttributes;

      nAttrs += 1; // Add one for the terminator
      pAttributes = (RAS_AUTH_ATTRIBUTE *)(LocalAlloc(LPTR, nAttrs * sizeof(RAS_AUTH_ATTRIBUTE)));
      if (pAttributes)
      {
            // Set the terminator array element
            pAttributes[nAttrs - 1].raaType = raatMinimum;
      }
      return pAttributes;
}

void
MyEapUtilAuthAttributeArrayFree(
      RAS_AUTH_ATTRIBUTE *pAttributes)
//
//  Free an array of authentication attribute values.
//
{
    if (pAttributes)
    {
        for (int i=0; pAttributes[i].raaType != raatMinimum; i++)
        {
            if (pAttributes[i].Value)
            {
                SecureZeroMemory(pAttributes[i].Value, pAttributes[i].dwLength);
                LocalFree(pAttributes[i].Value);
                pAttributes[i].Value = NULL;
            }
        }
        LocalFree(pAttributes);
    }
}

#define VENDOR_MICROSOFT     311
#define MS_VSA_MPPE_Send_Key 16
#define MS_VSA_MPPE_Recv_Key 17

#define MAX_MPPEKEY_LENGTH   32

// Format of the MPPE Key
// Byte 1-2:       Salt
// Byte 3:         Key Length (this is the length of the Actual Key and does not include Salt, Key Length and Padding fields) 
// Byte 4-35:      Actual Key  (Most access points require 32 byte keys for WPA)
// Byte 35-50:     Padding (required to make the length of the MPPE Key (not including the Salt) a multiple of 16 bytes)

struct MPPEKey
{
    BYTE Salt[2];
    BYTE KeyLength;
    BYTE Key[MAX_MPPEKEY_LENGTH];
    BYTE Padding[15];
};

DWORD
MyEapUtilAuthAttributeInsertMPPEKeyVSA(
    OUT RAS_AUTH_ATTRIBUTE *    pAttribute,
    IN  BYTE                    VendorType, // MS_VSA_MPPE_Send_Key or MS_VSA_MPPE_Recv_Key
    IN  BYTE const * const      pKey,
    IN  size_t                  cbKey)
//
//  Insert an MPPEKey VSA into the location specified by pAttribute.
//
{
    DWORD  dwResult;
    struct MPPEKey MPPEKey;
 
    if (cbKey > MAX_MPPEKEY_LENGTH)
        return ERROR_INVALID_PARAMETER;

    memset(&MPPEKey, 0, sizeof(MPPEKey));
    MPPEKey.KeyLength = cbKey;
    memcpy(&MPPEKey.Key[0], pKey, cbKey);
    dwResult = MyEapUtilAuthAttributeInsertVSA(pAttribute, VENDOR_MICROSOFT, VendorType, (PBYTE)&MPPEKey, sizeof(MPPEKey) - MAX_MPPEKEY_LENGTH + cbKey);  
    SecureZeroMemory(&MPPEKey, sizeof(MPPEKey));
    return dwResult;
}
    
DWORD 
MyEapUtilCreateMPPEAuthAttributes(
    BYTE const * const pSendKey,
    size_t             cbSendKey,
    BYTE const * const pRecvKey,
    size_t             cbRecvKey,
    RAS_AUTH_ATTRIBUTE **ppSendRecvKeyAttr)
//
// Save the MPPE Send and Recv Session Keys as Auth Attributes
//
{
    DWORD dwResult;
    RAS_AUTH_ATTRIBUTE* pSendRecvKeyAttr;

    // Allocate an auth attribute array able to hold 2 attributes (send key and recv key)
    pSendRecvKeyAttr = MyEapUtilAuthAttributeArrayAlloc(2); 
    if ( NULL == pSendRecvKeyAttr )
    {
        dwResult = ERROR_OUTOFMEMORY;
        goto done;
    }

    // Add the send key to the attribute array at index 0
    dwResult = MyEapUtilAuthAttributeInsertMPPEKeyVSA(&pSendRecvKeyAttr[0], MS_VSA_MPPE_Send_Key, pSendKey, cbSendKey);
    if (dwResult != NO_ERROR)
          goto done;

    // Add the receive key to the attribute array at index 1
    dwResult = MyEapUtilAuthAttributeInsertMPPEKeyVSA(&pSendRecvKeyAttr[1], MS_VSA_MPPE_Recv_Key, pRecvKey, cbRecvKey);
    if (dwResult != NO_ERROR)
          goto done;
          
done:
    if (dwResult != NO_ERROR)
    {
        // Free any resources
        MyEapUtilAuthAttributeArrayFree(pSendRecvKeyAttr);
        pSendRecvKeyAttr = NULL;
    }

    *ppSendRecvKeyAttr = pSendRecvKeyAttr;
    return dwResult;
}

time.h for WinCE at OpenNetCF

cenet — Thu, 22 Mar 2007 20:28:00 GMT

Windows CE does not support the time.h structures, as I blog about here. Fortunately Chris Tacke at OpenNETCF has created a free library to do this, which is available here, in order to make porting easier to CE. (If you're not porting code you should be using the Win32 time functions, which WinCE does support.)

Whenever I point folks at non-MS software I always have the disclaimer that MS doesn't officially support it, buyer beware, etc etc... I'm embarrassed to have to put that in for this case because I know Chris is a really good guy who's done a lot for the CE development community. Thanks Chris for your work here!

[Author: John Spaith]