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

On Thu, 25 Mar 2004 09:45:59 +0100, Frédéric Raynal 
<[email protected]> wrote:

> 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