[Frage] Freetz auf der 7320 mit tcpdump

mucki41 · 23 Mrz 2015

Hallo

Ich habe mir mal mit tcpdump meinen Netzwerkverkehr angeschaut.
Was sind das für Pakete?

10:30:05.732718 IP10 truncated-ip - 665 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip

Diese Pakete kommen da massenhaft

sf3978 · 23 Mrz 2015

mucki41 schrieb:
Ich habe mir mal mit tcpdump meinen Netzwerkverkehr angeschaut.
Was sind das für Pakete?

10:30:05.732718 IP10 truncated-ip - 665 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip

Evtl. ist das ein Hinweis, dass die MTU der FB nicht zur MTU der Mobilfunkhardware bzw. nicht zur MTU des Mobilfunkanschlusses passt ...?

mucki41 · 23 Mrz 2015

Was ist ein MTU????? und ich habe keine Mobilfunkhardware und auch kein Mobilfunkanschluss.
Bin ganz normal bei 1und1

koyaanisqatsi · 23 Mrz 2015

Moins

MTU <--<< Klickmal
...da gibt es auch eine passende Auflistung, wenn du sie einstellen möchtest.

IPv6 = fritz.box/internet/ipv6.lua

sf3978 · 23 Mrz 2015

mucki41 schrieb:
... ich habe keine Mobilfunkhardware und auch kein Mobilfunkanschluss.

Evtl. etwas mit Windows mobile/phone in deinem (W)LAN? Wer außer dir, benutzt noch diese FB?

mucki41 · 23 Mrz 2015

Nein geht auch nicht wlan wurde aus der Box entfernt....
was mich wundert wenn ich mir das ziel mal anschaue also 163-67-5-188.mobileinternet.proximus.be geht das nach Belgien mit sicherheit habe ich das nicht eingestellt

sf3978 · 23 Mrz 2015

mucki41 schrieb:
Nein geht auch nicht wlan wurde aus der Box entfernt....

Kannst Du in der Konsole der FB, evtl. mit "ps" etwas erkennen? Versuch mal mit dem Filter:

Code:

tcpdump -vvveni any host 137.135.20.86 or host 188.5.67.163

mucki41 · 23 Mrz 2015

da schaut es so aus

root@fritz:/var/mod/root# tcpdump -vvveni any host 137.135.20.86 or host 188.5.67.163
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
04:12:54.226206 Out ethertype IPv4 (0x0800), length 94: IP10 truncated-ip - 690 bytes missing! (tos 0xaa,ECT(0), id 32962, offset 56, flags [none], proto Options (0), length 768, options (unknown 53 [bad length 48]), bad cksum 5087 (->6df0)!)
137.135.20.86 > 188.5.67.163: ip
04:12:54.330441 Out ethertype IPv4 (0x0800), length 885: IP10 (tos 0xaa,ECT(0), id 32962, offset 56, flags [none], proto Options (0), length 768, options (unknown 53 [bad length 48]), bad cksum 5087 (->67bb)!)
137.135.20.86 > 188.5.67.163: ip
04:12:54.375001 Out ethertype IPv4 (0x0800), length 168: IP10 truncated-ip - 616 bytes missing! (tos 0xaa,ECT(0), id 32962, offset 56, flags [none], proto Options (0), length 768, options (unknown 53 [bad length 48]), bad cksum 5087 (->6d54)!)
137.135.20.86 > 188.5.67.163: ip
04:12:55.554348 Out ethertype IPv4 (0x0800), length 898: IP10 (tos 0xaa,ECT(0), id 32962, offset 56, flags [none], proto Options (0), length 768, options (unknown 53 [bad length 48]), bad cksum 5087 (->f865)!)
137.135.20.86 > 188.5.67.163: ip
04:12:55.598317 Out ethertype IPv4 (0x0800), length 781: IP10 truncated-ip - 3 bytes missing! (tos 0xaa,ECT(0), id 32962, offset 56, flags [none], proto Options (0), length 768, options (unknown 53 [bad length 48]), bad cksum 5087 (->f94e)!)
137.135.20.86 > 188.5.67.163: ip

und ps

root@fritz:/var/mod/root# ps
PID USER VSZ STAT COMMAND
1 root 1204 S init
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
4 root 0 SW [events/0]
5 root 0 SW [khelper]
8 root 0 SW [async/mgr]
22 root 0 SW [sync_supers]
23 root 0 SW [bdi-default]
25 root 0 SW [kblockd/0]
43 root 0 SW [kswapd0]
44 root 0 SW [aio/0]
53 root 0 SW [pm_info]
60 root 0 SWN [avmdebug]
86 root 0 SW [mtdblockd]
104 root 0 SW [l2tp]
108 root 0 SW [tffsd_mtd_0]
109 root 0 SW [avmnet_workqueu]
112 root 0 SW [avmnet_timer]
166 root 0 SW [cleanup_timer_f]
283 root 0 SWN [jffs2_gcd_mtd5]
302 root 0 SW< [loop0]
310 root 0 SW [capi_pipew/0]
311 root 0 SW [capi_schedw/0]
312 root 0 SW [pcmlink_ctrl]
313 root 0 SW [capitransp]
317 root 0 SW< [avm_dect_thread]
318 root 0 SW [ksock tcp worke]
319 root 0 SW [ksock tcp serve]
557 root 1040 S < /sbin/udevd --daemon
584 root 0 SW [khubd]
768 root 1048 S < /sbin/udevd --daemon
769 root 1044 S < /sbin/udevd --daemon
854 root 2168 S /bin/configd
927 root 0 SW [scsi_eh_0]
928 root 0 SW [usb-storage]
938 root 0 SW [RTT_Client]
945 root 2840 S dsl_control -i10_00_10_40_00_04_01_00 -f/lib/modules/dsp_ar9/ar9-B-dsl.bin -n/etc/dsl/notify/dsl_notify.sh
953 root 2176 S dsl_monitor -d
954 root 2176 S dsl_monitor -d
955 root 2176 S dsl_monitor -d
959 root 2176 S dsl_monitor -d
963 root 2840 S dsl_control -i10_00_10_40_00_04_01_00 -f/lib/modules/dsp_ar9/ar9-B-dsl.bin -n/etc/dsl/notify/dsl_notify.sh
964 root 2840 S dsl_control -i10_00_10_40_00_04_01_00 -f/lib/modules/dsp_ar9/ar9-B-dsl.bin -n/etc/dsl/notify/dsl_notify.sh
965 root 2840 S dsl_control -i10_00_10_40_00_04_01_00 -f/lib/modules/dsp_ar9/ar9-B-dsl.bin -n/etc/dsl/notify/dsl_notify.sh
966 root 2840 S dsl_control -i10_00_10_40_00_04_01_00 -f/lib/modules/dsp_ar9/ar9-B-dsl.bin -n/etc/dsl/notify/dsl_notify.sh
967 root 2840 S dsl_control -i10_00_10_40_00_04_01_00 -f/lib/modules/dsp_ar9/ar9-B-dsl.bin -n/etc/dsl/notify/dsl_notify.sh
968 root 2840 S dsl_control -i10_00_10_40_00_04_01_00 -f/lib/modules/dsp_ar9/ar9-B-dsl.bin -n/etc/dsl/notify/dsl_notify.sh
1045 root 0 SWN [dectuart_route]
1049 root 2384 S avmipcd
1051 root 2900 S l2tpv3d
1097 root 0 SW [autbtex]
1098 root 0 SW [ceocex_ne]
1099 root 0 SW [pmex_ne]
1100 root 0 DW [pmex_fe]
1250 root 4060 S pbd
1252 root 4060 S pbd
1253 root 4060 S {reg_upnp} pbd
1254 root 4060 S pbd
1255 root 4060 S pbd
1266 root 5484 S telefon a127.0.0.1
1269 root 5484 S telefon a127.0.0.1
1270 root 5484 S telefon a127.0.0.1
1273 root 4772 S dect_manager
1311 root 4172 S /usr/bin/aha
1313 root 4172 S /usr/bin/aha
1314 root 4172 S {upper_conn} /usr/bin/aha
1321 root 4172 S /usr/bin/aha
1322 root 4172 S /usr/bin/aha
1323 root 4172 S /usr/bin/aha
1324 root 4172 S /usr/bin/aha
1325 root 4172 S /usr/bin/aha
1326 root 824 S /bin/run_clock -c /dev/tffs -d
1327 root 4172 S {sRX} /usr/bin/aha
1487 root 1196 S {busybox} httpd-webcfg -P /var/run/webcfg.pid -p 81 -c /mod/etc/webcfg.conf -h /usr/mww/ -r Freetz
1583 root 1196 S {busybox} inetd
1670 root 1200 S {busybox} httpd -P /var/run/nhipd.pid -p 192.168.178.1:83 -h /usr/ipt -c /mod/etc/webcfg.conf -r Freetz
1961 root 1172 S dropbear -p 22 -0 -s
2189 root 1204 S init
2204 root 1020 S oamd
2358 root 11144 S /usr/bin/avm/ctlmgr
2385 root 11144 S /usr/bin/avm/ctlmgr
2386 root 11144 S /usr/bin/avm/ctlmgr
2387 root 11144 S /usr/bin/avm/ctlmgr
2483 root 3804 S multid -d
2543 root 5736 S < voipd
2716 root 4072 S dsld -g -i -n
2785 root 1236 S /sbin/chronyd -n -f /var/tmp/chrony.conf
3185 root 1216 S dropbear -p 22 -0 -s
3186 root 1220 S -sh
3247 root 1200 R {busybox} ps

PeterPawn · 23 Mrz 2015

Vielleicht machst Du mal einen Packetdump mit den AVM-Utilities ... wenn da kein Fehler beim "tcpdump" vorliegt und wirklich Protokoll 10 irgendwie benutzt wird (ist eigentlich eine VMS-Spezialität und knapp 20 Jahre aus der Mode), dann wäre das in der Tat sehr sehr merkwürdig. Aber schon ein falsches Capture seitens "tcpdump" würde das Problem erklären (falscher Offset z.B. durch VLAN-Tags) - woher kommt denn das verwendete "tcpdump" und die - meines Wissens auch benötigte - libpcap.so bei Deiner Box?

mucki41 · 23 Mrz 2015

Da geht es gleich weiter mit dem Problem.... diese Pakete von den ich rede sind nicht überall zu sehen mit avm utilities sind sie garnicht aufgetaucht und mit tcpdump auch nur auf Interface any und adsl damit kann ich ausschliessen das sie zum Beispiel aus meinem Lan kommen da sie auf eth0 und eth1 nicht auftauchen.
Und die libpcap.so ist verhanden.
Mir ist auch vorhin beim probieren aufgefallen jedes normale ip Paket hat so ein ip10 zu folge ich würde als sagen was immer ich mir auch anschauen im Internet wird
1 zu 1 an die 188.5.67.163 gesandt

PeterPawn · 23 Mrz 2015

@mucki41:
Das ist - entschuldige die deutliche Bemerkung - Unsinn.

Auf der FRITZ!Box gibt es Interfaces mit den unterschiedlichsten Kapselungen (Ethernet nativ, mit VLAN-Tags, PPPoE) und da macht es wenig Sinn, alle Pakete über einen Kamm zu scheren. Je nach Interface, auf dem ein Paket mitgeschnitten wird, werden andere "dissectors" benötigt, um den Paketinhalt zu interpretieren. Mit ein wenig Pech sind das, was Du da siehst, sogar die Telnet-Zugriffe auf der Console.

Schneide halt mal in eine Datei mit und schaue Dir das hinterher mit "WireShark" an ... da ist die Interpretation von Paketinhalten "more sophisticated" und man kann - durch Vorgabe/Wahl des (un)passenden "dissectors" - auch mal versuchen, das krude Ergebnis des "tcpdump" nachzuvollziehen.

mucki41 · 23 Mrz 2015

so mal in eine datei mitgeschnitten und angeschaut

tcpdump -i any not port 22 > test1.txt

07:21:44.246168 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.246325 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 1441:2881, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], len
07:21:44.247033 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 2881:4321, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], len
07:21:44.249051 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.249202 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.249713 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 4321:5761, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], len
07:21:44.250748 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 5761:7201, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], len
07:21:44.252440 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.252586 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.253414 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 7201:8641, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], len
07:21:44.254164 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 8641:10081, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], le
07:21:44.256151 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.256301 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.256843 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 10081:11521, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.257600 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 11521:12961, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.259564 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.259714 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.260264 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 12961:14401, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.261028 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 14401:15841, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.262999 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.263150 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.263436 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [P.], seq 15841:16410, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294],
07:21:44.264252 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.264424 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 16410:17850, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.266012 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.266428 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 17850:19290, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.267633 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 19290:20730, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.269150 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.269296 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.270162 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 20730:22170, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.271052 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 22170:23610, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.272891 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.273280 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 23610:25050, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.274038 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 25050:26490, ack 636, win 793, options [nop,nop,TS val 2257518915 ecr 6387294], l
07:21:44.276407 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip
07:21:44.276728 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 26490:27930, ack 636, win 793, options [nop,nop,TS val 2257518946 ecr 6389398], l
07:21:44.277705 IP 62.156.238.17.https > 192.168.178.4.48085: Flags [.], seq 27930:29370, ack 636, win 793, options [nop,nop,TS val 2257518947 ecr 6389399], l
07:21:44.279608 IP10 truncated-ip - 684 bytes missing! 137.135.20.86 > 163-67-5-188.mobileinternet.proximus.be: ip

PeterPawn · 23 Mrz 2015

Das ist zwar noch nicht das, was ich meinte (Option -w), aber zumindest wird die "Mißinterpretation" der Pakete deutlicher.

Wenn da immer von einem deutlich größeren Paket ausgegangen wird (es fehlen immer 684 Byte), dann wird wohl ein falsches Feld im Paket als Längenangabe interpretiert.

Wenn Du nun noch die Pakete mit der w-Option erst einmal in voller Länge in eine Datei schreibst und diese Datei dann hinterher tatsächlich mit "WireShark" untersuchst, kommst Du sicherlich auch dahinter, von welchem Interface die Pakete stammen (das entscheidet nun mal über den Aufbau der Pakete) und wie sie korrekt zu interpretieren sind.

EDIT:
Vielleicht schaust Du Dir ja mal eines dieser Pakete in hexadezimaler Darstellung an ... schon dann könnte die korrekte Interpretation des Pakets gelingen, wenn man erst einmal die verwendete Kapselung oder vorhandene VLAN-Tags (was ist es denn für ein Anschluß, das hättest Du ja spätestens bei der Erwähnung von VLAN-Tags mal ausführen können) identifiziert hat.

PeterPawn · 23 Mrz 2015

Ja ... und nun?

Hast Du denn auch mal in die Daten hineingesehen?

Es ist am Ende genau so, wie ich es vermutet habe ... Du brauchst Dir bloß mal die Pakete 6 bis 8 im Dump anzusehen und diese zu vergleichen.

Paket 6 ist eine DNS-Abfrage nach "www.google.de" vom Rechner mit der internen IP 192.168.178.5 (der MAC-Adresse nach ein DELL-Gerät) an die FRITZ!Box (192.168.178.1).

Daraus macht die Box selbst im Paket 7 eine Abfrage des DNS-Servers 217.237.149.205 von ihrer eigenen internen IP-Adresse.

Dieses wird dann wieder in Paket 8 zu einem Paket mit Kapselung, was von der hexadezimalen Adresse "0x57a8f587" (87.168.245.135 - das dürfte Deine externe IP-Adresse sein) an die "0xd9ed95cd" geht.

Deine Box hat die MAC-Adresse BC:05:43:A3:35:30, der DSLAM die MAC-Adresse 50:87:89:87:14:56.

Das eigentliche Ethernet-Paket (PPPoE, wie man an den beiden MAC-Adressen, gefolgt von 0x8864 für PPP-SessionData, sehen kann) beginnt im "cooked packet" (das kommt davon, wenn man Interfaces mit unterschiedlichen Charakteristika mixt) ab Offset 0x1A, der IP-Header bei Offset 0x30 (mit 0x4500).

Da ist beim besten Willen für mich nichts Auffälliges zu sehen, das ist ein simpler Layer8-Fehler, der sich aus der Anwendung von "tcpdump" auf "any"-Interface(s) ergibt, wenn diese unterschiedliche Kapselungen verwenden und somit nur "cooked packets" beim "tcpdump" ankommen.

Ich nehme aber auch begründete Gegenargumentationen gerne zur Kenntnis ...

mucki41 · 24 Mrz 2015

Layer 8 Fehler

Deine Box hat die MAC-Adresse BC:05:43:A3:35:30, der DSLAM die MAC-Adresse 50:87:89:87:14:56

ist mal auch falsch trotzdem bringt es mich ein ganzes stück weiter
in meinem Netzwerk gibt es keine 50:87:89:87:14:56 nicht mehr scheinbar liegt diese Mac in der Mülltonne
Meine Frage wo sind solche alten Mac Adressen in der Fritzbox gespeichert

PeterPawn · 24 Mrz 2015

mucki41 schrieb:
ist mal auch falsch

So steht es in den Netzwerk-Paketen.

in meinem Netzwerk gibt es keine 50:87:89:87:14:56 nicht mehr scheinbar liegt diese Mac in der Mülltonne

Warum sollte der DSLAM auch in Deinem Netzwerk liegen? Was das für ein Gerät ist und wo es sich normalerweise befindet, findest Du bestimmt heraus ...

Meine Frage wo sind solche alten Mac Adressen in der Fritzbox gespeichert

:gruebel:
Die Frage ist zu unspezifisch, als daß man sie korrekt beantworten könnte.

Was sind denn "alte Mac Adressen" in Deinen Augen? Eine MAC-Adresse hat auf Layer2 im Ethernet bzw. auch an einem DSL-Anschluß (das ist nun mal i.d.R. auch Ethernet-basiert) eine bestimmte Aufgabe und ich verstehe nicht, wie aus einer MAC-Adresse eine "alte Adresse" werden soll.

mucki41 · 24 Mrz 2015

es gab hier mal ein switch der aber im müll ist ich kann das also nicht mehr nachschauen ...... fakt ist die 50:87:89:87:14:56 gibt es nicht mehr die Fritzbox hat die sich aber gemerkt dieser eintrag müste entfernt werden aber wo?????

PeterPawn · 24 Mrz 2015

mucki41 schrieb:
fakt ist die 50:87:89:87:14:56 gibt es nicht mehr die Fritzbox hat die sich aber gemerkt dieser eintrag müste entfernt werden

Wenn ich es nicht komplett verlernt habe, den Inhalt von Netzwerkpaketen zu interpretieren, dann ist die erwähnte MAC-Adresse die des DSLAM (vielleicht versuchst Du ja doch einmal zu ergründen, was ein DSLAM ist?) und hat mit einem Switch absolut nichts zu tun ... abgesehen davon ist ein Switch (solange er nicht "manageable" ist) kein Gerät, was eine eigene MAC-Adresse haben sollte. Ein Ethernet-Paket enthält immer die Quelladresse des Absenders und als Zieladresse die des "richtigen Ziels" ... es findet keine "Kommunikation" zwischen Endgerät und Switch statt (von Flußkontrollen/Media-Sensing mal abgesehen).

JohnDoe42 · 24 Mrz 2015

mucki41 schrieb:
in meinem Netzwerk gibt es keine 50:87:89:87:14:56 nicht mehr

Diese MAC-Adresse ist an CISCO vergeben. Besaßt bzw. besitzt Du ein Cisco-Gerät ?

qwertz.asdfgh · 24 Mrz 2015

PeterPawn schrieb:
... dann ist die erwähnte MAC-Adresse die des DSLAM

Sicher das es der DSLAM ist? Sollte das nicht die MAC-Adresse des BRAS sein (von diesem wird ja erst die PPPoE-Verbindung terminiert)? Würde dann auch zu Cisco passen.
Leider ist der Beitrag mit dem Dump gelöscht worden sodass man sich das nicht mehr ansehen kann aber ich tippe dennoch auf den BRAS denn der DSLAM ist dbzgl. (MAC-Adresse) m.W.n. unsichtbar für die FritzBox...

[Frage] Freetz auf der 7320 mit tcpdump

Neuer User

IPPF-Promi

Neuer User

IPPF-Urgestein

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Aktives Mitglied

IPPF-Promi

Statistik des Forums