Omnia cannot connect to FTTH of Deutsche Telekom

My ISP (Deutsche Telekom) has installed an optical fiber modem in my home, which has a single ethernet port.

In Foris WAN settings, I left DHCP and MAC address on default/automatic, because I did not receive static IP address or MAC address from my ISP.

I did receive access codes for their network however. They also said, they would recognize my connection automatically and the codes are not needed in most cases.

Spoiler: it didn’t work. Foris error message: “WAN port has no link or hasn’t been configured yet. Your Internet connection probably won’t work”. Internet check fails. WAN port is connected via CAT5e ethernet to the fiber modem.

I tested the router given to me by my ISP and internet works.

I used the same cables and power cycled Omnia and modem multiple times without success.

Reading up on the modem suggests that it converts fiber to ethernet signals enterily, so that you should be able to plug in any ethernet devices, even a single laptop and obtain an IP address and internet access. However, testing with my laptop didn’t work too.

Setting WAN to PPPoE and entering my ISP access codes as PAP/CHAP username and paasword didn’t work too.

Maybe I need the access codes to decode the signals, when I use third party devices?

What does the ISP router doing differently?

Do I need to use SFP module?

Please correct me, but I think that SFP would do the same as the modem is already doing. Yet I do not have enough information about the modem to say for sure. I want to know more, but Deutsche Telekom holds information back. Please help.

Deutsche Telekom uses a mandatory VLAN7 and PPPoE, so you need to configure your WAN port to use VLAN7 and you should be set (that is mandatory independent for ADSL, VDSL2, and GPON(FTTH) links, the few DOCSIS(cable) links Telekom markets seem to use the DOCSIS default of DHCP).
Good luck!

No, the device offering the ethernet port is called ONT and acts as copper ethernet to GPON over optical fiber converter. You could get an ONT-SFP, and Deutsche Telekom (unlike most other german FTTH-ISPs) will provision customer owned ONTs assuming they follow the required specifications (you need to contact Telekom in that case), but for starters you are better off with the Telekom ONT.


Correct, a SFP module would obsolete the ISP’s modem. That said there are various reports of SFP modules currently not working properly with TOS4.x and later.
If you want to read about it there is a thread in the forum [1]

What sort of codes are those? ->

For that purpose that ISP’s modem would be in a full/half bridge mode and let the TO handle the authentication.

Probably indicates that the modem is just a modem indeed without any routing/dhcp/firewall capabilities. Do you have the specs of the modem somewhere online available?

[1] Supported SFP modules

Far as I know Foris does not (yet) provide VLAN settings for the WAN interface. If you are comfortable with ssh access try this in /etc/config/network (pertinent to TOS4.x and later)

config interface 'wan'
	option proto 'pppoe'
	option layer '1'
	option username ''
	option password ''
	option peerdns '0'
	option keepalive '6 10'
	option ifname 'eth2.7'
	option ipv6 'auto'

Mind enter the username and password. After saving the changes execute from ssh cli ubus -v call network reload or ifdown wan ; ifup wan.

If you are not comfortable with ssh use the LuCI interface instead. Check the logs about potential errors printed, either via LuCI or else from cli logread -f


Thanks, that already clears up things a bit more. Will try the WAN-configured-as-VLAN7-PPPoE-using-SSH solution suggestion. But very unsure about username and password. I hope Deutsche Telekom can help me with this one at least.

You get them by physical mail and it looks like this:

What they are exactly (usernames, passwords or encryption keys) is a good question.

EDIT: From, I gather that they are IDs for your connection, but are legacy technology, because the IDs are nowadays just IP addresses.

Unfortunately not. Google doesn’t help. The technician who installed it didn’t want to disclose information. The box is blank and I can’t open it. The hotline support don’t even know what I was talking about. I gathered my information from this german thread:

EDIT: It looks exactly like the Huawei EchoLife HG8010u shown here:

But it has this blank cover by Deutsche Telekom so that I can’t say it is the same model.

So here is the section from my times at telekom edited to contain the values from your example pdf (not on a turris omnia and with accepting the ISP’s DNS servers so please ignore these):

config interface 'wan'
        option _orig_ifname 'eth1'
        option _orig_bridge 'false'
        option proto 'pppoe'
        option ipv6 'auto'
        option ifname 'eth1.7'
        option username ''
        option password '123456'

The password field contains the “Persoenliches Kennwort”
and the username is contructed by concatenating three of the numbers with the suffix string "":

Note that if you connect to a BNG (and you probably are) then you can configure the BNG to accept any PPPoE password and username as they seem to use the lineID as collected by the Telekom system, but I have no idea what the default currently is, probably allow anything.
Sidenote, way in the past Telekom allowed to use PPPoE username and password nomadically, that is on other links as well (and for a time they even allowed multiple different concurrent PPPoE sessions over the same link IIRC)), but since a while now usrename/password and line are linked, so it is just consequent to get rid of the pppoe credentials… Even better would be to get rid of PPPoE at all but that is not going to happen any time soon.


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

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 ''
    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 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.


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


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?


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 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 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


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.


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…