Re: Debugging C# apps that use USB and Dial-up internet via Ethern
- From: William Powell <WilliamPowell@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 2 Jul 2008 15:40:03 -0700
Chris,
We were able to use the OpenNETCF wrappers for the iphelper functions to
successfully remove the ethernet routes so that we could still debug using
ethernet, but other operations within the system would use the appropriate
dial-up networking interface.
Just wanted to complete the posting.
Bill
"Chris Tacke, eMVP" wrote:
And if you're using SDF version 2.2, the OpenNETCF.Net.NetworkInformation.
namespace has all of the IPHelper routing stuff wrapped, so you don't even
have tp write the definitions or P/Invokes for those.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
"Michel Verhagen (eMVP)" <michel@xxxxxxxxxx> wrote in message
news:OZTwSTlmIHA.1768@xxxxxxxxxxxxxxxxxxxxxxx
The IPHelper functions should be able to help you out. What you want is
change the route or the metric (look at SetIpForwardEntry, SetIfEntry,
etc).
Good luck,
Michel Verhagen, eMVP
Check out my blog: http://GuruCE.com/blog
GuruCE
http://GuruCE.com
Consultancy, training and development services.
William Powell wrote:
WinCE Experts,
We are developing a WinCE 6.0 headless device (based on the Atmel 9260
and Adeneo BSP) that uses the USB function port as a virtual com port to
a PC (customer requirement): two hardware modules that provide dial-up
internet connections (GPRS and satellite); one Wifi module (with a
provided Ethernet driver) for communication to a remote server ;and an
ethernet port to support development only.
We currently have included the CoreCon components and the Autolauncher in
the build and can successfully create a flash based image that boots and
is ready for C# application debugging. We also autolaunch the cerhost
tool to allow the debug host to run the cerdisp tool to view a display on
the device (for development purposes)
Problem:
With the ethernet connection running to support debugging, we cannot seem
to get the dialup networking to recognize the dialup port as the
preferred networking transport. Test case 1:
To test, we've isolated the ethernet connection to the host by selecting
a static IP address and connected only the debug host PC and the target
system on a network (no DHCP, no access to the internet, no DNS). [We've
also tried this using a router not connected to the internet with just
the host and target on the router network and DHCP assigned IP addresses]
We starteup the OS image with a shell and created dialup entries for the
modem in the registry. When we initiate the dialup connection via the
control panel networking application, the modem connects (GPRS data
connection to the internet). We then try to ping a known site (google):
the device resolves the name and gets the IP, but then I see an error
message (transmit failed, error code 11010). The device is able to ping
itself properly but is unable to send/receive any data.
Test case 2:
We wrote a test program that programmatically starts the dialup
connection (using OpenNETCF calls) and transfers data over the
connection. This program is downloaded via ethernet (run without
debugging) from Visual Studio 2005, we disconnect the ethernet cable
(there is a pause in the program to give us time to do this), and the
program then executes, successfully starts the dialup networking
connection, and successfully transfers data over the dialup connection.
So, it appears if the ethernet connection is "not available" (but driver
still installed), WinCE select the other (dialup) networking connection
and works.
Question:
Is there a way to setup to use ethernet debugging to debug an application
that uses dialup networking such that the debugging packets are routed to
the ethernet port but other packets use the dialup networking connection.
Any help would greatly improve our ability to debug the program...
Bill Powell
- Prev by Date: Re: ISR implementation for a timing critical driver
- Next by Date: Remote Kernel Tracker is unable to connect to the device
- Previous by thread: Re: ISR implementation for a timing critical driver
- Next by thread: Remote Kernel Tracker is unable to connect to the device
- Index(es):
Relevant Pages
|
Loading
