On 15/05/16 14:39, Dreamcat4 wrote:
> Hi,
> Tried the 2.76rc2 this morning. Seems fine / OK for me.
>
Great. Thanks for that.
Cheers,
Simon.
> Have uploaded the binary here again (same place as before):
>
> https://dl.bintray.com/dreamcat4/linux/dnsmasq/
>
>
>
> On Sun, May 15, 2016 at 9
On 15/05/16 09:03, Michael Kuron wrote:
> Hi Simon,
>
> thanks, it’s working fine for me now. Before releasing 2.76, it would
> be good if more people could test this on actual hardware. Also,
> there’s one more item that needs to go into the release notes: we now
> redirect all clients to port 40
Hi,
Tried the 2.76rc2 this morning. Seems fine / OK for me.
Have uploaded the binary here again (same place as before):
https://dl.bintray.com/dreamcat4/linux/dnsmasq/
On Sun, May 15, 2016 at 9:03 AM, Michael Kuron <
michael-li...@physcip.uni-stuttgart.de> wrote:
> Hi Simon,
>
> thanks, it’s
Hi Simon,
thanks, it’s working fine for me now. Before releasing 2.76, it would be good
if more people could test this on actual hardware.
Also, there’s one more item that needs to go into the release notes: we now
redirect all clients to port 4011, including the BIOS clients. This is a change
Great, thanks. I've applied your patch and made a further change:
instead of changing the filename behaviour based on CSA, it looks at the
filename provided. If it has a suffix (strictly, if it includes a '.'
character) then the filename is used as-is. Otherwise it as the layer
added as suffix.
Th
I have included a patch below that makes essentially two modifications to get
PXE working with the UEFI firmware in VMware.
- It only appends the layer number to the file name on BIOS x86.
- It always redirects the client to port 4011. To do that, only the siaddr is
set and neither a boot file no
On 11/05/16 07:04, Jarek Polok wrote:
> On 05/10/2016 06:44 PM, Simon Kelley wrote:
> The full up to date list of arches seems to be there:
>
>
> http://www.ietf.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#processor-architecture
>
>
> (but only types 0 to 9 are defined in an rfc (r
On 11/05/16 07:04, Jarek Polok wrote:
> On 05/10/2016 06:44 PM, Simon Kelley wrote:
>> I just pushed my take on this to git. It's untested, and covers what I
>> think are the correct choices so far. Please could you all test?
>>
>> I picked
>>
>> 1) .0 in workaround mode, to match all other situati
On 05/10/2016 06:44 PM, Simon Kelley wrote:
I just pushed my take on this to git. It's untested, and covers what I
think are the correct choices so far. Please could you all test?
I picked
1) .0 in workaround mode, to match all other situations.
If I understand well then:
pxe-service=..., /p
I just pushed my take on this to git. It's untested, and covers what I
think are the correct choices so far. Please could you all test?
I picked
1) .0 in workaround mode, to match all other situations.
2) Workaround in non-proxy mode too.
3) Workaround engaged for CAS 6,7,8,9 only.
4) sname filed
Hi
On 05/10/2016 04:55 PM, Simon Kelley wrote:
Lots of good info. Thanks everybody. Some more queries.
First, I'm minded to go with Michael's choice for "enabling"
workarounds; ie do what's needed to make things work with buggy PXe
menu's when there's exactly one relevant menu entry.
OK, so
Lots of good info. Thanks everybody. Some more queries.
First, I'm minded to go with Michael's choice for "enabling"
workarounds; ie do what's needed to make things work with buggy PXe
menu's when there's exactly one relevant menu entry.
Second,
.0 vs. .efi
What's not been mentioned here is th
> - I think that this is just a workaround (because what
> dnsmasq implements should be working for PXE/UEFI ...)
> and it may not be needed in the future .. so kind more 'elegant' to
> implement it this way (option could be called 'pxe-menu-workaround'
> perhaps ?
This workaround will be req
Hello all, (and sorry for top-posting, but trying to catch up with this
thread)
Since I believe that you already described what I had in mind in my
version of the patch ;-) I'll like to just add few comments on remaining
points:
Simon:
yes of course that would be possible to skip the option
> The difference between Michael's patch and Jarek's seems to be that
> Michael's works automatically when there is precisely one valid boot
> service line, but Jarek's needs explicit configuration. What situation
> does Jarek's approach cover, that Michael's doesn’t?
I’ve also been wondering abou
I don't think that doing bug work-around behavior automagically is a
good idea. If it is required to do non-standard stuff, that should be
explicit.
The difference between Michael's patch and Jarek's seems to be that
Michael's works automatically when there is precisely one valid boot
service line
On Sun, May 8, 2016 at 3:41 PM, wrote:
> how about going the other way... reverse the logic so that those two are
> skipped all the time... then only if they are needed, add an option to
> enable them...
>
> pxe-add-menu=X86-64_EFI
> pxe-add-menu=BC_EFI
>
Yeah that is not an unwelcome sugges
On 05/08/2016 06:52 AM, Dreamcat4 wrote:
But it is bad for each UEFI pc users going forwards to know to need to
manually specify:
pxe-skip-menu=X86-64_EFI
pxe-skip-menu=BC_EFI
Every time around. Because that is nearly everybody going forwards. How to
solve? Can we then make the option logic wor
On Sat, May 7, 2016 at 9:49 PM, Simon Kelley
wrote:
> On 06/05/16 12:58, Jaroslaw Polok wrote:
> > Hi
> >
> > On 06/05/16 12:40, Dreamcat4 wrote:
> >
> >>
> >> Perhaps later down the line (once more people get onboard and can start
> >> using it), then this pxe UEFI mode can be improved even furt
On 06/05/16 12:58, Jaroslaw Polok wrote:
> Hi
>
> On 06/05/16 12:40, Dreamcat4 wrote:
>
>>
>> Perhaps later down the line (once more people get onboard and can start
>> using it), then this pxe UEFI mode can be improved even further. Either
>> buy some fresh eyes coming along to fix problems in i
Thanks Jarek!
Have tried your patch and switched to it in my auto builds now. Same
Bintray download URL as before:
https://dl.bintray.com/dreamcat4/linux/dnsmasq/
Re-formatted it so the patch will apply cleanly on v2.75 current release
version. Which is available here:
https://github.com/dreamc
Hi
On 06/05/16 12:40, Dreamcat4 wrote:
Perhaps later down the line (once more people get onboard and can start
using it), then this pxe UEFI mode can be improved even further. Either
buy some fresh eyes coming along to fix problems in ipxe.efi, or else
here in the dnsmasq behaviour. Or both. B
OK,
So I have 2 UEFI PCs. And today tested the patch. It worked! Very happy
about this.
I encourage other people to try it too, now the patched binary is available
from my bintray repo here:
https://dl.bintray.com/dreamcat4/linux/dnsmasq/
In coming days shall also be releasing a 'dreamcat4/pxe'
In the meantime,
Have setup an auto-builds. To make linux binary tarball of last released
version. In debian / ubunt filesystem layout.
Added with the necessary (but missing) uefi patch ^^ from Micahael
Its built here:
https://github.com/dreamcat4/docker-images/blob/master/linux-bin/Dockerfile
Hi there,
Was hit by this undocumented bug in dnsmasq today / yesterday. It took a
fair whilefor me to realize this was the cause of my problem. But now
finally here! Coming across this list, and several threads in it, Michael
has kindly posted a patch to help get PXE working for UEFI clients:
htt
25 matches
Mail list logo
