Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Internet und Telefon gestört oder gar ganz ausgefallen? Speedprobleme, die nicht offensichtlich auf die verwendeten Geräte zurückzuführen sind? Dann ist dieses Forum genau richtig!
Forumsregeln
Forenregeln


Bitte gib bei der Erstellung eines Threads im Feld „Präfix“ an, ob du Kunde von Vodafone Kabel Deutschland („[VFKD]“), von Vodafone West („[VF West]“), von eazy („[eazy]“) oder von O2 über Kabel („[O2]“) bist.
reneromann
Insider
Beiträge: 4917
Registriert: 28.06.2015, 13:26

Re: Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Beitrag von reneromann »

Flole hat geschrieben: 05.10.2018, 01:13 Wie bitte? Lokale IPv4 Pakete gehen zum AFTR mit ihrer lokalen Adresse? Wer bitte hat dir denn so einen Blödsinn erzählt, und wie genau soll das funktionieren?
Lies dir mal RFC6333 durch. Da steht schon gleich am Anfang, dass das CPE kein NAT hin zum B4-WAN-Interface machen darf, weil das NAT ausschliesslich im AFTR passiert (um Doppel-NAT zu vermeiden).
Kurz gesagt: Der Kabelrouter macht kein NAT, sondern verpackt die IPv4-Pakete komplett in IPv6 ein und schickt sie mit den internen IPs zum AFTR. Dort erfolgt dann das NAT auf Basis des Fünftupels IPv6-Adresse des CPE, (int.) IPv4-Adresse des anfragenden Gerätes, IPv4 des Servers, Source- und Destination-Port.
Und bei IPv6 gibt es, wie du ja sicherlich weißt, die privacy extensions sodass genau das ganze verhindert wird was du hier grad beschreibst.
Nope, die Privacy Extensions verhindern nicht, dass einzelne Rechner erkannt werden - es verhindert lediglich, dass du auch in mehreren Tagen noch erkannt werden kannst. Zum gleichen Zeitpunkt sind die Rechner eindeutig identifizierbar.
Flole
Insider
Beiträge: 9863
Registriert: 31.12.2015, 01:11

Re: Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Beitrag von Flole »

Also gehen sie doch nicht mit der lokalen IP an den AFTR, sondern mit einer IPv6 über die man auf die IPv4 schließen kann. Es wird definitiv nicht deine Lokale IPv4 als Quelladresse ohne weiteres im Vodafone Netz als Quelladresse geben.

Wenn du schon mit RFCs um dich schmeißt (und diese zunächst falsch beschreibt) dann antworte ich Mal mit RFCs: RFC4941 sagt ganz klar, das spätestens bei jeder Neuverbindung eine neue privacy extension generiert wird, also du wirst vom WLAN getrennt und schon hast du eine neue. Manche Geräte gehen so weit und tauschen die noch häufiger, Ubuntu alle 5 Minuten per Default. Dann wird dein OS Fingerprinting noch Lustiger.... Und wenn jemand den HTTP Useragent ändert geht's auch nicht mehr?
reneromann
Insider
Beiträge: 4917
Registriert: 28.06.2015, 13:26

Re: Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Beitrag von reneromann »

Flole hat geschrieben: 05.10.2018, 07:27 Also gehen sie doch nicht mit der lokalen IP an den AFTR, sondern mit einer IPv6 über die man auf die IPv4 schließen kann. Es wird definitiv nicht deine Lokale IPv4 als Quelladresse ohne weiteres im Vodafone Netz als Quelladresse geben.
Du hast die Funktionsweise von DS-Lite noch immer nicht verstanden.
Bei DS-Lite werden sehr wohl deine internen IPv4-Adressen an den AFTR weitergeleitet - dieser macht dann erst das NAT auf IPv4-Ebene. Es kommt jedoch zwischen dem CPE (Router) und dem AFTR ein IPv6-Tunnel zum Einsatz - d.h. deine IPv4-Pakete werden mit dem kompletten IPv4-Header (also insbesondere mit deinen lokalen IPv4-Adressen) innerhalb eines IPv6-Paketes vom Router an das AFTR-Gateway weitergeleitet. Der AFTR entpackt dann die in IPv6 gekapselten IPv4-Pakete und führt darauf NAT durch - und anstatt wie bei "normalem" NAT, bei dem "nur" das Vier-Tupel Source-IP, Source-Port, Destination-IP und Destination-Port entscheidend sind, speichert der AFTR ein Fünf-Tupel aus Source-IPv4, Source-Port, Destination-IPv4, Destination-Port -und- zusätzlich noch der IPv6 des CPE ab.

Der AFTR kann dann -bei Antworten- eben jene IPv4-Pakete "richtig" zurückwandeln, wieder in IPv6 packen und zum CPE schicken - dieses entpackt lediglich die IPv4-Pakete und leitet sie (ohne Änderungen daran vorzunehmen) an die Clients im LAN weiter.

Wenn du schon mit RFCs um dich schmeißt (und diese zunächst falsch beschreibt) dann antworte ich Mal mit RFCs: RFC4941 sagt ganz klar, das spätestens bei jeder Neuverbindung eine neue privacy extension generiert wird, also du wirst vom WLAN getrennt und schon hast du eine neue. Manche Geräte gehen so weit und tauschen die noch häufiger, Ubuntu alle 5 Minuten per Default.
Und auch hier stimmt deine Aussage so nicht. Während der Dauer, in der die mittels PE generierte IPv6 gültig ist, gehen alle Anfragen mit eben jener per PE generierten IPv6 nach außen - darum geht es aber gar nicht.
Denn du meintest ja, dass man dank PE nicht nachvollziehen könne, wie viele Rechner hinter einem Router hängen - und das stimmt so nicht. Denn da die IPv6 -auch mit aktivierten PE- rechnerspezifisch ist (ein 2. Rechner generiert im gleichen Netz zwingenderweise eine andere -auch mit PE erzeugte- IPv6), kann man darüber -während der Gültigkeitsdauer der IPv6- Rückschlüsse auf den Rechner ziehen. Man kann also ohne Weiteres erkennen, ob in dem Netz ein Rechner 10 Verbindungen aufbaut -oder- ob in dem Netz 10 Rechner jeweils eine Verbindung aufbauen - weil man trotz aktivierter PE bei 10 Rechnern am Server 10 verschiedene Host-Adressen zur gleichen Zeit sieht.

Die PE helfen nur dafür, als dass du damit nicht über längere Zeit und nicht anschlußübergreifend getracked werden kannst. Denn ohne PE würde sich der Hostteil selbst bei Neuvergabe eines anderen Präfix am Internetanschluß nicht ändern - insbesondere bei mobilen Geräten wie Notebooks, Tablets und SmartPhones würde das dazu führen, dass man präfixübergreifend (und somit auch anschlußübergreifend) nachvollziehen könnte, wo sich ein Gerät aufgehalten hat. Das klappt mit aktivierten PE so natürlich nicht, weil sich bei jeder Einwahl in ein neues Netz -oder- nach Ablauf der Gültigkeit der mit PE generierten IPv6 der Hostteil der IPv6 ändert.
Dann wird dein OS Fingerprinting noch Lustiger....
Wo schrieb ich, dass man damit OS Fingerprinting betreiben kann? Du kannst damit lediglich herauslesen, ob ein oder mehrere Rechner im Netzwerk hängen.
Unter welchem OS die Rechner laufen, kann man damit (nicht zwingend) bestimmen...
Und wenn jemand den HTTP Useragent ändert geht's auch nicht mehr?
Der HTTP User Agent ändert aber nichts an der Tatsache, dass mit trotz aktivierter PE herausfinden kann, wie viele Rechner gleichzeitig im Netz hängen und Anfragen abfeuern...
Flole
Insider
Beiträge: 9863
Registriert: 31.12.2015, 01:11

Re: Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Beitrag von Flole »

Du hast nicht verstanden das im IP Header eben nicht die Lokale IPv4 als Quelle steht, sondern irgendeine andere Adresse. Ob da nun im Datenverkehr (wie bei VPN) die lokalen IP Adressen stehen ist irrelevant, da die Quelladresse eben nicht die Lokale IP ist (das ist jetzt zumindest meine Definition von "gehen mit der lokalen IPv4....."). Für mich ist die Quell IP immer noch die, die im source Header des Paketes steht.

Diese Gültigkeit ist aber eben nur für die Dauer der jeweiligen Verbindung vorhanden. Also WLAN aus, Gültigkeit weg. Wenn du mir jetzt noch sagst wo ich geschrieben habe das man nicht sagen kann wie viele Geräte hinter einem Router sind wenn PE verwendet werden, wäre ich dir sehr verbunden.

Das OS Fingerprinting ist nunmal Thema des Threads, ich war jetzt davon ausgegangen das du dich darauf beziehst und nicht einfach wild in irgendeinem Thread dein IPv6 Wissen (oder Halbwissen) ablädst.

Und zu guter letzt: Es geht immer noch darum das OS des Endgerätes zu bestimmen und NICHT die Anzahl der Endgeräte, deren MAC, deren Seriennummer oder Telefonnummer oder whatever. Wenn man nun ständig ändernde IPs hat (wie bei PE) wird das ganze blöd es ständig neu zu identifizieren. Wenn man das nicht tut, könnten 2 Geräte mit ähnlicher IP verwechselt oder falsch identifiziert werden.

Entweder ich habe überlesen wo genau dieses Management nun stattfinden soll, oder dazu gibt es noch keine Antwort. Im AFTR ist es jedenfalls deutlich zu spät (ja ich weiß DPI undso, aber auch da wo man das tun könnte ist man bereits am Flaschenhals vorbei, wo man eine Überlastung ja bekämpfen müsste um es ohne unnötg großen Aufwand wirkungsvoll zu tun)
reneromann
Insider
Beiträge: 4917
Registriert: 28.06.2015, 13:26

Re: Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Beitrag von reneromann »

Flole hat geschrieben: 05.10.2018, 19:36 Du hast nicht verstanden das im IP Header eben nicht die Lokale IPv4 als Quelle steht, sondern irgendeine andere Adresse. Ob da nun im Datenverkehr (wie bei VPN) die lokalen IP Adressen stehen ist irrelevant, da die Quelladresse eben nicht die Lokale IP ist (das ist jetzt zumindest meine Definition von "gehen mit der lokalen IPv4....."). Für mich ist die Quell IP immer noch die, die im source Header des Paketes steht.
Und nochmal: Die Quell-IPv6-Adresse des Pakets am AFTR ist diejenige vom CPE (logischerweise, weil das CPE ja den DS-Lite-Tunnel per IPv6 zum AFTR aufbaut).
Innerhalb des Pakets ist jedoch die lokale IPv4 enthalten, die dann das AFTR-Gateway per NAT umsetzt. Am AFTR ist also sehr wohl bekannt, wie viele verschiedene Geräte per IPv4 im lokalen LAN sind.
Diese Gültigkeit ist aber eben nur für die Dauer der jeweiligen Verbindung vorhanden. Also WLAN aus, Gültigkeit weg.
Richtig - steht aber auch gar nicht zur Debatte...
Wenn du mir jetzt noch sagst wo ich geschrieben habe das man nicht sagen kann wie viele Geräte hinter einem Router sind wenn PE verwendet werden, wäre ich dir sehr verbunden.
Du schriebst:
Flole hat geschrieben: 05.10.2018, 00:51 Nicht wenn sich alle Geräte hinter einer IP Verstecken (NAT), da ist es unmöglich eine Verbindung einem Geräte zuzuweisen, und das ist so gewollt.
-in Kombination mit-
Flole hat geschrieben: 05.10.2018, 01:13 Und bei IPv6 gibt es, wie du ja sicherlich weißt, die privacy extensions sodass genau das ganze verhindert wird was du hier grad beschreibst.
Das OS Fingerprinting ist nunmal Thema des Threads, ich war jetzt davon ausgegangen das du dich darauf beziehst und nicht einfach wild in irgendeinem Thread dein IPv6 Wissen (oder Halbwissen) ablädst.
OS-Fingerprinting hat aber schon nichts mit NAT zu tun - also bitte erst einmal an die eigene Nase fassen.
Zumal man anhand des Traffics (ohne DPI) eh nicht herausfinden kann, welches OS den Traffic verursacht (außer man nimmt solche Sachen wie regelmäßige SMB-Browser-Requests mit rein).
Wenn man nun ständig ändernde IPs hat (wie bei PE) wird das ganze blöd es ständig neu zu identifizieren. Wenn man das nicht tut, könnten 2 Geräte mit ähnlicher IP verwechselt oder falsch identifiziert werden.
Du meinst: "könnten 2 Geräte mit gleicherIP verwechselt werden" - bei ähnlicher IPv6 hat man noch gar nichts gekonnt (und da würde ich auch keinerlei Aussage treffen wollen).
Mal davon abgesehen, dass eine IPv6 keine Aussage über das OS zulässt - wenn ich ein Multiboot-System "umboote", dann bekomme ich (ohne PE) die gleiche IPv6 heraus - trotz komplett anderem OS.
Flole
Insider
Beiträge: 9863
Registriert: 31.12.2015, 01:11

Re: Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Beitrag von Flole »

Wenn aber alle Verbindungen von einer IP kommen, ist es unmöglich eine einzelne Verbindung einem Gerät zuzuordnen, daher ja die Feststellung das es mit NAT eher schwierig wird.

Du kannst bei IPv6 in Verbindung mit dpi ohne PE einen Host identifizieren und diese Identifizierung bleibt relativ lange gültig, und das auch für alle Verbindungen von diesem Host. Mit PE ist das schon deutlich schwieriger.
amax
Kabelfreak
Beiträge: 1854
Registriert: 19.01.2008, 01:42
Wohnort: Region 2 / Heidekreis

Re: Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Beitrag von amax »

Na hier ist ja was los... :D

So, Leute hier mal kurz das Problem und die Darsteller.

1. Nahezu 11 Monate lief alles wie es soll, speed ok, oberes level. Ab September, mein 12 Monat im Vertrag, fing die Verbindung mit meinen Notebook
an zu zicken, normale Webseiten ( Presse) luden erst nach 3-4 Sekunden, die Inhalte bauten sich einzeln auf. Speedtest auf Oakla zum Schluß 27/2.8.... :brüll:
Mein Sixcore Desktop bekommt nun ca 28-300 Mbit anstatt 410.


Dazu muß ich vorausschicken , das ist ein älteres Gerät (Fujitsu/ Siemens) aber mit Gigabit , guter ST500-LM012 und Firewire und.....XP.
Ich habe darauf alle Tools und Programme die ich für Microelektonik und Messgeräte brauche.(z.B für ESC, Flightcontroller, 2.4GH RC Anlagen , Multiprotokoll Module und meine beiden DSP Boxen ( firewire) etc)
Das ganze habe ich seit 2013 aufgebaut und es war mit XP immer zuverlässig (Win7 geht nun auch, Win10 aber nicht immer).

Heute nach einigen Speedtest auf dem Notebook packte mich der Frust und ich habe meinen Desktop erst unter Win7/64 getestet und dann unter XP.
Es zeigte sich , das der erste Test und Win7 mies war und dann bei weiteren der Durchsatz immer weiter anstieg. ( auf DSLReports) Darauf hin bootet ich von den
Rechner unter XP und was soll ich sagen, gute Ergebnisse und im Bufferbloat sorgar um Längen besser als Win7(D) >> XP (B / Fiber/ 30 Verbindungen)!

Daraufhin holte ich das Notebook und hatte dort unter Fiber wieder knapp 340mbit ! GradeA+.

2. Wie passt das zusammen mit dem Mülltest bei Oakla?

Hier ist der Link von heute,( Messung 1bis 6 Desktop win7, 7 bis 9 XP, Messung 10 Notebook XP)
http://www.dslreports.com/speedtest/39922903

Tabelle bitte von unten lesen , Startzeit beachten
  • USA (EST) Down Up Ping B Q S = Link ISP Streams Button Tags Comment
    2018-10-05 08:51:37 338.3 51.3 34 - A+ A+ Cable Kabel Deutschland 24 / 16 >>>>Notebook
    2018-10-05 05:57:43 376.5 51.2 12 B A+ A Fiber Kabel Deutschland 30 / 16
    2018-10-05 05:52:21 362.1 51.3 12 B A+ A Cable Kabel Deutschland 18 / 16
    2018-10-05 05:51:07 362.5 51.2 12 C A+ A Cable Kabel Deutschland 18 / 16 >>> erster Test Desktop XP
    2018-10-05 05:44:10 387.6 52.3 14 D A+ B Cable Kabel Deutschland 16 / 16
    2018-10-05 05:40:40 317 51.5 13 C A+ A Cable Kabel Deutschland 12 / 12
    2018-10-05 05:31:25 371.5 49.7 15 D A+ B Cable Kabel Deutschland 16 / 16
    2018-10-05 05:29:54 342.6 52.7 13 D A B Fiber Kabel Deutschland 30 / 16
    2018-10-05 05:28:23 335.7 52.6 11 C A+ A Cable Kabel Deutschland 16 / 16
    2018-10-05 05:20:51 278.6 52.8 14 D A+ B Fiber Kabel Deutschland 30 / 16 >>>Erster Test Desktop Win7
    Join DSLReports to preserve these test results and more ..

Nachtrag:

Meine Verbindungen zu meinen US Foren sind vom langsamen Seitenaufbau nicht betroffen !
Zuletzt geändert von amax am 06.10.2018, 01:27, insgesamt 3-mal geändert.
ARRIS / RB750GR3 hEX.
Nun RED 250 / 50 .. http://www.dslreports.com/speedtest/69118186 ... :kaffee
Flole
Insider
Beiträge: 9863
Registriert: 31.12.2015, 01:11

Re: Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Beitrag von Flole »

Da kann ich dich beruhigen, das ganze hat nichts mit Bandbreitenmanagement zu tun. Ich würde eher auf ein Treiberproblem oder ein Problem mit dem OS/Webbrowser tippen.
amax
Kabelfreak
Beiträge: 1854
Registriert: 19.01.2008, 01:42
Wohnort: Region 2 / Heidekreis

Re: Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Beitrag von amax »

Nur ist merkwürdig das nach Tests mit dem Notebook die Bandbreite erst mal für den Desktop unter Win7 auch im Keller ist.

Treiberproblem? Waren doch vorher nicht da und geändert wurde auch nichts. Die Webbrowser sind nun alle Mist ( selbst die alten Mozilla ESR und auch Opera
beheben das nicht. Chrome habe ich runtergeschmissen.....

Die Schnittstellen Treiber müßen in Ordnung sein, ansonsten wäre das bei DSLReports aufgefallen.
ARRIS / RB750GR3 hEX.
Nun RED 250 / 50 .. http://www.dslreports.com/speedtest/69118186 ... :kaffee
Flole
Insider
Beiträge: 9863
Registriert: 31.12.2015, 01:11

Re: Reagiert das Bandbreitenmanagement auch auf das OS des Endgerätes?

Beitrag von Flole »

Ist das reproduzierbar? Selbes szenario, selber port, einfach nur kabel umstecken?

Du kriegst zumindest unter Win 7 ständig Updates wenn du das nicht deaktiviert hast. Eine Antivirensoftware kann Probleme verursachen usw.

Du könntest dir mal iperf runterladen und damit einen Speedtest laufen lassen, das klappt auch bei hohen Geschwindigkeiten gut. Dein Segment kann stark ausgelastet sein weshalb du immer knapp unter den 400 scheiterst.