dhcpd NAK, schnellere Antworten

[kwadronaut]

Moin,

On 14/03/16 21:59, Tim Niemeyer wrote:
> Am Mittwoch, den 09.03.2016, 11:16 +0100 schrieb kwadronaut:
>> ich habe soeben der dhcpd auf ein Erlanger GW umgebaut. Mit verschiedene
>> Gateways im gleichen Subnetz mit unterschiedlichen Bereiche, antwortet
>> einen dhcpd *nicht* wenn der eine REQUEST bekommt von ein Client der
>> soeben noch beim anderen GW seine IP geholt hatte. Deswegen dauert es
> Das ist sehr interessant. Ich dachte ein solcher Request wäre ein Renew
> und der wäre dann kein Broadcast sondern ein Unicast. Das würde
> bedeuten, dass es nur lange dauern, wenn der ursprüngliche Server nicht
> mehr da wäre.
> 
> Die Gateway-Selection baut nur Broadcast um, daher hat sie auf ein Renew
> keinen Einfluss.

Batman leitet alle DHCP paketen immer zum selektierten gateway, oder?
Das heisst, wenn einen Router den Gateway wechselt, bekomme ich
plötzlich anfragen wie DHCPREQUEST for 10.50.71.84 from 4c:7c: ... via
bat0 (anderen Bereich, außerhalb meiner Pool). Normalerweise antwortet
einen DHCPD *nicht* darauf, und dann kann es länger dauern bevor ein
DHCPDISCOVER verschickt wird. Deswegen antworte ich jetzt mit NAK. Das
gleiche Problem gibt es auch wenn jemand von einem bis zum nächsten
Router lauft, glaube ich.

>> manchmal länger als nötig um eine IP zu bekommen. Jetzt verschicke ich
>> auch ein NAK an derjenigen der eine IP vom anderen range hat. Falls
>> bedenken, höre ich es gerne:
> Wie sind denn bis jetzt deine Erfahrungen?

* Es schneit jetzt, weniger Traffic als sonst.
* Es gibt öfter Geräten die auf ein NAK noch 2,3 mal versuchen und der
gleichen DHCPREQUEST verschicken
* keine beschwerden
* nicht gemessen, gefühlt besser.

Es kostet aber mehr Ram.

> 
> Tim
> 
>> ---


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 836 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160315/932abba1/attachment-0002.sig>