Re: RFFR

On Wed, Jan 21, 2004 at 09:54:37AM -0500, Kathleen Poulsen wrote:
> 
> 1 file descriptor per interface rather than per context (i think
> this is underway).

Yep.

Note that it will very certainly break the current API :-(

My idea is to separate the interfaces functions and structures from
the libnet context. So, libnet_init()'s API wont change, but the
string used to select the device will become useless, or I should
rather say it will be used later for the cq interface (no more need of
a label, this will be the label).

What will change is the libnet_write() API as you will need to pass a
structure corresponding to the interface you want to use to send the
packet.

The device is only needed for LIBNET_LINK interface, but I dont want
to define 2 different functions as it can be confusing, but the new
API could be something like:

  int libnet_write(libnet_device_t *device, libnet_t *l) ;

For LIBNET_RAW, device can be NULL or whatever, it will be ignored.
For LIBNET_LINK, you will need to call something like:

  libnet_device_t* libnet_inite_device(char *dev);

Comments ?

	Fred Raynal


> 
> i'd like to see fields named as they are in ethereal; and i'd prefer to 
> see integration with an ethereal library rather than directly with pcap,
> so that parsed packets would be available.  ethereal has no library API yet,
> but by starting down the path of coexistence i think libnet would be
> heading in the right direction.
> 
> kathleen
> 
> 
> 
> On Tue, Jan 20, 2004 at 05:44:08PM -0800, Mike Schiffman wrote:
> > Hey. Ok so I'd like to make an official REQUEST FOR FEATURE REQUESTS 
> > (RFFR). What would you like to see in future versions of libnet? On the 
> > table thus far:
> > 
> > A unified name resolution function. Something to go forwards, backwards 
> > and handle ipv4 and ipv6 would be nice.
> > 
> > A pcap interface to allow seamless integration. Maybe this goes hand in 
> > hand with the following item:
> > 
> > A new interface for overlaying (captured) packets into network header 
> > templates. Previously we would do incorrect things like exposing 
> > internal libnet structures and overlay captured packets onto these (see 
> > Firewalk source for this bad practice). Also, this won't always work 
> > for some libnet headers that are simply base templates for packets that 
> > have dynamic sizes (DNS, IPv6, CDP, etc).
> > 
> > --
> > Mike Schiffman, CISSP
> > http://www.packetfactory.net/schiffman
> > Doveryay No Proveryay
> >