Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.

Hello,


On Wed, Mar 24, 2004 at 09:46:15PM -0000, Ste Jones wrote:
> > On Mar 23, 2004, at 1:14 PM, Guy Harris wrote:
> >> On Mar 23, 2004, at 12:09 PM, Michael Richardson wrote:
> 
> I really think there needs to be sort sort of unification between the two 
> libraries libpcap and libnet.... but joining them i don;t know if that the 
> best idea.... both require a fair amount of work to maintian so why not 
> start another api to handle the unification
> 
> The aim of the new api would be to act as the glue between both written 
> and captured frames, basically a userland stack api (ideally conforming to 
> all the relevant RFC's). Frames from libpcap could use this api to 
> determine what part of the libnet api to use to send frames required to 
> create a connection for example. The programmer could have full contol 
> over a stream and not have to worry about each individual frame (unless 
> they want to)... this would save manually handling connection states, 
> retransmission problems, fragementation issues and dropped packets 
> currently faced while using both lipcap and libnet. 


> Frédéric Raynal implemented something similar for handling
> connections a while back but i can;t find it on his site.... looked
> pretty good from what i can remember :)

Thanks :) But I stopped it because I had another idea to do it in a
better way ... but I had no time to do it yet :(

> I do think that libpcap should be able to send packets... if someone is 
> using libpcap to capture connections which should be terminated with a 
> simple rst, for example,  there should be a way to send a frame as another 
> api shouldn;t be required for anything this trivial.... anything more 
> complicated use libnet :)
> 
> On the flip side disregarding everything i just said..... would one API 
> for userland networking be that bad idea? many programs require libnet, 
> libpcap and libdnet why not chuck them all together? would make quite a 
> bit of sense in the long run would it not? A greater userbase with more 
> eyes looking at the code can;t be bad.
> 
> A quick list of advantages and disadvanteage for joining the API's
> 
> Advanatages
> More people looking at the source code
> Easier install one api opposed to two or three api's
> Greater portability - libpcap seem to run on everything ;) congratz on the 
> recent libnet win32 port btw ;)
> Easier API for a developer....interfaces would only need to be selected 
> once for example.
> TCPReplay capabilites within the api?
> 
> 
> Disadvantages
> The api would be more complex and harder to maintain?
> Couldn;t really think of any others ;)
> 
> 
> my initial thoughts as u can probably tell were against the idea.... but 
> if the main developers are up for it can;t see why not ;)
> 
> enough ranting for this evening ;)

Ok, so I start from here, and I'll start with a short story.

Some days ago, I sent a mail to Dug Song and Mike about one thing that
is in libdnet as I was writting some code to do the same in libnet. 2
or 3 days ago, I had a look to the new libpcap, and also found the
same feature. That is an API to "handle" the device (getting/setting
its adresses, netmask, and things like that). This is definitely
something one need when handling "network stuff" and thus should be
sahred by all those libraries.

Another point for the unification is to avoid the multiplication of
the same structures. For instance, both libpcap and libnet use a
socket to read or write: why not use the same one? Except for 802.11
where listening and writing cant be done at the same time, I cant see
any good reason (but I am probably missed it). Idem with the
structures describing headers: why should they be define in several
places whareas they are always the same?

Libpcap does much more than only "listenig on the network". The
callback system is pretty cool and that is something similar I wanted
to do with the "answering machine" based on network event. But for
that, libnids is also very interresting with its good TCP engine
(conntrack). Having a userland network stack was part of what I have
in mind.

There are few projects that are using only libnet, and more that are
focusing on libpcap. But most of projects use both of them. And for
those ones, a common API with easy ways to "convert" from one to the
other would be vey helpful.

That was just my 2cts of euros as a user of these 2 wonderful
libraries.

	Fred Raynal