>
> Hmm.... the test only checks to see if the module can be loaded.
> Anyone know if pcap_dispatch is available only in certain versions? If
> it is, I could make it conditionally available. It could, though, be a
> problem with linking on your machine.
>
Could be. It's one of those annoying Ubuntu machines :)
My Debian lenny MIPS does the same thing.
>> * change open_offline() to take a Stdio.File instead of a string
>> path (meaning you could hand it a Pipe() or a network stream or
>> whatever.
>
> It's important to understand that some of the behavior is defined by
> the pcap library. This, for example, is only available if your library
> has pcap_fopen_offline, and would be tricky to implement well because
> there isn't necessarily a fd available in a Stdio.File object.
>
Fair enough. I thought I would suggest it nonetheless.
>> * lookup_dev() throws an error on my machine.
>
> What sort of error? I've found that that function is a little flakey
> in general.
>
<jnh[at]uggo>:~$ sudo pike -e
'write("%O\n",Public.Network.Pcap.Pcap()->lookup_dev());'
Public.Network.Pcap()->lookup_dev(): arptype 65534 not supported by
libpcap - falling back to cooked socket
/usr/lib/pike/7.6.112/modules/Public.pmod/Network.pmod/Pcap.pmod:6:
Public.Network.Pcap.Pcap()->lookup_dev()
-:2: -()->run(1,(),mapping[16])
>> * using nbio uses lots of CPU
>
> Not sure I understand... there isn't an NBIO interface, is there? I
> assume that your question is really a matter of having a loop that's
> constantly running the capture call. I'm not sure that there's a way
> to know when a capture call will return a packet (uniformly, anyway).
>
There is a set_capture_callback(), but I wound up just using next()
instead because it didn't work the way I anticipated. Of course, I most
likely anticipated wrong :)
> In theory, the capture descriptor could be hooked to select/poll and
> then run in the backend, but that would be a major undertaking.
>
>> * it doesn't tell you what sort of interface (and thus what sort of
>> frames) you are using. eg tunnels will give you raw IP packets,
>> ethernet will give you ethernet frames.
>
> That, I think is easily doable: pcap_datalink() seems to provide this
> information.
>
That would be awesome.
> I will also add that I think some of this functionality is new in
> libpcap since I originally wrote the module, so I don't automatically
> add new features I'm not using. Therefore, feature requests are the
> best way to see that your needs are met. :)
Sure. I does meet my needs, I'm merely suggesting useful improvements :)
Thanks
James.
|