[syslinux] [PATCH] Updated udp.c to use real client ip and subnetmask values if on local subnet

[Wayne Workman]

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
>