7970 will nicht an einem neuen Asterisk connecten

Toggle sidebar Toggle sidebar
Upgrade 3CX to v18 and get it hosted free!
2

2bbionic

Neuer User
Mitglied seit
5 Sep 2005
Beiträge
34
Punkte für Reaktionen
0
Punkte
0
Hallo,

zu Testzwecken muß ein 7970 an einem anderen Asterisk connecten. Dazu habe ich die entsprechenden einträge im DHCP geändert, sodaß der server-name des TFTP-Servers ebenfalls auf den neuen Server zeigt. Auf diesem ist der TFTP neben asterisk installiert.
In der SEPXXX-Datei habe ich <processNodeName>, <ipAddr1> und in der sccp.conf die bindaddress entsprechend geändert.
Leider will das cisco sich aber immer noch mit dem alten * verbinden. Zwar holt es sich die Daten vom neuen Server per TFTP ab, aber scheint sie zu ignorieren. Über das Webinterface habe ich zumindest gesehen, dass immer noch die alte CallManager-IP drinsteht. im Display des Telefons steht "Registering"...
Was muss ich denn anstellen, damit sich das Cisco auf den neuen Server connected?

Hier noch meine Hardware:

Router: gentoo-Linux
Endgeräte:Cisco 7970, 3CX Softphones
Software: 1. Asterisk 1.4.13 mit mISDN (HFC) und chan_sccp 20071111 (beta) in XEN 2.6.20-xen-r6 (gentoo) 400 MB RAM
VoIP: Sipgate
POTS: ISDN
Anbindung: DSL 16000 T-Online
 
Zuletzt bearbeitet:
tftp-server per dhcp-option 150 übergeben?
 
zeig mal das logfile von dem tftp
 
Hallo,

hier ist der entsprechende Teil aus der dhcpd.conf
vor der Umstellung:

Code: 
option option-150 code 150 = text;
host 7970 {
        hardware ethernet 00:15:F9:7F:42:6E;
        fixed-address 192.168.100.151;
        server-name "192.168.100.200";
        next-server 192.168.100.200;
        option host-name "Cisco7970";
        option domain-name "agit.home";
        filename "xmlDefault.cnf.xml";
        }
und nach der Umstellung:
Code: 
option option-150 code 150 = text;
host 7970 {
        hardware ethernet 00:15:F9:7F:42:6E;
        fixed-address 192.168.100.151;
        server-name "192.168.100.252";
        next-server 192.168.100.252;
        option host-name "Cisco7970";
        option domain-name "agit.home";
        filename "xmlDefault.cnf.xml";
        }

und hier ein Logfile vom neuen TFTP-Server:

Code: 
Nov 12 11:36:35 [in.tftpd] RRQ from 192.168.100.151 filename CTLSEP0015F97F426E.tlv_
Nov 12 11:36:35 [in.tftpd] sending NAK (1, File not found) to 192.168.100.151
Nov 12 11:36:35 [in.tftpd] RRQ from 192.168.100.151 filename SEP0015F97F426E.cnf.xml_
Nov 12 11:40:21 [in.tftpd] RRQ from 192.168.100.151 filename CTLSEP0015F97F426E.tlv_
Nov 12 11:40:21 [in.tftpd] sending NAK (1, File not found) to 192.168.100.151
Nov 12 11:40:21 [in.tftpd] RRQ from 192.168.100.151 filename SEP0015F97F426E.cnf.xml_
Mehr wirft er mir leider nicht raus. Auf dem bisherigen Server sieht es aber genauso aus; funktioniert aber.

Grüße,

2bbionic
 
Nachtrag:

Ich habe mit mit tcpdump mal ausgeben lassen, was denn so passiert:
Ausgangsbasis: dhcpd.conf zeigt auf den neuen Server:

Ausgabe tcpdump -i eth0 -v src host 192.168.100.151 auf dem alten *
Code: 
11:23:12.928411 arp who-has 192.168.100.151 tell 192.168.100.151
11:23:12.928583 arp who-has 192.168.100.99 tell 192.168.100.151
11:23:13.119214 arp who-has 192.168.100.200 tell 192.168.100.151
11:23:17.581745 arp who-has 192.168.100.252 tell 192.168.100.151
11:23:22.249207 IP (tos 0x0, ttl 32, id 10, offset 0, flags [none], proto TCP (6), length 4                      4) 192.168.100.151.51828 > 192.168.100.200.cisco-sccp: S, cksum 0xd42b (correct), 235686983                      0:2356869830(0) win 8192 <mss 1400>
11:23:22.256257 IP (tos 0x0, ttl 32, id 11, offset 0, flags [none], proto TCP (6), length 4                      0) 192.168.100.151.51828 > 192.168.100.200.cisco-sccp: ., cksum 0x1544 (correct), ack 21593                      02052 win 8192
11:23:22.498161 IP (tos 0x60, ttl 32, id 12, offset 0, flags [none], proto TCP (6), length                       144) 192.168.100.151.51828 > 192.168.100.200.cisco-sccp: P 0:104(104) ack 1 win 8192
11:23:22.539176 IP (tos 0x60, ttl 32, id 13, offset 0, flags [none], proto TCP (6), length                       104) 192.168.100.151.51828 > 192.168.100.200.cisco-sccp: P 104:168(64) ack 1 win 8192
11:23:24.270967 IP (tos 0x60, ttl 32, id 14, offset 0, flags [none], proto TCP (6), length                       40) 192.168.100.151.51828 > 192.168.100.200.cisco-sccp: F, cksum 0x145f (correct), 168:168(                      0) ack 61 win 8192
11:23:24.271524 IP (tos 0x60, ttl 32, id 15, offset 0, flags [none], proto TCP (6), length                       40) 192.168.100.151.51828 > 192.168.100.200.cisco-sccp: R, cksum 0x145b (correct), 169:169(                      0) ack 61 win 8192
11:23:24.271773 IP (tos 0x0, ttl 32, id 16, offset 0, flags [none], proto TCP (6), length 4                      0) 192.168.100.151.51828 > 192.168.100.200.cisco-sccp: R, cksum 0x1362 (correct), 169:169(0                      ) ack 310 win 8192
11:23:40.256211 IP (tos 0x0, ttl 32, id 17, offset 0, flags [none], proto TCP (6), length 4                      0) 192.168.100.151.49419 > 192.168.100.200.cisco-sccp: R, cksum 0x2df6 (correct), 426574024                      5:4265740245(0) ack 2508698286 win 8192
11:23:56.467058 IP (tos 0x0, ttl 32, id 18, offset 0, flags [none], proto TCP (6), length 44) 192.168.100.151.50181 > 192.168.100.200.cisco-sccp: S, cksum 0x72ad (correct), 4051566000:4051566000(0) win 8192 <mss 1400>
11:23:56.467479 IP (tos 0x0, ttl 32, id 19, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.50181 > 192.168.100.200.cisco-sccp: ., cksum 0xb5e8 (correct), ack 2016500740 win 8192
11:23:56.493007 IP (tos 0x60, ttl 32, id 20, offset 0, flags [none], proto TCP (6), length 104) 192.168.100.151.50181 > 192.168.100.200.cisco-sccp: P 0:64(64) ack 1 win 8192
11:23:58.472758 IP (tos 0x60, ttl 32, id 21, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.50181 > 192.168.100.200.cisco-sccp: ., cksum 0xb56c (correct), ack 61 win 8192
11:23:58.480104 IP (tos 0x60, ttl 32, id 22, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.50181 > 192.168.100.200.cisco-sccp: F, cksum 0xb473 (correct), 64:64(0) ack 309 win 8192
11:23:58.480543 IP (tos 0x60, ttl 32, id 23, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.50181 > 192.168.100.200.cisco-sccp: ., cksum 0xb472 (correct), ack 310 win 8192
11:24:30.689397 IP (tos 0x0, ttl 32, id 24, offset 0, flags [none], proto TCP (6), length 44) 192.168.100.151.52606 > 192.168.100.200.cisco-sccp: S, cksum 0x3c19 (correct), 1617542112:1617542112(0) win 8192 <mss 1400>
11:24:30.689822 IP (tos 0x0, ttl 32, id 25, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.52606 > 192.168.100.200.cisco-sccp: ., cksum 0xec93 (correct), ack 1886647938 win 8192
11:24:30.712945 IP (tos 0x60, ttl 32, id 26, offset 0, flags [none], proto TCP (6), length 104) 192.168.100.151.52606 > 192.168.100.200.cisco-sccp: P 0:64(64) ack 1 win 8192
11:24:32.194596 IP (tos 0x60, ttl 32, id 27, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.52606 > 192.168.100.200.cisco-sccp: ., cksum 0xec17 (correct), ack 61 win 8192
11:24:32.204547 IP (tos 0x60, ttl 32, id 28, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.52606 > 192.168.100.200.cisco-sccp: F, cksum 0xeb1e (correct), 64:64(0) ack 309 win 8192
11:24:32.205000 IP (tos 0x60, ttl 32, id 29, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.52606 > 192.168.100.200.cisco-sccp: ., cksum 0xeb1d (correct), ack 310 win 8192
11:25:04.391191 IP (tos 0x0, ttl 32, id 30, offset 0, flags [none], proto TCP (6), length 44) 192.168.100.151.50798 > 192.168.100.200.cisco-sccp: S, cksum 0x7034 (correct), 221110801:221110801(0) win 8192 <mss 1400>
11:25:04.391583 IP (tos 0x0, ttl 32, id 31, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.50798 > 192.168.100.200.cisco-sccp: ., cksum 0x1179 (correct), ack 1235627142 win 8192
11:25:04.414604 IP (tos 0x60, ttl 32, id 32, offset 0, flags [none], proto TCP (6), length 104) 192.168.100.151.50798 > 192.168.100.200.cisco-sccp: P 0:64(64) ack 1 win 8192
11:25:06.396499 IP (tos 0x60, ttl 32, id 33, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.50798 > 192.168.100.200.cisco-sccp: ., cksum 0x10fd (correct), ack 61 win 8192
11:25:06.413440 IP (tos 0x60, ttl 32, id 34, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.50798 > 192.168.100.200.cisco-sccp: F, cksum 0x1004 (correct), 64:64(0) ack 309 win 8192
11:25:06.413892 IP (tos 0x60, ttl 32, id 35, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.50798 > 192.168.100.200.cisco-sccp: ., cksum 0x1003 (correct), ack 310 win 8192
11:25:38.603113 IP (tos 0x0, ttl 32, id 36, offset 0, flags [none], proto TCP (6), length 44) 192.168.100.151.50990 > 192.168.100.200.cisco-sccp: S, cksum 0xbae2 (correct), 3350912021:3350912021(0) win 8192 <mss 1400>
11:25:38.603517 IP (tos 0x0, ttl 32, id 37, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.151.50990 > 192.168.100.200.cisco-sccp: ., cksum 0x4519 (correct), ack 1083788449 win 8192
11:25:38.626534 IP (tos 0x60, ttl 32, id 38, offset 0, flags [none], proto TCP (6), length 104) 192.168.100.151.50990 > 192.168.100.200.cisco-sccp: P 0:64(64) ack 1 win 8192

Gleichzeitig lief auf dem neuen * ebenfalls tcpdump:

Code: 
11:23:58.153530 arp who-has 192.168.100.151 tell 192.168.100.151
11:23:58.155043 arp who-has 192.168.100.99 tell 192.168.100.151
11:23:58.344264 arp who-has 192.168.100.200 tell 192.168.100.151
11:24:02.807106 arp who-has 192.168.100.252 tell 192.168.100.151
11:24:06.818020 IP (tos 0x60, ttl 64, id 3, offset 0, flags [none], proto UDP (1                     7), length 60) 192.168.100.151.49152 > 192.168.100.252.tftp:  32 RRQ "CTLSEP0015                     F97F426E.tlv" o
11:24:06.984661 IP (tos 0x60, ttl 64, id 4, offset 0, flags [none], proto UDP (1                     7), length 61) 192.168.100.151.49153 > 192.168.100.252.tftp:  33 RRQ "SEP0015F97                     F426E.cnf.xml"
11:24:06.987883 IP (tos 0x60, ttl 64, id 5, offset 0, flags [none], proto UDP (1                     7), length 32) 192.168.100.151.49153 > 192.168.100.252.32776: UDP, length 4
11:24:06.989121 IP (tos 0x60, ttl 64, id 6, offset 0, flags [none], proto UDP (1                     7), length 32) 192.168.100.151.49153 > 192.168.100.252.32776: UDP, length 4
11:24:06.990316 IP (tos 0x60, ttl 64, id 7, offset 0, flags [none], proto UDP (1                     7), length 32) 192.168.100.151.49153 > 192.168.100.252.32776: UDP, length 4
11:24:06.991555 IP (tos 0x60, ttl 64, id 8, offset 0, flags [none], proto UDP (1                     7), length 32) 192.168.100.151.49153 > 192.168.100.252.32776: UDP, length 4
11:24:06.992703 IP (tos 0x60, ttl 64, id 9, offset 0, flags [none], proto UDP (1                     7), length 32) 192.168.100.151.49153 > 192.168.100.252.32776: UDP, length 4
11:24:11.820403 arp reply 192.168.100.151 is-at 00:15:f9:7f:42:6e (oui Unknown)

Und hier der Vollständigkeit halber noch die Ausgabe von in.tftpd:
Code: 
Nov 13 10:24:06 [in.tftpd] RRQ from 192.168.100.151 filename CTLSEP0015F97F426E.tlv_
Nov 13 10:24:06 [in.tftpd] sending NAK (1, File not found) to 192.168.100.151
Nov 13 10:24:06 [in.tftpd] RRQ from 192.168.100.151 filename SEP0015F97F426E.cnf.xml_

Warum das Telefon immer noch auf den alten Server will, verstehe ich nicht...

Grüße,
2bbionic
 
Ich will mich jetzt hier nicht über die Art und Weise der Programmierung der Firma Cisco auslassen...

Prüfe mal welcher tftpd auf dem alten und welcher auf dem neuen Server installiert ist.
 
hast Du schonmal einen kompletten Reset des Telefons probiert und getestet wo das Teil dann sucht?
 
Da Dein 7970 Dir etwas von "Registering"... anzeigt,
würde ich Dein Problem beim Asterisk vermuten.

Die DHCP-Option "filename "xmlDefault.cnf.xml" brauchst Du nicht, denn findet das Telefon seine Confs mit der Mac des Fons nicht, sollte ihm die Defaultconf reichen.

Die DHCP-Option 150, ist der Tftp-server und nicht der filename !

Probiere einfach mal den * mit "asterisk -vvvvv &" zu starten und schau Dir dann das Debug an, wenn Du Dein 7970 anstellst.

<NACHTRAG>
Da hatte ich doch glatt den zweiten Asterisk überlesen.
Nun würd auch ich es auf beta's Metode probieren.
SORRY.
</NACHTRAG>
 
Zuletzt bearbeitet:
@betateilchen: Kompletter Reset will ich vermeiden, da ich (noch) keine Firmware für das Teil habe.
Der TFTP-Server sind auf beiden Rechnern identisch.

Auch dem Cisco eine andere IP zu verpassen half nicht - das 7970 hat sich zwar brav seine neue IP abgeholt, aber wollte wieder zum alten Server connecten...

Versuchsweise habe ich den alten * abgeschaltet und den neuen mit der IP des alten hochgefahren. Das funktionierte seltsamerweise.
Kurios wurde es, als ich das ganze rückgängig machen wollte: alter Server mit alter IP, neuer Server mit neuer IP. Das ging dann auf einmal auch nicht mehr!

Meine Vermutung hier: Um sicherzugehen, dass er wirklich alle Daten zieht, habe ich das Telefon kurz stromlos gemacht - die Betonung liegt auf kurz. Anscheinend hat das Teil einen ARP-Cache oder merkt sich sonstwas, jedenfalls hat er zwar die richtige IP angesprochen; konnte sich aber nicht connecten. Ich habe dann ca. 20 Minuten mit stromlosen Telefon gewartet - dann ging es wieder (auf dem alten Server mit der alten IP).

Das bringt mich jetzt erstmal aber nicht weiter, warum das Cisco den neuen Server nicht fressen will, wenn er in der SEPXXX steht. Was ich noch nicht getstet hatte - mich hat für heute die Lust verlassen - ist, ob es funktionieren wird, wenn ich das Telefon nach einer stromlosen Phase an den neuen * mit der neuen IP connecten lasse.

Falls jemand hier noch eine Idee haben sollte - her damit, ansonsten schon mal Danke...

Grüße,

2bbionic
 
<nur mal so nebenbei>
Wie lange Du das Telefon stromlos machst, spielt keine Rolle. Das Telefon behält die Firmware auch im stromlosen Zustand.
</nur mal so nebenbei>
 
Ja, schon klar, ich dachte da eher an einen Pufferspeicher für Arp-Caches oder was weiß ich - oder eine TTL für Serververbindungen
Die Firmware wird ja IMHO nur gelöscht, wenn ich mit *123456789* (oder so ähnlich) resete.
 
Um antworten zu können musst du eingeloggt sein.
Kostenlos!
Jetzt holen

Neueste Beiträge

Kategorien

Wissenswertes

Statistik des Forums

Themen
248,862
Beiträge
2,303,106
Mitglieder
378,516
Neuestes Mitglied
jpttpee

3CX jetzt einen Monat kostenlos testen

Die Verbindung, Zusammenarbeit und Kommunikation mit Ihrem Team und Ihren Kunden war noch nie so einfach. Nutzen Sie unsere kostenlose 30-Tage-Testversion und entdecken Sie die richtige Lösung für Ihr Unternehmen.

3CX start your free trial guy
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten