Changes to PCBPORTHASH wrt TCP, review needed

From: Mike Silbersack (silby_at_silby.com)
Date: 10/27/03

  • Next message: FreeBSD bugmaster: "Current problem reports assigned to you" 
    Date: Mon, 27 Oct 2003 02:16:13 -0600 (CST)
To: freebsd-net@freebsd.org

    The attached patch is rather short, but makes a substantial change in how
    ports are bound, so I'd like a quick review of the code and the concept if
    possible.

    In short, what this patch does is remove established TCP connections from
    the PCBPORTHASH table, thereby allowing their ephemeral ports to be
    concurrently used by other tcp connections to other hosts/ports.

    To do this, I made the following changes:

    - in_pcbinshash was modified so that the "porthash" parameter determines
    whether or not the inp in question is added to the pcbporthash.

    - in_pcbrehash was modified so that the "remove" parameter determines
    whether the inp in question will be removed from the pcbportlist when it
    is rehashed in the pcbhash

    - in_pcbremlists was modified to account for pcbs not necessarily being in
    both hashes

    - syncache_socket uses the porthash parameter to ensure that incoming tcp
    connections are never added to the pcbporthash.

    - tcp_connect and tcp6_connect use ins_rehash to remove the inp in
    question from the pcbporthash list after the final ip/port has been
    determined. Note that the pcbhash is still consulted, so an attempt to
    create a tcp socket which conflicts with an already existing connection
    will be detected correctly.

    One easy way to test this patch is to install http_load, set your
    ephemeral port range to something in the range of 30, and have it start
    testing a host. It will quickly create TIME_WAIT sockets filling all
    ephemeral ports. Without this patch, you will be unable to create
    outgoing connections; with this patch, other outgoing connections will be
    fine.

    Note that since the port chosen is not released from the pcbporthash table
    until tcp_connect, repeated calls to bind can still reserve all ephemeral
    ports; I don't believe that is going to be a common case.

    So far, the only problem I can see is that in_pcbbind, being unaware of
    the state of pcbhash, may return ports which collide with in-use
    connections for the destination host while non-colliding ports are still
    available. I should be able to work around this potential issue with a
    simple retry loop, so it's not a big concern.

    Otherwise, can anyone see any problems that this change would cause? I
    believe that it would change behavior so that SO_REUSEADDR and
    SO_REUSEPORT would no longer be required for daemons which restart and
    attempt to listen on the same port, but I believe this to be a positive
    change. Ports used by tcp listen sockets and udp sockets should be
    protected as before, so that should be ok as well. Am I missing something
    subtle?

    Thanks,

    Mike "Silby" Silbersack

    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: FreeBSD bugmaster: "Current problem reports assigned to you"

    Relevant Pages

    • Re: problems with KB951746
      ... Blocking legitimate IP addresses responding on ports the ... using the net will cause the firewall to block IPs more rapidly. ... I doubt the patch, or SBS, is the problem here. ... tried different forwarders, different DNS servers, and root hints only. ...
      (microsoft.public.windows.server.sbs)
    • Re: problems with KB951746
      ... Blocking legitimate IP addresses responding on ports the firewall doesn't expect will cause problems. ... What I suspect is happening is that the patch is doing what it is supposed to do. ... It is also possible, but less likely, that your ISP's DNS servers are misconfigured and are unable to reply on odd source ports. ...
      (microsoft.public.windows.server.sbs)
    • Re: Patch available for shared em interrupts (Re: em, bge, network problems survey.)
      ... Note that this patch will not help you if you are not using the em ... shared irq that can be studied separately. ... <ACPI PCI bus> on pcib0 ... 2 ports with 2 removable, ...
      (freebsd-stable)
    • Re: [patch 0/8] xtensa: s6000 & s6105
      ... here is the core series of our s6000 port. ... First comes the nommu patch. ... everything that separates the S6000 from existing ports, ...
      (Linux-Kernel)
    • Re: [PATCH] for acpi S1 power cycle resume problems
      ... > I was told that if I had a patch to submit for a baseline change that ... > have 3 RWC bits, ... whoever did that RWC patch for UHCI ports certainly should ...
      (Linux-Kernel)