Re: [Dnsmasq-discuss] [PATCH] Remove empty tailing lines

2020-01-28 Thread Geert Stappers
On Thu, Dec 12, 2019 at 10:01:59PM +0100, Geert Stappers wrote:
> On Sun, Oct 13, 2019 at 11:37:15PM +0200, Geert Stappers wrote:
> > From: Geert Stappers 
> > 
> > Several .c files have empty lines at their end.
> > Because there is no need to keep them, are they now removed.
> 
> Find attached the same patch.
> 
> The purpose of this patch retransmit is getting it reviewed.
> 
> 
> Regards
> Geert Stappers
> 

$ sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
135 3653093
$ sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
148 3853179
$ sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
155 3973198
$ sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
158 4033225
$ sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
161 4083270
$ sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
162 4093272
$ sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
163 4113276
$ sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
163 4113276
$ sed --in-place -e '${/^ *$/d;}' src/*.c ; git diff | wc
163 4113276
$ 


> >From 372bed26359ec62f2746a81d08f54133a89c6491 Mon Sep 17 00:00:00 2001
> From: Geert Stappers 
> Date: Sun, 13 Oct 2019 23:05:42 +0200
> Subject: [PATCH 1/4] Remove empty tailing lines
> 
> Several .c files have empty lines at their end.
> Because there is no need to keep them, are they now removed.
> ---
>  src/arp.c   | 2 --
>  src/auth.c  | 3 ---
>  src/blockdata.c | 1 -
>  src/bpf.c   | 2 --
>  src/cache.c | 2 --
>  src/conntrack.c | 3 ---
>  src/dhcp6.c | 2 --
>  src/dnsmasq.c   | 2 --
>  src/forward.c   | 5 -
>  src/helper.c| 3 ---
>  src/inotify.c   | 1 -
>  src/lease.c | 4 
>  src/netlink.c   | 2 --
>  src/network.c   | 5 -
>  src/rfc2131.c   | 7 ---
>  15 files changed, 44 deletions(-)
> 
> diff --git a/src/arp.c b/src/arp.c
> index 6cfe014..66ecfb5 100644
> --- a/src/arp.c
> +++ b/src/arp.c
> @@ -230,5 +230,3 @@ int do_arp_script_run(void)
>  
>return 0;
>  }
> -
> -
> diff --git a/src/auth.c b/src/auth.c
> index 854af0d..f12ce4d 100644
> --- a/src/auth.c
> +++ b/src/auth.c
> @@ -863,6 +863,3 @@ size_t answer_auth(struct dns_header *header, char 
> *limit, size_t qlen, time_t n
>  }
>
>  #endif  
> -  
> -
> -
> diff --git a/src/blockdata.c b/src/blockdata.c
> index e6e625f..89a049d 100644
> --- a/src/blockdata.c
> +++ b/src/blockdata.c
> @@ -174,4 +174,3 @@ struct blockdata *blockdata_read(int fd, size_t len)
>  {
>return blockdata_alloc_real(fd, NULL, len);
>  }
> -
> diff --git a/src/bpf.c b/src/bpf.c
> index 982318d..6561f1a 100644
> --- a/src/bpf.c
> +++ b/src/bpf.c
> @@ -440,5 +440,3 @@ void route_sock(void)
>  }
>  
>  #endif /* HAVE_BSD_NETWORK */
> -
> -
> diff --git a/src/cache.c b/src/cache.c
> index 6168073..a360469 100644
> --- a/src/cache.c
> +++ b/src/cache.c
> @@ -1967,5 +1967,3 @@ void log_query(unsigned int flags, char *name, union 
> all_addr *addr, char *arg)
>else
>  my_syslog(LOG_INFO, "%s %s %s %s", source, name, verb, dest);
>  }
> -
> - 
> diff --git a/src/conntrack.c b/src/conntrack.c
> index d41de54..a11fedd 100644
> --- a/src/conntrack.c
> +++ b/src/conntrack.c
> @@ -83,6 +83,3 @@ static int callback(enum nf_conntrack_msg_type type, struct 
> nf_conntrack *ct, vo
>  }
>  
>  #endif
> -  
> -
> -
> diff --git a/src/dhcp6.c b/src/dhcp6.c
> index ce682db..1a2085d 100644
> --- a/src/dhcp6.c
> +++ b/src/dhcp6.c
> @@ -827,5 +827,3 @@ void dhcp_construct_contexts(time_t now)
>  }
>  
>  #endif
> -
> -
> diff --git a/src/dnsmasq.c b/src/dnsmasq.c
> index 7842538..b635413 100644
> --- a/src/dnsmasq.c
> +++ b/src/dnsmasq.c
> @@ -2082,5 +2082,3 @@ int delay_dhcp(time_t start, int sec, int fd, uint32_t 
> addr, unsigned short id)
>return 0;
>  }
>  #endif
> -
> - 
> diff --git a/src/forward.c b/src/forward.c
> index e4745a3..f488b90 100644
> --- a/src/forward.c
> +++ b/src/forward.c
> @@ -2405,8 +2405,3 @@ static unsigned short get_id(void)
>
>return ret;
>  }
> -
> -
> -
> -
> -
> diff --git a/src/helper.c b/src/helper.c
> index 62ac9cf..97f0dfb 100644
> --- a/src/helper.c
> +++ b/src/helper.c
> @@ -887,6 +887,3 @@ void helper_write(void)
>  }
>  
>  #endif
> -
> -
> -
> diff --git a/src/inotify.c b/src/inotify.c
> index 7107833..7d9c56b 100644
> --- a/src/inotify.c
> +++ b/src/inotify.c
> @@ -295,4 +295,3 @@ int inotify_check(time_t now)
>  }
>  
>  #endif  /* INOTIFY */
> -  
> diff --git a/src/lease.c b/src/lease.c
> index 081d90e..58bd73e 100644
> --- a/src/lease.c
> +++ b/src/lease.c
> @@ -1201,7 +1201,3 @@ void lease_add_extradata(struct dhcp_lease *lease, 
> unsigned char *data, unsigned
>  #endif
>  
>  #endif
> -   
> -
> -  
> -
> diff --git a/src/netlink.c b/src/netlink.c
> index eaa772d..91913ac 100644
> --- a/src/netlink.c
> +++ b/src/netlink.c
> @@ -367,5 +367,3 @@ static void nl_async(struct nlmsghdr *h)
>  queue_event(EVENT_NEWADDR);
>  }

Re: [Dnsmasq-discuss] pxe-service line for UEFI system?

2020-01-28 Thread Michal Zatloukal
On Wed, 22 Jan 2020 at 21:43, Geert Stappers  wrote:
>...
>
> FWIW
> Over here is "PXE service" not used.  I have no idea what I might be
> missing. My reason for involvement in this thread is finding what use
> case O.P. has for dnsmasq. Finding out if it can improve my use case,
> finding out if it can improve dnsmasq (which also benefits me).
>
At this point its mostly curiosity - I am migrating from an older
pxelinux, BIOS-only setup to iPXE for BIOS and UEFI, with possible
expansion into direct-booting specific clients like a Raspberry Pi. I
wanted to keep the option of booting into the old setup. Also, having
read the documentation, it should be possible to use dnsmasq to
provide PXE boot service independently of the DHCP server in the
network, which would be particularly useful for making an appliance-like
setup that is dropped into the network and provides tools like clonezilla,
memtest, etc. I haven't tried that mode yet.

> > > The idea of it is getting a "shared problem". And from
> > > a shared problem to get to a shared solution.
> >
> > A shared problem: Make UEFI PXE client display 2 boot options - one
> > for an existing boot image, and one to exit PXE (boot from disk,
> > etc.).
>
> My approach is default boot from disk and netbooting for a (re)install.
>
> Back to "pxe service".  It is a server-client-combo-issue.
> Here on this mailinglist is dnsmasq the only common factor.
> Dnsmasq is at server side. The explain the server-client-combo-issue
> needs the client side extra care.  So tell about client site.
> That includes the risk of losing audience here due "I don't have such
> clients". Increase audience numbers by "The seen behaviour can be
> reproduced with this libre virtualisation platform".

Oh, so you can't induce the issue/reproduce the preconditions. Now
it's clear to me :)

Sorry, I'm not keeping up with libre VM solutions, so I'm not sure
which, if any, can do PXE UEFI boot. I'm using vmware (Fusion, HW
version 14) to test this. Google finds this article [1], which
suggests it is possible to do in KVM. VirtualBox which I have
installed, does not support network boot in UEFI mode. If you have
UEFI hardware and don't mind using it for this, I would suggest using
the three-service config and seeing if that works correctly. I can
send a packet capture if needed.
I _think_ you should be able to replicate at least the PXE-menu part
of the issue with just a config for dhclient [2] - haven't tested this, as
§it requires the normal dhclient instance to be disabled.

Cheers,
MZ

> Groeten
> Geert Stappers
> --
> Leven en laten leven
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[1] 
https://eatpeppershothot.blogspot.com/2016/07/enable-pxe-netboot-in-kvm-guests-for.html
[2]
# dhclient.conf:
send vendor-class-identifier "PXEClient:Arch:7:UNDI:003016";
option client-system-architecture code 93 = unsigned integer 16;
send client-system-architecture 7;

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss