Re: UDP source port number when using RAW socket??

• Previous message: Kasper Dupont: "Re: kernel multicast socket reception problem"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sun, 11 Jul 2004 09:00:23 GMT

andreas_lindell76@hotmail.com (Andreas) writes:
>
> With this socket I can send RAW data to the server that listens on
> 62828 . When I send I create my own ethernet, IP and UDP and send it
> out on my eth0 interface. This all works fine and my server receives
> the data correctly and responds. However now I have a question what
> number to assign to my source port number on UDP when creating my
> packet on the client??

I guess you posted this a while ago, but I don't think anyone's
replied.

According to RFC 768, the source port in a UDP packet is an *optional*
field (specified as zero if unused), and I'm not aware of any newer
standard that contradicts this.

If it's specified, it merely "indicates the port of the sending
process, and may be assumed to be the port to which a reply should be
addressed in the absence of any other information."

So, if you don't need a UDP reply, just set it to zero.
Alternatively, (or if the receiving end has a broken network stack and
barfs on source port 0), set it to port 9 (reserved for the "discard"
service), and that shouldn't cause any problems.

> 1) How do I get "hold" of a valid UDP port number that I can assign to
> my RAW packet?
> 2) Is there some sort of API I can call and if so what?

If you *do* expect UDP packets in reply to the packets you send out,
then what you really want to do is open a plain UDP socket and bind(2)
it (probably specifying the local address as INADDR_ANY and specifying
the port as 0 if you want a local port automatically assigned---you
can use the getsockname(2) call to find out what port was assigned).
Use your raw socket to send out packets and your UDP socket to receive
replies. Hold the UDP socket open until you're finished, and that
will prevent the kernel from reallocating that port.

> 3) What are the implications/problems if one for some reason have two
> applications sending out data on the same port number?

Well, if a reply comes back to one of your raw-socket packets, it'll
be passed to the other application (i.e., the one that opened a
standard UDP socket that got bound to that port) and probably cause
problems.

-- 
Kevin <buhr@telus.net>

• Previous message: Kasper Dupont: "Re: kernel multicast socket reception problem"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]