-----Original Message-----
From: LI Jiang, SI-CT-SSM
Sent: Freitag, 16. Februar 2001 09:05
To: 'Guy Harris'
Subject: RE: [tcpdump-workers] udp port reuse
Hi Guy Harris,
Thank you for your reply.
-----Original Message-----
From: Guy Harris [mailto:[EMAIL PROTECTED]]
Sent: Freitag, 16. Februar 2001 06:55
To: LI Jiang, SI-CT-SSM
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [tcpdump-workers] udp port reuse
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> [EMAIL PROTECTED]
> Sent: Friday, February 09, 2001 5:02 PM
> To:
> Subject: [tcpdump-workers] udp port reuse
>
>
> Dear tcpdump workers,
>
> I am working on Reh Hat Linux 6.2
> I have a process listening on udp port P, I am writing another programm in
C
> to listen on the same udp port P in a unicast fashion.
What exactly are you trying to do here?
You said:
> I have a process listening on udp port P, I am writing another programm in
C
> to listen on the same udp port P in a unicast fashion.
Do you want an incoming UDP packet sent to port P to be sent to both of
those processes? (This is not normally supported by, as far as I know,
the socket interface on most if not all of the OSes that support a
sockets programming API for networking, which is why you're getting an
"address already in use" error - the address *is* already in use by the
first process, and only one process can use the address.)
If so, what are the two processes going to do with that packet?
A: ================================================
A: I have a process sending unicast UDP packets on one UDP port. This
process is using RTP, RTCP over UDP (a video streaming process program). I
wanted write another program doing QOS Monitoring on the latter process
(lost, jitter, rrt). That's why I want allow the other process retrive
packets from the same UDP port.
A: ================================================
If they're both supposed to do something other than just log the packet,
and if the two processes can be made aware of each other's existence,
another possibility might be to have one process handle all the
networking and just send a message to the other process to have it do
what work it's supposed to do.
If, however, the two processes can't be made aware of each other's
existence, you might have to do the same thing that tcpdump does - which
is *not* to create another socket; instead, it listens to raw network
traffic.
I.e.:
> But I can listen on the same udp port P using the following tcpdump
command:
>
> /usr/sbin/tcpdump udp port P
> tcpdump can listen on this port while there is another active loistening
> socket on the same port P.
>
> I would like to hnow how to bind and then listen on a udp port P, while
> there is another active socket on the same port.
Tcpdump isn't "listening" on that port in the same sense that a process
that creates a socket and binds it to port P is. Instead, the command
tcpdump udp port P
is - if that's the "tcpdump" that comes with RH 6.2 - capturing on all
networking interfaces (and not in promiscuous mode) and setting up a
packet filter that shows it only UDP packets sent to port P.
Note that if a UDP packet doesn't fit in a single link-layer frame, and
is fragmented by the IP layer, tcpdump will, with that filter, *NOT* see
the entire packet - it'll see only the first fragment, as only the first
fragment will have a UDP header.
On Thu, Feb 15, 2001 at 06:27:07PM +0100, [EMAIL PROTECTED] wrote:
> Do you know where I can find out the source code of a previous version of
> the tcpdump, for instance tcpdump 3.4 ?
Why do you want a previous version?
The current version, and the previous versions, don't differ in what
they do here. The version of tcpdump that comes with RH 6.2 is not the
standard tcpdump 3.4, so even if you *did* get the standard 3.4, it
wouldn't show you what the RH 6.2 tcpdump is doing - you would have to
get the source to the RH 6.2 tcpdump (i.e., load the source RPM for it)
to see what it's doing.
A: ================================================
A: Now I am using tcpdump for decoding RTCP packets sent by both video
streaming server and client, so I can monitor the QOS of this RTP session.
The command:
/usr/sbin tcpdump -vv -tt -T rtcp udp port 6971
prints on stdout a lot useful information of RTCP packets, but the tcpdump
man page doesn't explain what tcpdump prints. I have recognised several
fields from the RTCP RFC 1889. But, several fields stay meaningless, that's
why I am seaching for a tcpdump version that I can use for QOS monitoring
(prints on stdout a lot QOS information) and which also explains what it
prints.
I am seaching for tcpdump 3.4 source code, because Red Hat Linux has tcpdump
3.4 (tcpdump --version)
I am also working with tcpdump 3.6, to make it prints what I need.
The version of tcpdump is not important.
thank you very much for your help
cheers
Li jiang
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
