Paolo Abeni wrote:
Perhaps I'm missing the point, but I think a similar situation
currently happens in the pcap_findalldevs() function, which ultimately
calls pcap_open_live()/pcap_close() for each discovered device.
That's an implementation detail; if there were a way of determining
whether
Guy Harris wrote:
> Paolo Abeni wrote:
>
> > I thought that such things (pcap API to ask for supported parameters)
> > could be implemented adding dedicated fields into the pcap struct (on in
> > a pcap_t sub structure), which must be set by the platform specific
> > pcap_activate().
>
> That woul
Abeni Paolo wrote:
I thought that such things (pcap API to ask for supported parameters)
could be implemented adding dedicated fields into the pcap struct (on in
a pcap_t sub structure), which must be set by the platform specific
pcap_activate().
That would mean you couldn't ask for supported
hello,
on Tue 2/5/2008 9:57 PM Guy Harris wrote:
> I need to add:
> a routine to check whether you *can* set monitor mode, for the benefit
> of, for example, Wireshark (so it could display a "use monitor mode"
> checkbox iff you can run with it on or off);
[...]
> a routine to ask wh
BTW, my original tests of the monitor mode changes didn't work on
FreeBSD or OpenBSD, because the adapter was added when I plugged it
into the USB bus, but wasn't automatically brought up. I had to do
"ifconfig zyd0 up" to make it work.
If libpcap can determine that an adapter isn't up, sh
Abeni Paolo wrote:
Any comments are as usual very welcome.
So far, I have it compiling and working on:
Mac OS X 10.4
Mac OS X 10.5
FreeBSD 7.0 RC1
OpenBSD 4.2
Ubuntu 7.10
where "working" includes an additional pcap_set_rfmon() call to turn on
moni
hello,
I'm sorry for the long delay into posting something on the subject, but I'm
currently pretty busy with my work and spare time is lacking. Anyway I tried to
implements some of the idea discussed in the previous posts, and here is the
result. I tried to post the patch on the mailing list,
On Jan 13, 2008, at 3:33 PM, Michael Richardson wrote:
I.e. we should instead have a new pcap_open() call, and then we
should
have a serious of calls that set various options or ask for various
things based upon that handle.
Thus:
pcap_t pcap_open_live(char *device, int snaplen, int promis
> "Abeni" == Abeni Paolo <[EMAIL PROTECTED]> writes:
Abeni> - the (possibly high) number of new API that need to be added
Abeni> in order to support all required/wanted options for the open
Abeni> call - if we use the pcap struct to store all the supplied
Abeni> options (witch
hi all,
on 2008-01-13 23:33:55 Michael Richardson wrote:
> we should instead have a new pcap_open() call, and then we should
> have a serious of calls that set various options or ask for various
> things based upon that handle
>From a mere implementation POV, this looks like the easier solution.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Guy" == Guy Harris <[EMAIL PROTECTED]> writes:
>> What problem is the ultra-open parameter list supposed to solve?
Guy> 1) allow open options to be added without having to change the
Guy> signature of the open-live routine, so that
Michael Richardson wrote:
What problem is the ultra-open parameter list supposed to solve?
1) allow open options to be added without having to change the signature
of the open-live routine, so that we don't have to anticipate all the
options that might ever want to be added.
2) allow a app
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What problem is the ultra-open parameter list supposed to solve?
My experience is that you either make it a structure and deal with
possibly versioning it, you make it a string and let the library parse
it, or you go whole-hog, and make it XML.
I do
Guy Harris wrote:
Andy Howell wrote:
How about having a generic list of options? Something like:
typedef enum {
END_OF_OPTS,
PARAM_1,
PARAM_2,
} pcap_opts;
typedef union {
void *p;
unsigned int u;
} pcap_opt_value;
That assumes that an option will either be an "unsigne
Andy Howell wrote:
How about having a generic list of options? Something like:
typedef enum {
END_OF_OPTS,
PARAM_1,
PARAM_2,
} pcap_opts;
typedef union {
void *p;
unsigned int u;
} pcap_opt_value;
That assumes that an option will either be an "unsigned int" or a pointer
Abeni Paolo wrote:
hello,
I assume that the my initial suggestion is going to be dismissed,
right ?!?
on Thu 1/10/2008 10:47 AM Guy Harris wrote:
There'd also be an API to ask which parameters a particular adapter
supports (and possibly which values it supports for those
parameters, e.g. if
Abeni Paolo wrote:
I assume that the my initial suggestion is going to be dismissed, right ?!?
The extensible live-capture-open would be better (for one thing, a
global variable would have problems with multiple threads), but it might
be nice to get *something* into 1.0, so if we can't get t
hello,
I assume that the my initial suggestion is going to be dismissed, right ?!?
on Thu 1/10/2008 10:47 AM Guy Harris wrote:
> There'd also be an API to ask which parameters a particular adapter
> supports (and possibly which values it supports for those parameters,
> e.g. if one of the para
18 matches
Mail list logo
