Die Interface statistiken auf den Rechnern anschauen ist sicher nicht verkehrt:
Code: Alles auswählen
$ ip -s -h link
Code: Alles auswählen
$ ip -s -h link
Code: Alles auswählen
day rx | tx | total |
2019-11-09 1,93 GiB | 74,15 MiB | 2,00 GiB |
2019-11-10 1,48 GiB | 46,74 MiB | 1,53 GiB |
Fritte:
2019-11-09 2045 MB | 107 MB | 2161 MB |
2019-11-10 1599 MB | 72 MB | 1671 MB |
Code: Alles auswählen
2019-11-09 1.9045 GIB | 102.04 MIB | 2,012 GIB
Protkoll Overhead? Fragmentierung? PPPoE, VLAN? macht sicherlich nicht 1.5x aus aber 1-10% könnten es schon sein - je nach dem was da alles noch reinpfuscht.willy4711 hat geschrieben:10.11.2019 14:35:37Was mir auffällt, dass TX (gesendet) latent um den Faktor ca 1,5 höher ist, als von vnstat. Auf den ganzen letzten Monat ist die Differenz 0,5 GB.
Ob Zwangstrennung oder nicht hängt vom Provider ab. Ich habe z.B. keine Zwangstrennung und trotzdem keine feste IP-Adresse. Warum einige Provider an dieser Zangstrennung festhalten, ist mir sowieso schleierhaft. Einen Vorteil hat der Provider dadurch nicht, denn die Router verbinden sich ja sowieso innerhalb weniger Sekunden erneut, IP-Adressen kann der Provider dadurch also nicht einsparen. Die Vorratsdatenhaltung wird für den Provider teurer weil die Datenbanken öfter neue Verbindungsdaten speichern müssen und die Telefonie wird durch Zwangsunterbrechungen behindert.willy4711 hat geschrieben:10.11.2019 14:35:37Nun gibt es ja einen tägliche Zwangstrennung, die ganz sicherlich auch hin und her telefoniert, wieviel das ist auf den Monat gerechnet ? Keine Ahnung.
AVM bietet doch dieses myFritz an, was meines Wissens irgendso eine Cloudlösung ist. Darüber kann man per Smartphone-App die Box fernwarten, z.B. Rufweiterletungen einrichten oder auch Daten vom/ins LAN transferieren.Ich hab jetzt mal die AVM-Dienste und die Anbieterdienste wieder deaktiviert (sind mir wohl beim letzten Update von FritzOS wieder untergeschoben worden )
Nee das ist es sicher nicht. Ganz normales VDSL. "Verbraucher" über switch / router direkt angeschlossen.reox hat geschrieben:10.11.2019 14:59:24Protkoll Overhead? Fragmentierung? PPPoE, VLAN? macht sicherlich nicht 1.5x aus aber 1-10% könnten es schon sein - je nach dem was da alles noch reinpfuscht.
Da hab ich ungenau berichtet. Das macht die Fritte selber jeden Tag um 3 Uhr irgendwas, "um der ZwangstrennungMSfree hat geschrieben:10.11.2019 15:15:33Ob Zwangstrennung oder nicht hängt vom Provider ab. Ich habe z.B. keine Zwangstrennung und trotzdem keine feste IP-Adresse. Warum einige Provider an dieser Zangstrennung festhalten, ist mir sowieso schleierhaft. Einen Vorteil hat der Provider dadurch nicht, denn die Router verbinden sich ja sowieso innerhalb weniger Sekunden erneut, IP-Adressen kann der Provider dadurch also nicht einsparen. Die Vorratsdatenhaltung wird für den Provider teurer weil die Datenbanken öfter neue Verbindungsdaten speichern müssen und die Telefonie wird durch Zwangsunterbrechungen behindert.
Code: Alles auswählen
10.11.19 15:44:23 Die Systemzeit wurde erfolgreich aktualisiert von Zeitserver 217.188.59.84.
10.11.19 15:44:23 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a01:c22:3486:500::/56
10.11.19 15:44:23 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2a01:c22:3600:f8e:3681:c4ff:fe32:fe77
10.11.19 15:44:22 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 77.183.191.206, DNS-Server: 62.109.121.2 und 62.109.121.1, Gateway: 62.52.201.184, Breitband-PoP: BERJ12
10.11.19 15:44:19 DSL ist verfügbar (DSL-Synchronisierung besteht mit 105529/39190 kbit/s).
10.11.19 15:42:39 Anmeldung des Benutzers xxxxxxx an der FRITZ!Box-Benutzeroberfläche von IP-Adresse 192.168.0.40.
10.11.19 15:42:02 WLAN-Übertragungsqualität durch reduzierte Kanalbandbreite erhöht (2,4 GHz).
10.11.19 15:41:59 DSL-Synchronisierung beginnt (Training). [2 Meldungen seit 10.11.19 15:41:20]
10.11.19 15:41:12 Der USB-Speicher FRITZ_FAT wurde eingebunden.
10.11.19 15:41:05 USB-Gerät 1002, Klasse 'USB 2.1 (hi-speed) storage', angesteckt
Hmm, der Overhead bei PPPoE ist vor allem für kleine Netzwerkpakete relativ groß. Schließlich muß jedem normalen Internetpaket (egal ob UDP oder TCP) der PPP-Header vorangestellt werden. Der macht in der Regel 8 extra Bytes aus, die MTU ist bei PPPoE in der Regel 1492 Bytes, die MTU im LAN dagegen 1500 Bytes.reox hat geschrieben:10.11.2019 14:59:24Protkoll Overhead? Fragmentierung? PPPoE, VLAN? macht sicherlich nicht 1.5x aus aber 1-10% könnten es schon sein - je nach dem was da alles noch reinpfuscht.willy4711 hat geschrieben:10.11.2019 14:35:37Was mir auffällt, dass TX (gesendet) latent um den Faktor ca 1,5 höher ist, als von vnstat. Auf den ganzen letzten Monat ist die Differenz 0,5 GB.
Code: Alles auswählen
# ifconfig -a
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.31.1 netmask 255.255.255.0 broadcast 192.168.31.255
ether ... txqueuelen 1000 (Ethernet)
RX packets 379285427 bytes 26431804881 (24.6 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 630624379 bytes 927514528430 (863.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether ... txqueuelen 1000 (Ethernet)
RX packets 592013080 bytes 875257030725 (815.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 325645088 bytes 26603564982 (24.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1 (Lokale Schleife)
RX packets 7793580 bytes 3438558556 (3.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7793580 bytes 3438558556 (3.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1492
inet ... netmask 255.255.255.255 destination ...
ppp txqueuelen 3 (Punkt-zu-Punkt-Verbindung)
RX packets 591591274 bytes 862216642707 (803.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 325222970 bytes 19435996084 (18.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Code: Alles auswählen
ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.40 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 2a01:c22:3486:500:f9aa:708b:102:9744 prefixlen 64 scopeid 0x0<global>
inet6 fe80::5680:2019:2ea0:4954 prefixlen 64 scopeid 0x20<link>
inet6 fd00::270a:23e5:2608:d075 prefixlen 64 scopeid 0x0<global>
ether d0:50:99:71:41:8f txqueuelen 1000 (Ethernet)
RX packets 4696983 bytes 6882334134 (6.4 GiB)
RX errors 0 dropped 67026 overruns 0 frame 0
TX packets 1568047 bytes 117132071 (111.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Lokale Schleife)
RX packets 17351 bytes 13619610 (12.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 17351 bytes 13619610 (12.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Genau genau genommen wird seit dem letzten Hochbringen der Schnittstelle gezählt. Nach ifdown, ifup fängt es wieder bei Null an. In meinem Fall stimmen Boot und ifup allerdings überein.willy4711 hat geschrieben:10.11.2019 16:44:59Interessant. Ich vermute mal, dass ifconfig ab Rechner- Start zählt
Woher weißt du das denn so genau?rwkraemer hat geschrieben:15.04.2021 20:30:42das einzige was ich weiß, das der PC (Lenovo Ideacentre 510-15abr) offenbar für das angezeigte Datenvolumen verantwortlich ist.
Code: Alles auswählen
4 1.046436358 192.168.178.xx 142.250.181.206 TLSv1.2 273 Application Data
26 2.000687622 AvmAudio_a1:61:e5 AtherosC_00:00:01 HomePlug AV 60 MAC Management, Get Device Attributes Request
50 2.573821341 192.168.178.xx 172.217.130.42 TCP 66 60174 → 443 [ACK] Seq=1 Ack=2793 Win=4636 Len=0 TSval=138098891 TSecr=3970463500
1152 7.702448756 172.217.130.42 192.168.178.xx TCP 1462 443 → 60174 [ACK] Seq=997549 Ack=2550 Win=886 Len=1396 TSval=3970468627 TSecr=138104009 [TCP segment of a reassembled PDU]
1675 9.136266054 192.168.178.xx 172.217.19.74 TCP 74 46296 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3503579715 TSecr=0 WS=128
1676 9.159193119 172.217.19.74 192.168.178.xx TCP 74 443 → 46296 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1430 SACK_PERM=1 TSval=2771373098 TSecr=3503579715 WS=256
1677 9.159260621 192.168.178.xx 172.217.19.74 TCP 66 46296 → 443 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=3503579738 TSecr=2771373098
1678 9.162439663 192.168.178.xx 172.217.19.74 TLSv1.3 713 Client Hello
Ähh also meinen die, dass der WAN Counter die LAN Verbindungen mitzählt?! Dann wäre das aber ein Bug und kein Feature...rwkraemer hat geschrieben:16.04.2021 20:58:07AVM hat ja gesagt, dass bei LAN-Verbindungen bei der Darstellung des Datenvolumens zu Fehlern kommen kann
das sagt mir jetzt mal gar nichts.
Das hat erstmal nichts zur Sache. Was ich meine ist, wenn Wireshark aufzeichnet, kannst du auf Statistiken -> Endpunkte gehen.rwkraemer hat geschrieben:17.04.2021 21:00:49Ich habe bei Wireshark als Schnittstelle "Ethernet" gewählt, nicht "any".
Also nur nochmal zum Mitschreiben, so schaut deine Topologie aus:rwkraemer hat geschrieben:17.04.2021 21:00:49Der PC und das Notebook sind über LAN-Kabel mit dem Router verbunden
Code: Alles auswählen
+ ----------- PC Lenovo Ideacentre 510-15abr
|
Inet ------- Fritzbox 7430
|
+------------- Notebook Fujitsu Lifebook S762
Code: Alles auswählen
ip -s link
Code: Alles auswählen
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
3240 64 0 0 0 0
TX: bytes packets errors dropped carrier collsns
3240 64 0 0 0 0
2: enp2s0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 6c:4b:90:4b:d7:3d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
163272311 134101 0 7898 0 94
TX: bytes packets errors dropped carrier collsns
7553315 69462 0 0 0 0
Ja, das ist immer aus der Sicht des Rechners, auf dem der Befehl ausgeführt wird. Ich sehe da rund 16MB empfangene und rund 750kB gesendete Daten, also alles völlig harmlos.rwkraemer hat geschrieben:18.04.2021 20:48:29Wenn ich das richtig verstanden habe, wird ja mit hier der Verkehr ausgehend und eingehend vom Rechner gemessen.
Ich sehe da etwas mehr: Etwa 160MB an empfangenen und 7MB an gesendeten Daten. Aber das sollte nicht der springende Punkt sein, auffällig sind eher die hohe Zahl an verworfenen Paketen. Kabel in Ordnung? Netzwerkkarte ok?MSfree hat geschrieben:18.04.2021 21:48:18Ich sehe da rund 16MB empfangene und rund 750kB gesendete Daten, also alles völlig harmlos.