Omnia cannot connect to FTTH of Deutsche Telekom

Wow, thanks. I report on success as soon as I am free to mess with our internet again.

1 Like

For completeness, I note that Deutsche Telekom will provision any ONT with BBF.247-certification
https://www.broadband-forum.org/testing-and-certification-programs/bbf-247-gpon-onu-certification
https://www.broadband-forum.org/wp-content/uploads/2020/02/BBF.247-GPON-ONU-Products-long-image-2020-02-04.pdf

Since it is not known which TOS version you are utilising (thus always good to mentioned when seeking support) be aware of the difference in the naming convention of the WAN port and how that translates for the VLAN in option ifname:

TOSv      WAN port name     with VLAN ID 7
3.x       eth1              eth1.7
>=4.x     eth2              eth2.7

Unless that works and if you have access to the UI of the ISP’s router then you could perhaps check what is stipulated in there.

I have TurrisOS 4.0.5 ab9d1bf.

Still no internet. My WAN config in /etc/config/network reads:

config interface 'wan'
    option ipv6 'auto'
    option proto 'pppoe'
    option username '12345678901212345678900001@t-online.de'
    option password '123456'
    option ifname 'eth2.7'
    option keepalive '0'

Username and password not using example values ofc.

Network reloaded with the commands mentioned above.

Output of logread:

Feb  9 10:00:41 turris kernel: [  791.912678] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
Feb  9 10:00:42 turris kernel: [  791.931594] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
Feb  9 10:00:42 turris kernel: [  791.938916] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Feb  9 10:00:42 turris kernel: [  791.944819] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Feb  9 09:00:42 turris netifd: Interface 'wan' is enabled
Feb  9 09:00:42 turris netifd: Interface 'wan' is setting up now
Feb  9 10:00:42 turris kernel: [  791.952769] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Feb  9 09:00:42 turris insmod: module is already loaded - slhc
Feb  9 09:00:42 turris insmod: module is already loaded - ppp_generic
Feb  9 09:00:42 turris insmod: module is already loaded - pppox
Feb  9 09:00:42 turris insmod: module is already loaded - pppoe
Feb  9 09:00:42 turris pppd[16344]: Plugin rp-pppoe.so loaded.
Feb  9 09:00:42 turris pppd[16344]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Feb  9 09:00:42 turris pppd[16344]: pppd 2.4.7 started by root, uid 0
Feb  9 10:00:43 turris kernel: [  793.114894] mvneta f1034000.ethernet eth2: Link is Down
Feb  9 09:00:43 turris netifd: Network device 'eth2' link is down
Feb  9 09:00:43 turris netifd: VLAN 'eth2.7' link is down
Feb  9 09:00:43 turris netifd: Interface 'wan' has link connectivity loss
Feb  9 09:00:45 turris netifd: Network device 'eth2' link is up
Feb  9 09:00:45 turris netifd: VLAN 'eth2.7' link is up
Feb  9 09:00:45 turris netifd: Interface 'wan' has link connectivity
Feb  9 09:00:45 turris netifd: Interface 'wan' is setting up now
Feb  9 10:00:45 turris kernel: [  795.191776] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Feb  9 09:00:48 turris netifd: Interface 'wan' is now down
Feb  9 10:00:48 turris kernel: [  798.875544] mvneta f1034000.ethernet eth2: Link is Down
Feb  9 09:00:48 turris netifd: Interface 'wan' is disabled

Strangely, this WAN up/down log repeated many times until I stopped the logread.

How?

Maybe related: In Customer Center of Deutsche Telekom, I can toggle “Easy Login”:

image

This is, according to forum users, the automatic recognition of my connection by the ISP network, so that I don’t need credentials. Shouldn’t that mean that I don’t need credentials with any router I use?

image

That’s all I can do in the ISP router settings, that seems relevant.

This just applies to the login handling of DT’s web server (Customer Center) but is likely not relevant to the (PPPoE) credentials for subscriber authentication from the router.


Which is not helpful… wondering if they do some sort of MAC checking - comparing the ISP’s router MAC to a databse at their back end.

See if the drop down field (telekom automatic) offers some sort of custom settings and if so what they are.


Missing some information of why it is failing.

what is the output of ip l sh dev eth2?

For a more verbose output of PPP enable the debug flag in /etc/ppp/options.

AS long as that is going on, you will not be able to connect to the internet at all, as this will either not allow the PPPoE link to be established at all and it will, assuming a PPPoE link was established in the first place lead to frequent stalls and packet drops on the link.
I note that https://forum.turris.cz/t/turris-omnia-4-drops-wan-occasionally/12248?u=moeller0 might be related.

About the credentials, you are right I was referring to easy login, but had forgotten the name. But as it looks your issues arise even before the credentials are tested and even before the VLAN tag is required to be set, as it seems the link between the turris’ wan port and the ONT’s LAN port is somehow unstable.

I disagree, this is all about the PPPoE credentials. See https://www.telekom.de/hilfe/auftrag-erste-schritte/einrichtung-festnetz-internet-und-tv/was-ist-easy-login?samChecked=true unfortunately only in German, but here is what google translate returns for the relevant paragrpah:
"What is Easy Login and what is my advantage with it?

By converting our network to IP-based technology, in most cases it is no longer necessary to store your access data in the router. Dialing into the Internet is automatic. The technical term for this is “Easy Login”."

Yes, or rather any credntials will do, as the Telekom remote end will simply ignore them and use the lineID the system learns via an non-customer visible route (the DSLAM/MSAN port somehow labels the packets, either all or at the setup of the pppoe link).

Nope, Telekom does not do that, they follow the Endgeraetefreiheitsvorgabe pretty well. (If you bring your own ONT that needs to be provisioned by the Telekom system (but not via MAC address), but that is par for toe course for GPON).

What does ifconfig eth2.7 and `ifconfig eth1’ return?

Well, I am not familiar with the DT’s web server that handles login authentication but most likely it utilises the TCP/HTTP(S) protocols and not the PPP protocol. Latter is being leveraged between the CPE and the ATM only.

Anyway, a moot point on getting the subject sorted.

1 Like

Reading this [2] implies a slightly different format, which may specific though to a different parsing of the network manager on that other OS.

Falls die Anschlusskennung keine 12 Zeichen Länge hat, soll ein “#” die Trennung von den beiden Nummern anzeigen.

Not sure though how that jibes with


[2] https://www.dnetz.de/cms/pfsense-pppoe-an-ftth-modem-glasfaseranschluss.aspx

Easy Login was introduced relative recently as far as DT’s internet services go, so there is a lot of old information out there that might still be relevant if an old Anschlusskennung is in use that is shorter than 12 characters (IIRC all Anschlusskennungen are 12 characters since a looong time). But I fully agree that this is probably not the OP’s current issue

Did a bit of reading up on BGP - it seems that it can be checked in the Customer Center whether the subscriber line is connected to it. From what I gather it makes PPPoE redundant:

Mit BNG ist es nicht mehr nötig, dass sich der Kunde über eine Anschlusskennung und ein Passwort am Netz anmeldet. Über die Identifikation der Zugangsleitung („Line-ID“) erkennt das Netz den Teilnehmer vielmehr automatisch.

Voraussetzung ist, dass der Router dieses Verfahren unterstützt. Die Unterstützung für BNG haben die wichtigsten Routerhersteller wie AVM für die Fritzboxen, die Telekom selbst für ihre Speedport-Modelle sowie TP-Link, D-Link, Netgear und Zyxel über Software-Updates in der Regel schon vor einigen Monaten bereitgestellt.

I am not sure that TOS | OpenWrt has that support implement or if so how the setup would be.

And neither whether DT still supports PPPoE authentication via BGP - may be it is even selectable (to be manually activated) via the Customer Center?

1 Like

There is a bit about BNG here [3] but that does not make much sense the example just changes the VLAN ID from 2 to 7 but still cites PPPoE as protocol and related credentials.


[3] https://openwrt.org/docs/guide-user/network/wan/isp-configurations

1 Like

There is really no support required, only a lot of commercial router GUIs will not accept empty username and password, but IIRC if Easy Login is selected in the Kundencenter any username and password should do. BUT for the OP this is immaterial since he can always deactivate Easy Login and use his existing credentials. And, as I believe I stated somewhere above, even with Easy Login activated one still needs to use PPPoE on the link. I happen to know this, because I was a customer of Deutsche Telekom in the past and made it work with a Bt HomeHub5A as bridged-modem (running OpenWrt) and a main router running OpenWrt as well.

Yes, they do (even worse they still require a PPPoE tunnel, there is a reason why they called this Easy Login, and not DHCP :wink: ), just deactivate Easy Login. I keep harping on this, as I a) am a native German speaker and hence understand the Telekom documentation, b) used to be a Telekom customer @VDSL2 and during the switch from BRAS to BNG so have first hand experience, and c) did this with a router running OpenWrt; I would like to humbly say, I happen to know a bit about this topic.

Makes a ton of sense, if you know the background. Before the introduction of BNGs at ~900 locations in Germany Telekom concentrated user-management via PPPoE to ~73 locations, so they always used PPPoE and they always mandated to use of VLAN7, but before the BNG introduction one of te earlier upstream HOPs added that VLAN tag for the end-user if the packets where not tagged already, but with BNG Telekom got rid of most of their earlier aggregation network (used to converge all their lines onto the 73 BRAS locations) and decided to do away with the automatic addition of VLAN7 (probably since the device doing this in the past does not exist anymore in the new network design, where there is not much between AMs/MSANs and the BNG nodes).

In the example VLAN2 was only used towards the internal switch the “WAN” port, port 1 was untagged, so exactly what I describe above, a switch from untagged to tagged as VLAN7.

I hope that helps.

So in the other thread someone reported that in a similar case with an interface flapping between up and down, disabling autonegotiation helped. So here is an excerpt from man ethtool:

ethtool -s devname [speed N] [duplex half|full] [port tp|aui|bnc|mii] [mdix auto|on|off] [autoneg on|off] [advertise N] [phyad N] [xcvr internal|external] [wol p|u|m|b|a|g|s|f|d...] [sopass xx:yy:zz:aa:bb:cc] [msglvl N | msglvl type on|off 

So ethtool -s eth2 autoneg off might be worth testing…

I have the same problem here, set eth2.7 in /etc/config/network, tried the username with and without the # marks, but the interface is still flipping between up and down. Disabling autonegotiation with ethtool didn’t help either.

@mskr have you ever found a solution to this?

No sorry. Didn’t have time but plan to look at this again soon.

OK. I’m making some progress - I disabled the “Easy Login” on telekom.de, and set the username so that there’s just one # before the 0001, and no @t-online.de at the end. i.e. something like

option username ‘002222222222555555555555#0001’

now the interface doesn’t swithc between up and down anymore, and a new interface pppoe-wan is created:

pppoe-wan Link encap:Point-to-Point Protocol
inet addr:X.X.X.X P-t-P:62.155.247.164 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:60 errors:0 dropped:0 overruns:0 frame:0
TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:2619 (2.5 KiB) TX bytes:4088 (3.9 KiB)

but that’s all - I still can’t get to the internet, even the ping to 62.155.247.164 (which I suppose should be the gateway) fails.

OK. So 62.155.247.164 is probably not the gateway, but “remote IP address”. (Whatever that is - I have zero knowledge of how PPPoE works.) anyway I tried to get the debug log from ppp, and got this:

    Sep 10 18:21:04 turris pppd[21174]: Plugin rp-pppoe.so loaded.
    Sep 10 18:21:04 turris pppd[21174]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
    Sep 10 18:21:04 turris pppd[21174]: pppd 2.4.7 started by root, uid 0
    Sep 10 18:21:04 turris pppd[21174]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
    Sep 10 18:21:04 turris pppd[21174]:  dst ff:ff:ff:ff:ff:ff  src d8:58:d7:01:12:95
    Sep 10 18:21:04 turris pppd[21174]:  [service-name] [host-uniq  b6 52 00 00]
    Sep 10 18:21:04 turris pppd[21174]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 42
    Sep 10 18:21:04 turris pppd[21174]:  dst d8:58:d7:01:12:95  src 28:8a:1c:ef:ec:ad
    Sep 10 18:21:04 turris pppd[21174]:  [AC-name GORJ00] [host-uniq  b6 52 00 00] [service-name] [AC-cookie  85 9c cb 29 91 8b fd 30 9b 94 88 00 74 a3 21 2a]
    Sep 10 18:21:04 turris pppd[21174]: Send PPPOE Discovery V1T1 PADR session 0x0 length 32
    Sep 10 18:21:04 turris pppd[21174]:  dst 28:8a:1c:ef:ec:ad  src d8:58:d7:01:12:95
    Sep 10 18:21:04 turris pppd[21174]:  [service-name] [host-uniq  b6 52 00 00] [AC-cookie  85 9c cb 29 91 8b fd 30 9b 94 88 00 74 a3 21 2a]
    Sep 10 18:21:04 turris pppd[21174]: Recv PPPOE Discovery V1T1 PADS session 0x3cc9 length 42
    Sep 10 18:21:04 turris pppd[21174]:  dst d8:58:d7:01:12:95  src 28:8a:1c:ef:ec:ad
    Sep 10 18:21:04 turris pppd[21174]:  [service-name] [host-uniq  b6 52 00 00] [AC-name GORJ00] [AC-cookie  85 9c cb 29 91 8b fd 30 9b 94 88 00 74 a3 21 2a]
    Sep 10 18:21:04 turris pppd[21174]: PADS: Service-Name: ''
    Sep 10 18:21:04 turris pppd[21174]: PPP session is 15561
    Sep 10 18:21:04 turris pppd[21174]: Connected to 28:8a:1c:ef:ec:ad via interface eth2.7
    Sep 10 18:21:04 turris pppd[21174]: using channel 3
    Sep 10 18:21:04 turris kernel: [ 6931.073881] pppoe-wan: renamed from ppp0
    Sep 10 18:21:04 turris pppd[21174]: Renamed interface ppp0 to pppoe-wan
    Sep 10 18:21:04 turris pppd[21174]: Using interface pppoe-wan
    Sep 10 18:21:04 turris pppd[21174]: Connect: pppoe-wan <--> eth2.7
    Sep 10 18:21:04 turris pppd[21174]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x5fe3add9>]
    Sep 10 18:21:04 turris pppd[21174]: rcvd [LCP ConfReq id=0x92 <mru 1492> <auth pap> <magic 0x63ce33e5>]
    Sep 10 18:21:04 turris pppd[21174]: sent [LCP ConfAck id=0x92 <mru 1492> <auth pap> <magic 0x63ce33e5>]
    Sep 10 18:21:04 turris pppd[21174]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x5fe3add9>]
    Sep 10 18:21:04 turris pppd[21174]: sent [LCP EchoReq id=0x0 magic=0x5fe3add9]
    Sep 10 18:21:04 turris pppd[21174]: sent [PAP AuthReq id=0x1 user="002494196152551136296656#0001" password=<hidden>]
    Sep 10 18:21:04 turris pppd[21174]: rcvd [LCP EchoRep id=0x0 magic=0x63ce33e5]
    Sep 10 18:21:04 turris pppd[21174]: rcvd [PAP AuthAck id=0x1 ""]
    Sep 10 18:21:04 turris pppd[21174]: PAP authentication succeeded
    Sep 10 18:21:04 turris pppd[21174]: peer from calling number 28:8A:1C:EF:EC:AD authorized
    Sep 10 18:21:04 turris pppd[21174]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
    Sep 10 18:21:04 turris pppd[21174]: rcvd [IPCP ConfReq id=0xb1 <addr 62.155.247.164>]
    Sep 10 18:21:04 turris pppd[21174]: sent [IPCP ConfAck id=0xb1 <addr 62.155.247.164>]
    Sep 10 18:21:04 turris pppd[21174]: rcvd [IPCP ConfNak id=0x1 <addr 87.183.126.42> <ms-dns1 217.6.165.41> <ms-dns2 62.157.140.155>]
    Sep 10 18:21:04 turris pppd[21174]: sent [IPCP ConfReq id=0x2 <addr 87.183.126.42> <ms-dns1 217.6.165.41> <ms-dns2 62.157.140.155>]
    Sep 10 18:21:04 turris pppd[21174]: rcvd [IPCP ConfAck id=0x2 <addr 87.183.126.42> <ms-dns1 217.6.165.41> <ms-dns2 62.157.140.155>]
    Sep 10 18:21:04 turris pppd[21174]: local  IP address 87.183.126.42
    Sep 10 18:21:04 turris pppd[21174]: remote IP address 62.155.247.164
    Sep 10 18:21:04 turris pppd[21174]: primary   DNS address 217.6.165.41
    Sep 10 18:21:04 turris pppd[21174]: secondary DNS address 62.157.140.155
    Sep 10 18:21:04 turris pppd[21174]: Script /lib/netifd/ppp-up started (pid 21373)
    Sep 10 18:21:04 turris netifd: Network device 'pppoe-wan' link is up
    Sep 10 18:21:04 turris netifd: Interface 'wan6' is enabled
    Sep 10 18:21:04 turris netifd: Network alias 'pppoe-wan' link is up
    Sep 10 18:21:04 turris netifd: Interface 'wan6' has link connectivity 
    Sep 10 18:21:04 turris netifd: Interface 'wan6' is setting up now
    Sep 10 18:21:04 turris netifd: Interface 'wan6' is now up
    Sep 10 18:21:04 turris netifd: Interface 'wan' is now up
    Sep 10 18:21:04 turris pppd[21174]: Script /lib/netifd/ppp-up finished (pid 21373), status = 0x1
    Sep 10 18:21:05 turris firewall: Reloading firewall due to ifup of wan (pppoe-wan)
    Sep 10 18:21:05 turris kresd[21549]: [system] warning: hard limit for number of file-descriptors is only 4096 but recommended value is 524288
    Sep 10 18:21:05 turris kresd[21549]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
    Sep 10 18:21:07 turris firewall: Reloading firewall due to ifup of wan6 (pppoe-wan)
    Sep 10 18:21:15 turris kresd[21549]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
    Sep 10 18:21:25 turris kresd[21549]: [priming] cannot resolve '.' NS, next priming query in 10 seconds
    Sep 10 18:21:35 turris kresd[21549]: [priming] cannot resolve '.' NS, next priming query in 10 seconds

There’s two DNS servers listed, and I can ping both of them, but I cannot get anywhere else - e.g. ping to 8.8.8.8 fails.

Hey anything new here? I am now trying again to make it work…

Does not work for me. WAN interface still flipping between up and down. You can also see it at the LED blinking.

Foris still says: WAN port has no link or it hasn’t been configured yet. Your internet connection probably won’t work.

I don’t understand what it even means for WAN to have link. Isn’t that like pulling and plugging the cable all the time? Is my cable defect? I don’t think so since I tried multiple.

I even turned on force link as described in the other thread.

Still everything the same.

Looking closely at the logread, I spotted

turris kresd[4101]: [priming] cannot resolve '.' NS, next priming query in 10 seconds

every time before the WAN interface goes down.

Could it be a DNS problem?