Messages in this thread | | | Date | Tue, 14 Dec 2004 17:04:29 +0100 (MET) | From | Jan Engelhardt <> | Subject | Re: bind() udp behavior 2.6.8.1 |
| |
>Hello, > > I am not subscribed to this list so please CC me personally in >response. > > I am noticing some odd behavior with linux 2.6.8.1 on a redhat 8 box >when making udp requests. It seems subsequent udp calls are all >allocating the same source ephemeral udp port. I believe the kernel >should be randomizing these (or incrementing) these ports for subsequent >requests.
No, you can have a fixed port for any socket. (It's just a question whether you actually get the socket, because it might be in use.)
See http://linux01.org:2222/f/UHXT/examples/src/fastsock.c , which contains an example on how to choose a fixed port.
> We ran a test C program that just put a gethostbyname_r call >in a for loop of 40 calls and all 40 requests used the same UDP source >port (32789).
Looks normal to me. It might select a random port upon "libc invocation" and use it for all further requests. This is in fact very valid, because UDP is connectionless; packets can go from anywhere to anywhere without any pre-work.
> This is causing our firewall to drop some packets since >it thinks it already closed that connection due to too many transactions >using same udp source/dest port passing thru in too short a time frame.
Then, the firewall UDP implementation is broken. Note, an UDP connection *can not be closed*, because it never was "open". If it's trying to do something like iptables -p udp -m state --state RELATED it is doing it wrong, because that is an impossible situation.
Jan Engelhardt -- ENOSPC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |