Dialing the undialable and an exception that results

Editor
Mar 30, 2009 at 3:57 PM
Edited Mar 30, 2009 at 5:08 PM
I have a Sierra Wireless Compass 597 which I am testing for our purposes. It shows up as if it were a "Dial-up" connection in the Network Connections control panel but when "Connect" is selected from its menu nothing happens. I wanted to investigate this further and used Jeff's little sample connection launcher (as I hopefully will be using this device for some stuff later) and find that it produces an UnexpectedResultException. When do these occur, and is there anything I can do to get more information about what the problem is? (It turns out Sierra Wireless is very secretive about their SDK, so it isn't surprising their device is weird this way.)

I have a feeling this really isn't a dialup-like device at all, it seems a lot of these new fangled-cellular things (and some non-Microsoft VPN clients, too, for that matter) are very confusing from a device perspective.
 
Update: If I create a "dialup" style connection using the wizard that makes use of this device and calls what is shown to be the "phone number", this works to connect and disconnect. (Curiously, disconnect also works without this extra "layer".)
Coordinator
Mar 30, 2009 at 5:17 PM
That exception is thrown when a scenario is returned by the API that wasn't built into the project. I did this because I couldn't very well test all 300 possible return values from the API for every API call. I simply implemented the values that were indicated as being returnable by the API in the SDK documentation.

With that specific exception, you should see an ErrorCode property on it indicating a numeric value of the RAS error that occurred. If you give me that number I can tell you more in depth of the meaning of it. Also, you can use it in a catch block to determine what your application should do to handle said exception.

using (RasDialer dialer = new RasDialer())
{
    try
    {
        // Setup the dialer to dial your connection here.
        dialer.Dial();
    }
    catch (UnexpectedResultException ex)
    {
        if (ex.ErrorCode == 600)
        {
            // Do something else here.
        }
        else
        {
            throw;
        }
    }
}

Also, just a side note, that exception has been replaced by the RasException class in the 1.0 release candidate. It's become a base class for all RAS specific exceptions that are thrown which include an error code.
Editor
Mar 30, 2009 at 5:31 PM
Edited Mar 30, 2009 at 5:33 PM
Yeah, what with all the other issues pertaining to this project, I haven't gotten around to upgrading to the RC.

As for the error code, it claims to be of type 2.

Update: which I see is not a RAS error at all, accoding to the list at http://support.microsoft.com/kb/163111
Coordinator
Mar 30, 2009 at 5:46 PM
You are correct. That's the error value for ERROR_FILE_NOT_FOUND. Which that error isn't documented anywhere in the SDK as to why it would be returned from the dial method.

File not found errors are usually indicating it cannot find the phone book, or it cannot find the device you're specifying. I would try setting the PhoneBookPath property on the dialer to null, and if that has already been set, you could try specifying the full path to the phone book. It might be a file permission problem as well, so I would check that too. If you're going to specify the full phone book path, I'd suggest using the RasPhoneBook.GetPhoneBookPath static method to ensure you get the proper path.
Editor
Mar 30, 2009 at 6:34 PM
Curious error. I am obtaining the device to "dial" for the moment by adapting the paradigm in your example, Jeff: I loop until I get a phonebook entry with the name I want (aside: which is another problem related to my supporting multiple devices) and then I assign the phonebook path to the dialer based on that and its entry name. It works for some other items, most notably a POTS modem and a Novatel Wireless device. Setting the path to null produces the same behaviour. Assuming you are correct, that leaves us with it not finding the device, since finding the phonebook doesn't seem to be an issue. (Unless somehow the driver for the device "loads it wrong" or something weird like that, which is definitely out of my control.) Now why would it not find the device? It seems whatever is going wrong, Microsoft didn't anticipate it, whence the silent failure if you "dial" it in the Network Connections window.
Coordinator
Mar 30, 2009 at 6:57 PM
Edited Mar 30, 2009 at 6:59 PM
Setting the PhoneBookPath on the dialer to null simply tells it to use the default Windows phone book which loads both the all users' and current users' phone book files. That definitely doesn't seem to be your problem, so I'd have to agree your issue is definitely with the device. I'd probably restart the machine and try dialing the connection outside of your application to make sure something in my assembly isn't causing a blocking problem just to be safe if you haven't already. Out of curiosity, which method are you using to dial the connection? It might be something dealing with my assembly not cancelling the connection while dialing synchronously.

Also, you don't have to loop through the phone book if you already know the entry name you want. There's an overload on the indexer which takes the entry name and uses a dictionary lookup to find the appropriate entry instance. Though it might not be available in the version you're using, but it's available in the latest release, just fyi.
 
Edit: Forget I said anything about the assembly not cancelling the connection while dialing synchronously. I just checked the code and does already handle hanging up the connection for you if the connection attempt failed.
Editor
Mar 30, 2009 at 7:25 PM
It seems to be a problem with the way the device is handled within RAS itself, since the "fails silently" thing happens if the device is "dialed" in the control panel. I just restarted the dev machine to double check this and weirdly, the "category" markers ("dial-up", etc.) have disappeared in the control panel ... odd. (And it seems that whatever the built in "dialer" does differently, it does seem to snoop connections with the device type; now I get my PPP test thing in its list too.) What a crazy gizmo ... (sigh)
Coordinator
Mar 30, 2009 at 7:35 PM
No idea what to tell you then, sounds like it's some RAS wierdness going on and not something I can fix on my end.
Editor
Mar 31, 2009 at 2:55 PM
Agreed. Just making sure.