So ich habe mich jetzt (OK auch schon Gestern) an das frisch von euch angelieferte Aastra 57i gemacht.
Das anschließen und konfigurieren war nicht das Problem. Via Web komme ich auch ohne Probleme auf das Tel.
An der Stelle schnell mal den Commander auf, denn von den Snom´s bin ich es ja gewohnt das sie von selbst gefunden werden. Das war leider nicht so.
OK denke ich mir, binden wir es eben manuell ein. Schnell auf hinzufügen Aastra …, Name, MAC, HTTP-User (admin - ist ja der Standard Benutzer für Aastra) und das HTTP-Pass (22222 - wieder Standard).
An der Stelle speichern, und der Commander meint es besser zu wissen, und setzt den HTTP-User zurück auf seinen Standard (user).
Jetzt ist zwar mein schönes Aastra im MobyDick, aber leider bei Auth habe ich ein kleines Schloss und bei Status --> Gerät hat sich noch nicht registriert.
OK - Schaue ich mal nach der Firmware --> 2.0.XXXX (irgendwann aus 2007 - puhhh das ist alt :))
Schnell auf die Webseite von Aastra, die neue Firmware geladen und auf die Kiste. Soweit alles bestens geklappt. Webfrontend und Tel. sagen nun Version 2.6.0.1008 aus Juli 2010.
Weiter in MobyDick mit der Hoffnung es wird besser. Leider wieder ein Fehlschlag.
Passen die DHCP Optionen (falls nicht MobyDick DHCP ist)?
Schau mal in das */var/log/apache2/access.log *
während das Telefon startet. Dort siehst Du ob es überhaupt die Anlage konsultiert (nach …/provisioning/… ausschau halten). Nach dem Punkt kannst Du den DHCP schon ausschliessen.
Dann interessiert mich der Inhalt von /var/log/mobydick/provisioning/(mac).log
und /var/log/mobydick/provisioning/provisioning.log
Noch ein Hinweis zur Provisionierungs-URL. Seit der Release 6.05.00 ist der Commander insbesondere bei Aastra und Yealink Geräten recht großzügig. Solange die Url mit http://ip-der-anlage/provisioning beginnt, reicht es.
Die Aastras kennen übrigens 2 Default Accounts. Es gibt den “admin” und den “user”, somit hatte der Commander genau so recht wie du
also ich habe jetzt noch mal die Einstellungen im DHCP gecheckt, und denke eigentlich sollten sie richtig sein!?
Ich schicke euch mal die Einträge und das was mir die Logs geben.
Ergebnis: leider bekomme ich keine Logeinträge in der /var/log/apache2/access.log vom Aastra. Das Snom beim Neustart meldet sich ordnungsgemäß.
Wir nutzten einen Suse DHCP mit der folgenden .conf
class “snom” {
match if binary-to-ascii(16, 32, “”, substring(hardware, 0, 4)) = “1000413”;
}
if binary-to-ascii(16, 32, “”, substring(hardware, 0, 4)) = “1000413” {
option tftp-server-name “http://192.168.193.15/mobydickcmd/provisioning/snom/snom-settings-xml.php?u_mac={mac}”;
log(info, “Got request from snom phone.”);
}
class “aastra” {
match if substring(hardware, 1, 3) = 00:08:5d;
log(info, “Class for Aastra phone.”);
}
if substring(hardware, 1, 3) = 00:08:5d {
option tftp-server-name “http://192.168.193.15/mobydickcmd/provisioning/{mac}”;
log(info, “Got request from Aastra phone.”);
}
subnet 192.168.193.0 netmask 255.255.255.0 {
pool {
range 192.168.193.65 192.168.193.69;
allow members of “snom”;
}
pool {
range 192.168.193.80 192.168.193.100;
allow members of “aastra”;
}
Die Logs vom DHCP sehen für das SNOM so aus:
Oct 7 15:10:43 LinuxSrv01 dhcpd: Got request from snom phone.
Oct 7 15:10:43 LinuxSrv01 dhcpd: DHCPDISCOVER from 00:04:13:26:95:42 via eth0
Oct 7 15:10:44 LinuxSrv01 dhcpd: DHCPOFFER on 192.168.193.62 to 00:04:13:26:95:42 via eth0
Oct 7 15:10:44 LinuxSrv01 dhcpd: Got request from snom phone.
Oct 7 15:10:44 LinuxSrv01 dhcpd: DHCPREQUEST for 192.168.193.62 (192.168.193.17) from 00:04:13:26:95:42 via eth0
Oct 7 15:10:44 LinuxSrv01 dhcpd: DHCPACK on 192.168.193.62 to 00:04:13:26:95:42 via eth0
für das Aastra:
Oct 7 16:40:05 LinuxSrv01 dhcpd: Got request from Aastra phone.
Oct 7 16:40:05 LinuxSrv01 dhcpd: Class for Aastra phone.
Oct 7 16:40:05 LinuxSrv01 dhcpd: DHCPDISCOVER from 00:08:5d:1a:1a:06 (57i00085D1A1A06) via eth0
Oct 7 16:40:06 LinuxSrv01 dhcpd: DHCPOFFER on 192.168.193.163 to 00:08:5d:1a:1a:06 (57i00085D1A1A06) via eth0
Oct 7 16:40:06 LinuxSrv01 dhcpd: Got request from Aastra phone.
Oct 7 16:40:06 LinuxSrv01 dhcpd: Class for Aastra phone.
Oct 7 16:40:09 LinuxSrv01 dhcpd: Unable to add forward map from 57i00085D1A1A06.DOCURA2005 to 192.168.193.163: timed out
Oct 7 16:40:09 LinuxSrv01 dhcpd: DHCPREQUEST for 192.168.193.163 (192.168.193.17) from 00:08:5d:1a:1a:06 (57i00085D1A1A06) via eth0
Oct 7 16:40:09 LinuxSrv01 dhcpd: DHCPACK on 192.168.193.163 to 00:08:5d:1a:1a:06 (57i00085D1A1A06) via eth0
Oct 7 16:40:09 LinuxSrv01 dhcpd: Got request from Aastra phone.
Oct 7 16:40:09 LinuxSrv01 dhcpd: Class for Aastra phone.
Oct 7 16:40:12 LinuxSrv01 dhcpd: Unable to add forward map from 57i00085D1A1A06.DOCURA2005 to 192.168.193.163: timed out
Oct 7 16:40:12 LinuxSrv01 dhcpd: DHCPREQUEST for 192.168.193.163 (192.168.193.17) from 00:08:5d:1a:1a:06 (57i00085D1A1A06) via eth0
Oct 7 16:40:12 LinuxSrv01 dhcpd: DHCPACK on 192.168.193.163 to 00:08:5d:1a:1a:06 (57i00085D1A1A06) via eth0
in der /var/log/apache2/access.log vom MobyDick taucht nur das Snom beim Restart auf:
Danke Maik (mal wieder ) !
In der Tat ist die Url Falsch, es muss das “mobydickcmd” raus.
Dennoch sollten Requests in der access.log auftauchen, es sieht eher so aus, als ob es das Gerät erst gar nicht probiert.
Eventuell kommt das Aastra Gerät mit der geschweiften Klammer nicht klar und verwirft die tftp-server-name Option?
Hier zur Ergänzung noch ein Auszug aus der MobyDick dhcp config einer Testanlage (10.3.4.9):
class "Snom Phone" {
match if binary-to-ascii(16, 32, "", substring(hardware, 0, 4)) = "1000413";
}
if binary-to-ascii(16, 32, "", substring(hardware, 0, 4)) = "1000413" {
log(info, "Got request from Snom Phone.");
option tftp-server-name "http://10.3.4.9/provisioning/{mac}";
}
class "Aastra Phone" {
match if binary-to-ascii(16, 32, "", substring(hardware, 0, 4)) = "100085d";
}
if binary-to-ascii(16, 32, "", substring(hardware, 0, 4)) = "100085d" {
log(info, "Got request from Aastra Phone.");
option tftp-server-name "http://10.3.4.9/provisioning";
}
Also ich habe jetzt schon mal wieder eine ganze Reihe an Tests gemacht, aber bekomme das gerät immer noch nicht an die MD!?
Kann es evtl. auch an dem BootRom liegen? Hier hab ich die Version 2.0.1.1055
Ich habe jetzt auch schon mal probiert das Tel. manuell einzustellen, aber auch dann bekomme ich keine Meldungen in der /var/log/apache2/access.log
HHÜÜLLLFFFEEE
[EDIT]
ich habe mir beim Boot des Astra noch mal die syslog angesehen. Also das Tel. versucht wohl schon was zu bekommen, aber anscheinend kommt es nicht an!?
Oct 8 13:54:31 localhost atftpd[2701]: Serving /provisioning/security.tuz to 192.168.193.98:1026
Oct 8 13:54:31 localhost atftpd[2701]: Serving /provisioning/aastra.cfg to 192.168.193.98:1027
Oct 8 13:54:33 localhost atftpd[2701]: Serving /provisioning/security.tuz to 192.168.193.98:1028
Oct 8 13:54:33 localhost atftpd[2701]: Serving /provisioning/aastra.cfg to 192.168.193.98:1029
Oct 8 13:54:35 localhost atftpd[2701]: Serving /provisioning/security.tuz to 192.168.193.98:1030
Oct 8 13:54:35 localhost atftpd[2701]: Serving /provisioning/aastra.cfg to 192.168.193.98:1031
Oct 8 13:54:37 localhost atftpd[2701]: Serving /provisioning/security.tuz to 192.168.193.98:1032
Oct 8 13:54:37 localhost atftpd[2701]: Serving /provisioning/aastra.cfg to 192.168.193.98:1033
Oct 8 13:54:39 localhost atftpd[2701]: Serving /provisioning/security.tuz to 192.168.193.98:1034
Oct 8 13:54:39 localhost atftpd[2701]: Serving /provisioning/aastra.cfg to 192.168.193.98:1035
Oct 8 13:54:42 localhost atftpd[2701]: Serving /provisioning/security.tuz to 192.168.193.98:1036
Oct 8 13:54:42 localhost atftpd[2701]: Serving /provisioning/aastra.cfg to 192.168.193.98:1037
Oct 8 13:54:44 localhost atftpd[2701]: Serving /provisioning/security.tuz to 192.168.193.98:1038
Oct 8 13:54:44 localhost atftpd[2701]: Serving /provisioning/aastra.cfg to 192.168.193.98:1039
ich vermute stark das dies immer noch an deiner dhcp konfiguration liegt.
Das hier:
class “aastra” {
match if substring(hardware, 1, 3) = 00:08:5d;
log(info, “Class for Aastra phone.”);
}
if substring(hardware, 1, 3) = 00:08:5d {
option tftp-server-name “http://192.168.193.15/mobydickcmd/provisioning/{mac}”;
log(info, “Got request from Aastra phone.”);
}
Am einfachsten ist es wohl wenn du die Klassen mal aus dem Dhcp der Mobydick rauskopierst und 1:1 in deinem übernimmst, das Aastra würde ich zusätzlich nochmal resetten.
Welche Version ist denn dein DHCP- Server, hier gab meines Wissens nach vor Version 3.1.X kleinere Probleme mit den Klassen.
Aber ich würde sagen das liegt wohl an dem if substring(hardware, 1, 3) = 00:08:5d {, hier matched wohl nichts, so könnte es vllt. besser gehen:
if binary-to-ascii(16, 32, “”, substring(hardware, 0, 4)) = “100085d” {
Also es war der DHCP - Ich weiß zwar nicht weshalb aber ich habe einfach einmal die IP auf den der DHCP das Aastra gesetzt hat aus allen Pools herausgenommen, und dann wurde auch das Tel. mit der richtigen IP aus dem Pool besetzt und der Rest futzte auch auf Anhieb.
Jetzt habe ich aber ein ganz anderes Problem. Seit dem Aastra und MobyDick nun Freunde sind, hat das Aastra mich nicht mehr lieb!!
Seit dem komme ich via Web nicht mehr auf die Oberfläche. Also mit admin - 22222 futzt es nicht mehr? Kann es sein das Ihr dies abändert??
Und zweite Sache die hiermit aber nicht direkt was zu tun hat. Wie kann ich Daten (z.B. neue Firmware) auf den MobyDick bekommen.
Und nächste Frage, mit dem normalen admin - Login darf ich z.B. im Firmwareordner keine neuen anlegen.
Überschnitten haben sich die Pools auch nicht, aber der blöde DHCP hat das Tel. welches schon eine IP aus einem anderen Pool hatte nicht umgeswitcht.
Irgendwie wollte sich der Leav nicht löschen lassen.
Ich habe einfach die IP auf der das Tel. lag mal aus allen Pools raus genommen. Und sihe da, dann hat er ihm auch dem richtigen Pool zu sortiert.
) !