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
random thought... probably way of the scale but anywayz......... remove the network stack from the kernal and implement it userland using a combined version of libpcap libnet and libdnet (networkd API + deamon?).... bonus being could be run with priverlage seperation, chrooted and would not lead to kernal compromise if bugs found...... would be similar to what i am trying to do with the gobbler as a userland network toolkit for machines without an IP address and also similar to Fred's answer machine.
on openbsd you could have bpf reading in frames and dropping the mbuf's before any kernal processing is done on the frame (i have implemnted something similar so i know its possible).... the frame could then be procesed in userland and written back out at frame level from a prog and not the kernal
there would also need to be some method so that other programs still think they are connecting to a proper socket and not a userland prog... e.g. requiring no change to current programs using a kernal network stack
the obvious problem performance, but how much slower i don;t know?
oh yer there would be the instant firewall feature via dynamic libpcap filters... if it doesn;t match the filter drop it
any one up for the challange? ;)
probably goes a tad bit beyond the idea of just joining libnet, libpcap and libdnet :P
laters Ste Jones NetworkPenetration.com - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
