Syslinux - Jul 2015 - [PATCH] Updated udp.c to use real client ip and subnetmask values if on local subnet

>>>
 I have seen the capture but I couldn't find anything wrong there;
 When you get a minute please assemble the rest of info;
 so far it's not clear what the symptoms really are.
<<<

The IP4 config data struct contents from core_udp_open is included below. 
When UseDefaultAddress is TRUE, it passes 0.0.0.0 for StationAddress and 
NetMask. core_udp_open calls core_udp_configure which calls 
efiip4configure (BIOS). BIOS validates SA and NM but special-cases both 
null to allow for proxy. BIOS tries to find the GUID to configure but 
fails and returns EFI_UNSUPPORTED error, EFIERR(3).

Then core_udp_sendto attempts to send the packet even though it was never 
configured. It does not check for problems, instead relying on the 
core_udp_recv to timeout. It retries based on the timeout table but before 
completing all of the retries, the watchdog timer triggers a reset.

So the net is that no udp packets hit the wire once syslinux starts 
executing. I was able to circumvent this by setting UseDefaultAddress to 
FALSE and populating SA and NM to correct values. Is there a better/more 
global approach if the SA/NM values are NULL?

The other question I have is how should we handle a fail from the 
configure? Thoughts?
>>>
 >>>
 but I am headed out the door to see
 if a doctor can keep me alive... (I think I have bubonic plague.)
 <<<

 I hope our health is OK
<<<

Thanks! A bad bout of bronchitis but with a full pharmacy of meds, I'm 
doing much better. Better living through chemistry.


ip4 config data contents: 
This is a mem copy from an Arium so the first column is the address, 
second and third are 64 bit contents and the fourth is ASCII. The 
RemoteAddress is 10.39.31.250 (FA1F270A on the second row). Both SA and NM 
are 0. 

00000000C78CEF50L 0000400000000100 0000000000000000 ..... at ..........
00000000C78CEF60L 0000000000000001 FA1F270A06290000 ..........)..'.z
00000000C78CEF70L 0000000000000045 00000000C78CF003 E........p.G....

ip4 handle that results in EFI_UNSUPPORTED:

00000000C99E2318L 000000006C646E68 00000000C8E1DBA0 hndl.... [aH....
00000000C99E2328L 00000000C9BC07A0 00000000C8E0C828  .<I....(H`H....
00000000C99E2338L 00000000C99DDF28 000000000000780A (_.I.....x......
00000000C99E2348L 0000000000000401 000000586C617470 ........ptalX...
00000000C99E2358L 7E840FE73B45017E 0002D68E0F000002 ~.E;g..~.....V..
00000000C99E2368L 44227E03FC834100 850FE53B45046E8D .A.|.~"D.n.E;e..
00000000C99E2378L 0FED8548000002C3 0000005030646870 C...H.m.phd0P...
00000000C99E2388L AFAFAFAF00000004 AFAFAFAFAFAFAFAF ....////////////

Any questions or additional details needed, just ask.


Jeff Sloan

On Tue, Jul 14, 2015 at 4:26 PM,  <jeff_sloan at selinc.com>
wrote:
>>>>
> I have seen the capture but I couldn't find anything wrong there;
> When you get a minute please assemble the rest of info;
> so far it's not clear what the symptoms really are.
> <<<
>
> The IP4 config data struct contents from core_udp_open is included below.
> When UseDefaultAddress is TRUE, it passes 0.0.0.0 for StationAddress and
> NetMask. core_udp_open calls core_udp_configure which calls efiip4configure
> (BIOS). BIOS validates SA and NM but special-cases both null to allow for
> proxy. BIOS tries to find the GUID to configure but fails and returns
> EFI_UNSUPPORTED error, EFIERR(3).
Ahh! I think I have a better solution then.

A pedantic note: BIOS implies non-EFI mode.  Firmware is a more correct term.

What uEFI specification version does your system claim to be compliant
with?  I'd like to read over the spec for the call to verify things.
> Then core_udp_sendto attempts to send the packet even though it was never
> configured. It does not check for problems, instead relying on the
I see why.
> core_udp_recv to timeout. It retries based on the timeout table but before
> completing all of the retries, the watchdog timer triggers a reset.
>
> So the net is that no udp packets hit the wire once syslinux starts
> executing. I was able to circumvent this by setting UseDefaultAddress to
> FALSE and populating SA and NM to correct values. Is there a better/more
> global approach if the SA/NM values are NULL?
>
> The other question I have is how should we handle a fail from the
configure?
> Thoughts?
>
>>>>
>  >>>
> but I am headed out the door to see
> if a doctor can keep me alive... (I think I have bubonic plague.)
> <<<
>
> I hope our health is OK
> <<<
>
> Thanks! A bad bout of bronchitis but with a full pharmacy of meds, I'm
doing
> much better. Better living through chemistry.
>
>
> ip4 config data contents:
> This is a mem copy from an Arium so the first column is the address, second
> and third are 64 bit contents and the fourth is ASCII. The RemoteAddress is
> 10.39.31.250 (FA1F270A on the second row). Both SA and NM are 0.
>
> 00000000C78CEF50L 0000400000000100 0000000000000000 ..... at ..........
> 00000000C78CEF60L 0000000000000001 FA1F270A06290000 ..........)..'.z
> 00000000C78CEF70L 0000000000000045 00000000C78CF003 E........p.G....
>
> ip4 handle that results in EFI_UNSUPPORTED:
>
> 00000000C99E2318L 000000006C646E68 00000000C8E1DBA0 hndl.... [aH....
> 00000000C99E2328L 00000000C9BC07A0 00000000C8E0C828  .<I....(H`H....
> 00000000C99E2338L 00000000C99DDF28 000000000000780A (_.I.....x......
> 00000000C99E2348L 0000000000000401 000000586C617470 ........ptalX...
> 00000000C99E2358L 7E840FE73B45017E 0002D68E0F000002 ~.E;g..~.....V..
> 00000000C99E2368L 44227E03FC834100 850FE53B45046E8D .A.|.~"D.n.E;e..
> 00000000C99E2378L 0FED8548000002C3 0000005030646870 C...H.m.phd0P...
> 00000000C99E2388L AFAFAFAF00000004 AFAFAFAFAFAFAFAF ....////////////
>
> Any questions or additional details needed, just ask.
On Wed, Jul 8, 2015 at 7:34 PM, Gene Cumm <gene.cumm at gmail.com> wrote:
> Have you tested this with accessing both subnet-local and
> subnet-remote servers (ie, TFTP servers)?
Reasoning is simple: if your clients can't deal with UseDefaultAddress
for subnet-remote TFTP, then you can NOT use subnet-locality to
indicate whether UseDefaultAddress is "broken".  Loading only 1 file
from a subnet-remote TFTP after booting from a subnet-local TFTP will
suffice.

-- 
-Gene

Guys, I've been reading the email correspondence syslinux for approximately
3 months, from when I subscribed to the email notices approximately. I've
not missed a single E-Mail, and not one has gone un-read.

I must say that I've learned an incredible amount and only hope to learn
more. Keep up the good work.

I have been prowling your email correspondence for the FOG Project. You may
find them here: https://fogproject.org/  and their forums are located here:
https://forums.fogproject.org/

I'm looking at how syslinux's future can play/how it plays now with FOG.
I'm wondering if this technology can support WiFi based communications as
the Etherboot project does.

Don't feel compelled to answer now, I'll continue to follow your email
chain into the future for a year or so. You may respond at any point during
that time.

Thanks,
Wayne
Workman



On Fri, Jul 17, 2015 at 6:44 PM, Gene Cumm via Syslinux <syslinux at
zytor.com>
wrote:
> On Tue, Jul 14, 2015 at 4:26 PM,  <jeff_sloan at selinc.com> wrote:
> >>>>
> > I have seen the capture but I couldn't find anything wrong there;
> > When you get a minute please assemble the rest of info;
> > so far it's not clear what the symptoms really are.
> > <<<
> >
> > The IP4 config data struct contents from core_udp_open is included
below.
> > When UseDefaultAddress is TRUE, it passes 0.0.0.0 for StationAddress
and
> > NetMask. core_udp_open calls core_udp_configure which calls
> efiip4configure
> > (BIOS). BIOS validates SA and NM but special-cases both null to allow
for
> > proxy. BIOS tries to find the GUID to configure but fails and returns
> > EFI_UNSUPPORTED error, EFIERR(3).
>
> Ahh! I think I have a better solution then.
>
> A pedantic note: BIOS implies non-EFI mode.  Firmware is a more correct
> term.
>
> What uEFI specification version does your system claim to be compliant
> with?  I'd like to read over the spec for the call to verify things.
>
> > Then core_udp_sendto attempts to send the packet even though it was
never
> > configured. It does not check for problems, instead relying on the
>
> I see why.
>
> > core_udp_recv to timeout. It retries based on the timeout table but
> before
> > completing all of the retries, the watchdog timer triggers a reset.
> >
> > So the net is that no udp packets hit the wire once syslinux starts
> > executing. I was able to circumvent this by setting UseDefaultAddress
to
> > FALSE and populating SA and NM to correct values. Is there a
better/more
> > global approach if the SA/NM values are NULL?
> >
> > The other question I have is how should we handle a fail from the
> configure?
> > Thoughts?
> >
> >>>>
> >  >>>
> > but I am headed out the door to see
> > if a doctor can keep me alive... (I think I have bubonic plague.)
> > <<<
> >
> > I hope our health is OK
> > <<<
> >
> > Thanks! A bad bout of bronchitis but with a full pharmacy of meds,
I'm
> doing
> > much better. Better living through chemistry.
> >
> >
> > ip4 config data contents:
> > This is a mem copy from an Arium so the first column is the address,
> second
> > and third are 64 bit contents and the fourth is ASCII. The
RemoteAddress
> is
> > 10.39.31.250 (FA1F270A on the second row). Both SA and NM are 0.
> >
> > 00000000C78CEF50L 0000400000000100 0000000000000000 ..... at
..........
> > 00000000C78CEF60L 0000000000000001 FA1F270A06290000
..........)..'.z
> > 00000000C78CEF70L 0000000000000045 00000000C78CF003 E........p.G....
> >
> > ip4 handle that results in EFI_UNSUPPORTED:
> >
> > 00000000C99E2318L 000000006C646E68 00000000C8E1DBA0 hndl.... [aH....
> > 00000000C99E2328L 00000000C9BC07A0 00000000C8E0C828 
.<I....(H`H....
> > 00000000C99E2338L 00000000C99DDF28 000000000000780A (_.I.....x......
> > 00000000C99E2348L 0000000000000401 000000586C617470 ........ptalX...
> > 00000000C99E2358L 7E840FE73B45017E 0002D68E0F000002 ~.E;g..~.....V..
> > 00000000C99E2368L 44227E03FC834100 850FE53B45046E8D
.A.|.~"D.n.E;e..
> > 00000000C99E2378L 0FED8548000002C3 0000005030646870 C...H.m.phd0P...
> > 00000000C99E2388L AFAFAFAF00000004 AFAFAFAFAFAFAFAF ....////////////
> >
> > Any questions or additional details needed, just ask.
>
> On Wed, Jul 8, 2015 at 7:34 PM, Gene Cumm <gene.cumm at gmail.com>
wrote:
>
> > Have you tested this with accessing both subnet-local and
> > subnet-remote servers (ie, TFTP servers)?
>
> Reasoning is simple: if your clients can't deal with UseDefaultAddress
> for subnet-remote TFTP, then you can NOT use subnet-locality to
> indicate whether UseDefaultAddress is "broken".  Loading only 1
file
> from a subnet-remote TFTP after booting from a subnet-local TFTP will
> suffice.
>
> --
> -Gene
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>

>>>>
 The IP4 config data struct contents from core_udp_open
 is included below. When UseDefaultAddress is TRUE, it passes
 0.0.0.0 for StationAddress and NetMask. core_udp_open calls
 core_udp_configure which calls efiip4configure (BIOS). BIOS validates SA and NM
but
 special-cases both null to allow for proxy. BIOS tries to find the GUID to
 configure but fails and returns EFI_UNSUPPORTED error, EFIERR(3).
 
 
 
 Then core_udp_sendto attempts to send the packet even
 though it was never configured. It does not check for problems, instead
 relying on the core_udp_recv to timeout. It retries based on
 the timeout table but before completing all of the retries, the watchdog
 timer triggers a reset.
 
 
 
 So the net is that no udp packets hit the wire once
 syslinux starts executing. I was able to circumvent this by setting
UseDefaultAddress
 to FALSE and populating SA and NM to correct values. Is
 there a better/more global approach if the SA/NM values are NULL?
 
 The other question I have is how should we handle
 a fail from the configure? Thoughts?

<<<<

Then this means that when you use a "DHCP relay" your particular
firmware is able to retrieve
syslinux.efi but when creating an UDPv4 child when using UseDefaultAddress=1
the interface does not have valid IP address and mask (both NULL)

1) Are you sure you are really creating a child corresponding to the NIC that
booted syslinux.efi??
this is specially important if you have a multi-NIC client.

2) how about your client firmware? is it updated? does this happen with several
clients?

Best,
Patrick

>>> 
 What uEFI specification version does your system claim to be compliant
 with?? I'd like to read over the spec for the call to verify things.
 -- 
 -Gene
<<<

I've tried to find the relationship between UseDefaultAddress and DHP relays
but I couldn't find anything. The use of DHCP relays should be really
transparent...

Best,
Patrick