login
Search
Hello,
I am encountering an issue where the linux kernel is not randomizing the source ephemeral port when making udp requests. We came across this issue when trying to implement pam_ldap for logins, and pam_ldap was making a bunch of dns requests. However all the dns requets were using the same source udp port,so teh firewall was discarding some of them since it saw the same connection "too soon" and tore down the connection.
Is there any reason (or fix) as to why the kernel (currently running 2.6.8.1 on redhat 8) would keep reusing the same udp port for all successive dns requests (about 7 in under 5 seconds)?
I have reproduced this by simply putting a gethostbyname_r in a for loop and all 40 requests in my for loop use the same source udp port. Is there a workaround for this? FreeBSD seems to not behave this way.
thanks
adam
just some more info.. a piece
just some more info.. a piece of the strace looks like this..
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.12.8.176")}}, 28) = 0
send(3, "\nq\1\0\0\1\0\0\0\0\0\0\4ldap\3ops\texample\3"..., 40, 0) = 40
gettimeofday({1103036311, 709568}, NULL) = 0
poll(
which one is wrong?
Is there a reason not to reuse the source port? Is it written somewhere in a standards document? If not, it would be the fault of the firewall, which would be wrongly assuming one implementation's behaviour everywhere. Also, even if firewall rule writers like such assumptions, the notion of a UDP connection is a bit dubious, and i can imagine UDP-based protocols, which send constant streams of data packets in both directions (e.g. netcat "-u" mode). There is nothing wrong with that in the general case. Also even if you cycle through 32k ephemeral ports, the port numbers repeat every 32k requests. If you manage to send this amount in one seconds, you get the same problems. UDP packets are limited to 512 bytes, the resulting 32767*512 = 16777216 bytes per second are theoretically possible with gigabit ethernet :)
According to the man page udp(7), the sender can select the source port with bind(2), if needed.
Correction: UDP len>512, 64k ports
Two points: First, UDP packet maximum length is not 512, it's much higher like 8k or 64k, but I can't remember what. Normally in Ethernet the packets are fragmented at 1500 bytes, but with exotic hardware the limits are higher. Second, there are 65535 ports, not 32k.
yes..
About 32k is the amount recommended for high-usage systems, see e.g. http://www.faqs.org/docs/securing/chap6sec70.html
You don't want 'well known ports' assigned for this, so the 64k port space is divided into ranges.
About the '512 bytes': see http://www.faqs.org/rfcs/rfc1035.html section 2.3.4. In http://www.faqs.org/rfcs/rfc760.html on page 11/12 you find a possible reason for this: every ip host can receive 512 byte packets. Of course IP packets with up to 64k can exist (and even larger with extensions).
And none of your points invalidated my argument, just the number gets higher, but stays finite (even in the technical sense of existing products).