date:20170430

Re: [Dnsmasq-discuss] dhcp vendor-option and grub net_pxe_extensionspath

2017-04-30 Thread Carl Karsten

woked - yay.

dhcp-host=00:26:9e:03:9d:e5,set:negk,negk
dhcp-option-force=tag:negk,209,"partman-auto/disk=/dev/sda"

# grub/grub.cfg
net_get_dhcp_option appends ${net_default_interface} 209 string

menuentry "Install Ubuntu preseed" {
set gfxpayload=keep
linux /ubuntu-installer/amd64/linux gfxpayload=800x600x16,800x600 ---
auto=true url=dc10b DEBCONF_DEBUG=5 tasks="" hostname=
interface=${net_default_mac} ${appends}
initrd /ubuntu-installer/amd64/initrd.gz
}

~ # head /var/log/syslog
May  1 04:30:40 kernel: [0.00] Command line:
BOOT_IMAGE=/ubuntu-installer/amd64/linux gfxpayload=800x600x16,800x600 ---
auto=true url=dc10b DEBCONF_DEBUG=5 tasks= hostname=
interface=00:26:9e:03:9d:e5 partman-auto/disk=/dev/sda



On Fri, Apr 28, 2017 at 5:53 PM, Simon Kelley 
wrote:

> On 27/04/17 17:42, Carl Karsten wrote:
> > I am looking for the syntax of dhcp vendor options, and then how to
> > access them in grub-net.  I think.  maybe there is a better way.
> >
> > I pxe boot grub, which boots di (Debian Installer) and pass a preseed
> file.
> >
> > I am trying to work out a nice way to pass host specific info to di
> > example, most use:
> > partman-auto/disk="/dev/sda"
> > but one machine has an onboard ssd nvme which needs /dev/nvme0n1
> >
> > di will read values appended to the kernel boot line, so I can hard code
> > it like this:
> >
> > menuentry "Install Ubuntu preseed" {
> > set gfxpayload=keep
> > linux /ubuntu-installer/amd64/linux gfxpayload=800x600x16,800x600 ---
> > auto=true url=dc10b hostname= partman-auto/disk="/dev/nvme0n1"
> > interface=${net_default_mac}
> > initrd /ubuntu-installer/amd64/initrd.gz
> > }
> >
> > interface=${net_default_mac} - use the nic that pxe booted.
> >
> > Now I get lost in conf options and syntax.  forgive me for making stuff
> > up here, if it worked I wouldn't be asking for help.
> >
> > I am hoping for something like
> > partman-auto/disk=$(net_pxe_extensionspath/disk}
> >
> > in dnsmasq conf:
> > dhcp-host=40:8d:5c:7f:bb:90,,gator
> >
> > dhcp-option-force=host:gator,209,"disk=/dev/nvme0n1"
> >
>
> Look for "tags" in the man page, in this case, set a tag in the
> dhcp-host line (it can be the same as the hostname)
>
> dhcp-host=40:8d:5c:7f:bb:90,set:gator,gator
>
>
> and make the option conditional on that tag
>
> dhcp-option-force=tag:gator,209,"disk=/dev/nvme0n1"
>
> >
> > So yeah, how do I send random strings based on mac/hostname
> See above
>
>
> > and how do I read what was sent in grub?
>
> Set the "log-dhcp" flag in the dnsmasq configuration to get lots of
> useful information.
>
> Cheers,
>
> Simon.
>
> >
>
>
>
> > --
> > Carl K
> >
> >
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] bug:DHCP Relay not responding with DHCP OFFER.

2017-04-30 Thread Jason Kary

Hello,

The VLAN setup is pretty basic:


interface Vlan1001
  no shutdown
  mtu 9216
  no ip redirects
  ip address 10.168.101.1/24 

interface Vlan1002
  no shutdown
  mtu 9216
  no ip redirects
  ip address 10.168.102.1/24 
  ip dhcp relay address 10.168.101.20
  ip dhcp relay source-interface Vlan1002

Single host running ESXi connected to single router.

Take Care
Jason



> On Apr 28, 2017, at 5:36 PM, Simon Kelley  wrote:
> 
> On 27/04/17 22:02, Jason Kary wrote:
>> Hi Folks,
>> 
>> I have a basic setup for DHCP relay across VLANS in DNSMASQ.  
>> 
>> My configuration file looks like: 
>> 
>> 
>>bogus-priv
>>interface=ens160
>>log-dhcp
>>dhcp-range=10.168.102.100,10.168.102.150,255.255.255.0,12h
>> 
>> 
>> The client and server are running on a VMs in separate VLANS.  DHCP
>> requests appear to be coming across:
>> 
>> 
>>root@DHCP-UBUNTU-SERVER:~# tcpdump -i ens160 port 67 or port 68 -n
>>tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>decode
>>listening on ens160, link-type EN10MB (Ethernet), capture size
>>262144 bytes
>>03:58:40.966944 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP,
>>Request from 00:0c:29:65:e0:ea, length 322
>>03:58:46.487767 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP,
>>Request from 00:0c:29:65:e0:ea, length 322
>>03:58:54.424895 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP,
>>Request from 00:0c:29:65:e0:ea, length 322
>>03:59:07.795712 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP,
>>Request from 00:0c:29:65:e0:ea, length 322
>>03:59:19.196022 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP,
>>Request from 00:0c:29:65:e0:ea, length 322
>> 
>>root@DHCP-UBUNTU-SERVER:~# iptables -L
>>Chain INPUT (policy ACCEPT)
>>target prot opt source   destination
>> 
>>Chain FORWARD (policy ACCEPT)
>>target prot opt source   destination
>> 
>>Chain OUTPUT (policy ACCEPT)
>>target prot opt source   destination
>>root@DHCP-UBUNTU-SERVER:~#
>> 
>> 
>> The syslog log indicates the DCHP OFFERS are ‘supposed’ to be going out
>> however nothing is seen on the wire.
>> 
>> 
>>Apr 27 04:03:26 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>available DHCP range: 10.168.102.100 -- 10.168.102.150
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>DHCPDISCOVER(ens160) 00:0c:29:65:e0:ea
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>tags: ens160
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>DHCPOFFER(ens160) 10.168.102.128 00:0c:29:65:e0:ea
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>requested options: 1:netmask, 28:broadcast, 2:time-offset,
>>121:classless-static-route,
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>requested options: 15:domain-name, 6:dns-server, 12:hostname,
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>requested options: 40:nis-domain, 41:nis-server, 42:ntp-server,
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>requested options: 26:mtu, 119:domain-search, 3:router,
>>121:classless-static-route,
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>requested options: 249, 33:static-route, 252, 42:ntp-server
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>next server: 10.168.101.20
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>sent size:  1 option: 53 message-type  2
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>sent size:  4 option: 54 server-identifier  10.168.101.20
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>sent size:  4 option: 51 lease-time  12h
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>sent size:  4 option: 58 T1  6h
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>sent size:  4 option: 59 T2  10h30m
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>sent size:  4 option:  1 netmask  255.255.255.0
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>sent size:  4 option: 28 broadcast  10.168.102.255
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>sent size:  4 option:  3 router  10.168.102.1
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>sent size:  4 option:  6 dns-server  10.168.101.20
>>Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364
>>sent size: 20 option: 82 agent-id
>> 01:0a:01:08:00:06:00:4c:4f:2a:00:2f:02:06…
>> 
>> 
>> I’ve been trying to trace this issue and it is like the sendmsg system
>> call is not working properly.  I believe routing is setup properly on
>> the

Re: [Dnsmasq-discuss] Disabling dynamic DHCP assignment for known hosts

2017-04-30 Thread Simon Kelley

I just committed a patch to do this. I chose the tag "known-othernet"
just because it seemed more descriptive.


Cheers,

Simon.


On 19/04/17 19:36, Todd Sankey wrote:
> I tried a different approach. I created a patch (attached) so that the
> tag "knownother" is applied if there is a host definition that applies
> to a different context. In our setup, we then added
> "dhcp-ignore=tag:knownother".
> 
> On Wed, Mar 15, 2017 at 1:14 PM, Todd Sankey  > wrote:
> 
> Our setup has two wifi networks with different network addresses,
> one for employees and one for guests. On the employee network, the
> hosts all have static host entries that include IP addresses. The
> guest network has no static host entries. What we would like to do
> is prevent the employee machines from getting any assignment on the
> guest network.
> 
> We tried using "tag:!known" in the dhcp-range configuration, and we
> have tried a tag-if statement that sets a tag based on the guest
> network interface and known followed by a dhcp-ignore. Neither works. 
> 
> Looking through the code, I think it is because when looking for a
> dhcp_config entry, the search is filtered by whether the assigned
> address is valid for the interface the request was received on.
> Since the static assignments are only valid for the employee
> network, when a request is received on the guest network, the static
> assignments are not valid so the "known" tag is never set. As a
> result, neither the dhcp-range tag filter nor the tag-if filter has
> the desired effect.
> 
> I next tried having dhcp-host entries for every employee machine,
> one with a static assignment on the employee network, and one with a
> static assignment on guest network and appending "ignore" to the
> guest network entry. This seems to have the desired behaviour in
> that employee machines cannot get on the guest network. However,
> this obviously doubles the work of maintaining the host list. I am
> also not sure what this does to the guest address range having these
> static but ignored assignments.
> 
> Is there a better way to do this in the current version (2.76)?
> 
> If not, would it be a reasonable feature request to extend the
> handling of dhcp-host settings so that if there is an IP assignment
> and "ignore" is specified, then the host is ignored on networks
> where the IP assignment is not valid?
> 
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] bug: trunk DHCP offer/replies being ignored by some devices

2017-04-30 Thread Simon Kelley

I just reverted the guilty change, so 2.77 should be OK now.


Cheers,

Simon.

On 08/04/17 00:55, Pedro MG Palmeiro wrote:
> The latest firmware for the printer is from 2015. This is one of those
> shared Epson/Fuji/Xerox models which I believe is entering EOL, since
> there is already another printer
> called M200 (Ecotank). Anyway, I'll report it.
> 
> Should the the implementation be correct in dnsmasq, then there will be
> more reports of this behavior from gateways implementing it, and that
> may move Epson into action.
> 
> Adding a mac exclude switch to dnsmasq is just marginally better than
> setting the printer IP manually, since both require intervention per device.
> 
> A switch disabling the whole implementation, or making it optional, thus
> reverting to the old behavior would be better if feasible, but I don't
> agree with removing it completely.
> 
> If nothing can be done, or be deemed unfeasible to be done, my opinion
> is that not much harm is done, since there is a way of getting things
> working (manual IP).
> 
> So, for me (3) it is.
> 
> Cheers.
> 
> On Fri, Apr 7, 2017 at 11:00 PM, Simon Kelley  > wrote:
> 
> On 06/04/17 14:01, Pedro MG Palmeiro wrote:
> > Dnsmasq trunk replies are being ignored by some devices, in my
> case, two
> > epson printers (AL-M200).
> > Dnsmasq 2.76 works fine.
> >
> > This could be related with
> > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit
> ;
> > =88a77a78ad27adc3ed87b7ee603643d26cb896ee
> >
> > Please refer to
> > https://bugs.lede-project.org/index.php?do=details&task_id=673
> 
> > for tcpdumps.
> >
> 
> But RFC 6842 assures us that no clients are broken by this change :)
> 
> The options here, as I see it are
> 
> 1) revert the change and don't support 6842
> 2) provide a way to disable the client-id reply for broken clients.
> 3) provide a flag to disable the client-id for all clients.
> 4) make the new behaviour optional, and provide a flag to enable it.
> 5) declare it No Our Problem and get the broken clients fixed.
> 
> 
> 5) is possible - have you talked to Epson? the AL-M200 looks like a
> current product, and likely has field-upgradable firmware.
> 
> 1) is not attractive.
> 
> 2) may be possible. There is already a config option to tell dnsmasq to
> ignore _incoming_ client-ids for a particular client, that could be
> extended to apply to _outgoing_ cones too.
> 
> Specifically, you'd need to add something like
> 
> dhcp-host=,id:*
> 
> to turn off this for just those machines.
> 
> 4) is not attractive.
> 
> I'm interested in peoples opinions; a flag to kill the new client-uid
> behaviour globally, or just for particular MAC/IP addresses, or based on
> a tag?
> 
> A pity, the original patch was so simple...
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> 
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


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

Re: [Dnsmasq-discuss] dhcp vendor-option and grub net_pxe_extensionspath

Re: [Dnsmasq-discuss] bug:DHCP Relay not responding with DHCP OFFER.

Re: [Dnsmasq-discuss] Disabling dynamic DHCP assignment for known hosts

Re: [Dnsmasq-discuss] bug: trunk DHCP offer/replies being ignored by some devices

4 matches

Site Navigation

Mail list logo

Footer information