On Thu, May 05, 2016 at 01:05:25AM +0000, Fu, Siyuan wrote: > Hi, Michael > > Sending this RST is required by TCP RFC793 as below: > > http://tools.ietf.org/html/rfc793#section-3.9 > > SEGMENT ARRIVES > > If the state is CLOSED (i.e., TCB does not exist) then > > all data in the incoming segment is discarded. An incoming > segment containing a RST is discarded. *An incoming segment not > containing a RST causes a RST to be sent in response*. The > acknowledgment and sequence field values are selected to make the > reset sequence acceptable to the TCP that sent the offending > segment.
That's fair enough. Now that I understood the TCP driver behaves correctly by following this well defined standard. Thanks. > > For the case that "other running Managed Network instance with it's own > network stack", I think it's not TCP layer's responsibility, instead, it > should be handled by SNP or MNP driver. They shouldn't deliver those network > packets which are not owned by the network stack about it. I think this a good point. And that's what a user (at least I am) would expect generally when they have created instances (child handle) in their efi application to work on EFI Managed Network Protcol interfaces on its own. It's not only for sharing the access to SNP but also should provide isolation for packets per instances and applying filter settings. I think also one more thing to consider is security, it makes sniffing network activity from one application way too easy, Could we consider putting the effort for making isolation in MNP (at least for this case ..) and make it obvious in the spec ? > If other network stack want to take over the device from edk2 network stack > drivers, it had better to disconnect the edk2 network stack first, to avoid > such races between the two network stacks. That sounds like the same purpose to move to use SNP with exclusive open, which is the opposite for why I started looking into MNP. We are back to squre one. Acutally I was motivated to use MNP to replace SNP (with exclusive open) in grub2 because people advertising it better solution to integrate and co-operate with firmware network stack, you don't have to worry about side effects from killing off all running network instances and doing all setting from scatch. And the most important idea is I would like to see a chance that both grub2's native and firmware's network stack could coexist to enable the possibility to use protocols only provided by firmware (like the https is on the road) while not stopping the other from working. Thanks, Michael > > Best Regards > Siyuan > > > -----Original Message----- > > From: edk2-devel [mailto:[email protected]] On Behalf Of > > Michael Chang > > Sent: Wednesday, May 4, 2016 6:23 PM > > To: [email protected] > > Subject: [edk2] [PATCH] NetworkPkg: Discard TCP segment when no TCB > > found > > > > The TCP driver should discard(ignore) the incoming TCP segment when there's > > no > > TCB found to handle it, because that TCP segment may be subjected to be > > received by other running Managed Network instance with it's own network > > stack > > to handle it. Force sending reset segment in this case would just discrupt > > any > > TCP connection except the one established by EFI TCP protocol, which is not > > make sense imho. > > > > Thanks. > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Michael Chang <[email protected]> > > > > --- > > NetworkPkg/TcpDxe/TcpInput.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/NetworkPkg/TcpDxe/TcpInput.c b/NetworkPkg/TcpDxe/TcpInput.c > > index 745ee4c..7aa6f7e 100644 > > --- a/NetworkPkg/TcpDxe/TcpInput.c > > +++ b/NetworkPkg/TcpDxe/TcpInput.c > > @@ -794,10 +794,10 @@ TcpInput ( > > ); > > > > if ((Tcb == NULL) || (Tcb->State == TCP_CLOSED)) { > > - DEBUG ((EFI_D_INFO, "TcpInput: send reset because no TCB found\n")); > > + DEBUG ((EFI_D_INFO, "TcpInput: discard a segment because no TCB > > found\n")); > > > > Tcb = NULL; > > - goto SEND_RESET; > > + goto DISCARD; > > } > > > > Seg = TcpFormatNetbuf (Tcb, Nbuf); > > -- > > 2.6.6 > > > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
