Firmware-Update geht nicht - ATA defekt ?

[Morgi]

Danke, ab 40 gehts sowieso wieder bergab

 

[Morgi]

übrigens mein update auf 580 ist kläglich gescheitert.
So wie es hier schon einige Beschrieben haben: Nach update reset und das teil redet nicht mehr mit mir (also die Chinesin di da drin sitzt)
Auch über das WEB Interface kein mux.

...zurück auf 468 und alles ist in Butter....

 

[betateilchen]

Hast Du mal ein Update über den TFTP Server 217.20.120.121 probiert ? Am besten den ATA direkt an das DSL Modem hängen und ohne Router probieren.
Wenn wir eine Zeit ausmachen, wann Du das testen willst, dann kann ich online in mein SysLog schauen, ob es funktioniert, oder ob irgendein Fehler erkennbar ist.

 

[Morgi]

Danke , sehr nett aber bemüh dich mal nicht.
TFTP updates mach ich beruflich schon den ganzen Tag mit IP Telefonen.

wenns lokal net geht warum soll ich mir den ATA übers Internet zerschiessen ?

so dringend isses auch nicht. Ausserdem muss ich bis zum 20.8 noch 250 min telefonieren

 

[betateilchen]

Du kannst den ATA nicht per TFTP zerschießen - außerdem haben über diesen Server schon über 400 Geräte ihr Firmware-Update gezogen, warum soll das ausgerechnet bei DIR nicht funktionieren ?
Ich könnte Dir mit ziemlicher SIcherheit auch erklären, warum das lokal nicht geht, aber dazu habe ich im Moment keine Zeit.

 

[gboelter]

... also es hat jetzt geklappt!! FW 5.8 ist drauf!

Hallo Dominik,

gratuliere zum geglückten Update!

Günther

 

[ibooduoo]

die beiden Server ptbtime1 und ptbtime2 wurden bei der PTB schon vor längerer Zeit umbenannt. Um Probleme mit DNS-Einträgen zu vermeiden, sollte man nur noch die "neuen" Bezeichnungen verwenden.

Hmmm tasache ntp1.ptb.de und ntp2... gibts wirklich (hatte mich heute wahrscheinlich verschrieben :roll: ) aber ptbtime1 und ptbtime2 gibts auch (noch?) zeigen aber auf die selben IP-Adressen.

Hast Du zum Wechsel noch irgend nen offiziellen Link - hab bei der PTB und auch mit Google nix gefunden, das auf Problem mit ptbtime1 und 2. heindeutet. - Ne offizielle Aussage wäre zumindest für mich noch interessant.

Wer ganz sicher gehen will, kann in den Grandstream-Geräten auch direkt die IP-Adresse eintragen

Oder seinen eigenen NTP-Server. - Macht dann Sinn, wenn mann sowieso einen Rechner hat der immer läuft und kann damit sein eigenens Netzwerk incl. dem ATA mit der richtigen Zeit versorgen.

Grüße
Lutz

 

[Ralf]

ich wuerde mal versuchen den Router Netgear die F.w zu wechseln

mit der die ich jetzt drauf habe kann ich nicht updaten ( siehe Signatur )

mit der F.W wgr614v2.04_1.0.2. geht es

gruss ralf

 

[op-fuzzi]

hallo betateilchen.

habe ja von dir schon erfahren, das du den 486er von escbln hast "updaten" koennen. Da ist prima.

Waere sehr interessant zu erfahren, wie du das gemacht hast bzw. welchen Fehler "unsereiner" gemacht hat, das es nicht geht?

vielen Dank

pit

P.S Nehme an das du dem escbln die Firmware 1.058 aufgespielt hast. Wird er denn in Zukunft ueber den gs-info Server 217 020 120 121 neuer Update ohne Prbleme ziehen koennen?

 

[betateilchen]

Hallo Pit !

Erstens habe ich gleich die Firmware 1.0.5.9 aufgespielt und zweitens sollte es künftig keine Probleme mehr beim Update über die angegebene TFTP-IP geben, vorausgesetzt, der ATA hat einen DIREKTEN Internet-Zugang.

Wie ich das gemacht habe ? Ich habe den ATA an meinen speziell dazu eingerichteten "Grandstream-Reparatur-PC" gestöpselt (da laufen einige von mir selbst entwickelte Tools, die fast jede Fehlerquelle im ATA automatisch finden und darauf reagieren) und in weniger als 1 Minute war der ATA wieder voll funktionsfähig.

 

[superpit]

aber welchen Fehler hatte der Ata denn? Sorry fuer die Neugier.

Hatte gerade ein Gespraech mit einem Sipgatemitarbeiter (der auch hier im Forum liest und schreibt), der hat bei sich einen neuen 486er-Adapter genommen mit der alten 4x Firmware und ihn auf deinen TFTP-Server losgelassen, aber er hat sich keine Firmware gezogen (muss so gegen 16.10 gewesen sein). Ging nicht -genau wie bei mir.
Dann hat per lokalen TFTP die 5.090 drauf gemacht. Telefonieren konnte er aber er kam nicht mehr ins Webinterface.
Woran kann das liegen? Er will den 486er jetzt wieder auf die lezte 4er Version zurückflashen und mir das Teil dann so zuschicken, weil er an meinem 486er mit der 5.035 interessiert ist.

pit

 

[betateilchen]

@superpit

Der ATA hatte keinen Fehler. Punkt. Ende. Over & Out.
Und hör bitte auf, mich zusätzlich zu den Postings HIER immer das gleiche auch noch per PN zu fragen - es reicht, wenn ich es EINmal lese.

 

[escbln]

Irgendein Fehler muss aber doch da gewesen sein. Schliesslich hatte ich ihn über den WAN am DSL und er hat sich korrekt eingewählt. Über LAN-Anschluss kontte ich Internet nutzen. Jedoch hat er von keinem der TFTP-Server im Netz ein Update gezogen. Wie gesagt, der ATA war Router und direkt am DSL-Modem angeschlossen.

 

[superpit]

Der ATA hatte keinen Fehler. Punkt. Ende. Over & Out.
Und hör bitte auf, mich zusätzlich zu den Postings HIER immer das gleiche auch noch per PN zu fragen - es reicht, wenn ich es EINmal lese.

sorry, tut mirwirklich leid wenn ich dich damit genervt habe. Wird nicht wieder vorkommen.

vielen dank

pit

 

[loveless]

Router/Firewall und UDP

Hallo zusammen,

ich habe mal diesen Thread überflogen, weil ich eben vor demselben Problem stand, daß ein Firmware-Upgrade per TFTP nicht über meine Firewall funktionierte. Ich glaube, die tatsächliche Erklärung hier nicht gelesen zu haben. Verzeiht mir bitte, wenn es doch irgendwo dazwischen stand. Wer also außer mir keine Lust hat, mit einem eigenen TFTP-Server zu hantieren, sollte vielleicht weiterlesen.

TFTP benutzt UDP (und kein TCP). Als verbindungsloses Protokoll funktionieren mit UDP die üblichen Connection-Tracking-Methoden für TCP der gängigen Router nicht mehr: jedes eingehende UDP-Paket vom TFTP-Server wird sozusagen als neue eingehende Verbindung gewertet. TFTP funktioniert nicht über Standard-NAT! Ich will hier nicht ins Detail gehen (jedenfalls gehen die Antwortpakete des TFTP-Servers nicht an Port 69 und sie kommen auch nicht von Port 69), denn meine beiden Lösungsvorschläge sind eigentlich ganz einfach:

1. Für die Dauer des Upgrades alle von dem jeweiligen TFTP-Server eingehenden Pakete (oder zumindest UDP) an den ATA forwarden.
2. Meinem Linux-Router konnte ich ordentliches TFTP-Connection-Tracking ganz einfach durch Laden der beiden Module ip_conntrack_tftp und ip_nat_tftp beibringen.

Könnte sein, daß viele der Router im unteren Preissegment Lösung 1 nicht zulassen, weil sie eine spezifische Portangabe benötigen. Mein HT 486 "horchte" beim Upgrade auf Port 32874/udp, was aber durchaus von Firmware zu Firmware variieren könnte. Vielleicht läßt sich je nach Router der gesamte obere Portbereich kurzzeitig forwarden. Der Quellport des TFTP-Servers ist ziemlich sicher völlig unvorhersehbar.

Hoffentlich hilft Euch das weiter.

Grüße,
Christiane

 

[betateilchen]

Hallo loveless !

Danke für Deine Hinweise. Wenn es bei Dir so funktioniert hat - schön

Aber: eine grundsätzliche Lösung ist das nicht. Zumal es beim Update eines ATA486, der selbst Router ist und eine eigene TFTP-Logik zum Firmware-Update besitzt, ohnehin keinen anderen Router gibt, an dem man irgendwas einstellen würde.

Zum Thema Linux kann ich nur sagen, daß ich ausschließlich unter Linux arbeite und mit TFTP noch nie Probleme hatte - auch OHNE die von Dir erwähnten Module nachzuladen :wink:

 

[exim]

Re: Router/Firewall und UDP

@loveless: Super Erklärung!

Mein HT 486 "horchte" beim Upgrade auf Port 32874/udp, was aber durchaus von Firmware zu Firmware variieren könnte. Vielleicht läßt sich je nach Router der gesamte obere Portbereich kurzzeitig forwarden. Der Quellport des TFTP-Servers ist ziemlich sicher völlig unvorhersehbar.

Die Wahl der Ports zur Datenübertragung sollte bei TFTP auf beiden Seiten zufällig erfolgen, zumindest laut RFC. Ist jetzt noch die Frage wie das Grandstream implementiert hat.

Aber: eine grundsätzliche Lösung ist das nicht. Zumal es beim Update eines ATA486, der selbst Router ist und eine eigene TFTP-Logik zum Firmware-Update besitzt, ohnehin keinen anderen Router gibt, an dem man irgendwas einstellen würde.

Aber eben nur wenn der 486 selbst Router spielt. Wenn er als Client im LAN hängt oder der I-Net-Provider eine eigene NAT-Kiste einsetzt sieht das schon wieder anders aus.

Wenn man das LAN hinter NAT versteckt ist Connection Tracking speziell für TFTP ist ein Muß sonst wird TFTP hinter einem NAT-Router nicht funktionieren, genau so wenig wie FTP. FTP beherrschen alle NAT-fähigen Router, zumindest kenne ich keinen der es nicht kann. Doch bei TFTP sieht das leider schon ganz anders aus ...

 

[betateilchen]

naja - aber ist es nicht einfach weniger aufwendig, den ATA für das Firmware-Update einfach selbst als Router zu konfigurieren und die TFTP-IP einzutragen ? :wink:

 

[exim]

Das Einfachste wäre m.M.n. das Aufsetzen eines lokalen TFTP-Servers. Also ganz ohne NAT und externe IPs. Bei Linux-Distributionen ist sowieso mindestens ein tftpd dabei und bei Windows beschränkt sich das i.d.R. auf einen setup.exe-Doppelklick. So müssen weder ATA noch ein eventuell vorhandener Router umkonfiguriert werden. Und bei angedachten Updates in der Zukunft hat man den passenden TFTP dann gleich im Haus

 

[betateilchen]

ok - volle Zustimmung.

Aber vom ursprünglichen Thema, nämlich daß escbln ein Problem hat, sind wir inzwischen weit entfernt und auch das Problem ist längst geklärt.

Über Sinn, Zweck und Vorgehensweise bzgl. TFTP wurde und wird an anderer Stelle im Forum schon zur Genüge diskutiert :wink: