Beiträge von demolitionfabi

Zitat von HubeBube

Eine Buchse zum Herausführen des Glasfaserkabel aus dem Gehäuse ist bei dem ONT nicht vorgesehen, das würde der Funktionalität des FiberTwist-Systems wiedersprechen. Im Inneren gibt es eine SC/APC Buchse und daran musst Du dein Gf-Kabel anschließen. Leider ist damit die Fiber Management Unit (FMU) offen, da der ONT nun nicht mehr aufgedreht werden kann.

Genexist hat jedoch folgende "Abdeckungen"/Oberteile im Programm:

• F2110 [SC/APC]
• F2115 [LC/APC]

Da wird lediglich die interne SC/APC Buchse über ein kurzes Stück Glasfaserkabel nach außen geführt. Dies ist letztlich der Gf-TA/APL/Glasfaser-Dose, der passive Netzabschluss mit SC/APC oder LC/APC Anschluss.

Leider ist mir weder eine Bezugsquelle für Privatkunden noch eine Vorlage für einen 3D-Drucker bekannt.

Aber spricht denn etwas dagegen einfach ein Kabel an die Buchse anzustecken, so wie ich das in dem Foto im Anhang gemacht habe?

Zitat von Phino

Ja, sehe ich auch so als Praktiker, dass der ONT bis 1 Gbps okay ist.

Über Cat6a Kabel können doch auch 10 Gbps über RJ45 übertragen werden? Aber trotzdem ist es doch nicht toll, wenn ich ein aktives Gerät vor meinem Router habe, das mir die Glasfaser in Kupfer umwandelt, wenn ich die Glasfaser direkt an meinem Router anstecken könnte. Aber klar, okay ist es... vor allem, wenn man den SFP+ Port dann für etwas anders verwenden kann.

Zitat von HubeBube

Der SFP+ Slot ist nur für WAN? Ich bin bis jetzt davon ausgegangen, das dieser Port auch für Multigigabit Ethernet im LAN (bei enntsprechendem SFP+ Modul) genutzt werden kann.

Mein letzter Wissensstand war auch, dass der Port 10 nur als WAN Port genutzt werden kann, aber ich habe gerade gesehen, dass das wohl in einem Update geändert wurde (siehe Anhang).

(Auch nachzulesen hier: https://ubiquiti-networks-forum.de/board/thread/4…ls-lan-nutzbar/ )

Unter diesen Umständen gebe ich euch Recht, dass ich den wertvollen SFP+ Port auch lieber anderweitig benutze und bei dem Provider ONT bleibe.

Ich werde aber bei Gelegenheit trotzdem nochmal versuchen, die Seriennummer des Zyxel auf die meines Provider ONTs zu ändern und dann rein interessehalber schauen ob das überhaupt funktioniert und ob ich mit tcpdump dann noch mehr rausfinden kann.

Dafür warte ich aber gerade noch auf ein Glasfaserkabel, das ich an die Dose des ONT stecken kann.

Mein ONT ist ein FiberTwist-G2110C und deswegen ist an meiner Glasfaserleitung jetzt kein Stecker mehr, sondern eine Buchse.

Wie gesagt, die Konfiguration, Regeln und Routen sind völlig identisch: Ich habe das RJ45 Modul in den selben SFP Slot gesteckt, in dem vorher der Zyxel war, ohne irgendetwas an der Konfiguration zu verändern.

Die IP Adresse, die ich über den ONT an dem RJ45 Modul bekomme ist auch die gleiche, wie die die ich vorher mit dem Zyxel direkt über die Glasfaser Leitung bekommen habe...

Ich habe die WAN Konfiguration auf Auto gestellt, ich denke da ist IPv6 standardmäßig deaktiviert.

Wenn ich es manuell auf DHCPv6 stelle, müsste ich eine Prefix Delegation Size angeben.

Vlan Tag ist deaktiviert, wenn ich das aktiviere, dann bekomme ich wie gesagt ja nicht mal mehr eine IP Addresse vom DHCP...

Also ich habe wirklich keine Idee was ich noch prüfen könnte

Ich habe mir jetzt einen ONT von meinem ISP setzen lassen und habe zum testen in den gleichen WAN SFP Port von meiner UDM ein RJ45-SFP Modul gesetetzt und dort den ONT angesteckt:

Es hat auf Anhieb alles problemslos funktinoiert.

Also an der Konfiguration der UDM kann es nicht liegen, dass es nicht funktioniert die Glasfaser direkt an die UDM zu stecken. 🤔

HubeBube Alles klar, verstehe, vielen Dank, das ist dann aber sicher nichts was ich brauche, damit mein Ping oder traceroute funktioniert...

Zitat von frank_m

In deine Ausgabe sieht man, dass für die Output Chain einfach gar nichts vorhanden ist, und für WAN sind sowohl eingehend als auch ausgehend nur DROP Regeln zu sehen.

Für die Output Chain steht aber die Policy auf ACCEPT, das heißt doch wenn sonst keine Regel vorhanden ist, dann sollte doch alles akzeptiert werden, oder?

Und für WAN steht ja die Policy auch auf ACCEPT und die DROP Regeln sagen

• für IN: RETURN (also accept) falls ctstate RELATED,ESTABLISHED und nur ansonsten DROP
• für OUT: RETURN all (also alles akzeptieren)

Also für mich klingt das plausibel (falls ich es richtig verstanden und zusammengefasst habe), aber ich kenne mich damit auch wirklich nicht besonders gut aus...

Und mangle und nat sollten doch meines Erachtens auch keine Pakete wegfiltern... oder?

Mit "tcpdump -i any" schließe ich ja auch das Interface mit ein mit dem ich meinen PC verbunden habe und es zeigt so unendlich viel Traffic an, dass ich überhaupts nichts mehr finde...

Ich befürchte, dass ich einsehen sollte, dass mein Wissen nicht ausreicht und ich mir einen ONT von meinem ISP setzen lasse

(wobei es am Ende ja das gleiche ist, nur dass ich an dem RJ45 Port über DHCP meine Daten vom ONT bekomme, statt an dem SFP+ Port direkt über die Glasfaser)

Vielen Dank nochmal an alle für die Mühe und wenn noch jemand eine Idee hat bin ich natürlich auch dankbar.

Ich werde dann wenn der ONT installiert wurde auch mal versuchen, die Seriennummer des ONT in mein SFP Modul zu klonen und die MAC Adresse der UDM auf die des ONT zu stellen und dann nochmal versuchen, ob es nach wie vor das gleiche Problem gibt und hier berichten...

Ich habe es auch schon ganz ohne -i eth9 und auch schon mal mit -s 46.128.193.220 probiert, aber das Problem ist ja, dass meine pings und traceroutes im tcpdump gar nicht erscheinen!

Woran könnte das denn liegen?

Also hier sollte es ja unabhängig von einem eingestellten NAT funktionieren, oder:

Zitat von demolitionfabi

traceroute -s 46.128.193.220 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8) from 46.128.193.220, 30 hops max, 46 byte packets

1 46.128.193.220 (46.128.193.220) 3071.339 ms !H 3071.421 ms !H 3075.477 ms !H

Firewall Regeln habe ich keine eingestellt, ich habe die UDM wie gesagt auf Werkseinstellungen zurückgesetzt und gehe davon aus, dass die Standardeinstellungen passen sollten, oder?

Ich hatte sie auch schon mal gepostet, kann man damit was anfangen?

Zitat von demolitionfabi

iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination

UBIOS_INPUT_JUMP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)

target prot opt source destination

UBIOS_FORWARD_JUMP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

UBIOS_OUTPUT_JUMP all -- anywhere anywhere

Chain UBIOS_FORWARD_IN_USER (1 references)

target prot opt source destination

UBIOS_WAN_IN_USER all -- anywhere anywhere /* 00000001095216663481 */

UBIOS_WAN_IN_USER all -- anywhere anywhere /* 00000001095216663482 */

UBIOS_LAN_IN_USER all -- anywhere anywhere /* 00000001095216663483 */

Chain UBIOS_FORWARD_JUMP (1 references)

target prot opt source destination

UBIOS_FORWARD_USER_HOOK all -- anywhere anywhere

Chain UBIOS_FORWARD_OUT_USER (1 references)

target prot opt source destination

UBIOS_WAN_OUT_USER all -- anywhere anywhere /* 00000001095216663481 */

UBIOS_WAN_OUT_USER all -- anywhere anywhere /* 00000001095216663482 */

UBIOS_LAN_OUT_USER all -- anywhere anywhere /* 00000001095216663483 */

Chain UBIOS_FORWARD_USER_HOOK (1 references)

target prot opt source destination

UBIOS_FORWARD_IN_USER all -- anywhere anywhere /* 00000001095216663481 */

UBIOS_FORWARD_OUT_USER all -- anywhere anywhere /* 00000001095216663482 */

Chain UBIOS_INPUT_JUMP (1 references)

target prot opt source destination

UBIOS_INPUT_USER_HOOK all -- anywhere anywhere

Chain UBIOS_INPUT_USER_HOOK (1 references)

target prot opt source destination

UBIOS_WAN_LOCAL_USER all -- anywhere anywhere /* 00000001095216663481 */

UBIOS_WAN_LOCAL_USER all -- anywhere anywhere /* 00000001095216663482 */

UBIOS_LAN_LOCAL_USER all -- anywhere anywhere /* 00000001095216663483 */

Chain UBIOS_IN_GEOIP (0 references)

target prot opt source destination

Chain UBIOS_LAN_IN_USER (1 references)

target prot opt source destination

RETURN all -- 192.168.1.0/24 anywhere /* 00000001095216666481 */

RETURN all -- anywhere anywhere /* 00000001097364144127 */

Chain UBIOS_LAN_LOCAL_USER (1 references)

target prot opt source destination

RETURN all -- anywhere anywhere /* 00000001097364144127 */

Chain UBIOS_LAN_OUT_USER (1 references)

target prot opt source destination

RETURN all -- anywhere 192.168.1.0/24 /* 00000001095216666481 */

RETURN all -- anywhere anywhere /* 00000001097364144127 */

Chain UBIOS_OUTPUT_JUMP (1 references)

target prot opt source destination

Chain UBIOS_OUTPUT_USER_HOOK (0 references)

target prot opt source destination

Chain UBIOS_OUT_GEOIP (0 references)

target prot opt source destination

Chain UBIOS_WAN_IN_USER (2 references)

target prot opt source destination

RETURN all -- anywhere anywhere ctstate RELATED,ESTABLISHED /* 00000001095216663481 */

DROP all -- anywhere anywhere ctstate INVALID /* 00000001095216663482 */

DROP all -- anywhere anywhere /* 00000001097364144127 */

Chain UBIOS_WAN_LOCAL_USER (2 references)

target prot opt source destination

RETURN all -- anywhere anywhere ctstate RELATED,ESTABLISHED /* 00000001095216663481 */

DROP all -- anywhere anywhere ctstate INVALID /* 00000001095216663482 */

DROP all -- anywhere anywhere /* 00000001097364144127 */

Chain UBIOS_WAN_OUT_USER (2 references)

target prot opt source destination

RETURN all -- anywhere anywhere /* 00000001097364144127 */

(Ich habe nach dem Factory Reset nichts geändert an der UDM, also die Regeln sollten alle Standard sein)

Alles anzeigen

Ich habe auch mal versucht, die UDM bei meinem Eltern über den RJ45 WAN Port an einen Port der Fritz Box zu hängen, dann funktioniert alles einwandfrei (NAT etc.)...

Hmm, Addresse und Subnetzmaske sind ja schon übernommen, oder:

Zitat von demolitionfabi

ifconfig eth9

inet addr:46.128.193.220 Bcast:0.0.0.0 Mask:255.255.255.0

inet6 addr: fe80::d221:f9ff:fe79:24a6/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:268698 errors:0 dropped:0 overruns:0 frame:0

TX packets:3321 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:10000

RX bytes:11296771 (10.7 MiB) TX bytes:245140 (239.3 KiB)

Alles anzeigen

Und das Gateway habe ich ja auch schon versucht nochmal manuell zu setzen:

Zitat von demolitionfabi

Ich habe folgende Ausgabe bekommen:

Code: ip route

46.128.193.0/24 dev eth9 proto kernel scope link src 46.128.193.220
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

Das ist in der Tat komisch, dass es keinen default gibt, oder?

Ich habe folgendes probiert:

ip route add default via 46.128.193.1

Na und mein traceroute -i eth9 8.8.8.8 sollte ja auch ohne DNS funktionieren...

Also ich habe leider keine Idee, was ich noch versuchen könnte

Was sagt mir denn diese Vendor-Option Option 43? Die brauche ich nicht für irgendwas?

Danke nochmal!

Zitat von frank_m

Und warum du das loopback Interface hinzuziehst, wird auch nicht klar. Warum machst du das?

Sorry, das ist Quatsch, das war copy paste bei dem Versuch eine Lösung für die dropped packets zu finden 🙈

Ich habe ein DHCP Reply nach dem Neustart der UDM gecaptured:

IP (tos 0xc0, ttl 30, id 14564, offset 0, flags [none], proto UDP (17), length 406)
    46.128.193.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 378, xid 0x1326f357, Flags [none] (0x0000)
      Your-IP 46.128.193.220
      Gateway-IP 46.128.193.1
      Client-Ethernet-Address d0:21:f9:79:24:a6
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 172.28.216.14
        Lease-Time Option 51, length 4: 6948
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 46.128.193.1
        Domain-Name-Server Option 6, length 8: 195.234.128.139,217.68.162.53
        RN Option 58, length 4: 3348
        RB Option 59, length 4: 6048
        Hostname Option 12, length 12: "D021F97924A6"
        Vendor-Option Option 43, length 72: 1.70.104.116.116.112.115.58.47.47.112.114.111.118.97.99.115.46.109.105.112.45.112.108.97.116.102.111.114.109.46.110.101.116.58.55.53.52.55.47.108.105.118.101.47.67.80.69.77.97.110.97.103.101.114.47.67.80.69.115.47.103.101.110.101.114.105.99.84.82.54.57

Könnt ihr damit was anfangen?

Nochmals danke!

Ich habe folgende Ausgabe bekommen:

46.128.193.0/24 dev eth9 proto kernel scope link src 46.128.193.220
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

Das ist in der Tat komisch, dass es keinen default gibt, oder?

Ich habe folgendes probiert:

ip route add default via 46.128.193.1

default via 46.128.193.1 dev eth9
46.128.193.0/24 dev eth9 proto kernel scope link src 46.128.193.220
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

Aber ich bekomme nach wie vor das selbe Ergebnis:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 46 byte packets
 1  46.128.193.220 (46.128.193.220)  852.953 ms !H  3084.074 ms !H  3067.904 ms !H

Und wenn ich während des traceroute den tcpdump --interface=eth9 weiter laufen lasse, schlägt dort auch außer den ARP-Requests nach wie vor nichts auf.

Ich habe auch noch versucht ip route replace default via 46.128.193.220, das macht vermutlich keinen Sinn, hat auch genauso wenig funktioniert...

Wenn ich den tcpdump beende, dann steht da:

115 packets captured
8766 packets received by filter
8620 packets dropped by kernel

Habt ihr eine Idee warum da so viele packets dropped by kernel sind?

Edit: Folgendes ist Quatsch:

Ich habe auch noch folgendes probiert:

tcpdump -ni lo tcp -c 20 --interface=eth9

und:

tcpdump -ni lo udp -c 20 --interface=eth9

Aber mein traceroute taucht auch hier nicht auf!

Vielen Dank nochmal für eure Hilfe!

Die letzte Nachricht wurde zu lang, ich habe noch probiert:

Ich habe während dem tcpdump auch mal das Glasfaser Kabel abgesteckt, dann haben die Anfragen abgebrochen. Als ich es wieder eingesteckt habe, kamen wieder fast nur ARP Requests, aber bei weitem nicht mehr so viele wie oben, sondern nur noch alle paar Sekunden.

Kann jemand irgendwas hieraus schließen? Oder hat noch irgend einen Tipp für mich was ich noch versuchen könnte?

Vielen Dank nochmal!

Vielen Dank nochmal für die Antwort!

Zitat von frank_m

Es soll keine überzogene Kritik sein, aber es fällt mal wieder auf, dass sich Leute semiprofessionelles Equipment kaufen, die nicht mal Grundlagenwissen über Netzwerk-Konfiguration und Diagnose haben.

Völlig legitim, ich weiß wirklich nicht wo ich anfangen soll, aber darum frage ich ja und bin um jeden Tipp in die richtige Richtung froh, man wächst doch mit seinen Aufgaben

Ich hatte ja schon von der UDM versucht einen Ping zum Gateway zu machen und nachdem das nicht geklappt hat, bin ich nicht auf die Idee gekommen noch ein traceroute zu probieren.

Ich kann ja mal hier einfügen was ich gerade noch alles versucht habe:

(Die Outputs sind innerhalb der Spoiler)

(Ich habe nach dem Factory Reset nichts geändert an der UDM, also die Regeln sollten alle Standard sein)

Vielen Dank für den Tipp!

Ich hatte auch eine Konfigurationsproblem vermutet und deswegen die UDM auf Werkseinstellungen zurückgesetzt, aber das hat nichts geändert.

Ich sehe in der UDM übrigens auch, dass immer mal wieder paar Bytes Up und auch Down gehen über das Interface...

Das mit dem traceroute weiß ich nicht ob das so funktioniert, um mich per SSH mit dem Zyxel Interface verbinden zu können, muss ich dessen IP statisch auf 10.10.1.2 oder ähnlich setzen, wie z.B. hier beschrieben:

Aber dann macht das traceroute ja keinen Sinn, oder?

Wenn ich mich per SSH mit der Dream Machine verbinde, dann komme ich nicht mal bis zum Gateway...

Ich versuche das selbe mit einem DG Anschluss über Pyur, falls ich es noch zum laufen bekommen sollte, werde ich berichten, bisher bekomme ich nur eine IP, aber das Internet funktioniert nicht:

https://community.ui.com/questions/Unifi-Dream-Machine-Pro-with-fiber-internet-GPON-from-Deutsche-Glasfaser-Pyur-through-SFP-modul-ins/f39c845f-f945-4167-a7fd-46c6c26ff683