Fortsetzung der Diskussion von Unifi zu respondd Exporter - Unifi auf der Karte anzeigen:
Ich habe das mit einem Controller außerhalb des L2-Netzes probiert, konnte die UAPs auch adoptieren — kurz danach war aber Schicht im Schacht, die Geräte wurden als offline angezeigt. IMHO, weil die 10.0.0.0/8-IPs der UAPs zwar per NAT zu meinem Controller kommen, der Controller aber nicht zu ihnen? Hab’ mir erstmal mit einem L2TP-Tunnel geholfen, aber das skaliert eher nicht so gut.
Die APs müssen nur zum Controller. Andersrum ist nicht notwendig. Bei FFMUC Betreiben wir den Controller auch vollkommen losgelöst vom Freifunknetz.
Im Zweifel auf den AP per ssh und set-inform <controller adresse> ausführen.
Wir betreiben den Controller auch losgelöst. Wenn du im FF-Netz „unifi“ im DNS auflöst, verbinden sich die Geräte auch direkt dahin und können adoptiert werden, dann entfällt immer das lokale set-inform.
Schönen Gruß
Jan
Geht auch einfach per dhcp option :). Dann braucht es nicht mal DNS.
Das hat nur für den Kea-dhcpd entweder noch niemand hinbekommen oder es fehlt Doku.
Wenn man eine Search Domain (clients.example.freifunk.net) hat würde ich aber einfach unifi.clients.example.freifunk.net als Record anlegen: https://help.ui.com/hc/en-us/articles/204909754-UniFi-Layer-3-Adoption-for-Remote-UniFi-Network-Applications#6
Ich tendiere aber auch dazu einfach kein Unifi zu verbauen.
Stimmt lieber Omada mittlerweile ;). Da geht das auch mit Remote controller.
Man muss ihm nur beibringen Option 42 zu senden mit den passenden Values, das sollte auch kea können.
Ei freilich, für den isc-dhcpd ist das auch gut dokumentiert.
Nur für den (zumindest hier inzwischen üblichen) KEA hat da niemand was für (gefunden).
Ok, offensichtlich habe ich den Unifi-Controller dann falsch gehalten (Inform-URL war gesetzt auf FQDN, jener hat public v4).
Omada habe ich mal zwei 245 zum Spielen bestellt, lt. TP-Link unterstützen aber nur die Outdoor-Geräte meshing?
Bei uns meshen die Indoor Geräte perfekt :). (EAP 620)
Nur für den (zumindest hier inzwischen üblichen) KEA hat da niemand was für (gefunden).
Lässt sich ändern 
"option-def": [
{ "name" : "unifi-address",
"code" : 1,
"type" : "ipv4-address",
"space": "ubnt" }
],
"client-classes": [
{ "name": "ubnt",
"test": "(option[vendor-class-identifier].text == 'ubnt')",
"option-def": [
{ "name": "vendor-encapsulated-options",
"type": "empty",
"encapsulate": "ubnt",
"code": 43 }
],
"option-data": [
{ "name": "unifi-address",
"space": "ubnt",
"data": "10.3.0.30" },
{ "name": "vendor-encapsulated-options" }
]
}
],
Hmmja, ich halte auch Omada wohl wieder falsch …
EAP225-Outdoor & EAP245 an TL-SG108PE. Zweitverbundenes Gerät geht nur per Mesh online, floodet nach einer gefühlten Ewigkeit dann den DHCP-Server mit hunderten von Discovers, läuft ein paar Sekunden und ist wieder offline.
Es gibt ja keine zweite Chance für einen ersten Eindruck, und jener deutet gerade auf einen klassischen Copycat-Murx. Was ist das Geheimnis?
Das Problem hatten wir noch nie, bei uns gehen alle Geräte eigentlich instant online. Wir setzen aber auch auf SG2008 und EAP 620HD.
Das ist jetzt … unerwartet: mit 'nem 2008P tut’s, wie’s soll, beide bleiben wired online. WTF‽ Am PoE (-Budget) kann’s eigentlich nicht liegen, testweise den EAP245 per passivem Adapter bestromt, es bleibt dabei: das zweitgestartete Gerät verbindet sich per WiFi und verliert nach ein paar Pings die Verbindung wieder.
Zu alte Firmware und er macht irgendeinen Mist? (Also der 108)
Da steckten zuvor AC-M für 'nen Testaufbau dran, also eher nicht. Nur der Uplink war da 'ne FF-4040, nicht das Heimnetz; aber der 2008P tut da ja. Merkwürdig. Aber ja, so funktioniert das doch sehr ähnlich dem Unifi-Kram. Inkl. uralter Mongo-DB … Zuviel abgekupfert?
Vermutlich setzt Ihr dann DHCP Option 138 (CAPWAP), wie von TP-Link dokumentiert? Aber Du schreibst von Option 42, und was sind die »passenden Values«?
Mein Kommentar war zu Unifi ;). Nachdem das Thema erst hierum ging.
Aber ja Option 138 ist korrekt.
