[PROBLEM] Bug im Snom Bootloader betreffend MTU Discovery

[ViennaAustria]

Hallo!

Wir haben in einigen Aussenstellen fremde Internetanbindungen und tunneln uns daher einen Bereich unseres Netzes dort hinein. Klappt wunderbar. Da wir keine Verschlüsselung brauchen und die CPU vom Concentrator nicht überlasten wollen, verwenden wir IPoIP Tunnels. Die sind sehr effizient, haben aber den Nachteil, dass sie die MTU Size auf 1480 reduzieren.

Snom hat damit im Normalbetrieb anscheinend keine Probleme. Möchte man jedoch ein Firmware Upgrade machen, funktioniert das nicht: es bleibt bei "loading file" stecken. Anscheinend schafft es der Bootloader nicht, die verringerte MTU von 1480 zu erkennen und bleibt stur bei 1500.

Blöde Sache. Weiss jemand Abhilfe?

Wir wollen die Apparate auch nicht für jedes Upgrade demontieren und "aussen anstecken" müssen...

Weiters blöd ist, dass es dabei anscheinend kein Timeout gibt. Ich hatte gestern Abend das Update per Webinterface bei einem Kollegen gestartet und heute morgen fand er das Gerät noch immer bei "loading file" vor. Hier gehört ein Mechanismus hinein, der nach ein paar Minuten abbricht, wenn die neue Datei nicht geladen werden kann, und den Apparat stattdessen normal hochfährt.

Grüsse,
Thomas

 

[Maik]

Da wird dir wohl nur der snom-Support helfen können. Mach bitte mal dort ein Support-Ticket auf und informier uns dann bitte hier, wenn der Bug behoben wurde.

EDIT: Der Bug hat übrigens nichts mit dem Bootloader zu tun sondern betrifft den Applications-Teil der Firmware (-j). Du solltest also erst mal noch versuchen, auf die neueste Version upzudaten.

 

[ViennaAustria]

Hallo!

Der Bug hat übrigens nichts mit dem Bootloader zu tun sondern betrifft den Applications-Teil der Firmware (-j). Du solltest also erst mal noch versuchen, auf die neueste Version upzudaten.

Das ist erfolgt (also derzeit 5.3.6 in allen Apparaten). Beim nächsten Update werden wir ja sehen, ob das Problem noch immer besteht. Vorher war 5.0 drin und damit ging's leider nicht.

Thomas

 

[Guard-X]

Das Problem ist meiner Meinung bei SNOM schon bekannt und wurde mit der neuen Fw behoben...

 

[ViennaAustria]

Hallo!

Das Problem ist meiner Meinung bei SNOM schon bekannt und wurde mit der neuen Fw behoben...

Leider besteht der Bug auch noch bei

System Information:
Phone Type: snom360-SIP
MAC-Address: xxxxxxxxxxxx
IP-Address: xxx.xxx.xxx.xxx
Application-Version: snom360-SIP 5.3.6
Rootfs-Version: snom360 jffs2 v3.35
Firmware-URL: http://www.snom.com/download/snom360-6.2-SIP-j.bin
Production Information: Mac: xxxxxxxxxxxx;Version:Standard;Hardware:snom360 (Revesion B);Lot:12 (June 2005)​

Das LAN bei einigen unserer Mitarbeiter hat eine MTU von 1476 (nötig wegen IPoIP Tunnel); alle anderen Geräte (Windows- und Linuxrechner; Printserver, ...) kommen damit zurecht, nur das Snom im Bootloader nicht: wenn ich ein Update auf 6.2 versuche, dann bleibt es wieder gleich nach dem Reboot beim Download hängen.

Dann habe ich versucht, den lokalen HTTP Proxy Server zu verwenden und in den Advanced Configs

http_proxy!: xxx.xxx.xxx.xxx:8080
​

eingetragen. Das hat aber auch nicht funktioniert. Das Telefon spricht zwar mit dem HTTP Proxy, "vergisst" aber anscheinend im HTTP Request auf den Servernamen:

1150706333.997     49 xxx.xxx.xxx.xxx TCP_DENIED/400 1583 GET /download/snom360-6.2-SIP-j.bin - NONE/- text/html
1150706362.716     86 xxx.xxx.xxx.xxx TCP_DENIED/400 1619 GET /status.cgi?user=benjamin&status=redirect-off - NONE/- text/html
1150706362.718      0 xxx.xxx.xxx.xxx TCP_DENIED/400 1609 GET /status.cgi?user=benjamin&status=dnd-off - NONE/- text/html
1150706362.811      1 xxx.xxx.xxx.xxx TCP_DENIED/400 1595 GET /snom360/snom360.php?mac=000413231E74 - NONE/- text/html
1150706362.833      4 xxx.xxx.xxx.xxx TCP_DENIED/400 1541 GET /dummy.htm - NONE/- text/html
1150706362.879      2 xxx.xxx.xxx.xxx TCP_DENIED/400 1579 GET /snom360/snom360-firmware.htm - NONE/- text/html

Was kann ich tun?

Thomas

 

[Guard-X]

Was sagt denn der SNOM Support dazu?

mfg Guard-X