Re: [edk2] TCP->Configure after TCP->Close

Subject: Re: [edk2] TCP->Configure after TCP->Close

From: Thomas Rognon <tcrognon@gmail.com>

To: edk2-devel <edk2-devel@lists.sourceforge.net>

Date: 2014-02-18 01:14:47

I encountered the same issue. My workaround was to set the port to zero, which results in a random port being chosen every time (which would fail if the same port was randomly chosen, though the odds are very low). The port didn't matter in my application, but this would be unacceptable in many other applications. I'm also curious if this is a bug or if I'm doing something wrong.


On Mon, Feb 17, 2014 at 8:22 AM, Brendan Jackman <Brendan.Jackman@arm.com> wrote:
Hi there,

I'm developing a UEFI application that uses the EFI_TCP4_PROTOCOL. It Configures a TCP protocol interface in passive mode and calls Accept. When a connection is received, it opens the pre-configured protocol interface representing that connection (to make sure I'm clear: there are now two instances of the TCP protocol: one passive instance, on which I called Accept, and one instance representing the established connection). It then transfers data until it receives the CONNECTION_FIN error when the remote host closes the connection. Finally it calls the Close function on the protocol interface representing the connection, to close its own end of the connection.

When the connection is finished, it calls Accept again, on the original protocol interface, to listen for another connection. This works fine - I am able to receive multiple connections, on the same local port, one after the other.

However, when the application exits and re-starts, the call to Configure fails with EFI_INVALID_PARAMETER and the message "TcpConfigurePcb: Bind endpoint failed with Invalid Parameter". Stepping through the code shows that this is because there is still a TCP_CB in mTcpRunQue representing the TCP connection. It has the same IP address and local port as I've passed to Configure, so the operation fails under the assumption that someone else is already listening on this port.

I was able to work around the issue by, when the connection is closed by the remote host, not only calling Close on the protocol interface for the connection, but also calling Configure with NULL as the argument. This results in Tcp4FlushPcb being called, which removes the TCP_CB for the connection from mRunQue. When the application exits I also call Configure with NULL on the protocol interface representing the passive TCP listener. This is not ideal, because it calls all the event notify functions for any submitted IO tokens.

Is this a bug, am I misunderstanding the interfaces, or somewhere in between?

Best,
Brendan

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel