Digging more, loadfile("192.0.2.1::pxe.0", &file.data,
&file.size),
queries DNS, which sounds like it doesn't follow the same call path as
a COM32 calling pxe_dns(). If the DNS won't resolve the IP, things
won't load properly. pxechn.c32 sets sname in the intended packet to
"192.0.2.1" which may be confusing something.
More debugging needed.
--
-Gene
On Sat, Jul 13, 2013 at 10:34 AM, Gene Cumm <gene.cumm at gmail.com> wrote:> Digging more, loadfile("192.0.2.1::pxe.0", &file.data, &file.size), > queries DNS, which sounds like it doesn't follow the same call path as > a COM32 calling pxe_dns(). If the DNS won't resolve the IP, things > won't load properly. pxechn.c32 sets sname in the intended packet to > "192.0.2.1" which may be confusing something. > > More debugging needed. > > -- > -Genecore/legacynet/dns_resolv.c is quite different and doesn't bother testing quads first. Matt/HPA: should this be patched or somehow checked to see if it can be factored away? I've got a crude patch that I can clean up. -- -Gene
On Sat, Jul 13, 2013 at 5:30 PM, Gene Cumm <gene.cumm at gmail.com> wrote:> On Sat, Jul 13, 2013 at 10:34 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> Digging more, loadfile("192.0.2.1::pxe.0", &file.data, &file.size), >> queries DNS, which sounds like it doesn't follow the same call path as >> a COM32 calling pxe_dns(). If the DNS won't resolve the IP, things >> won't load properly. pxechn.c32 sets sname in the intended packet to >> "192.0.2.1" which may be confusing something. >> >> More debugging needed. >> >> -- >> -Gene > > core/legacynet/dns_resolv.c is quite different and doesn't bother > testing quads first. > > Matt/HPA: should this be patched or somehow checked to see if it can > be factored away? I've got a crude patch that I can clean up. > > -- > -GeneAlso, com32/lib/syslinux.c:pxe_dns() and core/pxe/dnsresolv.c:dns_resolv() (and now possibly core/legacynet/dns_resolv.c:dns_resolv()) both attempt to parse a dotted quad (duplicating effort that could likely be refactored). -- -Gene