Home > Archive > Unix Programming > January 2008 > socket programming again: possible to *sniff* udp packets before
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
socket programming again: possible to *sniff* udp packets before
|
|
| Lars Uffmann 2008-01-17, 4:25 am |
| Hi again,
I suppose there's no way to guarantee that I catch all UDP packets
arriving on a certain port if I am only p ing at them, while another
application is empyting the buffer as they come?
Or - in other words - if I want to read the whole UDP stream, the way to
do it would be to read the incoming port (emptying the buffer) with my
application, and forward a copy of the data to a different port for the
other application?
Thanks again :)
Lars
| |
| Lars Uffmann 2008-01-17, 8:11 am |
| Rainer Weikusat wrote:
> Use some kind of 'network tap', eg an (OS-specific) interface to the
> data link layer (SOCK_RAW, BPF, DPLI, or libpcap if you are a BSD).
Thanks, I'll have a look into that, but if the interface is OS-specific,
I'll probably go for the UDP forwarding solution, I wanna be platform
independent, whereever possible :)
Best Regards,
Lars
| |
| Logan Shaw 2008-01-19, 7:12 pm |
| Rainer Weikusat wrote:
> And I think you are overestimating the impact: Assuming not putting
> the interface into promiscous mode is possible with libpcap, that
> would be just (at most) twice the amount of work the kernel has to do
> anyway, because it needs to do something sensible with all arriving
> datagrams.
I haven't ever done that much with it, but I thought all the filtering
work that libpcap does was done in user space. So while in principle
it's the same amount of work, in practice with libpcap, all packets
(whether destined for that desired port or not) are going to have
to be sent into user space for libpcap to examine them. And my guess
is that will be a lot slower than when the kernel does it.
Also, another implication of libpcap that I don't think anyone has
mentioned: it requires root privileges, or at least it requires
privileges that let it see all network traffic. And the solution
that involves forwarding datagrams to another port does not require
that. So from a usability perspective, libpcap is maybe not a good
solution.
- Logan
| |
| Lars Uffmann 2008-01-21, 4:33 am |
| Rainer Weikusat wrote:
> firewall at 9 - 10 M/s. And I doubt the OP uses either a more than ten
> years old 'desktop PC' or a "slow", low-power RISC CPU intended to be
> used (among other things) embedded in consumer networking appliances.
Well actually I'm using 2GHz upwards systems with appropriate other
hardware components. :)
We'll see - right now, I think the port forwarding solution is the best
for me, mainly because I only just started network programming and due
to that, my skills are still somewhat limited - if I can sort the thing
just using the sockets library, that will be probably easier than
simultaneously learning the winpcap library as well - though I have
already installed that for packet monitoring on most of my systems :)
Thanks for all the inputs again!
Just out of curiosity, Rainer - where / in what field do you work?
Best Regards,
Lars
|
|
|
|
|