Aastra Dect GW - Link Konfigurationsdateien

Support
,
1

Beim Einrichten eines Aastra Dect GW
ist vorgesehen, dass die Konfiguration
(RFPs und Mobilteile)
exportiert werden kann.

Leider führen die beiden Links unter “Konfigurationsdateien”





  - [RFP Konfiguration herunterladen](http://mobydickcmd:mobydick@10.202.10.2/services/trc052703/17/radio_fixed_parts.csv) 
  - [Mobilteil Konfiguration herunterladen](http://mobydickcmd:mobydick@10.202.10.2/services/trc052703/17/portable_parts.csv)

nur zu jeweils leeren Seiten.
Die entsprechende URL sieht unverdächtig aus. Scheint das REST API zu verwenden.
z.B.:


http://mobydickcmd:mobydick@10.202.10.2/services/trc052703/17/portable_parts.csv

In den logs findet sich nirgends ein Hinweis auf einen Fehler.

Wie sollte das aussehen?

Das Ganze ist deswegen ärgerlich, da ohne diese Datei die intern vergebenen Passwörter für die Mobilteile “geraten” werden müssen.

Rainer

2

Hallo Rainer,

Die Links die du gepostet hast, sind auf jeden fall exakt so wie sie sein sollten, es existieren in der Tat 2 REST-Aufrufe die die jeweiligen Konfigurationsdateien erzeugen.

Welchen Browser verwendest du zum herunterladen der Dateien? - Mit einem aktuellen Chrome oder Firefox sollte es problemlos funktionieren.

Grüße,
Jan

3

Browser ist Firefox 21.0 (auf OpenSuse 12.3)
Also eigentlich unverdächtig…

4

Könntest du bitte die Logdateien /var/log/zend/php.log und /var/log/zend/error.log überprüfen, ob es dort zu Irgendwelchen PHP- bzw. Apache-Fehlern kommt? - Ich habe mal ein Bug-Ticket aufgenommen, allerdings brauche ich mehr Informationen, da es in unseren Testfällen hier einwandfrei funktioniert.

Grüße,
Jan

5

php.log ist ohne Einträge.
In zend/error.log gibt es für meinen aktuellen Test folgende Einträge:


[Mon Jun 10 23:15:28 2013] [error] [client 10.202.1.4] File does not exist: /var/www/favicon.ico
Device "eth0" does not exist.
Device "eth0" does not exist.
[Mon Jun 10 23:18:40 2013] [error] [client 10.202.1.4] File does not exist: /var/www/favicon.ico
[Mon Jun 10 23:18:40 2013] [error] [client 10.202.1.4] File does not exist: /var/www/favicon.ico

Die Referenz auf favicon.ico ist wohl dem Browser geschuldet.
Eher verwundert mich die Meldung zum fehlenden eth0.
Das device gibt es tatsächlich nicht.
(Das System bietet nur: bfx0, br0, eth1, eth2, lo, tun)
Es sollte also niemand auf diue Idee kommen, eth0 zu referenzieren…

6

Hmmm.

Könntest du das ganze mit einem anderen Browser (Chromium, o. ä.) und möglicherweise mit einem anderen Betriebssystem testen? Hast du irgendwelche Switches/Routers/VLans etc. zwischen dir und der MobyDick?

Grüße,
Jan

7

Auf die Schnelle leider nicht.
Auf meinen NetBSD servern ist kein X installiert.
Und der Zugriff via curl scheitert an Authorization oder Authentication (< HTTP/1.1 500 You don’t have the permission to download this file)

8

Und eine andere Browser-Version? Auf deinem Opensuse müsste ja eigentlich noch was installiert sein. Hier kann ich das Problem im moment leider nicht nachvollziehen, Es funktioniert mit Firefox 21.0 und Chrome 27…

Grüße,
Jan

9

Habe den Konquerer wieder installiert - keine Änderung.
Allerdings ist ein Blick in access.log aufschlussreich.
Die beiden Zeilen zu den verscheidenen Browsern zeigen Code 401.
Liegt also irgendwo an Berechtigungen?


10.0.2.73 - mobydickcmd [12/Jun/2013:17:15:16 +0200] "GET /services/trc052703/17/portable_parts.csv HTTP/1.1" 401 481 "http://moby.pruy.de/mobydickcmd/index.php?u_trc=052703&u_ctxtrc=051801&u_id=17" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) konqueror/4.10.3 Safari/534.34"
10.0.2.73 - mobydickcmd [12/Jun/2013:17:19:10 +0200] "GET /services/trc052703/17/portable_parts.csv HTTP/1.1" 401 481 "http://moby.pruy.de/mobydickcmd/index.php?u_trc=052703&u_ctxtrc=051801&u_id=17" "Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0"

Das bringt mich wieder zum Test mit curl.
Der Dialog ist folgender:


curl -v   -e 'http://moby.pruy.de/mobydickcmd/?u_trc=052703&u_ctxtrc=051801&u_id=17' http://mobydickcmd:mobydick@10.202.10.2/services/trc052703/17/portable_parts.csv
* About to connect() to 10.202.10.2 port 80 (#0)
*   Trying 10.202.10.2... connected
* Connected to 10.202.10.2 (10.202.10.2) port 80 (#0)
* Server auth using Basic with user 'mobydickcmd'
> GET /services/trc052703/17/portable_parts.csv HTTP/1.1
> Authorization: Basic bW9ieWRpY2tjbWQ6bW9ieWRpY2s=
> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
> Host: 10.202.10.2
> Accept: */*
> Referer: http://moby.pruy.de/mobydickcmd/?u_trc=052703&u_ctxtrc=051801&u_id=17
> 
< HTTP/1.1 500 You don't have the permission to download this file
< Date: Wed, 12 Jun 2013 15:33:58 GMT
< Server: Apache/2.2.16 (Debian)
< X-Powered-By: PHP/5.3.14 ZendServer/5.0
< Set-Cookie: PHPSESSID=2r9t3q48ptnli9td342gr2e0r4; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Connection: close
< Accept-Ranges: bytes
< Vary: Accept-Encoding
< Content-Length: 0
< Content-Type: text/html;charset=utf-8
< 
* Closing connection #0

und der zugehörige Log Eintrag:


10.202.10.2 - mobydickcmd [12/Jun/2013:17:33:58 +0200] "GET /services/trc052703/17/portable_parts.csv HTTP/1.1" 500 495 "http://moby.pruy.de/mobydickcmd/?u_trc=052703&u_ctxtrc=051801&u_id=17" "curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6"

Was auffällt ist, dass der lokale Zugriff einen Code 500 erzeugt, die remote Zugriffe einen Code 401.

Rainer

10

Hallo Rainer,

es ist zwar schon eine Weile her, aber es haben sich neue Erkentnisse ergeben. Hast du für deine MobyDick im DNS einen Hostnamen definiert und loggst dich darüber auf der Appliance ein?

Grüße,
Jan

11

Ja, das ist zutreffend.
Für die md appliance ist in meinem lokalen DNS ein Name definiert, der für die Zugriffe verwendet wird.

Gruß
Rainer

12

Hallo Rainer,

ich konnte das Problem finden & beheben, mit der MobyDick 7.08 wird der Download dann funktionieren. Ein Workaround bis dahin ist, das du die IP der Anlage anstatt den DNS-Namen im Browser eingibts, dann müsste es auch klappen.

Grüße,
Jan

13

Besten Dank!
Workaround funktioniert.
Und bis zur 7.08 ist es ohnehin nicht mehr weit.
Rainer