Freetz auf 29.04.57

[olistudent]

ctlmgr -s
ctlmgr -fv

?

MfG Oliver

 

[wengi]

/var/mod/root # ctlmgr -s
/var/mod/root # ctlmgr -fv
ctlmgr: process priority is 19
ctlmgr: [main.c:821] **** cwd -> {/var/mod/root}
/var/mod/root # ctlmgr: /var/flash/user.cfg:10: member mac not found in ST_struct internet_user
ctlmgr: /var/flash/user.cfg:10: member mac not in internet_user, try to recover
ctlmgr: load_config(user): warning: converted
ctlmgr: /var/flash/tr069.cfg: is empty
ctlmgr: FactoryDefault=/etc/default/avm/tr069.cfg (tr069)
ctlmgr: load_config(tr069): factory default loaded
ctlmgr: dlopen(/usr/share/ctlmgr/libdect.so) failed: File not found
ctlmgr: VPNConn_Register called...
ctlmgr: internal vcc:
ctlmgr:   name=voip vpi=1 vci=32 encap=1 sep_config=0 vcc=0x2aab6840
ctlmgr:   name=internet vpi=1 vci=32 encap=1 sep_config=0 vcc=0x2aab6840
ctlmgr: UNMAP budget,0
ctlmgr: DOUBLE pppoe,0 TO info,0
ctlmgr: box init ok
ctlmgr: ipmasqfwruleex_parse ret=0 'tcp 0.0.0.0:0 0.0.0.0:0 1 out'
ctlmgr: forwardrules: parse errror
ctlmgr: ipmasqfwruleex_parse ret=0 'udp 0.0.0.0:0 0.0.0.0:0 1 out'
ctlmgr: forwardrules: parse errror
ctlmgr: ipmasqfwruleex_parse ret=0 'udp 0.0.0.0:1194 0.0.0.0:1194'
ctlmgr: forwardrules: internal rule
ctlmgr: ipmasqfwruleex_parse ret=0 'udp 0.0.0.0:5060 0.0.0.0:5060'
ctlmgr: forwardrules: internal rule
ctlmgr: ipmasqfwruleex_parse ret=0 'tcp 0.0.0.0:22 0.0.0.0:22'
ctlmgr: forwardrules: internal rule
ctlmgr: ipmasqfwruleex_parse ret=0 'tcp 0.0.0.0:222 192.168.201.253:22 0 # SSH Blechbuechse'
ctlmgr: FWRule ON TCP 222 192.168.201.253 22
ctlmgr: ipmasqfwruleex_parse ret=0 'tcp 0.0.0.0:65534 192.168.201.253:65534 0 # transmission'
ctlmgr: FWRule ON TCP 65534 192.168.201.253 65534
ctlmgr: ipmasqfwruleex_parse ret=0 'tcp 0.0.0.0:223 192.168.201.252:22 0 # SSH Schaetzchen'
ctlmgr: FWRule ON TCP 223 192.168.201.252 22
ctlmgr: ipmasqfwruleex_parse ret=0 'tcp 0.0.0.0:8089 0.0.0.0:8089'
ctlmgr: forwardrules: internal rule
ctlmgr: ipmasqfwruleex_parse ret=0 'udp 0.0.0.0:5060 0.0.0.0:5060'
ctlmgr: forwardrules: internal rule
ctlmgr: ipmasqfwruleex_parse ret=0 'tcp 0.0.0.0:5060 0.0.0.0:5060'
ctlmgr: forwardrules: internal rule
ctlmgr: ipmasqfwruleex_parse ret=0 'udp 0.0.0.0:7078+32 0.0.0.0:7078'
ctlmgr: forwardrules: internal rule
ctlmgr: next auto check for firmware updates sheduled in 473905 seconds (2008-05-19 04:15:42)
ctlmgr: sipextra my_init
ctlmgr: capiotcp My_Init
ctlmgr: FactoryDefault=/etc/default/avm/vpn.cfg (vpn)
ctlmgr: load_config(vpn): factory default loaded
ctlmgr: VPNConn_Register called...
ctlmgr: VPNConn_Init called...
ctlmgr: /dev/avm_power <-- MODE=dsl
ctlmgr: WAN (ata) led value = 0
ctlmgr: [../webserver/webserver.c:583] Initialisation of webserver configuration
ctlmgr: symbol TI_Interpreter_LookupDBField not found
ctlmgr: startup (Apr 22 2008 11:01:35)
ctlmgr: [main.c:1163] *** WEBSERVER started successfully
ctlmgr: status change eth-interfaces
ctlmgr: box_led_update_status
ctlmgr: got led event 16
ctlmgr: Now doing actions: ActionMask is 0x2000
ctlmgr: calling samba_control reconfig_pw

/var/mod/root # cat /etc/default/avm/tr069.cfg
tr069cfg {
   enabled = no;
   igd {
      managementserver {
         url = "";
             username = "";
             password = "";
             URLAlreadyContacted = no;
      }
   }
   FirmwareDownload {
       enabled = no;
   }
}

Ich sollte vielleicht noch erwähnen, dass auf Port 80 was lauscht, mir allerdings nur eine weiße Seite präsentiert.
wengi

EDIT:
Ich arbeite über einen ssh-Tunnel! Wenn ich mit lynx auf die Weboberfläche gehe bekomme ich die normale Meldung:"Die FRITZ!Box Benutzeroberfläche basiert auf XHTML-Frames. Ihr Browser ..."

EDIT2:
Die weiße Seite, die geliefert wird, hat den (richtigen?) Quelltext. Angezeigt wird dennoch nichts.

 

[olistudent]

Gehst du vielleicht von extern auf das Webinterface? Ich kann an dem Log nichts auffälliges erkennen.

MfG Oliver

 

[McNetic]

Ist das vielleicht diese komische Referer-Geschichte (ich erinner mich nicht mehr genau)?

 

[matze1985]

versuche mal den HTTP_Referer auszuschalten:
http://www.ip-phone-forum.de/showpost.php?p=904577

 

[wengi]

Hallo alle,

danke für Eure Rückmeldungen. Es liegt, wie ich inzwischen weis, auf jeden Fall am ssh tunnel.

Auch jetzt, im lokalen Netz, funktioniert es NICHT über einen ssh Tunnel.
Direkt funktioniert es.

Also habe ich, wie matze vorgeschlagen hat, den HTTP_Referrer abgeschaltet.
Und siehe da: Es funktioniert

Der technische Hintergrung wäre wirklich sehr interessant, da es bei mir erst seit der oben erwähnten Firmware auftritt.

Danke
wengi

 

[CROCOP]

Hi,

naja dann passt was nicht mit der virtuellen IP einfach mal am anfang der debug.cfg folgende Zeile einbauen , dann geht das auch wieder mit der virtuellen IP

# portinterface
ifconfig eth0:1 192.168.178.253 netmask 255.255.255.0 up

 

[Tommyland78]

ctlmgr -s
ctlmgr -fv

?

MfG Oliver

Also Oliver, wenn ich mir dann das Ergebnis von "wengi" ansehe - hab das bei mir auch mal getestet - dann hab ich da mal ne Frage zu.

Wenn ich mir das also so ansehe, dann kann ich doch festlegen, dass gewisse Protokolle mit bestimmten Ports auf bestimmte, andere IP´s bzw. Ports weitergeroutet werden. Ich weis jetzt zwar nicht in welcher Datei ich das find, vermute mal die ar7.cfg, aber was mich jetzt interessiert...mal eben an Hand eines Beispiels:
Das hab ich unter anderem als Ergebnis:

ctlmgr: FWRule ON TCP 46612 192.168.1.50 46612
ctlmgr: ipmasqfwruleex_parse ret=0 '# tcp 0.0.0.0:81 192.168.178.252:81 0 # Freetz'

Wenn ich jetzt eine Regel erstelle mit:

ctlmgr: FWRule ON TCP 1111 192.168.1.50 1111
ctlmgr: ipmasqfwruleex_parse ret=0 '# tcp 0.0.0.0:1111 192.168.178.253:1111 0 # Freetz'

Würde es doch so sein, das ankommende Pakete TCP mit Port 1111 auf die 192.168.178.253 mit Port 1111 geroutet werden???

Im Grunde kann ich das ja in der Portfreigabe des Webinterfaces einstellen, ich frage deshalb nach, da ich bei meiner internen Portweiterleitung auf die FritzBox zwar am Interface einen ausgehenden Traffic sehe, aber keinen eingehenden. Ich vermute daher, dass die Box die Weiterleitung auf die 0.0.0.0 routet und nicht auf das virtuelle Interface 192.168.178.253. Somit würde sich der fehlende "eingehende" Traffic erklären.

Ich hoffe Du kannst mir folgen was ich meine. Ich häng mal nen Pic mit rann. Da ist gut zu sehen das es ausgehenden Traffic gibt, leider keinen eingehenden. Ich hoffe mit diesem Trick das zu lösen.