Hallo!
Seit heute kann ich mich auf meinem Comtrend VI-3223u nicht mehr mit der Standard-Kombination einloggen? Kann jemand bestätigen, daß Tele2 die geändert hat oder hab ich mir einen Virus eingefangen?
LG,
Chris
# base64 encoding
sum@sumThink ~ $ echo "my-root-pw-juhuu^^" | openssl base64 -e -a
bXktcm9vdC1wdy1qdWh1dV5eCg==
sum@sumThink ~ $
# base64 decoding
sum@sumThink ~ $ echo "bXktcm9vdC1wdy1qdWh1dV5eCg==" | openssl base64 -d -a
my-root-pw-juhuu^^
sum@sumThink ~ $
zid hat geschrieben:wenn du dich bei einem *privatanschluß* als root am comtrend anmeldest, kannst du dann tiefgreifende änderungen an der konfig (z.b. planieren der wartungschannels/tr069, umstieg von routing auf bridging usw.) vornehmen und diese änderungen auch rebootfest machen?
zid hat geschrieben:du kannst bei tele2 die gleiche nummer abziehen wie bei upc. s. die hochinteressante rückmeldung vom gandlz:
viewtopic.php?f=20&t=56479&p=468678&#p468459
da mußt nicht mal mim pw. rumwurschteln, liefert dir die hl von tele2 frei haus.
zid hat geschrieben:ad3)
die kistn ghört dir. wenn dein nachgeschalteter router nicht in der lage ist, mit irgendwelchen zwangstrennungen des providers umzugehen, dann ist das sicher nicht ein prob vom provider...
$ diff -U 1 -b -B -E i386-bridging.conf tele2-bridging.conf
zid hat geschrieben:>"...wenn ich in der backupsetting.conf die url vom configserver rauslösch und dann via "update settings" im webinterface uploade, bleiben die von mir gesetzen einstellungen erhalten..."
na seawas, da dürften die tecs von tele2 eine "kleinigkeit" übersehen haben...
und du hast die url vom acs jetzt wirklich rausgenommen?
zid hat geschrieben:>"...hab ich nun gemacht, im grunde machen die ja auch nichts anderes als die config am configserver zu editieren oder?..."
auf den papier mal ja. es könnte aber auch sein, daß tele2 bei der umstellung eine andre fw. mit eingebetteter bridge.conf aufs comtrend zieht, weil z.b. das bridging mir der routing fw. net gscheit funkt. möglicherweise werden bei der umstellung auf providerseite noch irgendwelche obskure zusatzeinstellungen vorgenommen, k.a.... faktum ist, daß beim gandlz, der bei der umstellung den offiziellen weg gegangen ist, das bridging funkt. soll jetzt nicht heißen, daß ich was gegen eigenregie hab. grad bei solchen nummern kann man sehr viel lernen (wenn man nicht gleich beim leichtesten gegenwind w.o. gibt)...
zid hat geschrieben:>"...es kann nicht an meinem router liegen - hab schon drei verschiedene geräte probiert (bei allen den keepalive aufgedreht)
sobald ich das comtrend ding reboote ist mein router wieder online..."
ich versteh deine ausführunmgen nicht ganz, gehen wir das ganze mal der reihe nach durch:
1. was meinst du mit "drei verschiedene geräte"?
welche router mit welcher fw. genau hast du getestet? sind das jetzt 3 exemplare ein und desselben modells, oder reden wir jetzt wirklich über 3 verschiedene modelle bzw. über ein und dasselbe modell, auf dem verschiedene fws. (openwrt, dd-wrt, tomato...) laufen?
ein paar screenshots deinen pppoe-configs oder (falls die konfig human readable is) die relevanten konfigabschnitte würden die diskussion erleichern.
zid hat geschrieben:2. mit deiner probbeschreibung kann ich nicht viel anfangen...
ich gehs mal durch, wie ich es versteh:
i.
du konfigurierst den pppoe-dialer, aktivierst ihn, die einwahl scheitert. wo genau? steht die pppoe-session und geht lcp den bach runter? oder kannst du gar keine pppoe-session starten? was sagen die logs? geht der ppp-link up, wenn du daten in richtung wan schickst?
ii.
du deaktivierst den dialer nicht und rebootest. die einwahl funkt. und was passiert dann? geht der link nach einer gewissen zeit wieder down oder wie? das würde auf dial-on-demand hindeuten.
bei einigen d-links gabs vor jahren zoff mit dem dem always-on bei pppoe. man konnte always-on zwar im webgui einstellen, die dinger blieben aber auf dial-on-demand. unmittelbare abhilfe bestand darin, mit einem rechner im lan alle paar minuten ein paar pings in richtung wan zu schicken, und irgendwann wurde das prob von d-link dann doch behoben. falls du ältere d-links verwendest, upgrade auf die aktuellste fw. durchführen.
zid hat geschrieben:3. wenn du (systematische) konfigfehler- net lachen, alles schon vorgekommen- und bugs bei den routern ausschließen kannst, bleibt nur noch das bridging am comtrend übrig.
und da kannst du aus meiner sicht nur einen vergleichstest machen, der ca. so ausschauen könnte:
i. fw. version aufschreiben und bridging.conf auf einem rechner sichern (ich werd diese konfig im folgenden
"i386-bridging.conf" nennen).
ii. routing.conf restaurieren, bei tele2 anrufen und auf bridging umstellen lassen.
iii. nach der umstellung fw-version checken (wär ja echt blöd, wenn...) und konfig sichern ("tele2-bridging.conf").
iv. testen, und da gibts nur 2 möglichkeiten:
- die einwahl mit den nachgeschalteten routern funkt noch immer nicht sauber => du hast zoff mit den routern, nimm ein mikrotik. da funkt pppoe sicher, verwend ich selbst.
- die einwahl funkt.
in dem fall die 2 konfigs diffen, also:
- Code: Alles auswählen
$ diff -U 1 -b -B -E i386-bridging.conf tele2-bridging.conf
so, und bei der diff gibts wieder 2 möglichkeiten, jetzt wirds lustig...
- die konfigs sind bis auf ein paar irrelevante kleinigkeiten ident. dann muß man davon ausgehen, daß tele2 bei der umstellung auf der eigenen seite noch ein paar einstellungen vornimmt und eine umstellung in eigenregie gar nicht möglich ist!
- die konfigs unterscheiden sich massiv. dann hast du bei deiner umstellung einen fehler gemacht, und der würde uns *sehr* interessieren.
> ip a
> ip r
# mit ps die pid vom pppd ermitteln:
> ps
# danach debugging aktivieren mit:
> kill -SIGUSR1 <pid-von-pppd>
> # ich nehm als ping target einen der 2 alten timeserver der uni wien (131.130.1.11, 131.130.1.12),
# die dinger funken sehr zuverlässig.
> while : ; do ping -c 1 131.130.1.11 >/dev/null || logger -p error "*** WAN link down ***"; sleep 60; done &
# ausgabe ist die pid des hintergrundprozesses, mit der ihr die while-schleife nach beendigung des tests killen könnt
# oder ihr macht halt einfach
> kill %1
> tail -f /var/log/messages
[admin@WoTik] > sy reso pr
uptime: 25w5d22h39m43s
version: 6.18
build-time: Aug/01/2014 10:47:47
free-memory: 223.7MiB
total-memory: 256.0MiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 680MHz
cpu-load: 0%
free-hdd-space: 491.9MiB <== da brauchts kein "tail -f" mehr^^
total-hdd-space: 511.8MiB
write-sect-since-reboot: 9700992
write-sect-total: 27633077
bad-blocks: 0%
architecture-name: mipsbe
board-name: RB450G
platform: MikroTik
[admin@WoTik] >
Mitglieder in diesem Forum: Google [Bot], Majestic-12 [Bot], Yandex [Crawler] und 21 Gäste