[Dnsmasq-discuss] adjustment for dhcp_release.c

[Rene Stoutjesdijk]

Hi Simon.,
thx for the quick response.
As i'm rather new to this stuff.
What is the Dbus and how can i make use out of it, or even better is
there an example how you can delete a lease via the Dbus.

wkr
rene


On Sat, Jan 3, 2015 at 6:21 PM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I think you're right about the problem.
>
> The simplest solution would be to add code the dhcp_release to provide
> the same circuit-id information that the client would.
>
> To be honest dhcp_release is a bit of a hack, and making it work in
> the general case probably isn't worth the effort. Much better would be
> to provide a method in the Dbus interface. The only inforamation
> actually required to identify a lease is the IP address, so a method
> to release the DHCP associated with a particular IPv4 or IPv6 lease
> would work great.
>
> Patches carefully considered :)
>
>
> Cheers,
>
> Simon.
>
>
>
> On 03/01/15 17:14, Rene Stoutjesdijk wrote:
>> Goodday,
>>
>> earlier today i did sent out an email (but probably something went
>> wrong) which i do repat later ,see QUOTED text at the end of this
>> email.
>>
>> After the initial email i've done some additional tests, and it
>> looks like the dhcp_relase.c program is "only" working when you
>> provide information just out of a ip pool.
>>
>> However when you provide ip addresses based upon an eg. circuit-id
>> then the address isn't cleared. As it looks like the circuit-id
>> (and maybe remote-id) are also checked upon beofre doing the
>> clearing.
>>
>> Is above assumption correct, and if yes how can the dhcp_release.c
>> be adjusted so that also the cirucitid and/or remote id can be
>> provided.
>>
>>
>> i've als tested the above assumption with the following scenario:
>> do a dhcp DORA process based upon circuit-id CUST14 after the ip
>> address was retrieved i changed the circuit-id on the switch
>> towards CUST14a then did a dhcp release from the end station, and
>> the lease file wasn't cleared.
>>
>> then i changed the switch back to CUST14
>>
>> i repeated above steps, and after the RELEASE message the lease
>> file was cleared for that entry.
>>
>> so above mentioned assumption looks to be true
>>
>> wkr rene
>>
>> see text below for previous email, which apparently went wrong).
>>
>> QUOTE
>>
>> Goodday,
>>
>> i do have a question about dhcp_release.c
>>
>> I'm trying to clear an entry within the dhcp lease table.
>>
>> At this moment i'm providing the ip address based upon
>> dhcp-circuitid. At this moment one of the en-users changed his mac
>> address and due to that resins he can't connect until his old
>> release is expired. So i wanted to clear manually his old entry
>> from the lease table.
>>
>> For this i wanted to use the command:
>>
>> ./dhcp_release eth1 10.64.1.0 a8:20:66:03:61:bc
>> 01:a8:20:66:03:61:bc
>>
>>
>> based upon his entry within the lease file:
>>
>> 1420293992 a8:20:66:03:61:bc 10.64.1.0 Renes-MBP
>> 01:a8:20:66:03:61:bc
>>
>>
>> But as soon as i execute the command i do see the following entry
>> within the syslog file:
>>
>> Jan  3 14:04:58 localhost dnsmasq-dhcp[3326]: 0 available DHCP
>> range: 10.64.1.0 -- 10.64.1.0
>>
>> and the entry isn't cleared from the table (and the enduser with
>> his new mac address can't connect).
>>
>>
>> i do have a basic dhcp file which looks like:
>>
>> dhcp-range=net:CUST14,10.64.1.0,10.64.1.0,255.192.0.0,4h
>> dhcp-circuitid=CUST14,CUST14
>>
>>
>>
>>
>> What am i doing wrong?
>>
>> thx in advance for your help.
>>
>> UNQUOTE
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJUqCUDAAoJEBXN2mrhkTWiMWcP/27fsgmJqMB1K7piEG3eJtXa
> hlqf23IMQW3Up/j0D/6m9ixbzJ/zjIhBaTt91hBhBLP7BDDcqVK/IJ5jKiK9MUPf
> CFHnPROrnrPbWgjdsjLBY1+mGytkCJj89bQv/eFtOmsoi2EIfDv1naBD4dIaE4Z9
> feW3r2+Cc1pR6fYoeu2jv70gvZ6E8PPFVKJQOA/lSXumk4NxygdpAnX8Hao4PPMM
> tzFbo4kWRBezUwd8renfP/HM9WG34JFcMO5lFk1vRqB6Ju+6DVTGSuCNe2Ojec+G
> s0YdhFcDvkdcPQhkS97URd5BWKsBbx4YlXsFDZqrv5781RK84+VKCdQUEA1pamYO
> pgVbIuB4r2C4XvSijEAKwrt1A5W5+pLYJZffVNfhgDmsfZ7mkGPZh9blNiARTQNr
> hTJgAvdyDbfhW2JZ59F7JSuqtOf8clh9eJF3waENqjbg3zyFywISEAPWHXTMFVBF
> ef/TwXVVfG7sodmHzM107E5SOXwrefZzcogEkyDVtYr9u/+06eM4kM3IP35hu17R
> kamyGfU3FK7XP6BsyxQ625woMsvhQtbB2LhigYd0JaTUf8KW/d66nopUrXsefKL8
> A8Z2cIoBAwRP7M07Y3bm1T4Q1D7tgu8DfLpl5R4+15xjPsdciURYxjNCmUbbHVAF
> QyTq2cIYTq/SejPPI06L
> =7gqu
> -----END PGP SIGNATURE-----