virtual IP trotz abgewähltem Freetz-Paket

[m.kress]

Hallo,
mein Speedport hat eine "alte" virtual-IP bekommen (eth0:1), obwohl ich das entspechende Freetz Paket, wo es mal mit hab einbauen lassen, mittlerweile nicht mehr verwende. D.h. ich habe ein neues Freetz-Paket gebaut ohne virtual-IP, aber virtual-IP wird trotzdem wieder gesetzt. In der /var/flash/freetz ist die IP noch zu finden. Wie krieg ich die jetzt da wieder raus ohne /var/flash/freetz komplett zu leeren?
Gruß
Markus

 

[olistudent]

Wenn das Paket nicht im Image ist, dann wird auch keine virtuelle IP gesetzt.

MfG Oliver

 

[m.kress]

Dann frag ich mich, woher das eth0:1 kommt, dazu ist die gesetzte IP, die gleiche wie ich sie für's virtual-IP mal gesetzt hatte (192.168.2.254). Dazu finden sich ja auch noch Reste der Konfig in der freetz-Konfigdatei.
Gruß
Markus

 

[olistudent]

Schonmal in die ar7.cfg geschaut? Was stehen denn da für Devices drin?

MfG Oliver

 

[m.kress]

Bin jetzt ein Stück weiter. Hab mal den int./ext. Schalter auf von ext. auf int. geschaltet. Daraufhin wurde eine alte IP 192.168.1.245 verwendet (ich habe mein Netz vorgestern von 192.168.1.0/24 auf 192.168.201.0/24 umgestellt. Die IP's hab ich in der inkonsistenten Einstellungsvariante korrigiert (der Schalter umgestellt, aber nicht im WebIf). Dann wieder zurück auf die konforme Einstellung mit ext. Schalter und Zugang über LAN1.

So siehts jetzt aus:

lan       Link encap:Ethernet  HWaddr 00:1A:4F:81:BE:12  
          inet addr:192.168.201.245  Bcast:192.168.201.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:38 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3528 (3.4 KiB)  TX bytes:4767 (4.6 KiB)

lan:0     Link encap:Ethernet  HWaddr 00:1A:4F:81:BE:12  
          inet addr:192.168.2.254  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

Du warst jetzt scheller. Ja, in der ar7.cfg steht was drin:

ar7cfg {
        mode = dsldmode_bridge;
        tsdisabled = yes;
        igddenabled = yes;
        igdd_control_enabled = no;
        wan_bridge_with_dhcpc = no;
        wan_bridge_gateway = 192.168.201.254;
        dhcpc_use_static_dns = yes;
        ethmode = ethmode_bridge;
        StatisticStartOfMonth = 1;
        macdsl_override = 00:00:00:00:00:00;
        ethinterfaces {
                name = "eth0";
                dhcp = no;
                ipaddr = 192.168.201.245;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = no;
                dhcpstart = 192.168.2.20;
                dhcpend = 192.168.2.200;
        } {
                name = "eth0:0";
                dhcp = no;
                ipaddr = 192.168.178.254;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
        } {
                name = "usbrndis";
                dhcp = no;
                ipaddr = 192.168.179.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
        } {
                name = "wlan";
                dhcp = no;
                ipaddr = 192.168.182.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "tiwlan0", "wdsup0", "wdsdw0", "wdsdw1", 
                             "wdsdw2", "wdsdw3";
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
        }
        brinterfaces {
                name = "lan";
                dhcp = no;
                ipaddr = 192.168.201.245;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "eth0", "usbrndis", "tiwlan0", "wdsup0", 
                             "wdsdw0", "wdsdw1", "wdsdw2", "wdsdw3";
                dhcpenabled = no;
                dhcpstart = 192.168.2.20;
                dhcpend = 192.168.2.200;
        } {
                name = "lan:0";
                dhcp = no;
                ipaddr = 192.168.2.254;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
        }
        dslinterface {
                name = "dsl";
                dhcp = no;
                ipaddr = 192.168.179.1;
                netmask = 255.255.255.255;
                dstipaddr = 192.168.179.1;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
        }
        dslinterface_metric = 2;
        pppoefw {
                interfaces = "usbrndis", "eth0", "tiwlan0", "wdsup0", 
                             "wdsdw0", "wdsdw1", "wdsdw2", "wdsdw3";
                nofirewall = yes;
                ipnetbiosfilter = yes;
                dnsfilter_for_active_directory = yes;
                hostuniq_filter = "";
                dpconfig {

Darf ich die eth0:0 und lan0:0 Abschnitte entfernen? Ebenso hat das wlan Interface eine merkwürdige Adresse. Die wird sicherlich nicht verwendet, oder?

Am besten setze ich den Speedport ganz zurück. Nur wie, es gibt ja kein Recovery-Tool.

Wann betätige ich besten den ext./int. Schalter? Wenn der Speedport aus ist? Schalte ich schon vorher auch per WebIf den Modus um?



EDIT:
Hab jetzt den Speedport komplett zurückgesetzt:
ar7.cfg gelöscht.
moduninstall all-mods
Dann nochmals im WebIf auf Werkseinstellungen zurücksetzen.
Das Branding hab ich von AVM auf TCOM in der freetz-WebIf zurückgesetzt.

Ein ifconfig gibt folgendes aus:

lan       Link encap:Ethernet  HWaddr 00:1A:4F:81:BE:12  
          inet addr:192.168.201.245  Bcast:192.168.201.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:1785 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2082 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:162612 (158.8 KiB)  TX bytes:369947 (361.2 KiB)

lan:0     Link encap:Ethernet  HWaddr 00:1A:4F:81:BE:12  
          inet addr:192.168.2.254  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

Es gibt in der ar7.cfg weiterhin den folgenden Eintrag:

{
                name = "lan:0";
                dhcp = no;
                ipaddr = 192.168.2.254;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
        }

Ist ein lan:0 Interface mit dieser Adresse normal ?


EDIT:
lan:0 entfernt.

Mein Speedport kann sich auch nicht mehr bei einem SIP-Provider anmelden. Mit den Identischen Einstellung bei einer 7170 klappts. Das Problem war vor dem Zurücksetzen auch schon vorhanden.
Ein SIP-Client von einem PC aus (Softphone) kann sich an auf dem Speedport laufenden Asterisk anmelden, der SIP-Client des Speedports dagegen nicht. Man kann mittels SIP-Debug Option im Asterisk sehen, wie das Softphone sich registriert, keinerlei Meldungen treten beim internen SIP-Client des Speedports auf. Kann hier irgendwo meine Netzwerkkonfig. des SP eine Macke haben?

Gruß
Markus

Gruß
Markus

 

[m.kress]

* schieb *, da ich immer wieder editiert habe.

 

[olistudent]

Hi.
Das ist die Notfall IP im Adressbereich den der Windows dhcp vergibt, wenn kein dhcp-Server erreichbar ist.
Wobei die bei mir "169.254.1.1" ist. Aber vielleicht liegt das an den defaults der Firmware.

MfG Oliver

 

[m.kress]

Danke. Und die war genau meine virtuelle IP, welche ich irgendwann mal konfiguriert hatte. Is auch ein blöder Zufall...
Jetzt such ich weiter nach meinem Voip Problem. Die voip.cfg hab ich schon ausgetauscht mit der meiner 7170. Half nix. Die 7170 kann sich auch an dem Speedport's Asterisk anmelden, nur der Speedport selbst nicht. Bind-Adresse hab ich auch schon geprüft und nutze immer die 192.168.201.245, egal ob von lokal oder remote. Irgendwo da muß das Problem aber liegen.

 

[m.kress]

Hallo Olistudent,
es wird kein voipd -R ausgeführt, deshalb gibt es keine Registrierung. Ich habe mit tcpdump und strace nachgeschaut. Warum geht das nicht? Sollte doch eigentlich bei Änderungen am WebIf und beim Starten gemacht werden. Asterisk habe ich dabei nicht am Laufen.
Gruß
Markus

 

[olistudent]

Das kann ich dir nicht sagen. Ich hatte mal was gelesen, dass sich irgendwelche Firmwares seltsam verhalten und falsch am Asterisk anmelden. Aber davon hab ich keine Ahnung.

MfG Oliver

 

[m.kress]

Nur das hier jetzt kein Asterisk mehr drauf ist. Wie gesagt der SIP-Clients (die Internetrufnummern) auf dem Speedport gehen alle nicht, egal wohin, auch die sich z.B. bei SIP-Gate anmelden.
Ein simples voipd -R behebt ja auch die Probleme. Ich frage mich nur warum der Speedport das nicht von selbst mehr macht.
Dann werde ich mal weiterschauen... Wir irgendwas dummes sein.

Eine Frage dazu noch:
Hab ich beim Zurücksetzen irgendwas vergessen?

Das hab ich gemacht zum Zurücksetzen:

ar7.cfg gelöscht.
moduninstall all-mods
Im WebIf auf Werkseinstellungen zurücksetzen.
Das Branding hab ich von AVM auf TCOM in der freetz-WebIf zurückgesetzt.

Das könnte ich noch machen (wenn's Sinn macht):

Original FW per adam2 drauf werfen.
Das Enviroment im adam2 prüfen.

Gruß
Markus

 

[olistudent]

Probier doch mal mit original Firmware. Dann wissen wir wenigstens, ob wir weitersuchen müssen.

MfG Oliver

 

[m.kress]

Hallo Olistudent,

die Original-Firmware funktioniert soweit. Auch hier habe ich einen Werksreset durchgeführt.

Was ich aber herausgefunden habe:

Der Speedport läuft bei mir als IP-Client (das geht ja mit der t-com Firmware so nicht). Als IP-Client kann ich die IP, sowie Nameserver und Gateway setzen oder per DHCP vergeben lassen. Per DHCP klappt die Anmeldung z.B. bei SIP-Gate. Vergebe ich IP, Nameserver und Gateway von Hand, geht die Anmeldung bei SIP-Gate nicht.

Das ganze habe ich mit einer minimal Freetz-Firmware (1939) getestet gebaut (keine Pakete, außer strace und tcpdump), vorher habe ich den Trunk komplett von der Platte gelöscht und neu gebaut.

Bei einem alten Freetz-Trunk (1845), bei der es sicher geklappt hatte, geht jetzt auch nicht mehr.

Durch meine IP-Unstellung (192.168.1.0/24 auf 192.168.201.0/24) könnte es sein, dass eine irgendwo eine IP aus 192.168.1.x versteckt konfiguriert war, die durch das Resetten jetzt nicht mehr da ist. Zeitlich würde das ganz gut zusammenpassen. Wie gesagt, mit DHCP geht eine auto. Anmeldung, ohne muß ich mit voipd -R das Anmelden anstossen.

Gruß
Markus

Gruß
Markus

 

[olistudent]

Kannst du denn im Strace einen Unterschied zwischen den beiden Fällen erkennen?

MfG Oliver

 

[m.kress]

Das blöde ist, dass der voipd immer neu gestartet wird, sobald an den VOIP Einstellungen gedreht und übernommen wird (warum?). Eine evtl. mit voipd -R hergestelle und vorhandene SIP-Registrieung geht dann verloren und wird dann auch nicht mehr wiederhergestellt, bis ich voipd -R wieder eingebe. voipd -R wird bei diesen Aktionen von der Firmware anscheinend nicht verwendet.
Mit strace ist dann leider nicht viel zu machen, wenn die Prozess immer wieder neu gestartet wird. Ge'strace'ed hab ich die websrv's, in der Hoffung ein voipd -R zu finden. Da war aber nix zu finden.

Ich überlege ob's evtl. sogar ein Feature ist. Nur fehlt mir ein sinnvoller Grund warum es bei DHCP geht und bei fest IP nicht.

Gruß
Markus

 

[olistudent]

Irgendwie kommt mir das Problem aus früheren Zeiten bekannt vor. Da haben die Leute dann eine Endlos-Schleife mit "voipd -R;sleep 60" aufgerufen.
Vielleicht solltest du eine 7170 Alien Firmware für deinen Anwendungsfall bauen. Ich denke, dass wäre die einfachste Lösung.

MfG Oliver

 

[m.kress]

Ich habe auch die älteren Threads gelesen. Da ging i.d.R. um die Neuregistrierung, wenn sich die IP eines vorgeschalteten Routers geändert hat. Von Bug's war da nie die Rede. Falls sich keine Lösung finden sollte, muß ich es halt auch so machen.

Es ging aber scheinbar schon, wobei ich auch nicht mehr weiss, was ich alles geändert habe (man ändert und testet, irgendwann gehts halt nicht mehr. Zumindst habe ich nie DHCP für's LAN eingeschaltet gehabt, danach habe ich bereits die Remote Syslogs durchsucht. Die Firmware kann ich auch ausschließen, da hab ich schon viel ältere getestet. Hatte vorher mal die tr069.cfg geändert, aber nur minimal. Die debug.cfg ist immer leer gewesen.

EDIT:
So habe sicherheitshalber statt mit Open-Suse 10.2 mal mit Stinky das freetz (1943) erstellt. Keine Veränderung.

EDIT2:
Die original FW unterstützt kein IP-Client Modus. Da ja vieles aus der Speedport-Firmware stammt, könnte es also normal sein mit der fehlenden Anmeldung.

Gruß
Markus

 

[m.kress]

Mit Freetz-Alienimage (Speedport_W_900V.AnnexB.34.04.39-7622_beta2.image) gehts. SIP wird jetzt automatisch registiert.