On Thu, May 05, 2016 at 07:42:33AM +0000, Fu, Siyuan wrote: > Hi, Michael > > So you want to have 2 network stack above the MNP protocol, the grub2 native > stack and the edk2 stack, right?
Yes, that's the idea basically. > Then do you need the 2 network stack work simultaneously? Not really as strict but is nice to have. As grub has no multi-tasking support there could have only one working at a time. What I am really concerned is how to achieve a single grub image (as NBP) that can provide its networking via both network stack but not mutually exclusive. For eg, you don't have to build two image, one for http and another for https because they may use mutually exclusive network stacks. > > If your requirement is the two network stack above MNP need to work at same > time, for example one stack is downloading HTTPs, while the other stack could > do TFTP download or reply ping message, I think it's very hard to achieve > that. For the income network packet, the Ethernet header only contains > Src/Dest MAC and a protocol type field, , there is no method for the MNP > driver to know which network stack it should be delivered to. And it couldn't > simply duplicate the packet and deliver them to the two network stack, that > will confuse upper layer drivers, like the TCP issue you met here, or many > other case, such as one stack released a DHCP server assigned IP address, > while another stack is still using it. Yes, I think you're right, as I am also poking around the MNP driver for how it matches instances (MnpEnqueuePacket function) and realized that the difficulties may actually be a limitation. > > If you only want to take turns to use the two network stack, things could be > a little simple. A possible I think, both the 2 stack need to have interface > to put the stack into a "sleep" state (no packet transmit, no packet > receive), and interface to "wake up" them. But there are still some > limitations on the usage, such as the IP address release. Does it require to configure every instance or a global status ? > > Another possible method I think, is to always let the two network stack use > different IP address. So the 2 IP drivers could discard the un-wanted packet. > But how to deal with the broadcast is still a problem. This sounds not possible in practice for how most dhcp server setup. What I remain confused is grub2 definitely used different port numbers, but the firmware still reset the TCP connection. Is the port situation any different with IP (I think both are met the status "TCB does not exist") for locating TCB for arriving packets ? > > Anyway, I think it's not easy to solve your problem only by using on current > UEFI protocol. So let's understand the real requirement first, then we can > try to figure out a way. Hope my explaination helps and please let me know if still anything unclear. :) Thanks, Michael > > Best Regards, > Siyuan > > > > > > From: Michael Chang [mailto:[email protected]] > Sent: Thursday, May 5, 2016 12:35 PM > To: Fu, Siyuan <[email protected]> > Cc: [email protected] > Subject: Re: [edk2] [PATCH] NetworkPkg: Discard TCP segment when no TCB found > > 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]<mailto:[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]<mailto:[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]<mailto:[email protected]> > > > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
