[Winpcap-users] RE: TCP/IP stack - reinventing the wheel
Tom at RedTile.Com
Wed Aug 16 15:38:10 GMT 2006
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
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
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.
~ 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.
>> Ramiro Polla
> 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>
>>> 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
>>> ~ 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/
> 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.
> - - - -
>>>> 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?
>>>> ~ Thomas O'Hare ~
>>>> It is meant for embedded hardware. But it does communicate well with
> 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
> For me these tasks do present a large challenge - might even look at
> outsourcing this part.
> 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
More information about the Winpcap-users