Syslinux - Nov 2013 - syslinux.efi pxeboot across multiple subnets

>I played around with the udp4_cb function and it looked like it was coming
back with token->Status == 512, which (if I read the spec right) isn't a
valid value. I'm not sure what is coming through on that. I changed the if
to if (token->Event) { cb_status = 0; }

Looks like the same thing with tcp.c. After I changed that callback,
everything went through and I go into the OS install.

But, if I go back to 1 subnet after those changes, it errors out with
Invalid Parameter when attempting to send the first packet.

(Sorry for the top posting.)

On Wed, Nov 13, 2013 at 4:26 PM, Jason Matthews
<jason.david.matthews at gmail.com> wrote:
>>I played around with the udp4_cb function and it looked like it was
coming
> back with token->Status == 512, which (if I read the spec right)
isn't a
> valid value. I'm not sure what is coming through on that. I changed the
if
> to if (token->Event) { cb_status = 0; }
>
> Looks like the same thing with tcp.c. After I changed that callback,
> everything went through and I go into the OS install.
>
> But, if I go back to 1 subnet after those changes, it errors out with
> Invalid Parameter when attempting to send the first packet.
>
> (Sorry for the top posting.)
I just started examining this and find it odd that the core_udp_recv()
doesn't zalloc() its token while core_udp_send()/core_udp_sendto() do.
 All three are a part of commit fe283b78 by Matt Fleming.  Should this
be made into a zalloc() rather than pushing it into the stack?  It'd
seem like it could run some stack issues plus there's no guarantee
what's in it (unless there's some stack trickery just before the calls
to core_udp_recv() )

-- 
-Gene

On Sun, Nov 24, 2013 at 6:29 AM, Gene Cumm <gene.cumm at gmail.com>
wrote:
> On Wed, Nov 13, 2013 at 4:26 PM, Jason Matthews
> <jason.david.matthews at gmail.com> wrote:
>>>I played around with the udp4_cb function and it looked like it was
coming
>> back with token->Status == 512, which (if I read the spec right)
isn't a
>> valid value. I'm not sure what is coming through on that. I changed
the if
>> to if (token->Event) { cb_status = 0; }
>>
>> Looks like the same thing with tcp.c. After I changed that callback,
>> everything went through and I go into the OS install.
>>
>> But, if I go back to 1 subnet after those changes, it errors out with
>> Invalid Parameter when attempting to send the first packet.
>>
>> (Sorry for the top posting.)
>
> I just started examining this and find it odd that the core_udp_recv()
> doesn't zalloc() its token while core_udp_send()/core_udp_sendto() do.
>  All three are a part of commit fe283b78 by Matt Fleming.  Should this
> be made into a zalloc() rather than pushing it into the stack?  It'd
> seem like it could run some stack issues plus there's no guarantee
> what's in it (unless there's some stack trickery just before the
calls
> to core_udp_recv() )
Aside from the core_udp_recv() question, I've got another patch but
just need to clean it a little.

-- 
-Gene

On 11/24/2013 03:29 AM, Gene Cumm wrote:
>>
>> (Sorry for the top posting.)
> 
> I just started examining this and find it odd that the core_udp_recv()
> doesn't zalloc() its token while core_udp_send()/core_udp_sendto() do.
>  All three are a part of commit fe283b78 by Matt Fleming.  Should this
> be made into a zalloc() rather than pushing it into the stack?  It'd
> seem like it could run some stack issues plus there's no guarantee
> what's in it (unless there's some stack trickery just before the
calls
> to core_udp_recv() )
> 
As long as it doesn't need to live longer than the function it is in,
using the stack seems sensible, but there might be a good reason to
memset() it to zero.

I have to admit that the use of zalloc() in some places and on the stack
in others looks odd.  It is worth noting that the Syslinux malloc
implementation is rather slow.

	-hpa