Hi, Eugene Thanks for your patch. We have reviewed it and found that the ARP announcement package doesn't conform to RFC 5227 2.3. It requests the ARP announcement package with source MAC is itself and destination MAC is 0. We updated the patch. Please take a look. Since we don't have test environment for this patch, please also help to test whether this patch could fix the issue in your environment.
Thanks Michalle From: Cohen, Eugene [mailto:[email protected]] Sent: Wednesday, May 23, 2012 6:24 AM To: [email protected]<mailto:[email protected]> Subject: Re: [edk2] Network - Must Ping Out First Dear MdeModulePkg Network maintainer, I've isolated the issue to be a network infrastructure issue where some networks (switches presumably) will not send packets until it has been able to make the IP Address <-> MAC Address association. To resolve this I have implemented the 'ARP Announcement' as described in RFC 5227. So when ARP is Configured one ARP Announcement packet is sent so that network infrastructure can update MAC address tables. I've attached the patch with this fix. MdeModulePkg: Implement transmission of ARP Announcement packets when ARP is configured to resolve an issue where incoming packets are not received due to network MAC address filters not being updated. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen [email protected]<mailto:[email protected]> Thanks, Eugene From: Cohen, Eugene Sent: Tuesday, May 22, 2012 3:55 PM To: [email protected]<mailto:[email protected]> Subject: [edk2] Network - Must Ping Out First Dear MdeModulePkg Network maintainer, I'm seeing an issue with IPv4 networking (in MdeModulePkg, not using IPv6 stuff from NetworkPkg) where the stack seems to require some outbound packets before it will respond to incoming ARPs or pings. Here's what fails: 1. Run an app that starts listening on a TCP port 2. Try to arp/ping/connect from an outside host - No response! But this works: 1. Try to ping another node on the network a. This does dhcp, gets an IP address, etc 2. Then run the same app from #1 in the first case which listens on a TCP port 3. Try to arp/ping/connect - Success! The app is very simple, it basically does these steps (up to the point of failure): 1. Configure TCP4 a. This does dhcp, gets an IP address, etc 2. Call TCP4 Accept() to start listening for a connection 3. Gets the node's IP address through GetModeData to display to the user while the listener is still active I think something about the stack is being configured differently in the second case to enable proper response to ARP requests. I wonder if the first case has been tested since the more common case for UEFI is to PXE boot which means that packets are originating from firmware as a client. Has this case been tested or is this a known issue? Thanks, Eugene
ARP.PATCH
Description: ARP.PATCH
------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
