Hi again,
My trace is similar to that except that my application also closes its own end
of the connection (so when the remote host sends a FIN, it responds with an ACK
then sends its own FIN and receives an ACK).
Thanks for pointing out DxeTcpIoLib - that's a great reference. My application
does actually work when I call Configure with NULL, but I had hoped to avoid
doing that as a) it didn't sound, from the spec, like the proper way to stop
listening and b) it calls all the event notify functions for submitted IO
tokens (which means I had to add code to the notify functions to detect this
case). The fact that DxeTcpIoLib uses Configure (NULL) reassures me about a),
and now I can see that the solution to b) is of course to use CloseEvent!
Many thanks for your help.
Brendan
From: Fu, Siyuan [mailto:[email protected]]
Sent: 19 February 2014 02:33
To: Brendan Jackman
Cc: [email protected]; [email protected]
Subject: RE: [edk2] TCP->Configure after TCP->Close
Hi, Brendan
I write an application and it works fine on both Tcp4Dxe driver in MdeModulePkg
and TcpDxe in NetworkPkg (EDKII latest version). Please help to check the trace
file attached to see if it's similar with your work mode:
1. The application starts and listens on port 32610.
2. Packet 62, received FIN from client and exit.
3. Restart and listen on same port.
4. Packet 69, new TCP connection established.
Also you could refer the TcpIoDestroySocket() function in DxeTcpIoLib and check
your application to see if it has finished all the cleanup work after FIN is
received, that is:
Close all the token events created before;
Configure both the passive handle and the connection handle with NULL;
CloseProtocol on both the passive handle and the connection handle;
Finally destroy the passive handle and exit.
If still fail, could you provide the network trace file, code base revision and
source code for analysis?
Thanks,
Siyuan
From: Brendan Jackman [mailto:[email protected]]
Sent: Tuesday, February 18, 2014 6:21 PM
To: Fu, Siyuan
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: RE: [edk2] TCP->Configure after TCP->Close
Hi Suyan
The passive instance is created by first opening a
EFI_TCP4_SERVICE_BINDING_PROTOCOL and then calling CreateChild on that. I pass
a NULL Handle to CreateChild so that the EFI_TCP4_PROTOCOL is installed on a
new handle. When the application exits I call Configure on the passive instance
with NULL for the TcpConfigData (which "brutally resets" the instance), and
then call DestroyChild.
Ideally rather than calling Configure with NULL, I would call Cancel , but as
you can see in Tcp4Main.c, Cancel isn't implemented in EDK2.
Tom:
>My workaround was to set the port to zero, which results in a random port
>being chosen every time
This would certainly solve my problem, but unfortunately the application is a
"server" so it needs to be on a particular port :(
Best,
Brendan
From: Fu, Siyuan [mailto:[email protected]]
Sent: 18 February 2014 02:23
To: Olivier Martin; Brendan Jackman
Cc: [email protected]<mailto:[email protected]>
Subject: RE: [edk2] TCP->Configure after TCP->Close
Hi, Brendan and Martin
To help understand the problem, could you tell me how does you create or get
the passive TCP instance upon the application start? And have you destroyed
the passive instance before the application exit, or you just leave it in
listen state?
Thanks,
Siyuan
From: Thomas Rognon [mailto:[email protected]]
Sent: Tuesday, February 18, 2014 7:15 AM
To: edk2-devel
Cc: Olivier Martin
Subject: Re: [edk2] TCP->Configure after TCP->Close
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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
-- 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
-- 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------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
