Syslinux - Jul 2015 - [syslinux:firmware] efi: Add network support

On Thu, May 9, 2013 at 6:39 AM, syslinux-bot for Matt Fleming
<matt.fleming at intel.com> wrote:
> Commit-ID:  fe283b78c973268f2d1f0309826ceeb5c9e8978d
> Gitweb:    
http://www.syslinux.org/commit/fe283b78c973268f2d1f0309826ceeb5c9e8978d
> Author:     Matt Fleming <matt.fleming at intel.com>
> AuthorDate: Fri, 22 Mar 2013 14:54:09 +0000
> Committer:  Matt Fleming <matt.fleming at intel.com>
> CommitDate: Tue, 23 Apr 2013 15:30:17 +0100
>
> efi: Add network support
> +/*
> + * This UDP binding is configured to operate in promiscuous mode. It is
> + * only used for reading packets. It has no associated state unlike
> + * socket->net.efi.binding, which has a remote IP address and port
> + * number.
> + */
> +static struct efi_binding *udp_reader;
> +
> +/**
> + * Open a socket
> + *
> + * @param:socket, the socket to open
> + *
> + * @out: error code, 0 on success, -1 on failure
> + */
> +int core_udp_open(struct pxe_pvt_inode *socket)
> +{
> +    memset(&udata, 0, sizeof(udata));
> +    udata.AcceptPromiscuous = TRUE;
> +    udata.AcceptAnyPort = TRUE;
Why promiscuous?  That seems to want to accept it on any local address
and put the NIC into promiscuous mode, avoiding the default MAC filter
in the NIC.  This should be uncessary as we're not capturinig.
> +/**
> + * Establish a connection on an open socket
> + *
> + * @param:socket, the open socket
> + * @param:ip, the ip address
> + * @param:port, the port number, host-byte order
> + */
> +void core_udp_connect(struct pxe_pvt_inode *socket, uint32_t ip,
> +                     uint16_t port)
> +{
> +    memcpy(&udata.StationAddress, &IPInfo.myip,
sizeof(IPInfo.myip));
> +    memcpy(&udata.SubnetMask, &IPInfo.netmask,
sizeof(IPInfo.netmask));
> +    memcpy(&udata.RemoteAddress, &ip, sizeof(ip));
> +    udata.RemotePort = port;
> +    udata.AcceptPromiscuous = TRUE;
> +
Looking at UEFI Spec v2.5 (same wording since the oldest 2.0 I have)
for EFI_UDP4_CONFIG_DATA, I could see now why an EFI implementer might
misinterpret the language and say that UseDefaultAddress is broken for
transmit even though my interpretation is that it will work for
transmit but is ignored for receive filtering.

-- 
-Gene

On Sat, 2015-07-18 at 07:43 -0400, Gene Cumm wrote:
> On Thu, May 9, 2013 at 6:39 AM, syslinux-bot for Matt Fleming
> <matt.fleming at intel.com> wrote:
> > Commit-ID:  fe283b78c973268f2d1f0309826ceeb5c9e8978d
> > Gitweb:    
http://www.syslinux.org/commit/fe283b78c973268f2d1f0309826ceeb5c9e8978d
> > Author:     Matt Fleming <matt.fleming at intel.com>
> > AuthorDate: Fri, 22 Mar 2013 14:54:09 +0000
> > Committer:  Matt Fleming <matt.fleming at intel.com>
> > CommitDate: Tue, 23 Apr 2013 15:30:17 +0100
> >
> > efi: Add network support
> 
> > +/*
> > + * This UDP binding is configured to operate in promiscuous mode. It
is
> > + * only used for reading packets. It has no associated state unlike
> > + * socket->net.efi.binding, which has a remote IP address and port
> > + * number.
> > + */
> > +static struct efi_binding *udp_reader;
> > +
> > +/**
> > + * Open a socket
> > + *
> > + * @param:socket, the socket to open
> > + *
> > + * @out: error code, 0 on success, -1 on failure
> > + */
> > +int core_udp_open(struct pxe_pvt_inode *socket)
> > +{
> 
> > +    memset(&udata, 0, sizeof(udata));
> > +    udata.AcceptPromiscuous = TRUE;
> > +    udata.AcceptAnyPort = TRUE;
> 
> Why promiscuous?  That seems to want to accept it on any local address
> and put the NIC into promiscuous mode, avoiding the default MAC filter
> in the NIC.  This should be uncessary as we're not capturinig.
If I remember correctly, this was required for TFTP boot because
otherwise it's impossible to accept DHCP packets when we have no IP
address assigned. I'm not suggesting that is the intention of the
AcceptPromiscuous flag, only that it was the observed behaviour on my
test machine.

Then again, this was over 2 years ago and on a development platform.
This may not be required anymore.
> > +/**
> > + * Establish a connection on an open socket
> > + *
> > + * @param:socket, the open socket
> > + * @param:ip, the ip address
> > + * @param:port, the port number, host-byte order
> > + */
> > +void core_udp_connect(struct pxe_pvt_inode *socket, uint32_t ip,
> > +                     uint16_t port)
> > +{
> 
> > +    memcpy(&udata.StationAddress, &IPInfo.myip,
sizeof(IPInfo.myip));
> > +    memcpy(&udata.SubnetMask, &IPInfo.netmask,
sizeof(IPInfo.netmask));
> > +    memcpy(&udata.RemoteAddress, &ip, sizeof(ip));
> > +    udata.RemotePort = port;
> > +    udata.AcceptPromiscuous = TRUE;
> > +
> 
> Looking at UEFI Spec v2.5 (same wording since the oldest 2.0 I have)
> for EFI_UDP4_CONFIG_DATA, I could see now why an EFI implementer might
> misinterpret the language and say that UseDefaultAddress is broken for
> transmit even though my interpretation is that it will work for
> transmit but is ignored for receive filtering.
As with all things related to UEFI there's a certain amount of "forget
what the spec says and just program to whatever the firmware *does*".

I suspect this is one of those cases.

I have vague recollections of trying to use DefaultAddress and it not
working as expected for TFTP with the machine I was testing on at the
time.

>>>
 > 
 > Why promiscuous?? That seems to want to accept it on any local address
 > and put the NIC into promiscuous mode, avoiding the default MAC filter
 > in the NIC.? This should be uncessary as we're not capturinig.
 
 If I remember correctly, this was required for TFTP boot because
 otherwise it's impossible to accept DHCP packets when we have no IP
 address assigned. I'm not suggesting that is the intention of the
AcceptPromiscuous
 flag, only that it was the observed behaviour on my test machine.
 <<<

That's probably required by the DHCP layer within the FW,
but whenever there's a TFTP transfer (either triggered by the FW or NBP) 
sure we must already have a defined IP then it shouldn't be necessary.

>>>
 Then again, this was over 2 years ago and on a development platform.
 This may not be required anymore.

 As with all things related to UEFI there's a certain amount of "forget
what the spec says and just
 program to whatever the firmware *does*".
	
Matt Fleming
<<<

I agree; UEFI is (still) a moving target.
 
 
Best,
Patrick