ra...@frontiernet.net wrote:
Ive puged all the history in the interest of brevity:
This should be my final post on using gPXE with dnsmasq
First, the gPXE peop[e claim that there is a bug in dnsmasq that appends
an extra chaaracter hex(00) at the end of all dhcp supplied option values.
a snooped dhcpoffer packet with wireshark confirms the asserstion by the
gPXE people.
The fact is that a 13 character bootfile name is a legth 14 option in
the dhcpoffer packet
I'm not sure if its a bug in dnsmasq or not, as I don't know the RFCs
well enough to make a judgement. But the gPXE people seemed convinced
that dnsmasq was somehow "wrong" in this.
Ignore my previous post: the "microsoft detector" is irrelevant here;
this comment from the code tells all.
/* See if we can send the boot stuff as options.
To do this we need a requested option list, BOOTP
and very old DHCP clients won't have this, we also
provide an manual option to disable it.
Some PXE ROMs have bugs (surprise!) and need zero-terminated
names, so we always send those. */
I think I still own the PXE ROM which demonstrates the bug.
This indicates a possible workaround: use
--dhcp-no-override
which stops dnsmasq from putting the filename is an option and always
leaves it in the dedicated filename field, where termination is not an
issue.
I'm confused about the bootfilename with a space at the end. They're
using space as an end marker? Note that if you want a space at the end
of your filename, you'll probably have to use quotes.
dhcp-boot="somename "
The two DHCPdiscover packets you send are indistuishable in any released
version of dnsmasq. I'll add a facility to do it and get it to you ASAP,
holidays permitting.
Cheers,
Simon.
