ASSERT : TCP.sys : Connection->AddressFile->Port != 0xFFFF

Using reactos-bootcd-0.4.15-dev-5186-gbbef618-x86-gcc-lin-dbg

Initially observed with a custome software polling SMTP/POP3 using tcp. every minute. Running fine for 7 days consecutively.

Systematically reproduced with a sample app that connects to a Socket then disconnect then reconnect....

• Open ~1 instance of CORE-18371.zip(source code included)
• "Start" on some existing ftp server, e.g. "ftp.heise.de"
• Wait ~20 minutes (Single occurence make it triggers at about 16K ops, If you want to hit it faster, you can run multiple instances in parallel)
•  Note : Likely fails on "0x3FFF"th port gets Allocated.

Assert with :

•  Assertion failed: Connection->AddressFile->Port != 0xFFF
•  Source File: /srv/buildbot/worker_data/Build_GCCLin_x86/build/sdk/lib/drivers/ip/transport/tcp/tcp.c, line 385

 Note : This situation is managed differently in : https://git.reactos.org/?p=reactos.git;a=blob;f=drivers/network/tcpip/tcpip/fileobjs.c#l478

 Full log with backtrace attached

Eip:

<ntoskrnl.exe:19cf6a (sdk/lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint))>

Frames:

<tcpip.sys:1b8ba (sdk/lib/drivers/ip/transport/tcp/tcp.c:385 (TCPConnect))>

<tcpip.sys:648f (drivers/network/tcpip/tcpip/dispatch.c:427 (DispTdiConnect))>

<tcpip.sys:cd44 (drivers/network/tcpip/tcpip/main.c:429 (TiDispatchInternal))>

<ntoskrnl.exe:7723d (ntoskrnl/io/iomgr/irp.c:1286 (IofCallDriver))>

<afd.sys:c5cf (drivers/network/afd/afd/tdi.c:67 (TdiCall))>

<afd.sys:cab2 (drivers/network/afd/afd/tdi.c:383 (TdiConnect))>

<afd.sys:29ce (drivers/network/afd/afd/connect.c:554 (AfdStreamSocketConnect))>

<afd.sys:78c2 (drivers/network/afd/afd/main.c:956 (AfdDispatch))>

<ntoskrnl.exe:7723d (ntoskrnl/io/iomgr/irp.c:1286 (IofCallDriver))>

<ntoskrnl.exe:6d03f (sdk/include/crt/mingw32/intrin_x86.h:716 (IopPerformSynchronousRequest))>

<ntoskrnl.exe:6dd9b (ntoskrnl/io/iomgr/iofunc.c:641 (IopDeviceFsIoControl))>

<ntoskrnl.exe:6f27a (ntoskrnl/io/iomgr/iofunc.c:1442 (NtDeviceIoControlFile))>

<ntoskrnl.exe:3fe5 (:0 (KiSystemCallTrampoline))>

<ntoskrnl.exe:15fc97 (ntoskrnl/ke/i386/traphdlr.c:1840 (KiSystemServiceHandler))>

<ntoskrnl.exe:3e2f (:0 (KiFastCallEntry))>

<ntdll.dll:10181>

<ws2_32.dll:c59e>

"Ignoring" the ASSERT leads to :

suggest that Allocated port grow "out of band" and not "recycled" properly

Ignoring again, make the sample app run until 32K ops then same ASSERT occurs

Placing some ASSERT in the code, I narrowed down the failing condition to :

if ((Port < PortSet->StartingPort) ||

        (Port >= PortSet->StartingPort + PortSet->PortsToOversee))

in https://git.reactos.org/?p=reactos.git;a=blob;f=sdk/lib/drivers/ip/network/ports.c#l53

digging further shows that the problem is upstream to the call to TCPAllocatePort as the "hint port" is 0xFFFF (forbidden)

 LocalAddress.Address[0].Address[0].sin_port == 0xFFF in

https://git.reactos.org/?p=reactos.git;a=blob;f=sdk/lib/drivers/ip/transport/tcp/tcp.c#l382

So the deep root cause is upstream and "Connection" object should not try to bind to local 0xFFFF port 

Patch for this problem and associated justification an analysis provided here : https://jira.reactos.org/browse/CORE-18371?focusedCommentId=137682&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-137682