[Problem] FRITZ!Box 7490 und WLAN Routing

megafix

Neuer User
Mitglied seit
17 Jun 2010
Beiträge
16
Punkte für Reaktionen
1
Punkte
3
Es geht um ein generelles Problem eines WLAN Clients auf das Internet zuzugreifen.

Wir nehmen einen beliebigen Linux Rechner, der per LAN mit der FRITZ!Box verbunden ist. Er befindet sich im gleichen Subnet, wie die FRITZ!Box und hat in den Kernel Parametern IPv4 Forwarding aktiviert, d.h. er fungiert als Router. Er selbst hat die FRITZ!Box als Default Gateway eingetragen.

Wenn sich ein WLAN Client an der FRITZ!Box anmeldet, bei dem nicht die FRITZ!Box als Standard Gateway eingetragen ist, sondern dieser genannte Linux Rechner, ist kein zuverlässiger Internet Zugang von diesem WLAN Client mehr möglich. Die Verbindung vom WLAN über das LAN ins WAN ist extrem instabil und langsam.

Ist der identische Client per LAN mit der FRITZ!Box verbunden und hat ebenfalls den Linux Rechner als Default Gateway eingetragen, funktioniert der Internetzugang problemlos.

Wird ein zusätzlicher WLAN-Accesspoint mit der FRITZ!Box verbunden und hierüber meldet sich ein WLAN Client an, funktioniert wieder alles, ebenfalls unter Nutzung des Linux Rechners als Default Gateway.

Hat jemand hierzu eine Idee, wo der Hund begraben sein könnte?
 
Zuletzt bearbeitet:
Wie nennt sich die Firmware der 7490 ?
 
Das genannte Problem tritt neben der 7490 auch mit den Modellen 7360, 3490 und 3272 auf. Eine 7580 z.B. zeigt das Problem nicht.

Getestet habe ich auf der 7490 mit 113.06.80-42822 (Final) und 113.06.80-42824 (Intern).

Es lässt sich aber auch mit älteren FRITZ!OS Versionen nachstellen.
 
Ich habe zumindest mit Windows-Notebooks das Problem nicht.

Bei mir arbeitet eine 7490 als DSL-Router (mit einem /28-Netz auf der LAN-Seite) und parallel als WLAN-AP (rein auf L2 als Bridge zwischen LAN und WAN). Die 7490 bietet keinen eigenen DHCP-Server an und ist über einen VLAN-fähigen Switch mit einem zentralen Linux-Server, der gleichzeitig mit einem umfangreichen Regelwerk die interne Firewall und das IDS gibt, verbunden, dabei kommt ein VLAN (also eine ID) zum Einsatz, wo nur die Box und der Server eingebunden sind. Da die Box auf der LAN-Seite kein Tagging macht, wird alles vom Switch getaggt und an den Server weitergereicht, der allerdings hat auf seinem Interface praktisch alle VLAN-IDs und taggt auch selbst.

Der Server teilt dann den Rest des IPv4-Segments, in dem sich auch das /28-Netz der 7490 befindet, in 4 /26-Segmente auf (die Box liegt im ersten) und sorgt mit seinem DHCP-Server dafür, daß die WLAN-Clients je nach ihrer Funktion in das jeweils passende Segment geraten, damit (nicht narrensicher, aber ausreichend, weil es neben dem VLAN zur 7490 eben noch weitere gibt) die Zugriffspfade halbwegs eingehalten werden und nicht jeder WLAN-Client (per IP) mit jedem Ethernet-Gerät (in weiteren IPv4-Segmenten) Kontakt aufnehmen kann - das muß alles über den Server, der auch intern Masquerading macht.

Die WLAN-Clients kriegen also alle den zentralen Server als Gateway verpaßt und der sorgt dann auch dafür, daß sie für den Internet-Zugriff wieder auf die 7490 zurückgelangen, wobei er eben noch ein Masquerading macht, denn die "Rückwärtsverbindung" soll ja ebenfalls über ihn laufen.

Dabei kann ich das geschilderte Problem nicht feststellen ... ich würde mal mit einem Mitschnitt nachsehen, ob da nicht das "angedachte" Gateway am Ende anstatt zu routen einfach nur mit "redirect"-ICMPs antwortet (das sieht halt bei sich selbst, daß eingehendes und ausgehendes Interface identisch sind und denkt sich: "Rede doch gleich mit dem richtigen Gateway.") und das muß (a) nicht jeder Client "mögen" und kann (b) zu Konflikten bei der L2-Adressierung führen. Das Verhalten bzgl. solcher Redirections läßt sich über Kernel-Einstellungen (per "sysctl", einfach mal dort in der Ausgabe nach "redirect" suchen) beeinflussen. Wenn das Linux-System dann tatsächlich selbst routet und keine Redirects stattdessen versendet, sollte das auch zuverlässig funktionieren.

Wenn der Server hier kein Masquerading macht, dann sollte m.E. die FRITZ!Box auf dem "Rückweg" ja die Daten direkt an den jeweiligen WLAN-Client "adressieren" und dessen IP-Adresse wird per ARP aufgelöst - die gefundene MAC-Adresse liegt aus Sicht der FRITZ!Box hinter dem "WLAN-Port" des internen Switches und damit gehen die Daten (theoretisch) direkt ins WLAN. Hier kommt dann sicherlich wieder hinzu, daß es aber im "packet accelerator" gar keine passende Regel für dieses "Ziel" im WLAN gibt, denn aus Sicht der Box kam die ursprüngliche Verbindung ja von der MAC-Adresse des (internen) Gateways. Welche Konsequenzen sich jetzt daraus ergeben mögen, kann ich so aus dem Stand nicht abschätzen ... also wohin die FRITZ!Box jetzt so ein eingehendes Paket tatsächlich schickt - an das Ziel der "PA session" (da steht die MAC-Adresse dabei, da bräuchte es keine ARP-Lookups o.ä.) oder ob das tatsächlich noch einmal den L3->L2-Prozess durchläuft und am Ende bei der MAC-Adresse passend zur IP-Adresse landet. Ich würde mal behaupten, daß es auf den "Inhalt" des Paketes ankommt und daß mal der eine und mal der andere Weg genommen wird, was dann auch zu der erwähnten Unzuverlässigkeit führen könnte.

Macht man also auf dem Gateway dann Masquerading und übernimmt stellvertretend die Rolle des WLAN-Clients als "Absender" von Paketen für das Internet, sollte es die Probleme auch nicht geben. Ob am Ende jeweils einer der beiden Ansätze schon hilft oder es beide braucht, weiß ich nicht ... ob der PA hier tatsächlich "mitspielt", kann man einfach dadurch testen, daß man ihn kurzerhand abschaltet und dann noch einmal probiert. Wie das geht, steht in anderen Threads ... Stichworte "PA", "packet accelerator", "avm_pa" - wer es ganz genau wissen will, sieht sich die Kernel-Quellen zum PA an, auch wenn die nur teilweise Aufschluß geben, weil Interna des Paket-Prozessors da auch nicht so richtig zu finden sind -> was kann man alles "automatisch" übersetzen lassen und nach welchen Kriterien kann man entscheiden lassen, ob ein Paket "beschleunigt" wird (also direkt zum Client weitergereicht wird) oder ob es eingehender "inspiziert" werden muß (wie z.B. ein FIN-Paket, damit die PA-Session dann auch geschlossen werden kann).
 
Halllo PeterPawn,

ganz vielen Dank für deine ausführlichen Erklärungen. Momentan kann ich aus zeitlichen Gründen noch nicht detailliert darauf eingehen und ich muss dein Update auch erst noch im Detail verdauen:)

An ICMP Redirect hatte ich auch schon gedacht, das scheint jedoch hier nicht ursächlich zu sein.

Eigentlich bin ich kein Freund voreiliger Schlüsse, aber der packet accelerator (avm_pa) könnte durchaus der Übeltäter sein.

Mit einem "echo disable > /proc/net/avm_pa/control" bzw. "echo enable > /proc/net/avm_pa/control" konnte ich das Fehlverhalten des WLAN Clients sofort beheben, bzw. wieder erzeugen. Aber das war nur ein einziger ganz schneller Test.

Leider komme ich erst morgen dazu wirklich aussagefähige Tests zu machen. Erst danach kann ich dann brauchbare Ergebnisse zurückgeben.

Der Ursprung dieses Problems liegt hier.

- - - Aktualisiert - - -

@PeterPawn,
jetzt habe ich zumindest schon etwas Zeit gefunden, mir Gedanken darüber zu machen, warum mein WLAN zu WAN Routing Problem bei dir nicht auftritt.

Dein Setup ist relativ umfangreich, daher wähle ich einen pragmatischen Ansatz, es radikal auf die für mein Problem relevanten Faktoren zu reduzieren.

Ich ignoriere daher alle deine VLANs, denn davon merkt die FRITZ!Box auf der LAN Seite nichts. Ob ein DHCP Server läuft oder nicht, ist ziemlich egal. Den DHCP Server der FRITZ!Box kann ich ohnehin nicht gebrauchen, weil ich ein alternatives Gateway möchte. Auch das zusätzliche IP Masquerading deines zentralen Linux-Server unterschlage ich, denn das kommt bei der FRITZ!Box als normaler IP Traffic an.

Deine WLAN Clients benutzen die FRITZ!Box als Access Point um in die VLANs zu gelangen. Wenn sie von dort aber ins Internet wollen, werden sie per Masquerading auf eine LAN Adresse umgesetzt. Mit LAN Clients kann ich das Problem auch nicht reproduzieren.

Deine FRITZ!Box kennt im Prinzip nur LAN Traffic ins Internet und zurück. Der WLAN Traffic kommt nicht über den Linux-Server hinaus.

Schlag mich bitte nicht, falls ich das völlig falsch dargestellt habe :)

Jetzt zurück zu dem WLAN zu WAN Routing Problem.

Auf dem WLAN Client (Lenovo Notebook) läuft ebenfalls Windows, in diesem Fall Windows 7 x64. Die Netzwerk Einstellungen wurden manuell vorgenommen, da ich ja ein anderes Gateway als die FRITZ!Box benutzen möchte. Der DHCP Server auf der FRITZ!Box könnte komplett abgeschaltet werden.

Meine FRITZ!Box 7490 ist kein DSL Router, sondern benutzt momentan Internetzugang über LAN1 zu einem Cisco DOCSIS 3.0 Kabelmodem. Das ist aber auch nicht relevant, denn ich habe noch einen DSL Anschluss, mit dem der Fehler auch reproduzierbar wäre. IP Masquerading läuft nur auf der FRITZ!Box.

Mein Linux Gateway routet den Client definitiv durch. Es versendet und akzeptiert keine ICMP redirects messages. Das ist alles über Kernel Parameter so eingestellt und funktioniert tadellos.

Der Fehler wird nur dann auftreten, wenn ein WLAN Client über das Linux Gateway zur FRITZ!Box geroutet wird und ins WAN geht. Im lokalen Subnet ist immer alles erreichbar.

Könnte dies der Unterschied zu deinem Setup sein, oder bin ich total auf dem Holzweg?
 
Zuletzt bearbeitet:
Wenn Du auf der FRITZ!Box unter /proc/net/avm_pa/sessions nachsiehst, müßtest Du m.E. Sitzungen sehen, die eben als Ethernet-Adressen nicht die des WLAN-Clients und der FRITZ!Box verwenden, sondern die der FRITZ!Box und des zusätzlichen Gateways, während aber die IPv4-Adresse in der Sitzung auf den WLAN-Client zeigt. Nur wenn es die auch wirklich gibt, ergibt meine Theorie überhaupt so etwas wie einen Sinn.

Das wäre m.E. das Ergebnis von Paketen, die vom Client an eine beliebige IP-Adresse gesendet werden sollen, daher die L2-Adresse des Gateways erhalten (L3 enthält ja das endgültige Ziel irgendwo im Internet) und dann dorthin geschickt werden - zwar mit der L2-Absenderadresse des Clients, aber die kommt jetzt nicht über das Gateway hinaus.

Das Gateway inspiziert jetzt die Pakete und trifft die Entscheidung, ob die passieren dürfen oder nicht - wenn ja, sendet es das empfangene Paket mit neuem L2-Header weiter. Der enthält jetzt die MAC-Adresse der FRITZ!Box als Ziel und die MAC-Adresse des Gateways als Absender.

Damit kommt das Paket auf der FRITZ!Box an, wird analysiert und erzeugt jetzt (wenn die Voraussetzungen stimmen) eine neue PA-Session ... aber eben mit den L2-Adressen, die im Paket stehen.

Kommt jetzt bei einem "normalen" Router im Rahmen so einer Verbindung ein Paket zurück, dann landet das ganz normal im Routing und wird über das LAN-Interface an die Ziel-IP-Adresse ausgeliefert, damit erhält es im Rahmen der "normalen" ARP-Auflösung als Ziel auf L2 direkt die MAC-Adresse des Clients und die Absenderadresse des Routers - das Gateway ist in den "Rückweg" der Daten gar nicht mehr (sicher) involviert. "Sicher" deshalb, weil ARP-Spoofing keine verläßliche Art der Adressierung ersetzen kann, denn welche Zuordnung auf dem Router gerade aktuell ist, wenn es ein Paket zu routen gilt, kann man damit nicht sicher "vorhersagen". Wobei es ja eigentlich auch keinen Grund gibt (wenn ich das Prinzip des eBlocker richtig verstanden habe), Antworten aus dem WAN ebenfalls noch zu analysieren ... es werden ja wohl schon die Requests unterdrückt (keine Ahnung, ob aktiv durch ICMPs oder einfach durch "reject" und der Client kriegt irgendwann ein Timeout) und dann gibt es erst gar nicht eine Antwort.

Bei der FRITZ!Box kann es aber eben passieren, daß jetzt so ein eingehendes Paket zu einer PA-Session gehört und dort direkt die IP-Adressen und -Ports ersetzt werden (das normale (R-)NAT) und gleichzeitig aber die L2-Adressen aus der Session für den Weitertransport verwendet werden. Sonst bräuchte so eine PA-Session die ja gar nicht erst zu speichern, wobei ich jetzt auch nicht nachgesehen habe, ob wirklich direkt die MAC-Adresse ebenfalls aus der Session genommen wird (drin steht sie aber eben sehr wohl, wie Du selbst nachsehen kannst) - als Hypothese sollte das "durchgehen" können mit der Begründung, daß so eine MAC-Adresse in der PA-Session sonst überflüssig wäre. Damit landet so ein Paket jetzt irgendwo "von der falschen Seite" am Gateway (keine Ahnung, was dieser eBlocker damit dann wirklich macht) und dieses wäre nun auch "für den Rückweg" zuständig - wieder nach Austausch des L2-Headers (Absender Gateway, Ziel Client).

Im Endeffekt hat aber der PA recht widersprüchliche Informationen vorliegen (Ethernet-Adressen und IP-Adressen passen nicht zueinander, sähe für ein IDS wie eine MITM-Attacke aus) und was daraus jetzt an konkreten Problemen resultiert, weiß ich nicht und will ich auch nicht "vorhersagen". Irgendwelche IDS-Ansätze wird es aber vermutlich geben, denn die FRITZ!Box soll/will sich ja mit ihrer Kindersicherung auch gegen allzu offensichtliches Spoofen einer MAC-Adresse verteidigen - Einzelheiten sind m.W. nicht bekannt, was da wie ausgewertet wird.

Eine denkbare Lösung wäre es, wenn so ein "eBlocker" bei der Feststellung, daß es sich beim Router um eine FRITZ!Box handelt, das etwas anders behandelt. Keine Ahnung, wer sonst noch bei seinen Routern von den erweiterten Funktionen bei den Lantiq-Chipsets wirklich Gebrauch macht, eine 100/40-VDSL-Verbindung, bei der die Daten wirklich alle durch den kompletten Linux-IP-Stack müssen, könnte die beiden Cores eines VR9 auch überfordern, bei anderen (älteren) Prozessoren sieht es wahrscheinlich noch finsterer aus.

Jedenfalls gäbe es bei der FRITZ!Box ja die Möglichkeit, daß sich der eBlocker wie ein "Repeater" verhält und die Daten nach seiner eigenen Analyse einfach per L2TPv3 an die FRITZ!Box weiterreicht. Damit müßte (ungetestet, nur Theorie) die FRITZ!Box jetzt die Verbindung als "direkt vom Client kommend" ansehen und auch in der PA-Session eigentlich die Ethernet-Adresse des Clients anstelle der des Gateways verwenden.

Eventuell hilft es ja aber auch schon, wenn der eBlocker wirklich richtig damit umgeht, daß er (obwohl er sich in demselben Subnetz befindet) auch vom Router in den Rückweg der Daten eingebunden werden kann (das dürfte eben bei einem "normalen Router" - s.o. - nie der Fall sein) und dann auch solche Pakete ordentlich "abliefert". Ob er das vielleicht jetzt schon macht, kann und will ich nicht einschätzen ... ich sehe halt den entscheidenden Unterschied, der (vermutlich) bei FRITZ!Boxen zu Problemen führt, im PA.

Ohne PA ist dann aber beim Durchsatz auch wieder schnell das Ende der Fahnenstange erreicht - einfach abschalten ist also auch nur bei ADSL2+ und 16 MBit/s noch eine gute Idee, schon bei VDSL50 könnte es eng werden, erst recht dann, wenn der Besitzer noch andere Funktionen der FRITZ!Box intensiver nutzt (z.B. VPN oder externes GUI, wo eben Verschlüsselung zusätzliche Performance braucht), dann kommt eine 7490 bei mir schon am VDSL25-Anschluß ins Schwitzen (auch mit PA).

Alles Theorie, weil ich zwar eine Vorstellung habe, mit welchen Mitteln sich der eBlocker in die Kommunikation automatisch(!) einklinken will, wenn er nicht tatsächlich als Default-Gateway bei irgendwelchen Clients konfiguriert ist (das "Versprechen", den einfach ins Netz zu stecken und den Rest macht er alleine, kann er ja auf "regulärem Weg" nur erfüllen, wenn ihm die Clients wirklich freiwillig den Traffic senden - schon beim ARP-Spoofing für die Adresse des eigentlichen Routers geht das in Grautöne über), aber ich habe ohnehin keinen alten RasPi mehr (einen 3B hätte ich gerade herumliegen) und könnte es daher ja (nach der Hardware-Liste) ohnehin nicht wirklich testen.
 
Das RPi 2 eBlocker Image funktioniert auch mit RPi 3. Nur die Startup Files müssen gewechselt werden.
(RPi = Raspberry Pi)

http://www.stonesblog.at/index.php/...pi3-installiern-kein-offizieller-support.html

Mit einem BPi M2+ macht es aber mehr Spass, weil er einen GbE Anschluss hat und man die Firmware in den 8GB eMMC kopieren kann.
(BPi = Banana Pi)

Warum eBlocker da eine langsame microSD reinsteckt verstehe ich nicht.

nachträgliche Korrektur (12 Feb 17): Dieser Kritik-Punkt ist unberechtigt, die aktuellen eBlocker im weißen Würfel-Gehäuse verwenden beim BPi M2+ den eMMC NAND und haben keine microSDHD im Slot. Da habe ich wohl Kunden mit dem DIY Image und Kunden mit der gekauften Lösung vermischt.
Es gab auch noch eine Vorserie mit BPi M2 im transparenten Standard (non-Custom) Gehäuse, die braucht natürlich eine microSD, weil sie noch keinen eMMC besitzt.


Ich muss deinen Update erst wieder verdauen, zumal du jetzt schon Problem 2 mit ARP Spoofing rein gebracht hast :)



Mit avm_pa hast du aber einen Volltreffer gelandet. Das ist die Ursache von Problem 1 (WLAN to WAN Routing). Für die Nachstellung ist kein eBlocker notwendig, nur ein zusätzlicher Router.
 
Zuletzt bearbeitet:
Hier mal ein erster Test mit einem Windows WLAN Client, der einen Raspberry Pi3 als Default Gateway benutzt.

Folgende Geräte sind involviert:

GerätMAC AdresseIP Adresse
FB MAC_A LAN08:96:d7:xx:xx:86192.168.188.1
FB MAC_DSL LAN08:96:d7:xx:xx:8a
CMTS LAN00:01:5c:xx:xx:4095.89.xx.231
Intel WLAN3c:a9:f4:xx:xx:ac192.168.188.102
RPi3 LANb8:27:eb:xx:xx:3b192.168.188.108









So sieht die manuelle Konfiguration des Windows Rechners aus.

avm1.png

Das wirkt sich so auf dem Windows Client aus:

avm2.png

Auf dem Windows Rechner wird fortwährend ein Ping ausgeführt um eine Verbindung ins Internet zu erzeugen.

f:\>ping -t eblocker.com
Pinging eblocker.com [138.68.124.96] with 32 bytes of data:
Reply from 138.68.124.96: bytes=32 time=18ms TTL=53
Reply from 138.68.124.96: bytes=32 time=16ms TTL=53
...


Auf dem Raspberry Pi3, der als Gateway dient, wird IP Forwarding aktiviert.

avm3 raspi.png

Folgende Commands werden auf der FRITZ!Box 7490 ausgeführt:

# cat /proc/net/avm_pa/brief
Version : For Linux 3.10.73 ( #0 SMP Thu Jan 19 17:52:54 CET 2017 )
State : enabled
HW State : enable
BSessions : 0
Sessions : 84
Max Sessions : 170
Sessions (dead): 11
Sessions (free): 160
Queuelen : 0
Rx pkts/secs : 50
Fw pkts/sec : 1
Ov pkts/sec : 0
Rx pakets : 51099
Rx bypass : 40639
Rx ttl <= 1 : 0
Rx broadcast : 0
Rx search : 10460
Rx match : 3582
Rx modified : 693
Fw pakets : 3251
Fw local : 2268
VPID1 : RX 0 TX 2 eth0
VPID2 : RX 0 TX 0 eth1
VPID3 : RX 0 TX 0 eth2
VPID4 : RX 6165 TX 4556 eth3
VPID5 : RX 1737 TX 11919 wasp
VPID6 : RX 0 TX 0 ptm_vr9
VPID7 : RX 1321 TX 2915 internet

# cat /proc/net/avm_pa/macaddrs
13: 00:01:5c:xx:xx:40 (9 3/eth0) # 95.89.xx.231 CMTS-LAN
145: 3c:a9:f4:xx:xx:ac (9 7/wasp) # 192.168.188.102 Intel WLAN
205: b8:27:eb:xx:xx:3b (2 6/eth3) # 192.168.188.108 RPi3 LAN

# arp -an
? (192.168.188.102) at 3c:a9:f4:xx:xx:ac [ether] on lan
? (192.168.188.108) at b8:27:eb:xx:xx:3b [ether] on lan

Der Packet Accelerator erstellt 3 Sessions, wenn der Raspberry als Standard Gateway benutzt wird.

Session : 7780 (132)
State : active
TX active : 0
In Pid : 3 (eth0)
In VPid : 7 (internet)
In HW : no
CT dir : original
Associated : 214
Realtime : no
PktType : IPv4+ICMP
FragOk : 1
Syn : 0
Fin : 0
Eth Hdr DS : 08:96:d7:xx:xx:8a 00:01:5c:xx:xx:40 proto 0800 # FB MAC_DSL LAN / CMTS LAN
IPv4 Hdr : 138.68.124.96 95.89.xx.231 proto 1 tos 00
ICMPv4 : echo reply id=1
Hdrlen : 46
IP version : 4
L2 pull : 14
SKB proto : 0800
*IPv4 Dst : 192.168.188.102
*IPv4 TTL : decrease
*L3 Sum : 0xe6ce
Hroom : 4
Timeout : 3
SW stats : 345 pkts, 25530 bytes
HW stats : 0 pkts, 0 bytes}
Egress : 0
Out Pid : 7 (wasp)
Out VPid : 5 (wasp)
Mtu : 1500
L2 push : 18: 3CA9F482FFAC0896D75BA186810000050800
Macaddr : 3c:a9:f4:xx:xx:ac ref 7 Pid 7 wasp # Intel WLAN
Orig Prio : 0:0
Prio : 0:0
TC index : 32768
cpmac prio : 0
SW stats : 345 pkts, 26910 bytes
HW stats : 0 pkts, 0 bytes
Pkts : TX 345 (acks 0)
--
Session : 7778 (144)
State : active
TX active : 0
In Pid : 7 (wasp)
In VPid : 5 (wasp)
In HW : no
Realtime : no
PktType : IPv4+ICMP
FragOk : 1
Syn : 0
Fin : 0
Eth Hdr DS : b8:27:eb:xx:xx:3b 3c:a9:f4:xx:xx:ac proto 8100 # RPi3 LAN / Intel WLAN
Vlan ID : 5
IPv4 Hdr : 192.168.188.102 138.68.124.96 proto 1 tos 00
ICMPv4 : echo request id=1
Hdrlen : 42
IP version : 4
L2 pull : 18
SKB proto : 0800
Hroom : 0
Timeout : 3
SW stats : 345 pkts, 26910 bytes
HW stats : 0 pkts, 0 bytes}
Egress : 0
Out Pid : 6 (eth3)
Out VPid : 4 (eth3)
Mtu : 1500
L2 push : 14: B827EB4DA53B3CA9F482FFAC0800
Macaddr : b8:27:eb:xx:xx:3b ref 3 Pid 6 eth3 # RPi3 LAN
Orig Prio : 0:0
Prio : 0:0
TC index : 0
cpmac prio : 0
SW stats : 345 pkts, 25530 bytes
HW stats : 0 pkts, 0 bytes
Pkts : TX 345 (acks 0)
--
Session : 7779 (214)
State : active
TX active : 0
In Pid : 6 (eth3)
In VPid : 4 (eth3)
In HW : no
CT dir : reply
Associated : 132
Realtime : no
PktType : IPv4+ICMP
FragOk : 1
Syn : 0
Fin : 0
Eth Hdr DS : 08:96:d7:xx:xx:86 b8:27:eb:xx:xx:3b proto 0800 # FB MAC_A LAN / RPi3 LAN
IPv4 Hdr : 192.168.188.102 138.68.124.96 proto 1 tos 00
ICMPv4 : echo request id=1
Hdrlen : 42
IP version : 4
L2 pull : 14
SKB proto : 0800
*IPv4 Src : 95.89.xx.231
*IPv4 TTL : decrease
*L3 Sum : 0x1731
Hroom : 0
Timeout : 3
SW stats : 345 pkts, 25530 bytes
HW stats : 0 pkts, 0 bytes}
Egress : 0
Out Pid : 3 (eth0)
Out VPid : 7 (internet)
Mtu : 1500
L2 push : 14: 00015C5814400896D75BA18A0800
Macaddr : 00:01:5c:xx:xx:40 ref 5 Pid 3 eth0 # CMTS LAN
Orig Prio : 10:2
Prio : 10:2
TC index : 33280
cpmac prio : 0
tack pkts : 1516 (accl acks 3901)
SW stats : 345 pkts, 25530 bytes
HW stats : 0 pkts, 0 bytes
Pkts : TX 345 (acks 0)


Wäre die FRITZ!Box das Standard Gateway, dann gäbe es nur 2 Sessions.

Session : 7780 (132)
State : active
TX active : 0
In Pid : 3 (eth0)
In VPid : 7 (internet)
In HW : no
CT dir : original
Realtime : no
PktType : IPv4+ICMP
FragOk : 1
Syn : 0
Fin : 0
Eth Hdr DS : 08:96:d7:xx:xx:8a 00:01:5c:xx:xx:40 proto 0800 # FB MAC_DSL LAN / CMTS LAN
IPv4 Hdr : 138.68.124.96 95.89.xx.231 proto 1 tos 00
ICMPv4 : echo reply id=1
Hdrlen : 46
IP version : 4
L2 pull : 14
SKB proto : 0800
*IPv4 Dst : 192.168.188.102
*IPv4 TTL : decrease
*L3 Sum : 0xe6ce
Hroom : 4
Timeout : 3
SW stats : 455 pkts, 33670 bytes
HW stats : 0 pkts, 0 bytes}
Egress : 0
Out Pid : 7 (wasp)
Out VPid : 5 (wasp)
Mtu : 1500

Session : 8411 (178)
State : active
TX active : 0
In Pid : 7 (wasp)
In VPid : 5 (wasp)
In HW : no
CT dir : reply
Associated : 132
Realtime : no
PktType : IPv4+ICMP
FragOk : 1
Syn : 0
Fin : 0
Eth Hdr DS : 08:96:d7:xx:xx:86 3c:a9:f4:xx:xx:ac proto 8100 # FB MAC_A LAN / Intel WLAN
Vlan ID : 5
IPv4 Hdr : 192.168.188.102 138.68.124.96 proto 1 tos 00
ICMPv4 : echo request id=1
Hdrlen : 42
IP version : 4
L2 pull : 18
SKB proto : 0800
*IPv4 Src : 95.89.xx.231
*IPv4 TTL : decrease
*L3 Sum : 0x1731
Hroom : 0
Timeout : 3
SW stats : 21 pkts, 1638 bytes
HW stats : 0 pkts, 0 bytes}
Egress : 0
Out Pid : 3 (eth0)
Out VPid : 7 (internet)
Mtu : 1500
 
Zuletzt bearbeitet:

Statistik des Forums

Themen
244,695
Beiträge
2,216,692
Mitglieder
371,315
Neuestes Mitglied
jack-mack
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.