Hi@all,

I recently experimented with the TP-Link TD-W8970B Router. Since the proprietary firmware from Deutsche Telekom isn't available anymore I'm not really able to set up the router properly anymore. Flashing it wasn't a problem but the DSL doesn't work properly in the current trunk version. The DSL itself syncs as expected and it doesn't show any errors including an "Active" state for the line. However no packets are returned from the DSL-provider. If you do a tcpdump on the DSL-interface you only see the PPPoE Disovery paket going out but nothing returns (Rx Packets: 0). I used Annex B and tone BV as well as PTM. So this shouldn't be the problem.

Besides this USB is completely not functional in Trunk anymore. I installed all necessary packets like kmod-usb2, usb-storage-extras and so on but no usb devices are detected and usbutils returns with error -99.

15.05.1:
Firmware starts but login isn't possible due to a broken login shell.

15.05:
If I downgrade to 15.05 usb works fine after i installed all the usb stuff. Unfortunately with 15.05 DSL doesn't work at all. I installed all the necessary firmware blobs. However I tried with the most current Deutsche Telekom firmware which has a different DSL-firmware in it. However the necessary firmware can still be extracted by the vdsl extractor tool.

Does somebody have some hints what I did wrong? I got this model running 1 year ago with the cut out 1.21 firmware of Deutsche Telekom inside a OpenWRT 15.05. Unfortunately I don't have a backup of this file anymore :-(

However I would prefer to run it with trunk as it doesn't seem to require to cut out proprietary firmware of other routers. USB is also really mandatory to me to get an USB overlay as the flash is too tiny for all my purposes...

EDIT: LEDE seems to have the very same issues as the current OpenWRT trunk...

(Last edited by FreierRadikaler1 on 19 Nov 2017, 18:48)

Are you by any chance subscribing to a VDSL line? If so, you need to set the proper VLAN ID on the PTM interface.

(Also I would recommend to use a stable LEDE build, 17.01.4 as of this writing. It is rock stable on a W8970.)

Nope, it's an ADSL2+ Annex B line (16 Mbit/s down / 1 Mbit/s up). I'm awear of this VLAN ID for VDSL. I set up this router for one of my friends already who has VDSL. There it's working absolutely smooth.

Don't I really need any additional firmware blibs for the current trunk versions ti get DSL working? As far as I can see there are still binary blobs in /lib/firmware thatnare loaded. I thought it's illegal to OpenWRT to ship these? What did change?

My hardware revision is 1.0 do I need 1.2 maybe?

(Last edited by FreierRadikaler1 on 20 Nov 2017, 10:35)

Ho-hum.

Not with a recent LEDE build. It already includes DSL firmware blobs, and they are a [edit: correction here] properly licensed replacement for the previously closed-source firmware blobs. If the DSL firmware didn't work you wouldn't get a line connect. The problem must be somewhere else.

Other than that, phew, I'm out of ideas, sorry. My W8970 has been working perfectly fine with a bog-standard ADSL2+ line (it is working on a VDSL line now.), out of the box without any shenanigans.

(Last edited by metai on 20 Nov 2017, 16:32)

Hardware situation:
The xDSL firmware for lantiq SOCs remains closed source, but there are two variants (and different versions thereof) plain VDSL2 and VDSL2+vectoring. Only the plain VDSL2 variant is licensed to be redistributable by Intel, the vectoring capable ones are not and must be licensed (paid for) by the vendor explicitly; this means LEDE can only ship the non-vectoring capable ones (if you need vectoring, you need to extract them from some licensed firmware yourself).

Software situation (Deutsche Telekom specific):
If your region deploys VDSL2+vectoring, all modems need to support it - even if your contract wouldn't need it (so this applies to 50/10 MBit/s connections as well). If you have a VDSL modem (firmware) which is not vectoring capable, DTAG only provides a 16 MBit/s VDSL non-vectoring fallback profile (yes this is still VDSL, not ADSL) - so you're not completely offline, but in a severely degraded state. All DTAG VDSL connections with VoIP (dubbed All-IP) need vlan tag 7 for the PPPoE session (internet and VoIP), only old ISDN+VDSL contracts don't require vlan tagging (until they're switched to VoIP).

For ADSL:
Classic POTS+ADSL or ISDN+ADSL connections connected to the old BRAS infrastructure don't require vlan tagging, but with the move to VoIP contracts these are switched to the newer BNG platform (and Annex J); the BNG platform requires vlan tag 7 for ADSL as well.

@slh: Thx for the detailed description! I have one of these early All-IP ADSL2+ Annex B contracts with 16Mbit/s. However i used a normal DSL-380T Modem from D-Link which i configured to bridge the DSL line to Ethernet so i can do my PPPoE from my linux server. On this linux server i never configured anything else besides the PPPoE connection via eth0. So there is no VLAN-tag at all and this still works fine.

How can this be?

Can i replace the current open source firmware blobs with the proprietary one that i extracted from the most current telekom routers? Do they work too? (That's just a question for the future. I don't have VDSL yet but I'm thinking about it to get it. In my region vectoring isn't available due to the lack of an additional provider who has it's own wire-based network (mendatory by regulations)).

Great information, but just as an addition even VoIP-VDSL2 lines @BRAS worked without explicit VLAN tagging (which officially was never supported), but @BNG VLAN7 is mandatory to get the PPPoE-Link up and running.

So all you do is replace the TP-Link with the D-Link and things just work, while going the other way around does not work? That is odd, just some random ideas:
Have you tried waiting for say 15 Minutes between powering of the D-Link and the TP-Link? Since DTAG will only allow a single concurrent PPPoE-Connection a somewhat harsh power off of the D-Link might be interpreted as a missing PPPoE-Edpoint instead of a proper shutdown and the PPPoE-Server at DTAG might not be willing to open a new link until it is certain the old link is truly gone away?

If the D-Link stopped working, maybe you where switched from BRAS to BNG and hence VLAN7 is not optional anymore. But that is easy to test, if the D-Link still works that is not going to be it, you can also look at the name of the PPPoE AC-Name. E.G:

PPPoE Tags
    AC-Name: TUEJ01

ACs with a short name with a three letter city code followed by the letter "J" followed by a number indicate BNG nodes instead of BRAS (the have an -aN- or -se800-somewhere in a longer AC-name ); just in case you wonder the J stands for Juniper the current supplier of the BNG hardware (so this heuristic might change should DTAG start using other manufacturers BNGs).

Some modems enable vlan tagging transparently, so simply testing vlan tag 7 might be worth it (even though it doesn't sound like that from your description).

Exactly this is what I did. In fact I planned to replace this proprietary D-Link dsl modem with the mentioned OpenWRT router. So my current internet is still provided by this DSL-Modem that basically doesn't do anything else then dsl<->eth bridging so my linux server can do all the PPPoE stuff and get a public IPv4-address. I basically just moved the telephony cable from the modem to the TD-W8970 an back. I never had any issued with the D-Link thingy. The connection always works even if i move the cable several times per minute. So the timeout of the Telekom must be really low. I will try tomorrow to set VLAN 7 to the eth0 interface. And try again with the TD-W8970.

So I would do an:

ip link add link eth0 name eth0.7 type vlan id 7

and set up the PPP daemon to use eth0.7 right?

(Last edited by FreierRadikaler1 on 21 Nov 2017, 11:25)

Regarding the timeout, the D-Link will probably be recognized as the one having intiated the old address (IIRC the PPPoE client often sends its MAC address as token for the server to evaluate, so it still makes sense to test the power down for > 15 minutes and try again with the TP-Link unless you already did that)

I found the problem: I set option xfer_mode 'ptm' instead of option xfer_mode 'atm'.

Now it syncs and I'm able to do the ppp session. Everything works fine. It even syncs ~0.5-1 Mbit/s faster then the D-Link Modem...

Now only the USB issue remains for the OpenWRT trunk version. Does somebody know what's going on there?

Hi FreierRadikaler1,

few months ago I had also trouble with openWrt and my USB-Ports.
I tryed out anything but unfortunately couldn't solve it with openWrt. Instead I switched to LEDE.
You can check my topic anyway maybe you can find a hint there:
https://forum.openwrt.org/viewtopic.php?id=72041

PS:currently I'm running LEDE 17.01.4 on a TP-Link TD9980 connected to ADSL (ISP German Telekom)