[Tele2] DMZ bei Modem Comtrend 3223u telefontauglich machen!

[alles]

Hallo liebe Gemeinde,

nachdem abermals ein Tele2-Modem (i3 Vood 452w) seine "Patschen gestreckt" hat, sprich defekt geworden ist, haben wir diesmal einen Comtrend vi-3223u bekommen. Habe daraufhin versucht, die gewohnten Einstellungen auf das neue Modem zu übertragen und musste nach reichlicher Recherche feststellen, dass das Telefon seinen Dienst quittiert, sobald man einen "DMZ Host" einträgt. Es kommen dann diese schnell aufeinanderfplgenden Signaltöne, so als es den Anschluss nicht gäbe. Entfernt man den Eintrag wieder, man braucht die Änderung nur abspeichern (also ohne Neustart des Modems), ist die Telefonleitung wieder freigegeben.
Bei Portforwardings bzw. "Virtual Servers" hingegeben gibt es nichts zu beanstanden. Doch hätte ich zwecks unbekümmerter Nutzung diverser Tools doch lieber DMZ aktiviert.

Drum habe ich mich rund um dieses Thema an den Technik-Support gewendet, doch die wollen einem diesbezüglich keine Antwort geben. Man meinte nur, es sei durchaus möglich, doch müssten dazu noch andere Einstellungen vorgenommen werden...und die kenne ich leider nicht, weshalb ich mich nun hilfesuchend an Euch wende.

Habt Ihr eine Idee, warum diese Symptome auftreten und wie kann man DMZ mit dem Telefon verträglich machen?

Liebe Grüße, alles

PS:
Ist es üblich, dass bei einem offenen Netzwerk kein Passwort vergeben werden kann? Beim vorherigen Modem konnte man sehr wohl ein Passwort hinterlegen. Beim Neuen gibt es das Passwortfeld nur bei den verschiedensten Verschlüsselungsvarianten!

[zid]

hallo alles,

>"...Habt Ihr eine Idee, warum diese Symptome auftreten und wie kann man DMZ mit dem Telefon verträglich machen?..."
in meiner geistigen beschränktheit kann ich mir nur ein szenario vorstellen, auf das deine problembeschreibung zutrifft:
du verwendest einen data channel fürs voip (sehr beliebt bei den frtzlern btw). und wenn du dann einen default server/exposed host setzt, geht das voip natürlich hoffnungslos schief, weil das dnat bekanntlich vor der routing-entscheidung erfolgt.
bei tele2 gibt es meines wissens aktuell 2 voip channels:
1.
routed pppoeoa @ pvc 8.40 mit atm-qos vbr-rt (pcr: 471, scr: 470, mbs: 100, cdvt: 6000)
2.
routed pppoeoa @ pvc 0.40 mit atm-qos ubr.

du müßtest jetzt nur nachschauen, ob
1.
das atm8.40 intf existiert
=> webgui > Advanced Setup > Layer2 Interface
2.
auf dem atm8.40 ein pppoe-dialer sitzt und eingewählt ist
=> webgui > Advanced Setup > WAN Service
achtung: die voip und data credentials sind verschieden!
3.
für voip tatsächlich der voip-dialer verwendet wird
=> webgui > Voice > SIP Basic Setup > Global parameters > Bound Interface Name
beim "Bound Interface Name" sollte der voip-dialer gesetzt sein.

wenn alle einstellungen von oben passen sollten, dann is die sog, "DMZ", die in wirklichkeit ein default server/exposed host is, buggy, und du wirst dich mit bridged pppoeoa, quasi als last resort, befassen müssen.

lg
zid

[gandlz]

Hallo zusammen,

habe hier das selbe Szenario: Internettarif gewechselt und ein Comtrend bekommen.

Beim Tilgin Vood wurden im Web-Interface unter Verbindungen eine DATA- und eine VOICE-Verbindung angezeigt. Man wählte die DATA-Verbindung und konnte dann in deren Einstellungen eine DMZ-IP angeben.

Beim Comtrend konnte ich nicht in die Einstellungen einer einzelnen Verbindung vordringen. Auch funktioniert bei mir das oft erwähnte Anmelden mit Benutzer root, Passwort 12345 nicht. Sondern nur Benutzer user, Passwort user.
Die DMZ vom Comtrend verhält sich bei mir auch wie hier bereits beschrieben und setzt das VOIP außer Kraft.

Ich habe das jetzt so gelöst und denke es geht eigentlich aufs Selbe raus. Vielleicht könnte jemand mit mehr Kenntnis zur Materie bestätigen, ob diese Regelung einem exposed host (DMZ) gleich kommt, oder ob beim exposed host noch mehr gemacht wird, außer die Ports zu öffnen:

Advanced Setup – NAT – Virtual Servers – Add:
WAN Interface: PPPoE-DATA…ppp7
Service Name (Custom): DMZ
Server IP Address: 192.168.1.2 (anderer Router WAN-IP)
External Port Start/End: 1/65535
Internal Port Start/End: 1/65535
Protocol: TCP/UDP

Mit dieser Einstellung kann ich jetzt das Port-Forwarding im anderen Router einstellen. Interessant wäre, ob das bereits jemand auf eine andere Art lösen konnte.

Vielen Dank und freundliche Grüße
Gandlz

[zid]

hallo gandlz,

>"...oder ob beim exposed host noch mehr gemacht wird, außer die Ports zu öffnen:..."
beim exposed host wird 1:1 nat gemacht, d.h. diese weiterleitung funkt auch für reine ip-protokolle (icmp, gre, esp, ah...), während bei dir halt nur tcp+udp weitergeleitet werden.
warum versuchst du am comtrend für data nicht bridged ethoa und läßt den nachgeschalteten router mit pppoe einwählen? einen pppoe-client haben praktisch alle soho-router, sogar die wix!box ((c) zillertaler ). dann wär dein router kein exposed host emhr, sondern ein richtiges gate mit anliegender pub-ip, und du hättest keinen zoff mit ip-protokollen und wärst ganz nebenbei auch das nervige doppel-nat los.

lg
zid

[gandlz]

Hallo zid,

vielen Dank für die Info.
Ich werde da mal vorerst bei meiner NAT-Einstellung bleiben und mich mit TCP und UDP zufrieden geben. Wahrscheinlich werde ich keine Nachteile merken. Ich wüsste nicht, ob ich die von dir erwähnten Protokolle schon mal für irgendetwas gebraucht habe.

Das Modem als Bridge zu nutzen wäre für mich eine Notlösung. Bei mir haben sich die Tilgin und auch schon das Comtrend, das ich noch nicht mal ein Monat habe, einfach von selbst zurückgesetzt. Merk ich dann daran, dass das WLAN wieder aktiv ist und die Tilgin hatten die DMZ nicht mehr drin bzw. beim Comtrend war die NAT-Einstellung weg.
Keine Ahnung woran das liegt. Ich glaub, dass diese Modems/Router einfach billiger Schrott sind.

Wenn ich jetzt meinen Router zum direkten Einwählen konfiguriere und das Modem als Bridge, dann wäre nach so einem ungewollten, automatischen Reset die Verbindung zum Internet nicht möglich. Ist dann sehr unfein, wenn ich nicht daheim bin und jemand anders, der sich da nicht auskennt das Internet braucht.

Deshalb habe ich bei den Dingern eigentlich nie mehr etwas an der Grundkonfiguration geändert. Nur Funktionen wie WLAN und Firewall deaktiviert und eben einen DMZ gesetzt. Dann funktioniert im schlimmsten Fall die Portweiterleitung bzw. bestimmte Anwendungen nicht mehr, aber die Verbindung zum Internet ist verfügbar.

mfg, Gandlz

[zid]

hallo gandlz,

falls du einen privatzugang hast, kannst du dir das bridging mim comtrend sowieso abschminken. lies einmal den hochinteressanten beitrag vom c durch:
viewtopic.php?f=20&t=56537&p=467540&#p467536
ich kannte diese neuerung im privatbereich gar nicht, weil die paar tele2-kunden, die ich am hals hab, biz-anschlüsse haben...
was würde mit den neuen richtlinien schiefgehen?
wenn du auf bridging umstellen wolltest, brauchtest du vollzugriff auf den schnittstellenstack, um die wartungschannels komplett auszuräumen. sonst würdest du ja gefahr laufen, das dieses comtrend-unding sich bei der nächsten gelegenheit eine default config vom acs reinzieht und du wieder am anfang stehst. mit so einer aktion würdest du aber die gesamte richtlinie aushebeln, und der user "USER" wäre sinnlos...

lg
zid

[gandlz]

Interessanter Beitrag und ich sage nur „na toll“

Inzwischen hat sich bei mir folgendes herausgestellt:

Ein paar Tage nach Einmarsch des Comtrends hat bei uns das Telefon nicht mehr funktioniert. Ein Modem Reset hatte das Problem behoben.
Vor ein paar Tagen wieder das selbe, aber ein Reset konnte nicht mehr helfen. Also beim Support angerufen und der Techniker konnte auch nix machen und musste „weiterleiten“. Einen Tag später kam dann eine SMS „Störung behoben“ und das Telefon geht wieder.

Jetzt ist mir aufgefallen, dass ich unter den WAN-Infos nur noch eine IP habe. Vorher war da ppp2 PPPoE-Voice und ppp7 PPPoE-Data. Für ppp7 hab ich das NAT konfiguriert.
Nun ist da aber nur noch ppp5.3 PPP.33 welches dann wohl unter der selben IP Telefon und Internet verbindet. Wenn ich da alle Ports auf meinen Router weiterleite, geht das Telefon auch wieder nicht.
Außerdem ist mir aufgefallen, dass mein VPN auch nicht mehr funktioniert, selbst wenn ich alle Ports weiterleite. Ich glaube das benötigt noch das GRE-Protokoll.

Was kann ich denn jetzt noch machen?

Dort wo man die DMZ setzten kann steht, dass vorher das NAT abgearbeitet wird und dann alles andere an die DMZ IP geht. Könnte ich da vielleicht im NAT die Ports fürs Telefon weiterleiten, damit dieses trotz DMZ noch funktioniert? Aber welche Ports und Protokolle nutzt das Telefon und wohin leite ich diese dann? An die eigene IP vom Modem?

Zuerst habe ich mich gefreut, dass ich dieses fehlerhafte Tilgin endlich los bin und jetzt wäre mir das wieder das aller liebste!

Mit freundlichen Grüßen
Gandlz

[zid]

pfff, jetzt wirds lustig...


hallo gandlz,

>"...Nun ist da aber nur noch ppp5.3 PPP.33 welches dann wohl unter der selben IP Telefon und Internet verbindet..."
na, der sauhaufen is perfekt. der ppp5.3 ist eine vull (virtual unbundled local loop), virtuelle entbündelung also. vorher warst wirklich entbündelt, jetzt nur noch virtuell, voip und data rennen über dieselbe schiene, und du bist nicht mehr in der lage, bei den virtual servers den traffic über den schnittstellenstack zu differenzieren.

>"...Ich glaube das benötigt noch das GRE-Protokoll..."
falls du mit "vpn" das obsolete pptp meinst, dann ja. pptp ist ein 2-channel-protocol. die kontrollverbindung rennt über den tcp/1723 und data eben über gre. bei jeder 2-channel-verbindung liegt ein bruch von osi vor, der bei genatteten verbindungen sehr nervig werden kann (nat is bekanntlich nervig, doppel-nat is geistesgestört), weil ja infos, die den den data-channel betreffen (bei pptp/gre gehts um die call-id) über den control-channel ausgetauscht werden. um dieses manko zu beheben, gibts protokollspezifische hilfsanwendungen, die gemeinhin als algs bezeichnet werden und nix andres als kernelmodule sind, die beim verbindungsaufbau auf application level mitsniffen und dort die relevaten infos fürs nat und die firewall extrahieren.
konkret macht das pptp/gre-alg *serverseitig* folgendes:

0. beim verbindungsaufbau werden die call-ids ausgetauscht (der gre-tunnel besteht ja aus 2 unidrektionalen links, mit jeweils einer eigenen call-id). das pptp/gre-alg ermittelt die ausgehandelten call-ids + die pptp-server-ip und schaltet dann

1. die forward chain für den inbound uni-link mit der ersnifften call-id und dst-ip = pptp-server frei.

2. richtet dann eine weiterleitung für gre mit *der ermittelten* call-id zum pptp-server ein, sehr selektiv also...

unterm strich gibts für die niederungen des alltags eine frohe und eine net so lustige botschaft:
1. wenn das pptp/gre-alg sauber funkt, müssen wir bei pptp *serverseitig* nur den tcp/1723 zum server weiterleiten. gre wird von dem alg automagically erledigt.

2. wenn das pptp/gre-alg net sauber funkt oder die korrekte verarbeitungsreihenfolge durch irgendwelche specials, def. server z.b., gebrochen wird, und es dann am eingesetzten gerät auch noch keine möglichkeit gibt, gre explizit weiterzuleiten, diese situation liegt beim comtrend vor, dann hast du keine chance, pptp/gre zum laufen zu kriegen.
liegt eine derartig unangenehme situation vor, weicht man einfach auf l2tp (=udp/1701) ipsec+nat-t (udp/500 + udp/4500), l2tp/ipsec (ipsec auch mit nat-t, also wieder udp/500 + udp/4500) oder ovpn (default meist udp/1194, manchmal, mikrotik z.b., tcp/1194) aus.


>"...Dort wo man die DMZ setzten kann steht, dass vorher das NAT abgearbeitet wird und dann alles andere an die DMZ IP geht..."
ja gut, das is klar. sonst würde der default server ja auch net als "default server" bezeichnet werden.
zuerst werden dedizierte weiterleitungen abgearbeitet, und für jenen traffic, für den diese weiterleitungsregeln nicht zutreffen, gibts zum schluß eine default weiterleitung, die man der einfachheit halber eben "default server" (manchmal auch "exposed host") nennt.
ich schreib dir jetzt mal das ganze graffl in iptables-jargon auf, sodaß du verstehst, was ich meine:

Code: Alles auswählen

# zuerst, die verarbeitung erfolgt von oben nach unten, irgendwelche dedizierte nats/"virtual servers", also z.b.:
# http
iptables -t nat -A PREROUTING -i ppp7 -p tcp --dport 80 -j DNAT --to-destination http.ser.ver.ip
# ssh
iptables -t nat -A PREROUTING -i ppp7 -p tcp --dport 22 -j DNAT --to-destination ssh.ser.ver.ip
# ipsec/ike
iptables -t nat -A PREROUTING -i ppp7 -p udp --dport 500 -j DNAT --to-destination ipsec.ser.ver.ip
# ipsec/nat-t
iptables -t nat -A PREROUTING -i ppp7 -p udp --dport 4500 -j DNAT --to-destination ipsec.ser.ver.ip
...usw.

# und zum schluß gibts für den rest, als last resort sozusagen, eine endültige weiterleitung
# zum default server (falls man das unbedingt haben will):
iptables -t nat -A PREROUTING -i ppp7 -j DNAT --to-destination def.ser.ver.ip

das ganze is also gleich wie beim routing. dort werden ja auch zuerst die host- und netzrouten (longest bit zählt bekanntlich) abgearbeitet und für dests, die durch keine host- oder netzroute abgedeckt sind, gibts zum schluß eine endgültige route: die default route.
die ähnlichkeit der bezeichnungen fällt dir auf?


>"...Was kann ich denn jetzt noch machen?..."
nicht viel, und alle optionen fallen eher so in die kategorie abführ- und brechmittel.

1. du verzichtest auf den default server und ähnliche konstruktionen...
...und leitest nur jene ports weiter, die du wirklich brauchst. ok,, doppel-nat, ich komm noch drauf zurück, hast du dabei, alles andre als appetitlich, aber den ramsch hast du auch mim def server drauf...
aus meiner sicht die einfachste lösung- und im fall des comtrend auch die mit der höchsten erfolgsaussicht.


2. du willst den def server *unpetinckt* haben, das voip aber in irgendeiner form aus dem regelwerk nehmen.
dann gibts grundsätzlich mindestens 2 möglichkeiten:

i. overruling- dein ansatz mit:
>"...Könnte ich da vielleicht im NAT die Ports fürs Telefon weiterleiten, damit dieses trotz DMZ noch funktioniert?...

ii. exception

ich kann dich "beruhigen", beide ansätze haben ihre nachteile:
ad i.- overruling:
- weitergeleitet wird in dem fall nur sip = udp/5060.

- da du bei den privatzugängen von tele2 keine statische pub-ip hast, kannst du fürs voip keine triviale (dummy-)weiterleitung einrichten und mußt in richtung 127.0.0.1 oder lan-ip comtrend gehen. bei der 127er is halt die frage, ob sie überhaupt als loopback konfiguriert ist, sichtbar is sie jedenfalls nicht, könnte aber durchaus sein, daß sie verdeckt eingerichtet und somit ansprechbar is. gut, dieser harakiri ghört dir...

- so, und wenn du den harakiri erledigt hast, dann bist du nur noch rtp konfrontiert. und das geht ganz einfach mit dem sip-alg. im webgui nach...
Advanced Setup > SIP ALG
...gehen und dort ein kakerl setzen.

- danach den def server setzen.

- schwäche dieses ansatzes:
abgesehen von potentiellen probs bei der weiterleitung selbst (127.0.0.1?), stellt sich die frage, ob das sip-alg bei einem self traffic sauber funkt, weil es ja normalerweise für transit traffic ausgelegt ist.

ad ii.- exception
- du setzt keinen def server, sondern spielst einen ähnlichen ansatz wie früher mit den vrtual servers.

- bei tcp ändert sich nix, alle 65k ports werden wie gehabt zum router weitergeleitet.

- bei udp nimmst du bei der weiterleitung den sip-port und die rtp-ports aus. ich nehm jetzt mal *beispielhaft* an, daß das comtrend für rtp den bereich udp/[10000-10100] verwendet. dann schaute das ganze so aus:
udp-weiterleitung1 = udp/[1-5059]
udp-weiterleitung2 = udp/[5061-9999]
udp-weiterleitung3 = udp/[10101-65535]
ingesamt hast du jetzt 3 weiterleitungen für 3 udp-portbereiche.

- der vorteil dieses ansatzes ist klar:
das voip wird nicht genattet, und du mußt nicht mim sip-alg rummurksen. hab ich schon erwähnt, daß nat shit is?

- es gibt aber auch einen zarten nachteil:
die rtp-bereiche sind nicht normiert- festgelegt is nur, daß sie über udp/1024 sein müssen- und variieren deshalb von gerät zu gerät. idr. reden wie so über 50-100 udp-ports.
beim comtrend sieht man die rtp-ports im webgui nicht, geschweige denn, daß man sie manuell vorgeben könnte (zumindest hab ich als root nix gefunden). du mußt sie also suchen oder, wenns blöd hergeht, erraten.

- die suche erfolgt übers sip debugging. du startest bei den udp-weiterleitungen mit der ausnahme udp/5060, gehst dann nach:
Voice > SIP Debg Setup > Global parameters
und setzt dort das log level "Debug".
Anwenden und sip-ua restarten oder comtrend rebooten.
wenn das comtrend wieder da is, führst du ein paar anrufe durch, die natürlich scheitern werden, weil du ja noch keine ausnahme für rtp gesetzt hast, und schaust dir dann die sip invites in den debug logs an, dort werden ja die rtp-sockets mitgeschickt.
dann ziehst du vom niedrigsten gefundenen port hausnummer 100 ab, zählst zum höchsten 100 dazu und setzt dieses intervall als ausnahme bei den weiterleitungen.

- es könnte aber auch passieren, daß du nicht mal mim debugging was siehst, oder es funkt net bei dir, weil du nur als "USER" unterwegs bist.
in dem fall mußt du den rtp-bereich mit einer klassischen intervallschachtelung eruieren.
ich geh davon aus, daß du weißt, was 'ne intervallschachtelung is. falls doch nein, und falls wirklich bedarf danach entstehen sollte, dann melde dich. ich mal dir einen grund- und aufriß davon...


3. die angekündigte reprise des nervigen themas doppel-/mehrfach-nat
ich frage mich, ob du eine gestaffelte netzstruktur, die du dir mit doppel-nat teuer erkaufst, überhaupt brauchst.

- wenn nein:
dann verwende den nachgeschalteten router einfach als switch/ap, und erledige die paar weiterleitungen, die du wirklich brauchst, mim comtrend. damit hättest du single-nat.

- wenn doch ja:
dann deaktivier am nachgeschalteten router das masquerading, setz am am comtrend unter
Advanced Setup > Routing > Static Route
eine route fürs lan des nachgeschalteten routers, leite die ports für die dienste, die im lan des routers rennen, am comtrend direkt ins lan des routers weiter und schaukle die sicherheitsrichtlinien lan-comtrend <-> lan-router mit der firewall des routers.
damit hättest du wieder single-nat mit einer 2-stufigen firewall- sehr einfach und effizient.

du kennst den begriff "atlantik"?
das is die etwas größer geratene badewanne, die angeblich 2 kontinente trennt.
und um diese badewanne zu überqueren, gibts mindestens 2 möglichkeiten:
1. schwimmflügerl
2. hochseejacht
variante #1 lehn ich ab, weil die mindestens so bescheuert is wie doppel- oder mehrfach-nat.


lg
zid

[gandlz]

Und nochmals „na toll“!

Also ich versteh da wohl die Hälfte nicht von deiner Info, aber so der Kerninhalt von allen Punkten ist klar.

Ich glaub ich ruf da nochmal beim Support an und mach Wind. Sonst will ich meinen alten ADSL-Tarif zurück oder wechsle den Anbieter. Ich will mein Internet schließlich nutzen können, wie ich es will.

Du sagst du bist root auf deinem Comtrend.
Vorausgesetzt du hast zwei getrennte Verbindungen für VoIP und DATA. Kannst du einen exposed host nur für DATA setzen? Bzw. kann man das einfach lösen wenn man root Zugriff hat?

Und noch zur Info: mein VPN-Server ist direkt auf dem DD-WRT Router. Und ja, PPTP. Brauch ich nicht oft und wenn, dann auch nur ein User. Ist in unregelmäßigen Abständen immer wieder extrem hilfreich, deshalb will ich darauf nicht verzichten.

Vielen Dank und freundliche Grüße
Gandlz

[gandlz]

Hallo nochmal. Möchte die aktuelle Situation bekannt geben:

Der Support hat mir mein Modem jetzt in den Bridge-Mode geschaltet. Der Techniker (keiner von der Hotline) hat mir versichert, dass das Modem auch nach einem Reset die Konfiguration beibehaltet. (Reset hab ich noch nicht getestet, Ein-Ausschalten hat jedoch funktioniert) Auf persönlichen Wunsch hat mir der Techniker auch das WLAN per default deaktiviert.

Lasst euch von der Hotline nichts erzählen! Drei Mitarbeiter waren sich sicher, dass die Config bei Neustart oder Reset verloren geht. Einer meinte sogar, dass das Telefon im Bridge-Mode nicht funktioniert, was es jedoch tut. Der oben erwähnte Techniker meinte, dass das Modem beim Einschalten immer die Config vom Server holt und dass er eben genau diese Config bearbeiten kann. Klingt irgendwie logisch.

Für mich bedeutet das nun folgendes:
Ich muss mich eigentlich mit dem Modem nicht mehr beschäftigen, da es alles auf meinen Router durchlässt. Port-Forwarding und das VPN funktionieren wieder.

Allerdings bleibt ein letzter Dorn im Auge:
Mir ist aufgefallen, dass bei einem Upload der Download komplett zusammenbricht. Das war auch vor dem Bridge-Mode schon so.
Mein Test hierzu sieht folgendermaßen aus:
Ich lade von diversen Servern große Dateien gleichzeitig. Dabei erreiche ich durchgehend ca. 19Mbit sehr stabil (18-20Mbit). Starte ich jetzt einen Upload erreicht dieser sofort und auch sehr stabil annähernd 4Mbit allerdings bricht der Download auf unter 1Mbit ein und schießt erst nach dem Upload wieder hoch.
Dabei ist egal was den Upload verursacht:
Dropbox, E-Mail (mit Anhang), Speedtest, FileZilla
Wenn der Upload nur ca. 3Mbit erreicht bleibt der Download bei 3-6Mbit.

Ganz normal erscheint mir das nicht. Hierzu einen Tipp?

Vielen Dank und freundliche Grüße
Gandlz

[zid]

jöö, jetzt wollt ich dem bekanten von einem bekannten von einem freund den link zu unsrer schnuckeligen diskussion schicken, weil der junge dasselbe prob wie du hat, und was sehen meine entzundenen äuglein? hochinteressante neuigkeiten! sehr schön, sehr schön...

hallo gandlz,

vielen dank für deine rückmeldung, die ich in meiner geistigen umnachtung komplett überlesen hab. die wichtigsten posts überles ich fast schon regelmäßig...

>"...Einer meinte sogar, dass das Telefon im Bridge-Mode nicht funktioniert,..."
hehe, den schnittstellenstack der eigenen konfig sollt ma halt schon kennen...
aber eben sehr interessant, daß tele2 auf kundenwunsch das bridging einrichtet, dann is man wenigstens das nervige double nat los und hat alle freiheiten am nachgeschalteten privatrouter.


>"...Ganz normal erscheint mir das nicht. Hierzu einen Tipp?..."
klarer fall von verstopfung.
wenn du einen reinen download durchführst, dann steht die gesamte us-bandbreite für die acks, mit denen dein rechner die empfangenen packerl bestätigt, zur verfügung. führst du hingegen gleichzeitig einen upload durch, dann müllt dir der upload den uplink zu, sodaß die acks nur verzögert weitergeleitet werden und die dl rate des download sinkt...
lösung: ipqos
du mußt den acks des download mehr raum geben oder eben up- und downloads zu verschiedenen zeiten durchführen. letzteres wär btw. die einfachste form eines ipqos.

lg
zid

[gandlz]

Hallo zid,

vielen Dank für deine Antwort, welche ich erst jetzt gesehen habe. Irgendwie schaff ich es nicht bei diesem Forum eine E-Mail-Benachrichtigung zu bekommen.

In der Zwischenzeit hab ich folgende Neuigkeiten:
Alle paar Tage verabschiedet sich die Internetverbindung. Mein Router schreibt in den WAN-Infos Disconnected und beim Klicken auf Connect ändert sich nichts. Den Router aus/einschalten nützt auch nichts. Also schalte ich das Modem aus/ein und nach ein-zwei Minuten Modemstarten verbindet sich der Router automatisch und das Internet ist wieder da.
Ich nehme also an, dass es am Modem und nicht am Router liegt. Zur Zeit versuche ich noch zu beobachten ob da eine Regelmäßigkeit vorliegt.

Als einzig Positives bleibt die Bestätigung, dass das Modem trotz mehreren Neustarts immer noch im Bridge-Mode ist. Einen Reset habe ich jedoch noch nicht getestet.

Zum IPQoS:
Ich habe QoS in meinem Router (DDWRT) aktiv und ein paar Prioritäten gesetzt. Aber ich sehe keine Möglichkeit den Download gegenüber dem Upload zu priorisieren. Müsste ich das im Modem aktivieren?

Außerdem ist mir jetzt noch was aufgefallen:
Streamingdienste wie VoxNow oder RTLNow funktionieren praktisch garnicht. Einerseits sind diese Seiten, welche den FlashPlayer nutzen wohl nicht grade ideal eingerichtet, denn es wird hier absolut nichts gepuffert. Sobald man die Wiedergabe pausiert, kann ich im Bandwidth-Monitoring vom Router sehen, dass nichts mehr passiert. Im Wiedergabemodus zeigt es dann eine Zick-Zack-Kurve welche alle ein-zwei Sekunden zwischen nahezu 0 und 1 oder maximal 2 Mbit wechselt. Also immer rauf und runter wobei in Summe praktisch nichts geladen wird. Das Resultat ist andauerndes Stoppen des Videos.
Testhalber habe ich mal parallel mit dem Notebook übers Handy-Internet den selben Stream gestartet und der hat problemlos abgespielt!
Seltsamerweise hat es vorher mit ADSL auch besser funktioniert, wenn auch nicht so reibungslos wie übers Mobilnetz.
QoS nützt hier auch nichts, weil ja nichts anderes läuft und der Download auch keine 2 Mbit übersteigt.

Danke für jede Hilfe!
LG, Gandlz

[zid]

und täglich grüßt das murmeltier...

hallo gandlz,

das ipqos laß ma jetzt vorübergehend außen vor, weil die gschicht mit der grundkonnektivität wichtiger is. der i386 hat nämlich genau dasselbe prob wie du, und der junge hat immerhin schon 3 (andere) router durchgetestet:
viewtopic.php?f=20&t=56537&p=468766#p468696
bin grad am knabbern, wie man am einfachsten licht ins dunkel dieser verworrenen situation bringen könnte und werd dazu im faden vom i387 was posten. schnupper halt ab und zu dort vorbei.

>"...Irgendwie schaff ich es nicht bei diesem Forum eine E-Mail-Benachrichtigung zu bekommen..."
die sind abgedreht worden, weil sonst das forum mit spam zugemüllt wird. net wirklich dramatisch, einfach ab und zu einen einkehrschwung hier machen... is wie beim wirt.

lg
zid