ISCs dhcrelay und Freifunk

Von der Idee über holprige Pisten bis zur funktionierenden Umsetzung.

Schon lange wünscht die technische Seite der Gütersloher Freifunker sich zentrales DHCP, denn das Standardsetup mit lokalem DHCP hat seine Schattenseiten: für jeden Server (i. e. Gluon-Gateway) muß ein Adressraum vorgehalten werden. Initial haben wir ein /21 genommen, das ergibt 2048 IP-Adressen — bei vier Gateways also 512 IP-Adressen pro Gateway. Dank batman_adv- und fastd-Artefakten verteilen sich schon Freifunk-Knoten nicht gleichmäßig auf die Gateways, und jeder Knoten zieht unterschiedlich viele Endgeräte an …

Das Ergebnis sehen wir seit über vier Wochen, und auch unsere Nutzer spüren es — es gibt immer öfter keine Verbindung zum Freifunk-Netz, da einfach das Gateway keine freien IP-Adressen mehr hat. Ein anderes hat ggf. noch welche, aber das schönt nur die Statistik — genutzt werden könne diese IPs leider nicht.

Im Zuge des parallelen Neuaufbaus (bei dem auch alte Fehler korrigiert werden können, anders als ggf. bei einem graduellen Wachstum über neue Server und Neuinstallation alter), haben wir die IPv4-Adressvergabe per DHCP fest per DCHP-Relay geplant: lokal auf dem Gateway läuft nur ein dummer Agent, der die Anfrage an einen zentralen Server weiterleitet, jener sucht eine IP und schickt sie wieder zurück. Soweit, so gut; allerdings müssen wir auch unterscheiden können, über welches Gluon-/batman_adv-Gateway die Anfrage kam, um entsprechend zumindest des Default-GW auf jenen Host zu setzen. Und hier patzt der ISC Relayserver: Es liefert zwar das Interface mit, über welches die Anfrage kam, aber keine weiteren Informationen — und das Interfaces ins Mesh heißt leider überall »br-ffgt«.

Nun sind wir beileibe nicht die Einzigen mit diesem Problem; und dankenswerterweise hat »Harvie« schon 2013 einen entsprechenden Patch geschrieben, denn er brauchte das selbst:

Manpage of dhcrelay says:
“The client supports inclusion of a Remote ID suboption as well, but this is not used by default.”

But there’s no support of setting Remote ID in Option 82 at dhcrelay. I think this would be really usefull. I need central DHCP server with relays in my company. We use manageable switches with Option 82 support, these are OK (they’re including RemoteID of switch and CircuitID of port to DHCP requests).
But in some places without these switches we need to use Linux with dhcrelay instead (CircuitID identifies interface as needed, but we also need to set RemoteID as we have multiple relays in our network, which means shitloads of conflicting eth0s and eth1s)

So i really need to append different RemoteIDs set by commandline argument on each relay…

Right now i am going to make some ugly dirty adhoc patch to dhcrelay, but i guess you can do it much better… Do you think it’s possible to get this improvement in official release?

Leider wurde das nie weiterverfolgt und in ISCs dhcrelay aufgenommen :( Also habe ich flugs den Patch in 4.2.4-7ubuntu12.3 der ISC-DHCP-Tools reingehackt — und bin, wg. der absichtlich anderen Paketbezeichnung, in der Abhängigkeistfalle gelandet :(

root@gw01:~# dpkg -i /usr/src/isc-dhcp-relay_4.2.4-7remoteid12.3_amd64.deb 
dpkg: warning: downgrading isc-dhcp-relay from 4.2.4-7ubuntu12.3 to 4.2.4-7remoteid12.3
(Reading database ... 127037 files and directories currently installed.)
Preparing to unpack .../isc-dhcp-relay_4.2.4-7remoteid12.3_amd64.deb ...
isc-dhcp-relay stop/waiting
Unpacking isc-dhcp-relay (4.2.4-7remoteid12.3) over (4.2.4-7ubuntu12.3) ...
dpkg: dependency problems prevent configuration of isc-dhcp-relay:
 isc-dhcp-relay depends on isc-dhcp-common (= 4.2.4-7remoteid12.3); however:
  Version of isc-dhcp-common on system is 4.2.4-7ubuntu12.3.

dpkg: error processing package isc-dhcp-relay (--install):
 dependency problems - leaving unconfigured
Processing triggers for ureadahead (0.100.0-16) ...
ureadahead will be reprofiled on next reboot
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Errors were encountered while processing:
 isc-dhcp-relay

Gut, zusammen mit isc-dhcp-common läßt sich dann auch das gefixte isc-dhcp-relay-Package installieren. Und, yeah, endlich eindeutige Identifikation des die DCHP-Anfrage weiterleitenden Systems:

lease 10.255.8.33 {
  starts 0 2015/10/25 01:19:28;
  ends 0 2015/10/25 01:29:28;
  cltt 0 2015/10/25 01:19:28;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet b8:27:eb:6a:83:c6;
  uid "\001\270'\353j\203\306";
  option agent.circuit-id "br-ffgt";
  option agent.remote-id "gw01";
  client-hostname "ffgt-rpi1";
}

Nächste Hürde: batman_advs Wahl des (DHCP-) Gateways, die nicht immer mit der fastd-Verbindung korreliert …