[Winpcap-users] RE: TCP/IP stack - reinventing the wheel

Wed Aug 16 15:38:10 GMT 2006

Mark

I would be more then happy to see how you exported your 4 functions for
access by VB.

My last stumbling block is exporting functions in an easy as possible
manner.

I know there are several methods (DEF, macro, etc), several types of of
Libraries (static, dynamic, etc), but I just want the easiest, safest
and fastest way to have my functions available to an external program.

It "sounds" like you and I are doing about the same exact thing.

I am sure some people on the list are groaning at this point ( ;-) but
"sorry to say" I have had to use higher level languages for years and
now desperately want to get back lower in the "food chain" as possible
(C/C++).

BTW, it was already pointed out to me as to your concerns of this code
being 8 bits (see the thread below from Ramiro).  I had asked the same
and it was pointed out that the compiler will usually resolve data types
and can be addressed (supposedly) very easily.

I have great interest in this new code as part of what I am doing will
eventually lead to greater customizations of existing firmware.  So this
may be a great tutorial, or tool.

Obviously it may be better to send any code you wish to part with off
list unless there are others wanting also.

Thanks,
~ Thomas O'Hare ~
President, RedTile, Inc. - DBA: RedTile Software
Web, Wireless, Network, Database & Systems Software
+1.407.295.9148 ; +49.8651.717950 ; http://www.RedTile.Com/
Operations Manager; Virtual FoxPro User Group
Tom at VFUG.Org ; http://www.VFUG.Org/

Mark Buchanan wrote:
> Thanks for your responses:
> 
>> From: "Ramiro Polla" <ramiro86 at hotmail.com>
> 
>> Hello Mark,
> 
>> Try uIP. It's very nice, and it has a windows port.
> 
>> www.sics.se/~adam/uip/
> 
>> Bye,
>> Ramiro Polla
> 
> Ramiro,
> 
> I have looked at this site and it looks promising. There are some
> concerns however: The code basically is for porting the TCP/IP stack to
> small devices. What I need to do is add on to the TCP/IP stack so that
> the application can pretend to listen on and accept connections for
> multiple IP addresses (not listening for multiple connections from
> multiple IP clients but pretending to be multiple servers at the same
> time). I don't know if I have the expertise to use the C code from this
> site, port it to a Windows environment (preferably VB.NET), and make the
> necessary extensions needed. * * * See more comments below.
> 
> - - - - 
> 
>>> From: "Thomas O'Hare" <Tom at RedTile.Com>
> 
>>> Mark
> 
>>> A question first.
> 
>>> When you did your DLL did you create your own functions?  If so, did
> you put them into a type of library to define them?  If so, what type of
> library and what else can you share on this.  My biggest problem is my
> own functions to be exported for use by "other" programs.  IOW, I need
> to write functions to simplify a lot of what goes on in WinPCap so the
> higher language (with less inherent power) can more easily process data.
> 
>>> Maybe an Answer:
> 
>>> Not really, but it is worth mentioning.
> 
>>> Can you set up a subnet mask to filter the IP addresses you want
> monitored?  It is usually much easier at some point in your code to
> define a subnet if possible as a filter then process the IP's that are
> filtered.
> 
>>> Thanks,
>>> ~ Thomas O'Hare ~
>>> President, RedTile, Inc. - DBA: RedTile Software
>>> Web, Wireless, Network, Database & Systems Software
>>> +1.407.295.9148 ; +49.8651.717950 ; http://www.RedTile.Com/
>>> Operations Manager; Virtual FoxPro User Group
>>> Tom at VFUG.Org ; http://www.VFUG.Org/
> 
> Thomas,
> 
> The DLL that I wrote is extremely small. Most of the code comes right
> out of the WinPCAP examples - with a few things added for my own
> customization. There are 4 functions defined that the VB.NET application
> calls: one to select an adapter - defined by number, another to close
> it, another to process incoming packets (the DLL receives the packets as
> they come in and stores the packet data into a large array, when the
> function is called the entire array is passed to VB and the DLL array is
> reset), and the last to send out a single packet. It would have made
> more sense to have a callback function defined for incoming packets but
> this wasn't necessary - the incoming packets also came in bursts with up
> to 20 packets coming in within 2 ms.
> 
> Note that I don't bother with anything but the packet data itself. The
> time stamp, header info, MACs, etcetera is ignored. In this application
> the VB.NET handles all protocol issues including timing and resending of
> packets as needed - it's a good thing that it is simple protocol and I
> have had a few years to master it. TCP/IP seems a little overwhelming at
> this point.
> 
> I actually purchased a commercial DLL that does what's needed before I
> wrote my own. (There is a link on the WinPCAP FAQ site to this
> software.) The purchased DLL solution proved to have serious performance
> issues (it could handle about 600 packets / second but killed CPU usage
> - I needed to handle 2000 packets / second). I also tried a solution
> that made direct calls to the adapter using C# - doing a simple
> performance test showed that this was also way to slow. The DLL that I
> wrote myself works extremely fast - so much so that I had to slow down
> the sending of data packets because the software receiving and
> processing them on separate PCs couldn't handle it.
> 
> I don't mind sharing the DLL code that I wrote - let me know.
> 
> - - - - 
> 
>>>> Ramiro
> 
>>>> Sounds nerdy enough for me to get happy about.  But it says for 8 or
> 16 bit controllers.  IOW, I get the feeling it is for embedded or
> proprietary hardware.
> 
>>>> I think Mark needed at least 32 bit stuff.
> 
>>>> Am I missing something?
> 
>>>> Thanks,
>>>> ~ Thomas O'Hare ~
> 
> ------------------------------
> 
>>>> Hello,
> 
>>>> It is meant for embedded hardware. But it does communicate well with
> any 
> other TCP/IP stack.
> 
>>>> The code is very generic and simple (always uses 8-bit bytes, no
> words or 
> dwords) so that it will compile on most non-C-compliant proprietary 
> compilers. Gcc optimizes it very well. It does a good job on finding out
> 
> what could be 32-bit and making it good for the processor.
> 
>>>> I`d say It`s worth the try.
> 
>>>> Ramiro Polla
> 
> I have downloaded the source code and have started to look at it. One
> strategy might be the following:
> 
> 1. Take the uip code and encapsulate it in an object in .NET or a DLL.
> When the object is created give it an IP and MAC address.
> 2. Use WinPCAP to capture all packets, filter the packets sending them
> to the appropriate uip object.
> 3. When uip sends out packets they get routed through to WinPCAP again.
> 4. Provide an interface to the higher level application to handle data
> IO.
> 
> For me these tasks do present a large challenge - might even look at
> outsourcing this part.
> 
> Mark
> --------------------------------------------------------
> 
>  
> Mark Buchanan
> 
> 
> Senior Engineer, Controls Systems
> Giffels Associates Limited
> 
> 
>  
> Mark.Buchanan at giffels.com |  T 416 675 9750 Ext. 5253  |  F 416 798 5559  |  giffels.com
>  
> 
>     This communication is intended solely for the addressee(s) and contains information that is privileged, confidential
>     and subject to copyright. Any unauthorized use, copying, review or disclosure is prohibited. If received in error,
>     please notify us immediately by return e-mail.
>  
> 
> --------------------------------------------------------
> 
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users