Userland I/P stack?

I’d need to extend/improve an existing TCP/IP stack for embedded
systems. It would make life much easier if I could do this using VS and
friends on Win7. The task at hand is primarily focused on UDP. WinPCap
looks like it provides an adequately lower level driver interface for
both packet transmission and reception. Am I thinking along the right
lines here or is there a better (or no) way to do this?

Thx++

Jerry.

The problem with using WinPCap or any Windows NDIS protocol for this purpose
is the fact that all IP packets will be received by both the Windows TCP/IP
stack and your own protocol. In some cases the Windows stack may respond in
some way that conflicts with the response your own protocol’s desired
response. In addition, your protocol would receive UDP packets that will be
destined for the host TCP/IP stack; you must distinguish these from your
own.

What problems are you trying to solve?

Can raw sockets provide the features you desire?

Thomas F. Divine
http://www.pcausa.com


From: “Jerry Evans”
Sent: Sunday, February 10, 2013 11:29 AM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] Userland I/P stack?

> I’d need to extend/improve an existing TCP/IP stack for embedded systems.
> It would make life much easier if I could do this using VS and friends on
> Win7. The task at hand is primarily focused on UDP. WinPCap looks like it
> provides an adequately lower level driver interface for both packet
> transmission and reception. Am I thinking along the right lines here or is
> there a better (or no) way to do this?
>
> Thx++
>
> Jerry.
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

N++ (thos!).

Lift the code up in App layer and use raw_socket. Usually this
interface is to test out new protocol !

-pro

On Sun, Feb 10, 2013 at 10:42 AM, Thomas F. Divine wrote:
> The problem with using WinPCap or any Windows NDIS protocol for this purpose
> is the fact that all IP packets will be received by both the Windows TCP/IP
> stack and your own protocol. In some cases the Windows stack may respond in
> some way that conflicts with the response your own protocol’s desired
> response. In addition, your protocol would receive UDP packets that will be
> destined for the host TCP/IP stack; you must distinguish these from your
> own.
>
> What problems are you trying to solve?
>
> Can raw sockets provide the features you desire?
>
> Thomas F. Divine
> http://www.pcausa.com
>
> --------------------------------------------------
> From: “Jerry Evans”
> Sent: Sunday, February 10, 2013 11:29 AM
> To: “Windows System Software Devs Interest List”
> Subject: [ntdev] Userland I/P stack?
>
>
>> I’d need to extend/improve an existing TCP/IP stack for embedded systems.
>> It would make life much easier if I could do this using VS and friends on
>> Win7. The task at hand is primarily focused on UDP. WinPCap looks like it
>> provides an adequately lower level driver interface for both packet
>> transmission and reception. Am I thinking along the right lines here or is
>> there a better (or no) way to do this?
>>
>> Thx++
>>
>> Jerry.
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

> friends on Win7. The task at hand is primarily focused on UDP. WinPCap

looks like it provides an adequately lower level driver interface for
both packet transmission and reception. Am I thinking along the right

Terrifying complexity.

One of the jobs of the protocol is to bind to adapters below it and sockets above it. These interfaces are OS-specific.

Emulating your embedded OS’s interfaces in user-mode Windows is terrifying complexity and time waste.

The glamour of use of the merry toy called Visual Studio does not worth it I think. I think it is better to fine-tune Eclipse to your needs.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>> […] on Win7. The task at hand is primarily focused on UDP. WinPCap
>> looks like it provides an adequately lower level driver interface
>> for both packet transmission and reception. […]

Since you mention Win7 and WinPCap together, another problem with
WinPCap is that it’s not maintained; for now, it should be ok for
WinXP-era stuff, but don’t be surprised if things fail with Win7 onward,
especially with any new network driver architectures.

Luckily, things might be improving sometime:
http://www.winpcap.org/pipermail/winpcap-users/2012-December/004690.html
http://www.winpcap.org/pipermail/winpcap-announce/2013-February/000030.html

Also, you might want to do a code review of the WinPCap drivers. The
last time I did, as I recall, there were multiple things that weren’t
supported, that I would’ve expected to be (which the Unix LibPCap
library did support).

http://www.pcausa.com

You might also want to check out Thomas’s similar product:
http://www.rawether.net/

Or, if this is a Windows-centric thing, maybe NetMon APIs, instead of
WinPCap APIs.

Some years ago, I was called in to consult on a project. They wanted to
do their own network protocol, because a Reliable Friend Of A Friend Of
Some Manager had said that if you opened your machine for TCP/IP, your
system was vulnerable to cracking. Apparently they had overlooked
concepts like VPN and SSL. And essentially I could not convince them that
they had to implement a flow-management system comparable to that of
TCP/IP; they thought that a non-flow-controlled protocol analogous to UDP
would be more than sufficient for their needs. I told them there was
nothing I could do to save them from the disaster their misinformation was
leading them into, and turned the work down.

It was a smart move; the project died of its own mass of problems, but it
took two more years. The network, as I predicted, did not work reliably
outside the development lab (read: as soon as it hit a router, packets
started dropping).
joe

N++ (thos!).

Lift the code up in App layer and use raw_socket. Usually this
interface is to test out new protocol !

-pro

On Sun, Feb 10, 2013 at 10:42 AM, Thomas F. Divine
> wrote:
>> The problem with using WinPCap or any Windows NDIS protocol for this
>> purpose
>> is the fact that all IP packets will be received by both the Windows
>> TCP/IP
>> stack and your own protocol. In some cases the Windows stack may respond
>> in
>> some way that conflicts with the response your own protocol’s desired
>> response. In addition, your protocol would receive UDP packets that will
>> be
>> destined for the host TCP/IP stack; you must distinguish these from your
>> own.
>>
>> What problems are you trying to solve?
>>
>> Can raw sockets provide the features you desire?
>>
>> Thomas F. Divine
>> http://www.pcausa.com
>>
>> --------------------------------------------------
>> From: “Jerry Evans”
>> Sent: Sunday, February 10, 2013 11:29 AM
>> To: “Windows System Software Devs Interest List”
>> Subject: [ntdev] Userland I/P stack?
>>
>>
>>> I’d need to extend/improve an existing TCP/IP stack for embedded
>>> systems.
>>> It would make life much easier if I could do this using VS and friends
>>> on
>>> Win7. The task at hand is primarily focused on UDP. WinPCap looks like
>>> it
>>> provides an adequately lower level driver interface for both packet
>>> transmission and reception. Am I thinking along the right lines here or
>>> is
>>> there a better (or no) way to do this?
>>>
>>> Thx++
>>>
>>> Jerry.
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Do you really need to feed this stack from the network or just a test
harness? If you have a test harness, you can likely do this all in UM
(perhaps using raw sockets & the loopback adapter). If you need to feed
this from the network, then make sure to unbind all other protocols from the
interface you are using for testing so that the Windows network stack does
not process them as well as your code

“Jerry Evans” wrote in message news:xxxxx@ntdev…

I’d need to extend/improve an existing TCP/IP stack for embedded
systems. It would make life much easier if I could do this using VS and
friends on Win7. The task at hand is primarily focused on UDP. WinPCap
looks like it provides an adequately lower level driver interface for
both packet transmission and reception. Am I thinking along the right
lines here or is there a better (or no) way to do this?

Thx++

Jerry.

Thanks - I have found a good solution. Details here:
http://www.dupuis.me/node/21