Question about libpcap

[Gerald Lee]

We have a unique situation. An engineer want to use libpcap to
create compile a packet filter. However, he wants to use it purely in
memory. The problem comes in that the application is threaded, and one
of the other threads is blocked on stdin. This causes the parser to
attempt to get more input from stdin. He tracked it down to the state
of yyin, and would just as soon directly manipulate it. Others of us
are discouraging this approach.
However, I need to give him either 1) the appropriate
incantations, or 2) a new interface (or variation on the current theme).
We've tried things like pcap_compile_nocap, and still see the problem.
Suggestions for either the correct usage (preferred), or
suggestions for a name for a new entry point (even if we are the only
ones using it ;).

Thanks,
- bob

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Maxwell]

Post by Gerald Lee
We have a unique situation. An engineer want to use libpcap to
create compile a packet filter. However, he wants to use it purely in
memory. The problem comes in that the application is threaded, and one
of the other threads is blocked on stdin. This causes the parser to
attempt to get more input from stdin. He tracked it down to the state

When you say 'the parser' - do you mean the bpf lex/yacc machine?

Post by Gerald Lee
of yyin, and would just as soon directly manipulate it. Others of us
are discouraging this approach.
However, I need to give him either 1) the appropriate
incantations, or 2) a new interface (or variation on the current theme).
We've tried things like pcap_compile_nocap, and still see the problem.

I'm not following the description of the problem here.
pcap_compile_nopcap takes the filter program as the str argument, and
shouldn't be touching any file handles...

[Gerald Lee]

-----Original Message-----
David Maxwell Thursday, July 19, 2007 7:47 PM

Post by David Maxwell

Post by Gerald Lee
We have a unique situation. An engineer want to use libpcap to
create compile a packet filter. However, he wants to use it purely in
memory. The problem comes in that the application is threaded, and one
of the other threads is blocked on stdin. This causes the parser to
attempt to get more input from stdin. He tracked it down to the state

When you say 'the parser' - do you mean the bpf lex/yacc machine?

Yes, sorry to be less than complete.

Post by David Maxwell

Post by Gerald Lee
of yyin, and would just as soon directly manipulate it. Others of us
are discouraging this approach.
However, I need to give him either 1) the appropriate
incantations, or 2) a new interface (or variation on the current theme).
We've tried things like pcap_compile_nocap, and still see the

problem.

Post by David Maxwell
I'm not following the description of the problem here.
pcap_compile_nopcap takes the filter program as the str argument, and
shouldn't be touching any file handles...

Once more, I'm working partially off of our engineers description of
his interaction with it. It appears to be a an assumption that in
the non-interactive case, yyin will be null or something like that.
Our application is threaded, and another thread has stdin and is
blocked on it. It appears that once the parser (lex/yacc machine)
processes the given input, it will wait on yyin if that variable is
active.

His answer was to directly manipulate this, obviously generated,
variable directly. I'm trying to get a quick answer to him so
this nonsense doesn't happen.

thanks,
- bob

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Maxwell]

Post by Gerald Lee
David Maxwell Thursday, July 19, 2007 7:47 PM

Post by David Maxwell
When you say 'the parser' - do you mean the bpf lex/yacc machine?

Yes, sorry to be less than complete.

Quite all right. The bpf virtual machine is a packet parser, so I was
trying to figure out if you meant rules or packets... rules. Got it.

Post by Gerald Lee

Post by David Maxwell
I'm not following the description of the problem here.
pcap_compile_nopcap takes the filter program as the str argument, and
shouldn't be touching any file handles...

Once more, I'm working partially off of our engineers description of
his interaction with it. It appears to be a an assumption that in
the non-interactive case, yyin will be null or something like that.

I wouldn't expect an assumption like that to exist in the code, since
you can define whatever input mechanism you like...

Here's a page that describes the traditional hackey method for not using
STDIN, and a cleaner method supported by flex. Comparing these to what
you're using right now to set up string based input should give a hint
as to what's wrong.

http://pintday.org/kjell/hack/lex

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gerald> We have a unique situation. An engineer want to use
Gerald> libpcap to create compile a packet filter. However, he
Gerald> wants to use it purely in memory. The problem comes in that
Gerald> the application is threaded, and one of the other threads is
Gerald> blocked on stdin. This causes the parser to attempt to get
Gerald> more input from stdin. He tracked it down to the state of
Gerald> yyin, and would just as soon directly manipulate it. Others

Is this a BSD lex issue, or a libpcap issue?
If the latter, perhaps tcpdump-***@lists.tcpdump.org would be better.

- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] ***@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRqQ5R4CLcPvd0N1lAQIAVAf/YFsaMGY7QWQQ/M/ZMTWwaGuUUSZz7qdE
Fp4WFWYti+xvrwINfHz6M3Jq+TfB62/OvHGMh24yw4j9NCBInM0j4NQUtVNk59QP
CFuDWLvRsnaVAQ0DqHcmPQNo3MfEoVbvJhtEGCkKT8m97CqmZcCTK6K8Vl1ETe4G
1ZPg3dQe9PPj3ShyQV8M+h4kTdzZSvR6vGU2MfvlEBbVOFI2FwSGOQVHfVy1nmiN
CZce94BQGr0+1176dcVg4Y9XG+rMkmLzSnF0fFXfcSWSGQ5u8rDSx2aZTKOVxW4x
bsIik3PFC+H83gsMmdRjIrl12ljIy5p3AzKmiE5ZJBKTVNyOhSl71w==
=QMHS
-----END PGP SIGNATURE-----

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Gerald Lee
We have a unique situation. An engineer want to use libpcap to
create compile a packet filter. However, he wants to use it purely in
memory. The problem comes in that the application is threaded, and one
of the other threads is blocked on stdin. This causes the parser to
attempt to get more input from stdin. He tracked it down to the state
of yyin, and would just as soon directly manipulate it. Others of us
are discouraging this approach.
However, I need to give him either 1) the appropriate
incantations, or 2) a new interface (or variation on the current theme).
We've tried things like pcap_compile_nocap, and still see the problem.
Suggestions for either the correct usage (preferred), or
suggestions for a name for a new entry point (even if we are the only
ones using it ;).

This sounds like an application bug...
...or
...perhaps an interaction problem if the lex/yacc code being
used by bpf is interacting incorrectly with lex/yacc used by
the application elsewhere?

darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gerald Lee]

Post by Darren Reed

Post by Gerald Lee
We have a unique situation. An engineer want to use libpcap to
create compile a packet filter. However, he wants to use it purely in
memory. The problem comes in that the application is threaded, and one
of the other threads is blocked on stdin. This causes the parser to
attempt to get more input from stdin. He tracked it down to the state
of yyin, and would just as soon directly manipulate it. Others of us
are discouraging this approach.
However, I need to give him either 1) the appropriate
incantations, or 2) a new interface (or variation on the current theme).
We've tried things like pcap_compile_nocap, and still see the

problem.

Post by Darren Reed

Post by Gerald Lee
Suggestions for either the correct usage (preferred), or
suggestions for a name for a new entry point (even if we are the only
ones using it ;).

This sounds like an application bug...
...or
...perhaps an interaction problem if the lex/yacc code being
used by bpf is interacting incorrectly with lex/yacc used by
the application elsewhere?

That may be. But this is unique in that it is a threaded
application rather than a more traditional application. Also,
this is only a problem when the other thread is waiting on
input from the tty.
I've not had time as yet to look at his code, nor to
try to check for untoward interaction. It doesn't seem that
he is doing anything wrong. So far it has been my assumption,
and yes I know what that means, that it is an interaction that
wasn't expected by the library designer(s). I've looked at
both the man page and the header file, and so far, what
he claims to be doing seems alright.

Post by Darren Reed
darren

thanks,
- bob

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de