Discussion:
lantiq DSL drivers / firmware info
(too old to reply)
Martin Blumenstingl
2015-04-06 22:00:57 UTC
Permalink
Hello,

I recently purchased a TP-Link TD-W8970 on which I have installed OpenWrt.
My goal is to use it as my main "DSL router", so it has to connect to
the internet.
For the reference: at the moment I'm using a "AVM FritzBox" for this
purpose, which is connected directly to the phone jack (the web
interface tells me it's using "B43", which should be Annex B).

Unfortunately the situation regarding the drivers and the
(corresponding) firmware files is not as good as it could be.

There is no list of firmware files (I understand that those cannot be
distributed) which could serve as a reference.
Thus I decided to read the driver's source code and build a list of
firmware files that I have stumbled across: [0]
Feel free to send me the details how to get more versions into this
list (please be aware that I need a link to a public hosted file that
*everyone* can download).
Reading all this information from binary files is not what I wanted,
so I wrote a small script that does the job: [1]

While I was at it I researched if there was a newer driver version
that the one we currently have in OpenWrt (v4.11.4).
There was an update to v4.11.11 like 9 months ago, which was reverted
because it was not working for everyone.
Since I was not sure if the old driver could handle newer DSL
firmwares I searched if I could find anything newer than v4.11.11 -
and I found v4.15.2 in BT Home Hub 5A's sources (unfortunately with
all build files stripped off).
I published the updated drivers (with build files hacked back in) /
userspace utility on github: [2], [3], [4], [5]

Noteworthy changes:
- Danube support was stripped (ARX100 is now the first supported platform)
- Vectoring support (might still require other kernel patches)

The patch to get the new drivers into OpenWrt can be found here: [6]
(Please note that you need to create the tarballs yourself and put
them in the dl/ directory).
This updated driver works "as good" as the old one: I get to status
0x300 (HANDSHAKE) but not further (but that is probably "my own
problem").

In the end I also have a question:
Is there any list of recommended DSL settings per ISP?
For example it seems that for VDSL you have to use PTM, with the
correct Annex B firmware, etc. - but can that information be found on
the wiki?
If not then I'll look into creating a page in the next few days (which
YOU, valued reader, need to fill with info :-)).

Please let me know if anyone is experimenting with my updated DSL driver.
Also I'd like to hear if the firmware page is helpful and/or if you
have firmware versions that work for you (which should obviously
listed there as well).


Regards,
Martin



[0] https://xdarklight.github.io/lantiq-xdsl-firmware-info/
[1] https://github.com/xdarklight/lantiq-xdsl-firmware-info
[2] https://github.com/xdarklight/drv_mei_cpe
[3] https://github.com/xdarklight/drv_dsl_cpe_api_vrx
[4] https://github.com/xdarklight/lib_ifxos
[5] https://github.com/xdarklight/dsl_cpe_control_vrx
[6] https://gist.github.com/xdarklight/58fe9807594d5366e068/download
Daniel Golle
2015-04-07 10:31:14 UTC
Permalink
Hi Martin,

thanks for diggin' in the proprietary dirt and extracting all the
legally possible info for each firmware file.
I also got some VRX200 boards flying around here, most of them in
productive use on VDSL2 lines. However, I might give your updated
driver a try once I'm awake during less critical daytimes.

On lantiq-xdsl-firmware-info:
What about having BITH hashes or even magnet:-links next to the file
names? That would surely increase the sustainability of your work ;)

On updating the driver:
From what I understood we already got two seperate versions of the
driver, one for Danube/ADSL and one for xRX/VDSL...?

On ISP settings:
Most ISPs use the ITU recommended enumeration of VLANs on PTM/VDSL.
However, some don't, thus having some reference on that would
definitely make things easier for new users. We should list VLANs,
PPP settings and status of IPv6 support (native DS, DS-Lite, 6rd, ...
as well as the length of the prefix the ISP delegates to the users
router). Quite often this is not consistent and we might need a
couple of entries for some ISPs offering quite different services
depending on the region and the date of the initial subscription.

About your questions:
Yes, VDSL(2) only makes sense with PTM.
No, nothing useful on the wiki for now afaik.
Yes, happy to fill the missing info where ever I can.


Once again, thank you for doing this!


Cheers


Daniel

On Tue, Apr 07, 2015 at 12:00:57AM +0200, Martin Blumenstingl wrote:
> Hello,
>
> I recently purchased a TP-Link TD-W8970 on which I have installed OpenWrt.
> My goal is to use it as my main "DSL router", so it has to connect to
> the internet.
> For the reference: at the moment I'm using a "AVM FritzBox" for this
> purpose, which is connected directly to the phone jack (the web
> interface tells me it's using "B43", which should be Annex B).
>
> Unfortunately the situation regarding the drivers and the
> (corresponding) firmware files is not as good as it could be.
>
> There is no list of firmware files (I understand that those cannot be
> distributed) which could serve as a reference.
> Thus I decided to read the driver's source code and build a list of
> firmware files that I have stumbled across: [0]
> Feel free to send me the details how to get more versions into this
> list (please be aware that I need a link to a public hosted file that
> *everyone* can download).
> Reading all this information from binary files is not what I wanted,
> so I wrote a small script that does the job: [1]
>
> While I was at it I researched if there was a newer driver version
> that the one we currently have in OpenWrt (v4.11.4).
> There was an update to v4.11.11 like 9 months ago, which was reverted
> because it was not working for everyone.
> Since I was not sure if the old driver could handle newer DSL
> firmwares I searched if I could find anything newer than v4.11.11 -
> and I found v4.15.2 in BT Home Hub 5A's sources (unfortunately with
> all build files stripped off).
> I published the updated drivers (with build files hacked back in) /
> userspace utility on github: [2], [3], [4], [5]
>
> Noteworthy changes:
> - Danube support was stripped (ARX100 is now the first supported platform)
> - Vectoring support (might still require other kernel patches)
>
> The patch to get the new drivers into OpenWrt can be found here: [6]
> (Please note that you need to create the tarballs yourself and put
> them in the dl/ directory).
> This updated driver works "as good" as the old one: I get to status
> 0x300 (HANDSHAKE) but not further (but that is probably "my own
> problem").
>
> In the end I also have a question:
> Is there any list of recommended DSL settings per ISP?
> For example it seems that for VDSL you have to use PTM, with the
> correct Annex B firmware, etc. - but can that information be found on
> the wiki?
> If not then I'll look into creating a page in the next few days (which
> YOU, valued reader, need to fill with info :-)).
>
> Please let me know if anyone is experimenting with my updated DSL driver.
> Also I'd like to hear if the firmware page is helpful and/or if you
> have firmware versions that work for you (which should obviously
> listed there as well).
>
>
> Regards,
> Martin
>
>
>
> [0] https://xdarklight.github.io/lantiq-xdsl-firmware-info/
> [1] https://github.com/xdarklight/lantiq-xdsl-firmware-info
> [2] https://github.com/xdarklight/drv_mei_cpe
> [3] https://github.com/xdarklight/drv_dsl_cpe_api_vrx
> [4] https://github.com/xdarklight/lib_ifxos
> [5] https://github.com/xdarklight/dsl_cpe_control_vrx
> [6] https://gist.github.com/xdarklight/58fe9807594d5366e068/download
> _______________________________________________
> openwrt-devel mailing list
> openwrt-***@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Johannes Berg
2015-04-29 15:44:03 UTC
Permalink
On Tue, 2015-04-07 at 00:00 +0200, Martin Blumenstingl wrote:

> Feel free to send me the details how to get more versions into this
> list (please be aware that I need a link to a public hosted file that
> *everyone* can download).

You can run the "w921v_fw_cutter" also on newer firmware for that, e.g.
http://hilfe.telekom.de/dlp/eki/downloads/Speedport/Speedport%20W%20921V/Firmware_Speedport_W921V_1.34.000.bin

which gets you a file with
filename: vr9_dsl_fw_annex_b.bin
version: 5.6.7.6.1.7-5.6.7.2.1.2
sha1sum: 1e472dad0eda88281af7c00cd3f49fcc29d4fa83
filesize: 877836
Firmware1:
PLATFORM: 5
PLATFORM_STR: VRX200
APPLICATION_TYPE: 7
APPLICATION_TYPE_STR: VDSL over ISDN incl. vectoring support
VERSION_STR: 6.7.6
RELEASE_STATUS: 1
RELEASE_STATUS_STR: Pre-Release
Firmware2:
PLATFORM: 5
PLATFORM_STR: VRX200
APPLICATION_TYPE: 2
APPLICATION_TYPE_STR: ADSL Annex B
VERSION_STR: 6.7.2
RELEASE_STATUS: 1
RELEASE_STATUS_STR: Pre-Release


> While I was at it I researched if there was a newer driver version
> that the one we currently have in OpenWrt (v4.11.4).
> There was an update to v4.11.11 like 9 months ago, which was reverted
> because it was not working for everyone.
> Since I was not sure if the old driver could handle newer DSL
> firmwares I searched if I could find anything newer than v4.11.11 -
> and I found v4.15.2 in BT Home Hub 5A's sources (unfortunately with
> all build files stripped off).

Did you figure out which firmware that can deal with? Have you tried
running it? I could try running it with vectoring.

johannes
Martin Blumenstingl
2015-05-01 21:01:42 UTC
Permalink
Hi Johannes,

I'm re-sending this because I accidentally replied only to you in the
first email.

>> There's at least one firmware file that should do vectoring that you
>> haven't covered, in more recent tarballs for the Speedport W921V (you
>> have V_5.3.4.A.1.6-5.3.6.4.1.2 from an older one)
>
> filename: vr9_dsl_fw_annex_b.bin
> version: 5.6.7.6.1.7-5.6.7.2.1.2
> sha1sum: 1e472dad0eda88281af7c00cd3f49fcc29d4fa83
Thanks for this!
I have just pushed an update so the steps are available for everyone.

>> Has anyone tried any of these firmwares with newer drivers to see if
>> they can do vectoring?
>
> Put another way - does anyone have a driver that works with firmware
> 6.x?
Neither v4.11.4 nor v4.11.11 support vectoring.
Thus you need at least v4.15.2 (see my other thread which has the links).
Unfortunately *I* did not manage to get it working yet (on ADSL2 / Annex B).


Regards,
Martin

On Wed, Apr 29, 2015 at 5:37 PM, Johannes Berg
<***@sipsolutions.net> wrote:
> On Wed, 2015-04-29 at 17:12 +0200, Johannes Berg wrote:
>> > Since I was not sure if the old driver could handle newer DSL
>> > firmwares I searched if I could find anything newer than v4.11.11 -
>> > and I found v4.15.2 in BT Home Hub 5A's sources (unfortunately with
>> > all build files stripped off).
>>
>> How do you determine the firmware version?
>
> Never mind, of course your script does it.
>
>> There's at least one firmware file that should do vectoring that you
>> haven't covered, in more recent tarballs for the Speedport W921V (you
>> have V_5.3.4.A.1.6-5.3.6.4.1.2 from an older one)
>
> filename: vr9_dsl_fw_annex_b.bin
> version: 5.6.7.6.1.7-5.6.7.2.1.2
> sha1sum: 1e472dad0eda88281af7c00cd3f49fcc29d4fa83
> filesize: 877836
> Firmware1:
> PLATFORM: 5
> PLATFORM_STR: VRX200
> APPLICATION_TYPE: 7
> APPLICATION_TYPE_STR: VDSL over ISDN incl. vectoring support
> VERSION_STR: 6.7.6
> RELEASE_STATUS: 1
> RELEASE_STATUS_STR: Pre-Release
> Firmware2:
> PLATFORM: 5
> PLATFORM_STR: VRX200
> APPLICATION_TYPE: 2
> APPLICATION_TYPE_STR: ADSL Annex B
> VERSION_STR: 6.7.2
> RELEASE_STATUS: 1
> RELEASE_STATUS_STR: Pre-Release
>
>
>> Has anyone tried any of these firmwares with newer drivers to see if
>> they can do vectoring?
>
> Put another way - does anyone have a driver that works with firmware
> 6.x?
>
> johannes
>
Johannes Berg
2015-05-04 17:55:49 UTC
Permalink
Hi Martin,

> >> Has anyone tried any of these firmwares with newer drivers to see if
> >> they can do vectoring?
> >
> > Put another way - does anyone have a driver that works with firmware
> > 6.x?
> Neither v4.11.4 nor v4.11.11 support vectoring.
> Thus you need at least v4.15.2 (see my other thread which has the links).
> Unfortunately *I* did not manage to get it working yet (on ADSL2 / Annex B).

You said you also don't actually have the current one working though,
which was working well for me (on both Annex A and Annex B with VDSL
fallback).

Note that the system seems to be too slow for 100 Mbps though, so this
is somewhat academic, it can't do 100 Mbps NAT in my tests. I'm probably
going to replace it with something faster and leave VDSL to a separate
modem.

johannes
Martin Blumenstingl
2015-05-04 19:00:48 UTC
Permalink
Hi Johannes,

> You said you also don't actually have the current one working though,
> which was working well for me (on both Annex A and Annex B with VDSL
> fallback).
Like I previously said: there's probably something wrong at my end.
I have the Annex A version of the TD-W8970 and I am trying to use it with
my Annex B ADSL connection (for the record: I am not using a splitter).
While trying to connect the dsl_cpe_control tool reports:
"Wrong combination of DSL PHY Firmware and hybrid type used! Please
change one of it."
So either my configuration is still incorrect or the modem is somehow
(probably a hardware configuration, maybe via a resistor) configured to
enforce a different hybrid or Annex type (this is pure speculation though).

> Note that the system seems to be too slow for 100 Mbps though, so this
> is somewhat academic, it can't do 100 Mbps NAT in my tests. I'm probably
> going to replace it with something faster and leave VDSL to a separate
> modem.
I am interested in your test results, even though it's purely academic :-).

Someone else has tested the new driver in the meantime (using Annex A,
no VDSL): [0]
It seems that the modem syncs and is even able to connect (as far as I
understand with some manual steps), but after a few minutes the connection
drops.


Regards,
Martin


[0] https://github.com/xdarklight/drv_mei_cpe/issues/1#issuecomment-98380611
Johannes Berg
2015-05-04 19:13:58 UTC
Permalink
On Mon, 2015-05-04 at 21:00 +0200, Martin Blumenstingl wrote:

> Like I previously said: there's probably something wrong at my end.
> I have the Annex A version of the TD-W8970 and I am trying to use it with
> my Annex B ADSL connection (for the record: I am not using a splitter).
> While trying to connect the dsl_cpe_control tool reports:
> "Wrong combination of DSL PHY Firmware and hybrid type used! Please
> change one of it."

I've never seen that, but which firmware are you using?

I'd been using the speedport 1.21
(e1ef690e8dc0075468d4b6ba7bcdd0fc710bc671) one IIRC.

> So either my configuration is still incorrect or the modem is somehow
> (probably a hardware configuration, maybe via a resistor) configured to
> enforce a different hybrid or Annex type (this is pure speculation though).

Are you on VDSL Annex B, where you'd fall back to ADSL 16/1 when
vectoring isn't supported? If so, this configuration should work:

config vdsl 'dsl'
option annex 'b'
option firmware '/lib/firmware/vdsl.bin'
option tone 'b'
option xfer_mode 'ptm'

(actually I think you can/should remove the "annex" line)

On my previous ISP I was on Annex A, but I don't have the right
configuration right now.

> > Note that the system seems to be too slow for 100 Mbps though, so this
> > is somewhat academic, it can't do 100 Mbps NAT in my tests. I'm probably
> > going to replace it with something faster and leave VDSL to a separate
> > modem.
> I am interested in your test results, even though it's purely academic :-).

First I'm going to replace this router with one that's faster, and then
I'll start playing with this :-) Right now I need it to have internet
connectivity.

> Someone else has tested the new driver in the meantime (using Annex A,
> no VDSL): [0]
> It seems that the modem syncs and is even able to connect (as far as I
> understand with some manual steps), but after a few minutes the connection
> drops.

Interesting. I don't think I ever saw any connection dropouts ever.
OTOH, I occasionally had the whole system spontaneously wedge itself and
require a power cycle, so ...

johannes
Martin Blumenstingl
2015-05-04 19:46:01 UTC
Permalink
> I've never seen that, but which firmware are you using?
>
> I'd been using the speedport 1.21
> (e1ef690e8dc0075468d4b6ba7bcdd0fc710bc671) one IIRC.
I am running Chaos Calmer (but I've also tried Barrier Breaker) and that
is exactly the firmware I am using.

> Are you on VDSL Annex B, where you'd fall back to ADSL 16/1 when
> vectoring isn't supported? If so, this configuration should work:
No VDSL here yet. A fritz box (with stock firmware) on the same line
reports: http://abload.de/img/fritz_box_dsldzudk.png

> config vdsl 'dsl'
> option annex 'b'
> option firmware '/lib/firmware/vdsl.bin'
> option tone 'b'
> option xfer_mode 'ptm'
My settings look similar: I use xfer_mode 'atm' - but the other values
are identical.

> On my previous ISP I was on Annex A, but I don't have the right
> configuration right now.
I'm using a line provided by Deutsche Telekom (resold to 1&1, but that
shouldn't make a difference).

> First I'm going to replace this router with one that's faster, and then
> I'll start playing with this :-) Right now I need it to have internet
> connectivity.
Makes sense - never play with productive hardware :-)


Regards,
Martin
Sylwester Petela
2015-05-04 21:16:48 UTC
Permalink
W dniu 2015-05-04 o 21:13, Johannes Berg pisze:
> On Mon, 2015-05-04 at 21:00 +0200, Martin Blumenstingl wrote:
>
>> Like I previously said: there's probably something wrong at my end.
>> I have the Annex A version of the TD-W8970 and I am trying to use it with
>> my Annex B ADSL connection (for the record: I am not using a splitter).
>> While trying to connect the dsl_cpe_control tool reports:
>> "Wrong combination of DSL PHY Firmware and hybrid type used! Please
>> change one of it."
> I've never seen that, but which firmware are you using?
>
> I'd been using the speedport 1.21
> (e1ef690e8dc0075468d4b6ba7bcdd0fc710bc671) one IIRC.
>
>> So either my configuration is still incorrect or the modem is somehow
>> (probably a hardware configuration, maybe via a resistor) configured to
>> enforce a different hybrid or Annex type (this is pure speculation though).
> Are you on VDSL Annex B, where you'd fall back to ADSL 16/1 when
> vectoring isn't supported? If so, this configuration should work:
>
> config vdsl 'dsl'
> option annex 'b'
> option firmware '/lib/firmware/vdsl.bin'
> option tone 'b'
> option xfer_mode 'ptm'
>
> (actually I think you can/should remove the "annex" line)
>
> On my previous ISP I was on Annex A, but I don't have the right
> configuration right now.
>
>>> Note that the system seems to be too slow for 100 Mbps though, so this
>>> is somewhat academic, it can't do 100 Mbps NAT in my tests. I'm probably
>>> going to replace it with something faster and leave VDSL to a separate
>>> modem.
>> I am interested in your test results, even though it's purely academic :-).
> First I'm going to replace this router with one that's faster, and then
> I'll start playing with this :-) Right now I need it to have internet
> connectivity.
>
>> Someone else has tested the new driver in the meantime (using Annex A,
>> no VDSL): [0]
>> It seems that the modem syncs and is even able to connect (as far as I
>> understand with some manual steps), but after a few minutes the connection
>> drops.
> Interesting. I don't think I ever saw any connection dropouts ever.
> OTOH, I occasionally had the whole system spontaneously wedge itself and
> require a power cycle, so ...
>
> johannes

No dropouts, system flooded with:

[ 456.056000] DSL[00]: negative response for MsgID=0x2B0A
(Class=0x00003100) - on try 0!
[ 456.764000] DSL[00]: Error for send CMD MsgID=0x2B0A - KEEP line!
[ 456.768000] DSL[00]: ERROR - ReTx PM counters read failed!
[ 457.032000] MEI_DRV[00 - 01]: ReadAck[0x2B0A] - FctOP ERROR 0x31!

and after about 20-30 min hangs, after disabling ReTx at build system
stays online for at least 6 hours (didn't test further) with some
warnings repeating every two seconds:

[ 458.772000] DSL[00]: WARNING - Data Path counters are not supported
for the FE!

vectoring and ReTx works acording to friend but system log shows some
errors as well like on my ADSL line but not so many.

On ADSL and also on VDSL with never firmware and errors/warnings
appearing in log, system is under quite big load, compared to stock drivers.

Probably we need dsl_control script to be reworked, as new features
aren't present in it and stock/default config isn't the best.

Regards
Johannes Berg
2015-05-05 06:56:57 UTC
Permalink
On Mon, 2015-05-04 at 23:16 +0200, Sylwester Petela wrote:

> [ 456.056000] DSL[00]: negative response for MsgID=0x2B0A
> (Class=0x00003100) - on try 0!
> [ 456.764000] DSL[00]: Error for send CMD MsgID=0x2B0A - KEEP line!
> [ 456.768000] DSL[00]: ERROR - ReTx PM counters read failed!
> [ 457.032000] MEI_DRV[00 - 01]: ReadAck[0x2B0A] - FctOP ERROR 0x31!
>
> and after about 20-30 min hangs, after disabling ReTx at build system

How did you disable ReTx?

> stays online for at least 6 hours (didn't test further) with some
> warnings repeating every two seconds:
>
> [ 458.772000] DSL[00]: WARNING - Data Path counters are not supported
> for the FE!

That seems pretty harmless - the driver code is really really ugly
though. Probably should just remove the message.

> vectoring and ReTx works acording to friend but system log shows some
> errors as well like on my ADSL line but not so many.

What firmware/driver combination was this with?

> On ADSL and also on VDSL with never firmware and errors/warnings
> appearing in log, system is under quite big load, compared to stock drivers.

Yeah, this is true. I'm not sure what I said yesterday ("it's too slow")
is correct, but certainly it's pretty loaded.

johannes
Sylwester Petela
2015-05-05 07:28:23 UTC
Permalink
W dniu 2015-05-05 o 08:56, Johannes Berg pisze:
> On Mon, 2015-05-04 at 23:16 +0200, Sylwester Petela wrote:
>
>> [ 456.056000] DSL[00]: negative response for MsgID=0x2B0A
>> (Class=0x00003100) - on try 0!
>> [ 456.764000] DSL[00]: Error for send CMD MsgID=0x2B0A - KEEP line!
>> [ 456.768000] DSL[00]: ERROR - ReTx PM counters read failed!
>> [ 457.032000] MEI_DRV[00 - 01]: ReadAck[0x2B0A] - FctOP ERROR 0x31!
>>
>> and after about 20-30 min hangs, after disabling ReTx at build system
> How did you disable ReTx?

Added to makefile in vdsl-app and vdsl-control

--disable-dsl-pm-retx-counters \
--disable-dsl-pm-retx-thresholds \

vdsl_cpe_control commands were ignored when trying to disable it by them.

>
>> stays online for at least 6 hours (didn't test further) with some
>> warnings repeating every two seconds:
>>
>> [ 458.772000] DSL[00]: WARNING - Data Path counters are not supported
>> for the FE!
> That seems pretty harmless - the driver code is really really ugly
> though. Probably should just remove the message.

Cannot find witch function this message is referring to, need to
investigate more.

>
>> vectoring and ReTx works acording to friend but system log shows some
>> errors as well like on my ADSL line but not so many.
> What firmware/driver combination was this with?

xcpe_567517_562301.bin: VDSL over ISDN incl. vectoring support for
VRX200, version: 6.7.5 | ADSL Annex A for VRX200, version: 6.2.3

4.15.2 -app/control; 1.4.5 -mei

>
>> On ADSL and also on VDSL with never firmware and errors/warnings
>> appearing in log, system is under quite big load, compared to stock drivers.
> Yeah, this is true. I'm not sure what I said yesterday ("it's too slow")
> is correct, but certainly it's pretty loaded.
>
> johannes
>
Yes slow but why ? Because of load or because of hardware, Zyxel on
stock openwrt driver can achieve 80Mbps without that much load.
Johannes Berg
2015-05-05 07:31:22 UTC
Permalink
On Tue, 2015-05-05 at 09:28 +0200, Sylwester Petela wrote:

> >> [ 458.772000] DSL[00]: WARNING - Data Path counters are not supported
> >> for the FE!
> > That seems pretty harmless - the driver code is really really ugly
> > though. Probably should just remove the message.
>
> Cannot find witch function this message is referring to, need to
> investigate more.

I found it in Martin's drv_dsl_cpe_api_vrx repository.

> >> vectoring and ReTx works acording to friend but system log shows some
> >> errors as well like on my ADSL line but not so many.
> > What firmware/driver combination was this with?
>
> xcpe_567517_562301.bin: VDSL over ISDN incl. vectoring support for
> VRX200, version: 6.7.5 | ADSL Annex A for VRX200, version: 6.2.3
>
> 4.15.2 -app/control; 1.4.5 -mei

Ok, I'll give that a try as soon as I've removed this from my productive
env.

Or perhaps I'll just put another image on a separate extroot since I
have extroot setup anyway.

> Yes slow but why ? Because of load or because of hardware, Zyxel on
> stock openwrt driver can achieve 80Mbps without that much load.

Not sure, perhaps the CPU is just slow?

johannes
Sylwester Petela
2015-05-23 12:39:02 UTC
Permalink
W dniu 2015-05-05 o 09:31, Johannes Berg pisze:
> On Tue, 2015-05-05 at 09:28 +0200, Sylwester Petela wrote:
>
>>>> [ 458.772000] DSL[00]: WARNING - Data Path counters are not supported
>>>> for the FE!
>>> That seems pretty harmless - the driver code is really really ugly
>>> though. Probably should just remove the message.
>> Cannot find witch function this message is referring to, need to
>> investigate more.
> I found it in Martin's drv_dsl_cpe_api_vrx repository.
>
>>>> vectoring and ReTx works acording to friend but system log shows some
>>>> errors as well like on my ADSL line but not so many.
>>> What firmware/driver combination was this with?
>> xcpe_567517_562301.bin: VDSL over ISDN incl. vectoring support for
>> VRX200, version: 6.7.5 | ADSL Annex A for VRX200, version: 6.2.3
>>
>> 4.15.2 -app/control; 1.4.5 -mei
> Ok, I'll give that a try as soon as I've removed this from my productive
> env.
>
> Or perhaps I'll just put another image on a separate extroot since I
> have extroot setup anyway.
>
>> Yes slow but why ? Because of load or because of hardware, Zyxel on
>> stock openwrt driver can achieve 80Mbps without that much load.
> Not sure, perhaps the CPU is just slow?
>
> johannes
>

Anyone got a clue how to disable warnings ? Tried to disable PM counters
but without any luck.

[ 47.436000] DSL[00]: PM NE processing out of Poll Cycle!
[ 47.636000] DSL[00]: Unsupported message with MsgID=0x0245!
[ 47.640000] DSL[00]: Unsupported message with MsgID=0x1C44!
[ 47.644000] DSL[00]: WARNING - Saving PM Channel Counters for FE are
not supported!
[ 47.652000] DSL[00]: WARNING - Saving PM Line Performance Counters
for FE are not supported!
[ 70.760000] DSL[00]: MEI_InternalXtmSwhowtimeEntrySignal(nFast=0,
nIntl=928000)
[ 70.768000] enter showtime, cell rate: 0 - 2188, 1 - 2188, xdata
addr: 0x86d10000
[ 70.784000] enter showtime, cell rate: 0 - 2188, 1 - 2188, xdata
addr: 0x86d10000
[ 70.792000] DSL[00]: WARNING - Data Path counters are not supported
for the FE!
[ 71.792000] DSL[00]: WARNING - FE line failures retrieving not
supported by the FW in ADSL mode!
[ 72.436000] pppoe-wan: renamed from ppp0
[ 72.800000] DSL[00]: WARNING - FE line failures retrieving not
supported by the FW in ADSL mode!
(...)
[ 106.792000] DSL[00]: WARNING - Data Path counters are not supported
for the FE!
[ 107.064000] DSL[00]: WARNING - FE line failures retrieving not
supported by the FW in ADSL mode!
[ 108.072000] DSL[00]: WARNING - FE line failures retrieving not
supported by the FW in ADSL mode!
Aleksander Wałęski
2015-05-23 21:22:58 UTC
Permalink
Sylwester Petela <sscapi <at> gmail.com> writes:

>
>
> W dniu 2015-05-05 o 09:31, Johannes Berg pisze:
> > On Tue, 2015-05-05 at 09:28 +0200, Sylwester Petela wrote:
> >
> >>>> [ 458.772000] DSL[00]: WARNING - Data Path counters are not
supported
> >>>> for the FE!
> >>> That seems pretty harmless - the driver code is really really ugly
> >>> though. Probably should just remove the message.
> >> Cannot find witch function this message is referring to, need to
> >> investigate more.
> > I found it in Martin's drv_dsl_cpe_api_vrx repository.
> >
> >>>> vectoring and ReTx works acording to friend but system log shows
some
> >>>> errors as well like on my ADSL line but not so many.
> >>> What firmware/driver combination was this with?
> >> xcpe_567517_562301.bin: VDSL over ISDN incl. vectoring support for
> >> VRX200, version: 6.7.5 | ADSL Annex A for VRX200, version: 6.2.3
> >>
> >> 4.15.2 -app/control; 1.4.5 -mei
> > Ok, I'll give that a try as soon as I've removed this from my
productive
> > env.
> >
> > Or perhaps I'll just put another image on a separate extroot since I
> > have extroot setup anyway.
> >
> >> Yes slow but why ? Because of load or because of hardware, Zyxel on
> >> stock openwrt driver can achieve 80Mbps without that much load.
> > Not sure, perhaps the CPU is just slow?
> >
> > johannes
> >
>
> Anyone got a clue how to disable warnings ? Tried to disable PM
counters
> but without any luck.
>
> [ 47.436000] DSL[00]: PM NE processing out of Poll Cycle!
> [ 47.636000] DSL[00]: Unsupported message with MsgID=0x0245!
> [ 47.640000] DSL[00]: Unsupported message with MsgID=0x1C44!
> [ 47.644000] DSL[00]: WARNING - Saving PM Channel Counters for FE
are
> not supported!
> [ 47.652000] DSL[00]: WARNING - Saving PM Line Performance Counters
> for FE are not supported!
> [ 70.760000] DSL[00]: MEI_InternalXtmSwhowtimeEntrySignal(nFast=0,
> nIntl=928000)
> [ 70.768000] enter showtime, cell rate: 0 - 2188, 1 - 2188, xdata
> addr: 0x86d10000
> [ 70.784000] enter showtime, cell rate: 0 - 2188, 1 - 2188, xdata
> addr: 0x86d10000
> [ 70.792000] DSL[00]: WARNING - Data Path counters are not supported
> for the FE!
> [ 71.792000] DSL[00]: WARNING - FE line failures retrieving not
> supported by the FW in ADSL mode!
> [ 72.436000] pppoe-wan: renamed from ppp0
> [ 72.800000] DSL[00]: WARNING - FE line failures retrieving not
> supported by the FW in ADSL mode!
> (...)
> [ 106.792000] DSL[00]: WARNING - Data Path counters are not supported
> for the FE!
> [ 107.064000] DSL[00]: WARNING - FE line failures retrieving not
> supported by the FW in ADSL mode!
> [ 108.072000] DSL[00]: WARNING - FE line failures retrieving not
> supported by the FW in ADSL mode!
>


Not sure if this helps, but some modules seem to accept debug_level
parameter at load. In GPL tarbal for W8980 (http://www.tp-
link.com/resources/gpl/GPL_TD-W8980.tar.gz) i found this line:
#insmod /lib/modules/drv_dsl_cpe_api.ko debug_level=3
Also, there are references in code to this:
https://github.com/xdarklight/lib_ifxos/search?q=debug_level

Also, using binwalk, I was able to extract dsl firmware from latest
W9980 firmware update (TD-W9980_V1_150507).

filename: xcpe_574306_571801.bin
version: 5.7.4.3.0.6-5.7.1.8.0.1
sha1sum: f8a13f16f5ead64bb0d2d551fbef8f1a838322f7
filesize: 923152
Firmware1:
PLATFORM: 5
PLATFORM_STR: VRX200
APPLICATION_TYPE: 6
APPLICATION_TYPE_STR: VDSL over IDSN
VERSION_STR: 7.4.3
RELEASE_STATUS: 0
RELEASE_STATUS_STR: Release
Firmware2:
PLATFORM: 5
PLATFORM_STR: VRX200
APPLICATION_TYPE: 1
APPLICATION_TYPE_STR: ADSL Annex A
VERSION_STR: 7.1.8
RELEASE_STATUS: 0
RELEASE_STATUS_STR: Release

Might be useful as it seems to be newest version reported so far.
Martin Blumenstingl
2015-05-23 22:11:27 UTC
Permalink
> Also, using binwalk, I was able to extract dsl firmware from latest
> W9980 firmware update (TD-W9980_V1_150507).
>
> filename: xcpe_574306_571801.bin
> version: 5.7.4.3.0.6-5.7.1.8.0.1
> sha1sum: f8a13f16f5ead64bb0d2d551fbef8f1a838322f7

Thanks a lot - added that one as well.
Sylwester Petela
2015-05-24 10:30:04 UTC
Permalink
W dniu 2015-05-23 o 23:22, Aleksander Wałęski pisze:
> Sylwester Petela <sscapi <at> gmail.com> writes:
>
>>
>> W dniu 2015-05-05 o 09:31, Johannes Berg pisze:
>>> On Tue, 2015-05-05 at 09:28 +0200, Sylwester Petela wrote:
>>>
>>>>>> [ 458.772000] DSL[00]: WARNING - Data Path counters are not
> supported
>>>>>> for the FE!
>>>>> That seems pretty harmless - the driver code is really really ugly
>>>>> though. Probably should just remove the message.
>>>> Cannot find witch function this message is referring to, need to
>>>> investigate more.
>>> I found it in Martin's drv_dsl_cpe_api_vrx repository.
>>>
>>>>>> vectoring and ReTx works acording to friend but system log shows
> some
>>>>>> errors as well like on my ADSL line but not so many.
>>>>> What firmware/driver combination was this with?
>>>> xcpe_567517_562301.bin: VDSL over ISDN incl. vectoring support for
>>>> VRX200, version: 6.7.5 | ADSL Annex A for VRX200, version: 6.2.3
>>>>
>>>> 4.15.2 -app/control; 1.4.5 -mei
>>> Ok, I'll give that a try as soon as I've removed this from my
> productive
>>> env.
>>>
>>> Or perhaps I'll just put another image on a separate extroot since I
>>> have extroot setup anyway.
>>>
>>>> Yes slow but why ? Because of load or because of hardware, Zyxel on
>>>> stock openwrt driver can achieve 80Mbps without that much load.
>>> Not sure, perhaps the CPU is just slow?
>>>
>>> johannes
>>>
>> Anyone got a clue how to disable warnings ? Tried to disable PM
> counters
>> but without any luck.
>>
>> [ 47.436000] DSL[00]: PM NE processing out of Poll Cycle!
>> [ 47.636000] DSL[00]: Unsupported message with MsgID=0x0245!
>> [ 47.640000] DSL[00]: Unsupported message with MsgID=0x1C44!
>> [ 47.644000] DSL[00]: WARNING - Saving PM Channel Counters for FE
> are
>> not supported!
>> [ 47.652000] DSL[00]: WARNING - Saving PM Line Performance Counters
>> for FE are not supported!
>> [ 70.760000] DSL[00]: MEI_InternalXtmSwhowtimeEntrySignal(nFast=0,
>> nIntl=928000)
>> [ 70.768000] enter showtime, cell rate: 0 - 2188, 1 - 2188, xdata
>> addr: 0x86d10000
>> [ 70.784000] enter showtime, cell rate: 0 - 2188, 1 - 2188, xdata
>> addr: 0x86d10000
>> [ 70.792000] DSL[00]: WARNING - Data Path counters are not supported
>> for the FE!
>> [ 71.792000] DSL[00]: WARNING - FE line failures retrieving not
>> supported by the FW in ADSL mode!
>> [ 72.436000] pppoe-wan: renamed from ppp0
>> [ 72.800000] DSL[00]: WARNING - FE line failures retrieving not
>> supported by the FW in ADSL mode!
>> (...)
>> [ 106.792000] DSL[00]: WARNING - Data Path counters are not supported
>> for the FE!
>> [ 107.064000] DSL[00]: WARNING - FE line failures retrieving not
>> supported by the FW in ADSL mode!
>> [ 108.072000] DSL[00]: WARNING - FE line failures retrieving not
>> supported by the FW in ADSL mode!
>>
>
> Not sure if this helps, but some modules seem to accept debug_level
> parameter at load. In GPL tarbal for W8980 (http://www.tp-
> link.com/resources/gpl/GPL_TD-W8980.tar.gz) i found this line:
> #insmod /lib/modules/drv_dsl_cpe_api.ko debug_level=3
> Also, there are references in code to this:
> https://github.com/xdarklight/lib_ifxos/search?q=debug_level
>
> Also, using binwalk, I was able to extract dsl firmware from latest
> W9980 firmware update (TD-W9980_V1_150507).
>
> filename: xcpe_574306_571801.bin
> version: 5.7.4.3.0.6-5.7.1.8.0.1
> sha1sum: f8a13f16f5ead64bb0d2d551fbef8f1a838322f7
> filesize: 923152
> Firmware1:
> PLATFORM: 5
> PLATFORM_STR: VRX200
> APPLICATION_TYPE: 6
> APPLICATION_TYPE_STR: VDSL over IDSN
> VERSION_STR: 7.4.3
> RELEASE_STATUS: 0
> RELEASE_STATUS_STR: Release
> Firmware2:
> PLATFORM: 5
> PLATFORM_STR: VRX200
> APPLICATION_TYPE: 1
> APPLICATION_TYPE_STR: ADSL Annex A
> VERSION_STR: 7.1.8
> RELEASE_STATUS: 0
> RELEASE_STATUS_STR: Release
>
> Might be useful as it seems to be newest version reported so far.
> _______________________________________________
> openwrt-devel mailing list
> openwrt-***@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Was quite obvious but I've missed it, default debug level have been
changed since 4.11.4 so adding/changing:

--enable-error_print \
--disable-warning_print \
--enable-debug-prints=no \

gets rid of all warnings except of errors so on ADSL even with ReTx
enabled console is silent and CPU usage dropped down to earlier level, I
cannot test VDSL so if anyone can check it and post some results.
Working with newest binary xcpe_574306_571801 from TP-LINK.

Newest trunk with patches from xdarklight, packages from DrayTek.

Full log: http://pastebin.com/KtwqydD8
Martin Blumenstingl
2015-05-24 15:15:34 UTC
Permalink
> Was quite obvious but I've missed it, default debug level have been changed
Excellent catch, I should have noticed it when I removed "-DDSL_DEBUG_DISABLE"

> Newest trunk with patches from xdarklight, packages from DrayTek.
What do you mean exactly with "packages from DrayTek"?

> Full log: http://pastebin.com/KtwqydD8
Looks clean :-)

I am currently updating my patch to include your configuration change.
To make that applying the patch easier I have also tagged the versions on github
(I used a "-custom" suffix to indicate that it's not 1:1 lantiq's version).
olewales
2015-05-24 15:39:16 UTC
Permalink
On Sun, May 24, 2015 at 5:15 PM, Martin Blumenstingl
<***@googlemail.com> wrote:
>> Was quite obvious but I've missed it, default debug level have been changed
> Excellent catch, I should have noticed it when I removed "-DDSL_DEBUG_DISABLE"

This might come in handy for DSL tinkerers, though. Probably should be
made mencuonfig option

>> Newest trunk with patches from xdarklight, packages from DrayTek.
> What do you mean exactly with "packages from DrayTek"?
>
>> Full log: http://pastebin.com/KtwqydD8
> Looks clean :-)
>
> I am currently updating my patch to include your configuration change.
> To make that applying the patch easier I have also tagged the versions on github
> (I used a "-custom" suffix to indicate that it's not 1:1 lantiq's version).

Waiting impatiently for this new patch. For now I can say that I have
problems with old driver combined with newest TP-LINK dsl firmware on
VDSL line. Once I establish known working configuration I'll build fw
with latest driver and test again.
Martin Blumenstingl
2015-05-24 16:04:01 UTC
Permalink
> Waiting impatiently for this new patch. For now I can say that I have
> problems with old driver combined with newest TP-LINK dsl firmware on
> VDSL line. Once I establish known working configuration I'll build fw
> with latest driver and test again.
New patch is ready: [0]

Let me know if VDSL works with this driver for you.
Then we can think of how to get the new version into OpenWrt.


[0] https://gist.github.com/xdarklight/2986587133d97892a4b3/download
Aleksander Wałęski
2015-05-25 06:00:08 UTC
Permalink
Good news! It works.
Furthermore, I could only get it to work on my line with this new
driver. I tried old driver with 6 different firmwares (VDSL fw
versions: 3.2.8, 3.4.A, 4.6.D, 4.7.9, 6.8.4, 7.4.3). Older ones got me
as far as "full_init [0x380]" but then process was interrupted and
started all over again. I suspect that DSLAM I am connected to could
not negotiate parameters it wanted from modem. Newer firmwares on the
other hand just sit at "idle request [0xFF]". Probably they are not
compatible with old driver version. This is quite interesting because
they are reports from people running openwrt Lantiq devices on VDSL2
lines from my ISP (Orange Polska).

With the new driver and lastest firmware (from W9980) I got showtime
right away, I didn't even have to touch any configuration. As I
discovered, that's because this combination of driver/firmware
(probably mostly firmware) seems to ignore all magic numbers passed by
dsl_control. It behaves the same regardless of what I provide to
vdsl_cpe_control as init bits (-i) or low level configuration file
(-l). -M parameter also seems unnecessary. Firmware either has some
hard coded values which match my connection, or more likely, it
performs autodetection of line parameters. This makes sense because
W9980 is sold worldwide and has to support all configurations
imaginable. Unfortunately TP-LINK firmware seems to be mostly bunch of
binaries talking to one another (in this case /lib/libcmm.so seems to
call dsl_cpe_control) so passive analysis is not easy. Maybe someone
could try to spy on firmware running on actual device.

This of course should be confirmed by few people (preferably on vastly
different connections) before sending patch upstream, but if it turns
out to be true it will greatly simplify xDSL configuration on Lantiq
devices. My dsl_control script currently looks like this (also on
pastebin if line wraping messes with it: http://pastebin.com/G0jUQMxL)

---------------------------------------

#!/bin/sh /etc/rc.common
# Copyright (C) 2015 OpenWrt.org

# needs to start before the atm layer which starts at 50
START=48

EXTRA_COMMANDS="status lucistat"
EXTRA_HELP=" status Get DSL status information
lucistat Get status information if lua friendly format"

SERVICE_DAEMONIZE=1
SERVICE_WRITE_PID=1

[ -f /lib/functions/lantiq_dsl.sh ] && . /lib/functions/lantiq_dsl.sh
XDSL_CTRL=vdsl_cpe_control


start() {

config_load network
config_get firmware dsl firmware
config_get xfer_mode dsl xfer_mode

[ -z "${xfer_mode}" ] && xfer_mode=ptm

case "${xfer_mode}" in
atm)
insmod ltq_atm_vr9
;;
*)
insmod ltq_ptm_vr9
;;
esac



[ -z "${firmware}" ] && firmware=/lib/firmware/vdsl.bin
[ -f "${firmware}" ] || {
echo failed to find $firmware
return 1
}

service_start /sbin/vdsl_cpe_control \
-i \
-n /sbin/dsl_notify.sh \
-f ${firmware} \
-A /lib/firmware/vdsl.scr
}

stop() {
DSL_NOTIFICATION_TYPE="DSL_INTERFACE_STATUS" \
DSL_INTERFACE_STATUS="DOWN" \
/sbin/dsl_notify.sh

service_stop /sbin/vdsl_cpe_control
}

---------------------------------------

Got rid of most of the things. Whats left:
1. Module loading. Tried to just load both modules even if we don't
use them but then kernel complains about IRQ conflict and crashes
badly soon afterwards.
2. Firmware path. Hardcoding this would not be very elegant but we
could remove it from network configuration file while reworking
firmware installation script (it will be necessary eventually)
3. dsl_notify stuff
4. -i command line switch. No "init bits" need to follow but it seems
that it has to be there.
5. VDSL autoboot script (more on that below).

TP-LINK includes vdsl.scr, which according to comment, enables ReTx in
both directions. I have not noticed any change in my setup after
enabling this but it think we should include this to maintain
potentially the same performance.



On the side note. Lantiq modem achieves a bit lower sync rates than
router provided by my ISP (about 22Mbit / 3.5Mbit vs 25Mbit/4Mbit) but
I am willing to make this sacrifice for having full control over
hardware and configuration. I am seriously concerned about performance
though. I managed to get 130Mbit/s from iperf over wired connection. I
have yet to check NAT/routing performance but routing between subnets
on gigabit ethernet I was hoping to do seems to be out of question.

On Sun, May 24, 2015 at 6:04 PM, Martin Blumenstingl
<***@googlemail.com> wrote:
>> Waiting impatiently for this new patch. For now I can say that I have
>> problems with old driver combined with newest TP-LINK dsl firmware on
>> VDSL line. Once I establish known working configuration I'll build fw
>> with latest driver and test again.
> New patch is ready: [0]
>
> Let me know if VDSL works with this driver for you.
> Then we can think of how to get the new version into OpenWrt.
>
>
> [0] https://gist.github.com/xdarklight/2986587133d97892a4b3/download
Sylwester Petela
2015-05-25 06:52:44 UTC
Permalink
W dniu 2015-05-25 o 08:00, Aleksander Wałęski pisze:
> Good news! It works.
> Furthermore, I could only get it to work on my line with this new
> driver. I tried old driver with 6 different firmwares (VDSL fw
> versions: 3.2.8, 3.4.A, 4.6.D, 4.7.9, 6.8.4, 7.4.3). Older ones got me
> as far as "full_init [0x380]" but then process was interrupted and
> started all over again. I suspect that DSLAM I am connected to could
> not negotiate parameters it wanted from modem. Newer firmwares on the
> other hand just sit at "idle request [0xFF]". Probably they are not
> compatible with old driver version. This is quite interesting because
> they are reports from people running openwrt Lantiq devices on VDSL2
> lines from my ISP (Orange Polska).
>
> With the new driver and lastest firmware (from W9980) I got showtime
> right away, I didn't even have to touch any configuration. As I
> discovered, that's because this combination of driver/firmware
> (probably mostly firmware) seems to ignore all magic numbers passed by
> dsl_control. It behaves the same regardless of what I provide to
> vdsl_cpe_control as init bits (-i) or low level configuration file
> (-l). -M parameter also seems unnecessary. Firmware either has some
> hard coded values which match my connection, or more likely, it
> performs autodetection of line parameters. This makes sense because
> W9980 is sold worldwide and has to support all configurations
> imaginable. Unfortunately TP-LINK firmware seems to be mostly bunch of
> binaries talking to one another (in this case /lib/libcmm.so seems to
> call dsl_cpe_control) so passive analysis is not easy. Maybe someone
> could try to spy on firmware running on actual device.
>
> This of course should be confirmed by few people (preferably on vastly
> different connections) before sending patch upstream, but if it turns
> out to be true it will greatly simplify xDSL configuration on Lantiq
> devices. My dsl_control script currently looks like this (also on
> pastebin if line wraping messes with it: http://pastebin.com/G0jUQMxL)
>
> ---------------------------------------
>
> #!/bin/sh /etc/rc.common
> # Copyright (C) 2015 OpenWrt.org
>
> # needs to start before the atm layer which starts at 50
> START=48
>
> EXTRA_COMMANDS="status lucistat"
> EXTRA_HELP=" status Get DSL status information
> lucistat Get status information if lua friendly format"
>
> SERVICE_DAEMONIZE=1
> SERVICE_WRITE_PID=1
>
> [ -f /lib/functions/lantiq_dsl.sh ] && . /lib/functions/lantiq_dsl.sh
> XDSL_CTRL=vdsl_cpe_control
>
>
> start() {
>
> config_load network
> config_get firmware dsl firmware
> config_get xfer_mode dsl xfer_mode
>
> [ -z "${xfer_mode}" ] && xfer_mode=ptm
>
> case "${xfer_mode}" in
> atm)
> insmod ltq_atm_vr9
> ;;
> *)
> insmod ltq_ptm_vr9
> ;;
> esac
>
>
>
> [ -z "${firmware}" ] && firmware=/lib/firmware/vdsl.bin
> [ -f "${firmware}" ] || {
> echo failed to find $firmware
> return 1
> }
>
> service_start /sbin/vdsl_cpe_control \
> -i \
> -n /sbin/dsl_notify.sh \
> -f ${firmware} \
> -A /lib/firmware/vdsl.scr
> }
>
> stop() {
> DSL_NOTIFICATION_TYPE="DSL_INTERFACE_STATUS" \
> DSL_INTERFACE_STATUS="DOWN" \
> /sbin/dsl_notify.sh
>
> service_stop /sbin/vdsl_cpe_control
> }
>
> ---------------------------------------
>
> Got rid of most of the things. Whats left:
> 1. Module loading. Tried to just load both modules even if we don't
> use them but then kernel complains about IRQ conflict and crashes
> badly soon afterwards.
> 2. Firmware path. Hardcoding this would not be very elegant but we
> could remove it from network configuration file while reworking
> firmware installation script (it will be necessary eventually)
Getting rid of init script isn't good probably, as original driver in
UGW passes the same commands (mostly) to dsl_control.
Firmware dir is also in original UGW init script, moving it from config
to init doesn't make any difference.
> 3. dsl_notify stuff
> 4. -i command line switch. No "init bits" need to follow but it seems
> that it has to be there.
> 5. VDSL autoboot script (more on that below).
>
> TP-LINK includes vdsl.scr, which according to comment, enables ReTx in
> both directions. I have not noticed any change in my setup after
> enabling this but it think we should include this to maintain
> potentially the same performance.

General init is made by script (Low-level config, etc.) Rest is
calculated from API or by firmware (mostly firmware bits) (see My
earlier problem with ReTx on ADSL) You can see it in this log
http://pastebin.com/ne1aELff

>
>
>
> On the side note. Lantiq modem achieves a bit lower sync rates than
> router provided by my ISP (about 22Mbit / 3.5Mbit vs 25Mbit/4Mbit) but
> I am willing to make this sacrifice for having full control over
> hardware and configuration. I am seriously concerned about performance
> though. I managed to get 130Mbit/s from iperf over wired connection. I
> have yet to check NAT/routing performance but routing between subnets
> on gigabit ethernet I was hoping to do seems to be out of question.

Its switch related, vlan performance is quite low on vrx devices, as for
sync speed, depends what chip sits on DSLAM.


> On Sun, May 24, 2015 at 6:04 PM, Martin Blumenstingl
> <***@googlemail.com> wrote:
>>> Waiting impatiently for this new patch. For now I can say that I have
>>> problems with old driver combined with newest TP-LINK dsl firmware on
>>> VDSL line. Once I establish known working configuration I'll build fw
>>> with latest driver and test again.
>> New patch is ready: [0]
>>
>> Let me know if VDSL works with this driver for you.
>> Then we can think of how to get the new version into OpenWrt.
>>
>>
>> [0] https://gist.github.com/xdarklight/2986587133d97892a4b3/download
> _______________________________________________
> openwrt-devel mailing list
> openwrt-***@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

What You have missed is that driver needs to be universal, vrx supports
ADSL as well, annex a/b lines, it can be tuned to have better
performance but not without getting rid of its "universality".
Aleksander Wałęski
2015-05-25 07:39:41 UTC
Permalink
On Mon, May 25, 2015 at 8:52 AM, Sylwester Petela <***@gmail.com> wrote:
>
>
> Getting rid of init script isn't good probably, as original driver in UGW
> passes the same commands (mostly) to dsl_control.

I _suspect_ that new firmware is detecting line parameters
automatically. If this is true then keeping such "magic" values in
configuration might actually decrease compatibility for some users (if
driver is somehow using them anyway). This needs testing.

> Firmware dir is also in original UGW init script, moving it from config to
> init doesn't make any difference.

This isn't crucial. I was just wondering if /etc/network/config is the
most logical place for it.

> What You have missed is that driver needs to be universal, vrx supports ADSL
> as well, annex a/b lines, it can be tuned to have better performance but not
> without getting rid of its "universality".

That's why I think we should stick to TP-LINK firmware as default.
it's not customized for any ISP in particular.
As for tunning: For now it does not seem that we can adjust any
parameters that would noticeably improve performance on one ISP while
breaking support for another. (SNR margin adjustment comes to mind,
but it's ISP-agnostic). Presence of some features improve xDSL
performance but it all happens in firmware anyway, which we get as
binary blob and can do nothing with it. Everything that can be done is
probably there by default or is enforced by DSLAM.
Martin Blumenstingl
2015-05-25 11:34:25 UTC
Permalink
On Sun, May 24, 2015 at 9:47 PM, Sylwester Petela <***@gmail.com> wrote:
> Packages/tar files from DrayTek GPL
Thank you SO much for this hint!
Just for the reference - the original download link for this is: [0]

I have taken those sources (as they contain the complete build system)
and updated my patch: [1]
The original tarballs can be found here: [2], [3], [4]

It seems that there are two more versions in the vigor 2760 tarball,
both having "ugw511" in their name.
Does anyone know if those should be used instead of the "normal" versions?

Maybe you and Aleksander can try this patch again?

Regards,
Martin


[0] http://gplsource.draytek.com/Vigor2760/v2760_v1212_GPL_release.tar.bz2
[1] https://gist.github.com/xdarklight/2986587133d97892a4b3/download
[2] http://filebin.ca/22vnTBiPZGVT/drv_dsl_cpe_api_vrx-4.15.2.tar.gz
[3] http://filebin.ca/22vnUkVF56Ep/drv_mei_cpe-1.4.1.tar.gz
[4] http://filebin.ca/22vnWceEtRCR/dsl_cpe_control_vrx-4.15.2.tar.gz
[5] http://filebin.ca/22w5lADvJHn0/drv_dsl_cpe_api_ugw511_vrx-4.15.2.tar.gz
[6] http://filebin.ca/22w5junG6FCc/dsl_cpe_control_ugw511_vrx-4.15.2.tar.gz

On Sun, May 24, 2015 at 6:04 PM, Martin Blumenstingl
<***@googlemail.com> wrote:
>> Waiting impatiently for this new patch. For now I can say that I have
>> problems with old driver combined with newest TP-LINK dsl firmware on
>> VDSL line. Once I establish known working configuration I'll build fw
>> with latest driver and test again.
> New patch is ready: [0]
>
> Let me know if VDSL works with this driver for you.
> Then we can think of how to get the new version into OpenWrt.
>
>
> [0] https://gist.github.com/xdarklight/2986587133d97892a4b3/download
Aleksander Wałęski
2015-05-25 14:08:02 UTC
Permalink
On Mon, May 25, 2015 at 1:34 PM, Martin Blumenstingl
<***@googlemail.com> wrote:

> I have taken those sources (as they contain the complete build system)
> and updated my patch: [1]
> The original tarballs can be found here: [2], [3], [4]
>
> It seems that there are two more versions in the vigor 2760 tarball,
> both having "ugw511" in their name.
> Does anyone know if those should be used instead of the "normal" versions?

Running diff between the two versions (both cpe_control and driver) it
seems that it adds support for remotely changing xDSL mode and
requesting system reboot over DSL link. Seems to be DrayTek's way of
doing autoconfiguration. I don't know if this is generic DSL feature
or is it meant for some specific ISP but it probably needs matching
firmware and definitely userspace support. It's probably safe to
include it in openwrt but I doubt that anyone will make use of this,
especially knowing that those functions might disappear from the API
if we get newer driver source from elsewhere.


> Maybe you and Aleksander can try this patch again?

Sure, I'll flash my device with this and let it run for some time to
see if there are any problems.

>
>
Aleksander Wałęski
2015-05-27 19:20:46 UTC
Permalink
On Mon, May 25, 2015 at 4:08 PM, Aleksander Wałęski <***@gmail.com> wrote:

>> Maybe you and Aleksander can try this patch again?
>
> Sure, I'll flash my device with this and let it run for some time to
> see if there are any problems.
>
Ok, I tested your latest patch and everything seems to work but I
suggest following build flag changes (which I tested in my build):

add --enable-debug-prints=err to ltq-vdsl-app and change
enable-debug-prints to err in ltq-vdsl-vr9. Default debug level in api
seems to be higher, thats why it caused so much spam in kernel log.
"err" seems to be fine. I didn't notice any messages in dmesg during
normal operation nor any other side effects to this. And it might
provide very useful info if something goes wrong. This is much more
important for vdsl_cpe_control app, and that is the reason why I
started to mess with compilation flags to begin with. with debug
prints disabled it strips all help text in the console which makes
playing with it somewhat frustrating. Here is an example of output of
the same command with debug-prints=off on ltq-vdsl-app:


DSL_CPE#>acos
nReturn=-1 (wrong number of parameters/help not available)


and with debug-prints=err


DSL_CPE#>acos
Long Form: AutobootConfigOptionSet
Short Form: acos

Input Parameter
- DSL_boolean_t bWaitBeforeConfigWrite
false = 0
true = 1
- DSL_boolean_t bWaitBeforeLinkActivation
false = 0
true = 1
- DSL_boolean_t bWaitBeforeRestart
false = 0
true = 1
- DSL_boolean_t bAutoContinueWaitBeforeConfigWrite (dsl_cpe_control)
false = 0
true = 1
- DSL_boolean_t bAutoContinueWaitBeforeLinkActivation (dsl_cpe_control)
false = 0
true = 1
- DSL_boolean_t bAutoContinueWaitBeforeRestart (dsl_cpe_control)
false = 0
true = 1

Output Parameter
- DSL_Error_t nReturn


Additionally, I added --disable-dsl-ceoc to ltq-vdsl-app since CEOC is
disabled in API by default anyway.


Again, can someone with ADSL line test what parameters
vdsl_cpe_control actually needs to operate with newest driver and
firmware version (from W9980)? I accidentally compiled driver with
high debbuging level at one point and got this in kernel log:

========== Port Mode Control (default) ===========
[ 438.848000]
[ 438.848000] Dual Port Lock : UNLOCKED
xDSL Mode Lock : UNLOCKED
[ 438.848000]
[ 438.848000] Preferred Port Mode : SINGLE
Preferred xDSL Mode : VDSL
[ 438.848000]
[ 438.848000] Current Port Mode : NONE
Current xDSL Mode : NONE
[ 438.848000]
[ 438.848000]
==================================================
[ 438.848000]
========== Port Mode Control (current) ===========
[ 438.848000]
[ 438.848000] Dual Port Lock : LOCKED
xDSL Mode Lock : LOCKED
[ 438.848000]
[ 438.848000] Preferred Port Mode : SINGLE
Preferred xDSL Mode : VDSL
[ 438.848000]
[ 438.848000] Current Port Mode : SINGLE
Current xDSL Mode : VDSL
[ 438.848000]
[ 438.848000]
==================================================

This makes me wonder if maybe TP-LINK firmware is just prepared to
support VDSL by default, but needs a startup parameter to support
ADSL. I still don't think it needs "low level config" though. It makes
sense not to require end user to know annex/tone group connection
requires.
Martin Blumenstingl
2015-06-01 21:32:42 UTC
Permalink
Hi Aleksander,

On Wed, May 27, 2015 at 9:20 PM, Aleksander Wałęski <***@gmail.com> wrote:
> add --enable-debug-prints=err to ltq-vdsl-app and change
> enable-debug-prints to err in ltq-vdsl-vr9.
> ...
> Additionally, I added --disable-dsl-ceoc to ltq-vdsl-app since CEOC is
> disabled in API by default anyway.
Thanks for the explanation. Here's the updated patch (I didn't have
time to test if myself yet though): [0]

> Again, can someone with ADSL line test what parameters
> vdsl_cpe_control actually needs to operate with newest driver and
> firmware version (from W9980)?
I can test it this weekend on an Annex B ADSL connection. So I will
test with firmware 1e472dad0eda88281af7c00cd3f49fcc29d4fa83 or
186b5406e6511c97d997b48f5e0ec5ad3f62600d (see [1]).


Regards,
Martin


[0] https://gist.github.com/xdarklight/2986587133d97892a4b3
[1] https://xdarklight.github.io/lantiq-xdsl-firmware-info/
Aleksander Wałęski
2015-06-01 23:54:01 UTC
Permalink
Thanks for answer. I cannot unfortunately test new patch right away,
because I sort of put this device "in production" but if it is only
compilation flags that changed that I am sure it works. I suspected
some kind of memory leak, because driver control process is quite
heavy on memory but it does not seem to grow any larger than about 7MB
(4 days uptime, steady size for at least 2 days).

As for firmware: you got me interested when you mentioned Annex B. I
was sure that W9980 was multi-annex and that its firmware should
support this, but I was wrong. TD-W9980B seems to be made to address
this. There isn't very much information on it on TP-LINK website, but
I was able to google it
http://www.tplink.com/be/products/details/?model=TD-W9980B (Belgian
section, but website is in English). There is firmware update
available for it, but strangely, only on German website
http://www.tp-link.de/support/download/?model=TD-W9980B&version=V1
Extraction procedure is exactly the same as for regular TD-W9980.
Details of firmware file inside:

filename: xcpe_573E16_571502_ISDN.bin
version: 5.7.3.E.1.6-5.7.1.5.0.2
sha1sum: 83c2b3d7e980d4f20e85ba3e9d6f557752006ec9
filesize: 904516
Firmware1:
PLATFORM: 5
PLATFORM_STR: VRX200
APPLICATION_TYPE: 6
APPLICATION_TYPE_STR: VDSL over IDSN
VERSION_STR: 7.3.E
RELEASE_STATUS: 1
RELEASE_STATUS_STR: Pre-Release
Firmware2:
PLATFORM: 5
PLATFORM_STR: VRX200
APPLICATION_TYPE: 2
APPLICATION_TYPE_STR: ADSL Annex B
VERSION_STR: 7.1.5
RELEASE_STATUS: 0
RELEASE_STATUS_STR: Release

Difference between this and 186b5406e6511c97d997b48f5e0ec5ad3f62600d
seem to be Vectoring support for VDSL (ADSL firmware version number is
the same). I was expecting only Annex difference, but this firmware
may be specifically tweaked for Germany ("# for DT/Germany market" in
vdsl.scr). I guess ADSL over ISDN is not very popular elsewhere.

On Mon, Jun 1, 2015 at 11:32 PM, Martin Blumenstingl
<***@googlemail.com> wrote:
> Hi Aleksander,
>
> On Wed, May 27, 2015 at 9:20 PM, Aleksander Wałęski <***@gmail.com> wrote:
>> add --enable-debug-prints=err to ltq-vdsl-app and change
>> enable-debug-prints to err in ltq-vdsl-vr9.
>> ...
>> Additionally, I added --disable-dsl-ceoc to ltq-vdsl-app since CEOC is
>> disabled in API by default anyway.
> Thanks for the explanation. Here's the updated patch (I didn't have
> time to test if myself yet though): [0]
>
>> Again, can someone with ADSL line test what parameters
>> vdsl_cpe_control actually needs to operate with newest driver and
>> firmware version (from W9980)?
> I can test it this weekend on an Annex B ADSL connection. So I will
> test with firmware 1e472dad0eda88281af7c00cd3f49fcc29d4fa83 or
> 186b5406e6511c97d997b48f5e0ec5ad3f62600d (see [1]).
>
>
> Regards,
> Martin
>
>
> [0] https://gist.github.com/xdarklight/2986587133d97892a4b3
> [1] https://xdarklight.github.io/lantiq-xdsl-firmware-info/
Martin Blumenstingl
2015-06-04 20:30:26 UTC
Permalink
On Tue, Jun 2, 2015 at 1:54 AM, Aleksander Wałęski <***@gmail.com> wrote:
> Extraction procedure is exactly the same as for regular TD-W9980.
Thanks, I have it that this afternoon.

> I was expecting only Annex difference, but this firmware
> may be specifically tweaked for Germany ("# for DT/Germany market" in
> vdsl.scr). I guess ADSL over ISDN is not very popular elsewhere.
Yes, Germany is a bit special regarding this...


> On Mon, Jun 1, 2015 at 11:32 PM, Martin Blumenstingl
> <***@googlemail.com> wrote:
>> I can test it this weekend on an Annex B ADSL connection. So I will
>> test with firmware 1e472dad0eda88281af7c00cd3f49fcc29d4fa83 or
>> 186b5406e6511c97d997b48f5e0ec5ad3f62600d (see [1]).
I was able to test those two today: both are working fine on my ADSL2+
Annex B connection - I did not notice any difference between them.

I have also updated my patch once again: [0].
It does not spam my dmesg, device is still responsive. However, I
cannot say anything regarding stability yet. Let's wait a few days...


Regards,
Martin


[0] https://gist.github.com/xdarklight/2986587133d97892a4b3
Aleksander Wałęski
2015-06-05 02:56:41 UTC
Permalink
Try playing with /etc/init.d/dsl_control when you'll have a moment to
spare to see if all parameters it passes to control application are
necessary. Selecting between ADSL and VDSL may be necessary but
firmware for ADSL seems to be annex-specific and I think that each
step we can make towards simplifying configuration will be welcomed.

On Thu, Jun 4, 2015 at 10:30 PM, Martin Blumenstingl
<***@googlemail.com> wrote:
> On Tue, Jun 2, 2015 at 1:54 AM, Aleksander Wałęski <***@gmail.com> wrote:
>> Extraction procedure is exactly the same as for regular TD-W9980.
> Thanks, I have it that this afternoon.
>
>> I was expecting only Annex difference, but this firmware
>> may be specifically tweaked for Germany ("# for DT/Germany market" in
>> vdsl.scr). I guess ADSL over ISDN is not very popular elsewhere.
> Yes, Germany is a bit special regarding this...
>
>
>> On Mon, Jun 1, 2015 at 11:32 PM, Martin Blumenstingl
>> <***@googlemail.com> wrote:
>>> I can test it this weekend on an Annex B ADSL connection. So I will
>>> test with firmware 1e472dad0eda88281af7c00cd3f49fcc29d4fa83 or
>>> 186b5406e6511c97d997b48f5e0ec5ad3f62600d (see [1]).
> I was able to test those two today: both are working fine on my ADSL2+
> Annex B connection - I did not notice any difference between them.
>
> I have also updated my patch once again: [0].
> It does not spam my dmesg, device is still responsive. However, I
> cannot say anything regarding stability yet. Let's wait a few days...
>
>
> Regards,
> Martin
>
>
> [0] https://gist.github.com/xdarklight/2986587133d97892a4b3
Martin Blumenstingl
2015-06-05 08:59:56 UTC
Permalink
On Fri, Jun 5, 2015 at 4:56 AM, Aleksander Wałęski <***@gmail.com> wrote:
> Try playing with /etc/init.d/dsl_control when you'll have a moment to
> spare to see if all parameters it passes to control application are
> necessary. Selecting between ADSL and VDSL may be necessary but
> firmware for ADSL seems to be annex-specific and I think that each
> step we can make towards simplifying configuration will be welcomed.
I'm hoping to have time for this on Saturday, because starting on
Monday my connection will be upgraded to VDSL.

For your own tests: please make sure you restart the device every time
you change /etc/init.d/dsl_control. At least the old driver (4.11.4) didn't
allow changing some values (after vdsl_cpe_control passed the values
to the kernel driver, it silently ignored any change to those values).


Regards,
Martin
Martin Blumenstingl
2015-06-06 11:49:32 UTC
Permalink
On Fri, Jun 5, 2015 at 4:56 AM, Aleksander Wałęski <***@gmail.com> wrote:
> Try playing with /etc/init.d/dsl_control when you'll have a moment to
> spare to see if all parameters it passes to control application are
> necessary.
It seems that the lowlevel configuration is indeed not required
anymore.
Removing the "autoboot" configurations also did not make any
difference.
DSL is still coming up fine, and still syncing at the same speed.

I have updated my patch yet again: [0]

Maybe you can give it a go again with your VDSL connection?
Someone testing with ADSL and Annex A would be good as
well.


[0] https://gist.github.com/xdarklight/2986587133d97892a4b3
Aleksander Wałęski
2015-06-06 12:05:51 UTC
Permalink
As I mentioned earlier I am already running with very minimal
configuration. My control process parameters list looks like this:

/sbin/vdsl_cpe_control -i -n /sbin/dsl_notify.sh -f
/lib/firmware/vdsl.bin -A /lib/firmware/vdsl.scr

-i is required, but actual initialization bits are not (in my case).
As far as I know this selects operation mode of the firmware
(VDSL/ADSL). Not sure if firmware can autodetect this, or if it just
defaults to VDSL.

I am passing -A vdsl autoboot script just for peace of mind (it was
included with firmware). My connection seems to work exactly the same
without it.

We indeed could use some more testing. Preferably not only on
different annexes but different ISPs as well.

On Sat, Jun 6, 2015 at 1:49 PM, Martin Blumenstingl
<***@googlemail.com> wrote:
> On Fri, Jun 5, 2015 at 4:56 AM, Aleksander Wałęski <***@gmail.com> wrote:
>> Try playing with /etc/init.d/dsl_control when you'll have a moment to
>> spare to see if all parameters it passes to control application are
>> necessary.
> It seems that the lowlevel configuration is indeed not required
> anymore.
> Removing the "autoboot" configurations also did not make any
> difference.
> DSL is still coming up fine, and still syncing at the same speed.
>
> I have updated my patch yet again: [0]
>
> Maybe you can give it a go again with your VDSL connection?
> Someone testing with ADSL and Annex A would be good as
> well.
>
>
> [0] https://gist.github.com/xdarklight/2986587133d97892a4b3
Sylwester Petela
2015-06-06 13:23:07 UTC
Permalink
W dniu 2015-06-06 o 14:18, Aleksander Wałęski pisze:
> Interesting. Have you made a note of which parameter made such a
> difference? I guess disabling ReTx could potentially cause lower sync
> speeds because DSLAM needs to compensate for lack of retransmissions.
> It may be enabled/disabled in autoboot script as it is in latest
> TP-LINK firmware.
> Vectroring needs firmware to have it enabled, but its VDSL2-only
> feature anyway so it shouldn't cause issues for you. Bonding does not
> seem to be supported by the driver (yet).
>
> Router's performance change with time worries me a bit. Are you sure
> it is DSL part that is slowing it down? I have 9 days uptime at this
> point and have not noticed any slowdowns yet.

As for speed, yes only DSL is affected. LAN -> WLAN and overall (USB/3G)
performance is same, bit higher CPU usage but cannot trace it by top,
ram a bit but that because driver is bit bigger.

ReTx on ADSL isn't used so I don't know if driver tries to do something
that it can't do.

What intriges me is that only two options (except low-level init) are
different VDSL / ADSL related in init scripts delivered with original
driver package:


if [ "$wanphy_phymode" = "0" -o "$wanphy_phymode" = "3" ]; then
# If BitSwap is disabled, or Retransmission is enabled
# then set the DSL Parameters accordingly
if [ "$BS_ENA" != "1" ]; then
dir="0 1"
for j in $dir ; do
LFCG_VALS=`${BIN_DIR}/dsl_cpe_pipe.sh lfcg $j`
if [ "$?" = "0" ]; then
for i in $LFCG_VALS; do eval $i 2>/dev/null; done
${BIN_DIR}/dsl_cpe_pipe.sh lfcs $nDirection \
$bTrellisEnable $BS_ENA $RETX_ENA
$bVirtualNoiseSupport \
$b20BitSupport >/dev/null
else
if [ "$j" = "0" ]; then
${BIN_DIR}/dsl_cpe_pipe.sh lfcs $j 1 $BS_ENA
$RETX_ENA \
0 -1 >/dev/null
else
${BIN_DIR}/dsl_cpe_pipe.sh lfcs $j 1 $BS_ENA
$RETX_ENA \
0 0 >/dev/null
fi
fi
done

After 9 days and bit of performance drop I reverted back to stripped out
init script and also lowered debug level to default so I can track what
is causing these issues.

> On Fri, Jun 5, 2015 at 9:27 AM, Sylwester Petela <***@gmail.com> wrote:
>>
>> W dniu 2015-06-05 o 04:56, Aleksander Wałęski pisze:
>>> Try playing with /etc/init.d/dsl_control when you'll have a moment to
>>> spare to see if all parameters it passes to control application are
>>> necessary. Selecting between ADSL and VDSL may be necessary but
>>> firmware for ADSL seems to be annex-specific and I think that each
>>> step we can make towards simplifying configuration will be welcomed.
>>
>> There are more parameters required then only dsl_control passes, low_level
>> config, ReTx, Bonding, Vectoring.
>>
>> Getting rid of these gave me two things:
>>
>> 1. slower 1 synch (full_init -> exception -> full_init)
>> 2. after couple of days (8d 0h 9m 30s) router is less responsive then at the
>> beginning, d/u speed is also affected.
>>
>> Tested on Annex A line ATM, compared to normal dsl_control with only higher
>> debug level (it consumes bit more RAM then lower debug level).
>>
>> Conclusion: maybe on VDSL line these values have margin usage but ReTx or
>> Vectoring on Annex A ADSL line is bit to much to driver.
>>
>>> On Thu, Jun 4, 2015 at 10:30 PM, Martin Blumenstingl
>>> <***@googlemail.com> wrote:
>>>> On Tue, Jun 2, 2015 at 1:54 AM, Aleksander Wałęski <***@gmail.com>
>>>> wrote:
>>>>> Extraction procedure is exactly the same as for regular TD-W9980.
>>>> Thanks, I have it that this afternoon.
>>>>
>>>>> I was expecting only Annex difference, but this firmware
>>>>> may be specifically tweaked for Germany ("# for DT/Germany market" in
>>>>> vdsl.scr). I guess ADSL over ISDN is not very popular elsewhere.
>>>> Yes, Germany is a bit special regarding this...
>>>>
>>>>
>>>>> On Mon, Jun 1, 2015 at 11:32 PM, Martin Blumenstingl
>>>>> <***@googlemail.com> wrote:
>>>>>> I can test it this weekend on an Annex B ADSL connection. So I will
>>>>>> test with firmware 1e472dad0eda88281af7c00cd3f49fcc29d4fa83 or
>>>>>> 186b5406e6511c97d997b48f5e0ec5ad3f62600d (see [1]).
>>>> I was able to test those two today: both are working fine on my ADSL2+
>>>> Annex B connection - I did not notice any difference between them.
>>>>
>>>> I have also updated my patch once again: [0].
>>>> It does not spam my dmesg, device is still responsive. However, I
>>>> cannot say anything regarding stability yet. Let's wait a few days...
>>>>
>>>>
>>>> Regards,
>>>> Martin
>>>>
>>>>
>>>> [0] https://gist.github.com/xdarklight/2986587133d97892a4b3
>>
Martin Blumenstingl
2015-06-28 00:02:36 UTC
Permalink
On Sat, Jun 6, 2015 at 3:23 PM, Sylwester Petela <***@gmail.com> wrote:
> After 9 days and bit of performance drop I reverted back to stripped out
> init script and also lowered debug level to default so I can track what is
> causing these issues.
If it is a driver issue then you can test the new version (more info below).

A few days ago I got a new set of DSL drivers - version 4.16.2.4 to be exact.
I am writing this very email while connected with that updated driver.
(this is with firmware
5.7.3.3.0.7-5.7.1.5.0.2 / 186b5406e6511c97d997b48f5e0ec5ad3f62600d on
a VDSL line).

The patch for updating the DSL driver can be found here: [0]
Please note that it depends on [1]

Regards,
Martin


[0] https://gist.github.com/xdarklight/3452b26620b28f3bc577
[1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-June/033911.html
Aleksander Wałęski
2015-07-10 17:31:18 UTC
Permalink
Hello Martin,

I've just applied your patch against trunk (r46292) and flashed this
firmware. Unfortunately linked patch did not apply cleanly because
some of your changes were accepted into openwrt trunk. I was able to
fix it locally but I hope you will update your patch for others to
test it. So far new driver seems to run smoothly but I'll give it some
time. I have HUGE problems with wifi but I don't think it's related to
lantiq stuff

On Sun, Jun 28, 2015 at 2:02 AM, Martin Blumenstingl
<***@googlemail.com> wrote:
> On Sat, Jun 6, 2015 at 3:23 PM, Sylwester Petela <***@gmail.com> wrote:
>> After 9 days and bit of performance drop I reverted back to stripped out
>> init script and also lowered debug level to default so I can track what is
>> causing these issues.
> If it is a driver issue then you can test the new version (more info below).
>
> A few days ago I got a new set of DSL drivers - version 4.16.2.4 to be exact.
> I am writing this very email while connected with that updated driver.
> (this is with firmware
> 5.7.3.3.0.7-5.7.1.5.0.2 / 186b5406e6511c97d997b48f5e0ec5ad3f62600d on
> a VDSL line).
>
> The patch for updating the DSL driver can be found here: [0]
> Please note that it depends on [1]
>
> Regards,
> Martin
>
>
> [0] https://gist.github.com/xdarklight/3452b26620b28f3bc577
> [1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-June/033911.html
Sylwester Petela
2015-07-11 07:39:02 UTC
Permalink
Where did You get/find v4.16.2.4 packages ?

W dniu 2015-07-10 o 19:31, Aleksander Wałęski pisze:
> Hello Martin,
>
> I've just applied your patch against trunk (r46292) and flashed this
> firmware. Unfortunately linked patch did not apply cleanly because
> some of your changes were accepted into openwrt trunk. I was able to
> fix it locally but I hope you will update your patch for others to
> test it. So far new driver seems to run smoothly but I'll give it some
> time. I have HUGE problems with wifi but I don't think it's related to
> lantiq stuff
>
> On Sun, Jun 28, 2015 at 2:02 AM, Martin Blumenstingl
> <***@googlemail.com> wrote:
>> On Sat, Jun 6, 2015 at 3:23 PM, Sylwester Petela <***@gmail.com> wrote:
>>> After 9 days and bit of performance drop I reverted back to stripped out
>>> init script and also lowered debug level to default so I can track what is
>>> causing these issues.
>> If it is a driver issue then you can test the new version (more info below).
>>
>> A few days ago I got a new set of DSL drivers - version 4.16.2.4 to be exact.
>> I am writing this very email while connected with that updated driver.
>> (this is with firmware
>> 5.7.3.3.0.7-5.7.1.5.0.2 / 186b5406e6511c97d997b48f5e0ec5ad3f62600d on
>> a VDSL line).
>>
>> The patch for updating the DSL driver can be found here: [0]
>> Please note that it depends on [1]
>>
>> Regards,
>> Martin
>>
>>
>> [0] https://gist.github.com/xdarklight/3452b26620b28f3bc577
>> [1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-June/033911.html
Martin Blumenstingl
2015-07-12 13:44:29 UTC
Permalink
Hi,

On Sat, Jul 11, 2015 at 9:39 AM, Sylwester Petela <***@gmail.com> wrote:
> Where did You get/find v4.16.2.4 packages ?
Someone with access to lantiq's "UGW" replied last month on the
mailing list and sent me the updated package versions.

Since my latest patches were merged into the OpenWrt repository the
patch which updates the lantiq DSL drivers/application did not apply
anymore.
Here is the updated patch which applies against today's trunk: [0]

Regards,
Martin


[0] https://gist.github.com/xdarklight/3452b26620b28f3bc577
Andre Heider
2015-07-23 21:32:55 UTC
Permalink
Hi Martin,

On Sun, Jul 12, 2015 at 3:44 PM, Martin Blumenstingl
<***@googlemail.com> wrote:
> Since my latest patches were merged into the OpenWrt repository the
> patch which updates the lantiq DSL drivers/application did not apply
> anymore.
> Here is the updated patch which applies against today's trunk: [0]
>
> Regards,
> Martin
>
>
> [0] https://gist.github.com/xdarklight/3452b26620b28f3bc577

over the course of this thread you mentioned having a similar setup as
I do, so maybe you can help me out as I didn't yet get this working
(neither did I without this patch and a couple of firmware versions):

* I got a TDW8970 (non B version). If I understood correctly this is
annex a as far as the official firmware is concerned, but with openwrt
and the correct dsl firmware I can use this with annex b, right?
* I got a german adsl annex b line
* I'm using yesterday's trunk (b8bbdc62, which already has 703c4da0
'lantiq: Make the MEI address available for kernel drivers') with your
patch quoted above on top
* I'm using firmware 186b5406e6511c97d997b48f5e0ec5ad3f62600d

The dsl line never syncs, and letting 'vdsl_cpe_control --c' just sit
there spits out repeatedly:
'DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used!
Please change one of it.'.

This sounds like an annex incompability? Was I wrong and there is a
hardware difference and I cannot use the non B model with annex b?

Thanks in advance,
Andre
Martin Blumenstingl
2015-07-23 21:51:33 UTC
Permalink
Hi Andre,

On Thu, Jul 23, 2015 at 11:32 PM, Andre Heider <***@gmail.com> wrote:
> The dsl line never syncs, and letting 'vdsl_cpe_control --c' just sit
> there spits out repeatedly:
> 'DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used!
> Please change one of it.'.
At some point during my tests I got a second device (an Arcadyan
VGV7510KW22 - which came as "Annex B" device from the factory). Using
the very same config made this device sync fine.

> This sounds like an annex incompability? Was I wrong and there is a
> hardware difference and I cannot use the non B model with annex b?
Indeed, I have read multiple times that the DSL modem should support
all annexes - but as our tests have shown: it doesn't (at least for
ADSL). My guess is that the modem physically supports it but there's a
bootstrap pin (to which a resistor is soldered... or not) which
configures it to be Annex A *or* B only.
The interesting part: VDSL is not affected by this (all ISPs in all
countries seem to use VDSL over ISDN). I am using an Annex A device on
a German VDSL line and this is working fine.

bottom line: it seems that the modems are bound to a specific annex
for ADSL operation.


Regards,
Martin
Alexander Couzens
2015-07-23 22:03:06 UTC
Permalink
On Thu, 23 Jul 2015 23:51:33 +0200
Martin Blumenstingl <***@googlemail.com> wrote:

> Hi Andre,
>
> On Thu, Jul 23, 2015 at 11:32 PM, Andre Heider <***@gmail.com> wrote:
> > The dsl line never syncs, and letting 'vdsl_cpe_control --c' just sit
> > there spits out repeatedly:
> > 'DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used!
> > Please change one of it.'.
> At some point during my tests I got a second device (an Arcadyan
> VGV7510KW22 - which came as "Annex B" device from the factory). Using
> the very same config made this device sync fine.
>
> > This sounds like an annex incompability? Was I wrong and there is a
> > hardware difference and I cannot use the non B model with annex b?
> Indeed, I have read multiple times that the DSL modem should support
> all annexes - but as our tests have shown: it doesn't (at least for
> ADSL). My guess is that the modem physically supports it but there's a
> bootstrap pin (to which a resistor is soldered... or not) which
> configures it to be Annex A *or* B only.
> The interesting part: VDSL is not affected by this (all ISPs in all
> countries seem to use VDSL over ISDN). I am using an Annex A device on
> a German VDSL line and this is working fine.
>
> bottom line: it seems that the modems are bound to a specific annex
> for ADSL operation.
I've seen the same. With annex b device, same firmware, the modem syncs to adsl, with annex a not. vdsl is working unrelated to the annex (B on A and vice versa is working).
If someone would like to search for differences on the pcb, I can make photos of both pcbs.

best,
lynxis
--
Alexander Couzens

mail: ***@fe80.eu
jabber: ***@jabber.ccc.de
mobile: +4915123277221
Andre Heider
2015-07-23 22:24:43 UTC
Permalink
Hi Alexander,

On Fri, Jul 24, 2015 at 12:03 AM, Alexander Couzens <***@fe80.eu> wrote:
> If someone would like to search for differences on the pcb, I can make photos of both pcbs.

soldering rx, tx and gnd on a pcb for a serial connection is as far as
my hardware skills go, but maybe we can figure out the differences
together ;)

If you find the time, could you attach photos to the wiki page?
If we figure anything out I'm willing to attempt an annex change on my router.

Regards,
Andre
Aleksander Wałęski
2015-07-23 22:55:05 UTC
Permalink
> If someone would like to search for differences on the pcb, I can make photos of both pcbs.

Please do, it might be interesting. Also, if they are not identical
(except for ADSL annex) it might be very difficult to find relevant
differences.
It sort of does not make sense to me that the only difference
hardware-wise would be pcb jumper. You would think that company like
TP-Link is trying very hard to save money where they can. They already
have different firmware for "B" versions (W8970B W8980B) so why not
use some spare GPIO to pull front-end configuration pin to state in
which it has to be (if this is really whats happening). You might say
that it's protection against cross flashing firmware from the other
model but it is already possible to crossflash W8980 to W9980 without
any hardware changes. Why not protect against that? Another theory is
that Lantiq might be enforcing such implementation on manufacturers
but it is also unlikely for me. All the other settings seem to be
changed only by firmware updates. Why not this one?
https://en.wikipedia.org/wiki/Asymmetric_digital_subscriber_line#/media/File:ADSL_annex_overview.svg
Looking at this graph it seems plausible that there is some kind of
additional high-pass filter before front-end or entirely different
chip adapted to upstream transmission on slightly higher frequency for
Annex B. However, w8970 in my country is advertised as supporting ALL
BUT Annex B in this graph and thus needs to cover full bandwidth.
Aleksander Wałęski
2015-07-23 23:00:28 UTC
Permalink
On Fri, Jul 24, 2015 at 12:55 AM, Aleksander Wałęski <***@gmail.com> wrote:

> so why not
> use some spare GPIO to pull front-end configuration pin to state in
> which it has to be

Actually, it just dawned on me that they can be doing just that. In
the bootloader. This is the only part of firmware we are not changing.
If PCBs turn out to be identical we might want to check this.
Martin Blumenstingl
2015-07-23 23:20:06 UTC
Permalink
On Fri, Jul 24, 2015 at 1:00 AM, Aleksander Wałęski <***@gmail.com> wrote:
> Actually, it just dawned on me that they can be doing just that. In
> the bootloader. This is the only part of firmware we are not changing.
> If PCBs turn out to be identical we might want to check this.
That was my first guess, but I am using the open source u-boot version
on the BT Home Hub 5A (= Annex A device) and it still refuses to
connect to Annex B (at least back when I tried last, I switched to
VDSL like two months ago).

If you can figure out where the boot_sel pins are (similar to [0] or
[1]) to get it into CFG04 mode (= boot via UART) then I can add a
patch for Daniel Schwierzeck's open source lantiq u-boot. But be
aware: you need to pull some of them HIGH (= 3.3V, *NOT* 5V) - you
could damage your device by pulling the wrong pin HIGH.


Regards,
Martin


[0] http://wiki.openwrt.org/toh/arcadyan/vgv7510kw22
[1] http://wiki.openwrt.org/toh/bt/homehub_v5a
Mathias Kresin
2015-08-15 21:38:37 UTC
Permalink
Am 24.07.2015 um 01:20 schrieb Martin Blumenstingl:
> On Fri, Jul 24, 2015 at 1:00 AM, Aleksander Wałęski <***@gmail.com> wrote:
>> Actually, it just dawned on me that they can be doing just that. In
>> the bootloader. This is the only part of firmware we are not changing.
>> If PCBs turn out to be identical we might want to check this.
> That was my first guess, but I am using the open source u-boot version
> on the BT Home Hub 5A (= Annex A device) and it still refuses to
> connect to Annex B (at least back when I tried last, I switched to
> VDSL like two months ago).

I can confirm that it is unrelated to the bootloader. I crossflashed my
Annex A W8980v1 with the W9980B (Annex B) firmware. During crossflash,
the bootloader is updated as well. Afterwards, I do get exactly the same
error message as Andre:

xDSL Leave SHOWTIME!!
DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used!
Please change one of it.
nReturn=0 nData="E843 0003 0001 0009 "
nReturn=0 nData="5048 0000 0001 "
nReturn=0 nData="1762 0000 0001 "

I did not connected the device to an Annex B ADSL line yet, but I guess
the result will be the same.

Furthermore, I replaced the content of ***@f200 (@f100 is the device
mac address stored) and mtd5 with a bunch of 0x11, to test for a magic
value, that is read from there. U-boot replaces the content of mtd5 with
the ddr params right after reboot and neither the error message changes
if a W9980B firmware is booted, nor an error message appears if a W9980
firmware is booted. The content of mtd6 seams to be unrelated to me,
since it contains the ath calibration data.

I share Daniels guess, that there could be a resistor, which locks the
VRX208 to Annex A/Annex B ADSL mode. As already mentioned, it's
unrelated to VDSL. My Annex B VDSL line works with the W9980B (and
properly W9980) firmware out of the box.

> If you can figure out where the boot_sel pins are (similar to [0] or
> [1]) to get it into CFG04 mode (= boot via UART) then I can add a
> patch for Daniel Schwierzeck's open source lantiq u-boot. But be
> aware: you need to pull some of them HIGH (= 3.3V, *NOT* 5V) - you
> could damage your device by pulling the wrong pin HIGH.

I found the location of the boot_sel pin and have updated the W8980v1
wiki page.

Mathias
John Crispin
2015-08-18 05:40:31 UTC
Permalink
Hi,

On 15/08/2015 23:38, Mathias Kresin wrote:
> Am 24.07.2015 um 01:20 schrieb Martin Blumenstingl:
>> On Fri, Jul 24, 2015 at 1:00 AM, Aleksander Wałęski
>> <***@gmail.com> wrote:
>>> Actually, it just dawned on me that they can be doing just that. In
>>> the bootloader. This is the only part of firmware we are not changing.
>>> If PCBs turn out to be identical we might want to check this.
>> That was my first guess, but I am using the open source u-boot version
>> on the BT Home Hub 5A (= Annex A device) and it still refuses to
>> connect to Annex B (at least back when I tried last, I switched to
>> VDSL like two months ago).
>
> I can confirm that it is unrelated to the bootloader. I crossflashed my
> Annex A W8980v1 with the W9980B (Annex B) firmware. During crossflash,
> the bootloader is updated as well. Afterwards, I do get exactly the same
> error message as Andre:
>
> xDSL Leave SHOWTIME!!
> DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used!

this line above says it all ... here is a bit of tech background.

Annex-A is when you run dsl on an analogue phone line
Annex-B is when you run dsl on a digital phone line

For this to work the dsl has a so called hybrid. consider it like a
frequency filter. The hybrid dictates which firmware is required and
what line you can run it on. running an annex-a unit will only ever work
with an annex-a firmware on a POTS line. a annex-b hybrid will require a
annex-b firmware and an ISDN line.

John


> Please change one of it.
> nReturn=0 nData="E843 0003 0001 0009 "
> nReturn=0 nData="5048 0000 0001 "
> nReturn=0 nData="1762 0000 0001 "
>
> I did not connected the device to an Annex B ADSL line yet, but I guess
> the result will be the same.
>
> Furthermore, I replaced the content of ***@f200 (@f100 is the device
> mac address stored) and mtd5 with a bunch of 0x11, to test for a magic
> value, that is read from there. U-boot replaces the content of mtd5 with
> the ddr params right after reboot and neither the error message changes
> if a W9980B firmware is booted, nor an error message appears if a W9980
> firmware is booted. The content of mtd6 seams to be unrelated to me,
> since it contains the ath calibration data.
>
> I share Daniels guess, that there could be a resistor, which locks the
> VRX208 to Annex A/Annex B ADSL mode. As already mentioned, it's
> unrelated to VDSL. My Annex B VDSL line works with the W9980B (and
> properly W9980) firmware out of the box.
>
>> If you can figure out where the boot_sel pins are (similar to [0] or
>> [1]) to get it into CFG04 mode (= boot via UART) then I can add a
>> patch for Daniel Schwierzeck's open source lantiq u-boot. But be
>> aware: you need to pull some of them HIGH (= 3.3V, *NOT* 5V) - you
>> could damage your device by pulling the wrong pin HIGH.
>
> I found the location of the boot_sel pin and have updated the W8980v1
> wiki page.
>
> Mathias
> _______________________________________________
> openwrt-devel mailing list
> openwrt-***@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Damian Kaczkowski
2017-07-10 12:06:21 UTC
Permalink
Hello all.

I have done some research regarding soft-switching DSL Annex. I got few
boards which are able to operate in Annex A or B without hardware mods of
the hybrid. Seems that dsl_control is able to send some commands to the DSL
PHY so it can sync with Annex A line while being equipped with Annex B DSL
transformer which is a part of hybrid I suppose. I have tested the
following boards:
- AVM/1&1 FRITZ!Box 7330 SL
- AVM/1&1 FRITZ!Box 7362 SL
- AVM/1&1 FRITZ!Box Fon WLAN 7320
- AVM/1&1 FRITZ!Box Fon WLAN 7360 SL
- AVM FRITZ!Box WLAN 3370

Non of them is "international edition". All are marked by vendor as Annex B
only editions and all of them are equipped with DSL transformers matched to
Lantiq Chips Annex B (that's what datasheets says).

They are equipped with the following DSL transformers:
UMEC UTB01930S 270uH, 2:1, Annex B, Supplementary For Lantiq’s XWAY™
VRX208 Chip (3370)
LinkCom LAL0530 270uH, 2:1, Annex B, Supplementary For Lantiq’s XWAY™
VRX208 Chip (7362 SL, 7360 SL)
VOGT unknown, unknown, Annex B, Suplementary for
Lantiq AR9 Chip (7320, 7330 SL)
MNC EP-832SG 1.4mH, 2:1, Annex A, Supplementary For Lantiq’s XWAY™
VRX208 Chip (TD-W8970V1, TD-W8980V1, TD-W9980V1)
MNC EP-833SG 270uH, 2:1, Annex B, Supplementary For Lantiq’s XWAY™
VRX208 Chip (TD-W8970BV1, TD-W8980BV1, TD-W9980BV1)

On Freetz firmware I was able to soft-switch all above AVM boards from
Annex B to Annex A and successfully sync to Annex A/M DSLAM/Line.

After switching firmware to LEDE/OpenWrt on those boards I am getting the
same error as Andre got on TP-LINKs:
'DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used! Please
change one of it.'.

To sum up:
Freetz OS loaded with LEDE DSL firmware sync without a problem. So the
problem is not the DSL firmware itself.
Hybrid is also not a problem cause on Freetz OS I have successfully sync
Annex B boards (soft-switched to Annex A) to Annex A line.

I have done numerous tests and come to conclusion that dsl_control and/or
driver implementation is the main problem and thing to focus on.

LEDE dsl_control is not able to start the DSL PHYs (with Annex B
transformers) loaded with Annex A firmware and sync them to Annex A line,
but the same boards sync fine with Freetz OS + Freetz dsl_control.

I spot that dsl_control on Freetz generates the adsl.cfg upon start. This
adsl.cfg is generated with different sets of commands according to selected
Annex.

adsl.cfg content differs between board models/generation. Similar boards
got the same adsl.cfg contents. This is probably due to different DSL
transformer or whole hybrid? I need to double check and confirm this to be
sure.

Here is an example of adsl.cfg file content generated on 7320 SL board:
For Annex B:
#AVM ADSL Annex B, generated by dsl_control
[WaitForConfiguration]={
sics 1 1 1 3
}
[WaitForLinkActivate]={
lfcs 1 1 1 1 0 0
}
[WaitForLinkActivate]={
lfcs 0 1 1 0 0 0
}
[WaitForLinkActivate]={
cw info 86 0 0x4801
}
[WaitForLinkActivate]={
avmcrmw optn 25 0 0x2000
}
[WaitForLinkActivate]={
cw cnfg 45 0 0xe
}
[WaitForLinkActivate]={
avmcrmw info 103 1 0x2000
}

For Annex A:
#AVM ADSL Annex A, generated by dsl_control
[WaitForConfiguration]={
sics 1 1 1 3
}
[WaitForLinkActivate]={
lfcs 1 1 1 1 0 0
}
[WaitForLinkActivate]={
lfcs 0 1 1 0 0 0
}
[WaitForLinkActivate]={
cw info 86 0 0x4801
}
[WaitForLinkActivate]={
avmcrmw optn 25 0 0x2000
}
[WaitForLinkActivate]={
cw cnfg 45 0 0xe
}
[WaitForLinkActivate]={
cw info 94 0 0x1467
}


Here is an example of adsl.cfg file content generated on 3370 board:
For Annex B:
#AVM ADSL Annex B
[WaitForLinkActivate]={
avmcrms info 103 1 0x2000
}
[WaitForLinkActivate]={
avmcrmr info 111 8 0010
}
[WaitForLinkActivate]={
avmcrms test 0 0 0x4000
}
[WaitForLinkActivate]={
avmcrms dsl 13 0 0x0002
}
[WaitForLinkActivate]={
avmcw cnfg 46 0 0xe
}
[WaitForLinkActivate]={
avmcrms info 111 8 0x0004
}
[WaitForLinkActivate]={
avmcrms dsl 13 0 0x0008
}

For Annex A:
#AVM ADSL Annex A
[WaitForLinkActivate]={
avmcrmr info 111 8 0010
}
[WaitForLinkActivate]={
avmcrms test 0 0 0x4000
}
[WaitForLinkActivate]={
avmcrms dsl 13 0 0x0002
}
[WaitForLinkActivate]={
avmcw cnfg 46 0 0xe
}
[WaitForLinkActivate]={
avmcw moni 5 0 0x204B
}
[WaitForLinkActivate]={
avmcw moni 5 1 0x0000
}
[WaitForLinkActivate]={
avmcrms info 111 8 0x0004
}
[WaitForLinkActivate]={
avmcrms dsl 13 0 0x0008
}


As you can see there are some AVM and non standard commands comparing to
LEDE/OpenWrt dsl_control flavour. Those are for eg.:
avmvig AVM_VersionInformationGet
avmcr AVM_CmvRead
avmcw AVM_CmvWrite
avmcrms AVM_CmvReadModifySet
avmcrmr AVM_CmvReadModifyReset
avmpet AVM_ProdEchoTest
avmhwrfit AVM_HWRFITest
avmdsmmcs AVM_DSM_MacConfigSet
cr CmvRead
cw CmvWrite


More can be found by looking into dsl_control file extracted from AVM
boards firmwares (Freetz buildroot can do that).
It also contains adsl.cfg commands if someone wants to debug this further
without access to the boards itself.

Example content of dsl_control:
avm_dsl_cli_DsmMacConfigSet
cw DSL_CPE_SCRIPT: CMV WR %s %d %d, value=0x%04x, retCode=%d
mw %s %s %s DSL_CPE_SCRIPT: Dbg Memory write address=%08x, value=%04x,
retCode=%d
dsl_control: mw %08x fail
mr dsl_control: error:mr parameter type mismatch!



Anyone got an idea or could spare a hint on how to debug what AVMs
dsl_control is actually doing/sending to the DSL PHY driver?

Could anyone with deep Lantiq knowledge look into this please? My knowledge
about Lantiq DSL tools/drivers ends here : (.

What needs to be done so the LEDE/OpenWrt dsl_control could also be able to
switch Annex on those and maybe other AR9/VR9 boards?


I can assist in some tests if you need. I also got all TP-Links VR9 boards
(both Annexes) plus some other AR9/VR9/AR10 boards and also an Annex A/M
ADSL/ADSL2+ DSLAMs (can't test VDSL right now).


Greets.
Damian Kaczkowski
2017-07-10 12:23:56 UTC
Permalink
Hello all.

I have done some research regarding soft-switching DSL Annex. I got
few boards which are able to operate in Annex A or B without hardware
mods of the hybrid. Seems that dsl_control is able to send some
commands to the DSL PHY so it can sync with Annex A line while being
equipped with Annex B DSL transformer which is a part of hybrid I
suppose. I have tested the following boards:
- AVM/1&1 FRITZ!Box 7330 SL
- AVM/1&1 FRITZ!Box 7362 SL
- AVM/1&1 FRITZ!Box Fon WLAN 7320
- AVM/1&1 FRITZ!Box Fon WLAN 7360 SL
- AVM FRITZ!Box WLAN 3370

Non of them is "international edition". All are marked by vendor as
Annex B only editions and all of them are equipped with DSL
transformers matched to Lantiq Chips Annex B (that's what datasheets
says).

They are equipped with the following DSL transformers:
UMEC UTB01930S 270uH, 2:1, Annex B, Supplementary For Lantiq’s
XWAY™ VRX208 Chip (3370)
LinkCom LAL0530 270uH, 2:1, Annex B, Supplementary For Lantiq’s
XWAY™ VRX208 Chip (7362 SL, 7360 SL)
VOGT unknown, unknown, Annex B, Suplementary
for Lantiq AR9 Chip (7320, 7330 SL)
MNC EP-832SG 1.4mH, 2:1, Annex A, Supplementary For Lantiq’s
XWAY™ VRX208 Chip (TD-W8970V1, TD-W8980V1, TD-W9980V1)
MNC EP-833SG 270uH, 2:1, Annex B, Supplementary For Lantiq’s
XWAY™ VRX208 Chip (TD-W8970BV1, TD-W8980BV1, TD-W9980BV1)

On Freetz firmware I was able to soft-switch all above AVM boards from
Annex B to Annex A and successfully sync to Annex A/M DSLAM/Line.

After switching firmware to LEDE/OpenWrt on those boards I am getting
the same error as Andre got on TP-LINKs:
'DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used!
Please change one of it.'.

To sum up:
Freetz OS loaded with LEDE DSL firmware sync without a problem. So the
problem is not the DSL firmware itself.
Hybrid is also not a problem cause on Freetz OS I have successfully
sync Annex B boards (soft-switched to Annex A) to Annex A line.

I have done numerous tests and come to conclusion that dsl_control
and/or driver implementation is the main problem and thing to focus
on.

LEDE dsl_control is not able to start the DSL PHYs (with Annex B
transformers) loaded with Annex A firmware and sync them to Annex A
line, but the same boards sync fine with Freetz OS + Freetz
dsl_control.

I spot that dsl_control on Freetz generates the adsl.cfg upon start.
This adsl.cfg is generated with different sets of commands according
to selected Annex.

adsl.cfg content differs between board models/generation. Similar
boards got the same adsl.cfg contents. This is probably due to
different DSL transformer or whole hybrid? I need to double check and
confirm this to be sure.

Here is an example of adsl.cfg file content generated on 7320 SL board:
For Annex B:
#AVM ADSL Annex B, generated by dsl_control
[WaitForConfiguration]={
sics 1 1 1 3
}
[WaitForLinkActivate]={
lfcs 1 1 1 1 0 0
}
[WaitForLinkActivate]={
lfcs 0 1 1 0 0 0
}
[WaitForLinkActivate]={
cw info 86 0 0x4801
}
[WaitForLinkActivate]={
avmcrmw optn 25 0 0x2000
}
[WaitForLinkActivate]={
cw cnfg 45 0 0xe
}
[WaitForLinkActivate]={
avmcrmw info 103 1 0x2000
}

For Annex A:
#AVM ADSL Annex A, generated by dsl_control
[WaitForConfiguration]={
sics 1 1 1 3
}
[WaitForLinkActivate]={
lfcs 1 1 1 1 0 0
}
[WaitForLinkActivate]={
lfcs 0 1 1 0 0 0
}
[WaitForLinkActivate]={
cw info 86 0 0x4801
}
[WaitForLinkActivate]={
avmcrmw optn 25 0 0x2000
}
[WaitForLinkActivate]={
cw cnfg 45 0 0xe
}
[WaitForLinkActivate]={
cw info 94 0 0x1467
}


Here is an example of adsl.cfg file content generated on 3370 board:
For Annex B:
#AVM ADSL Annex B
[WaitForLinkActivate]={
avmcrms info 103 1 0x2000
}
[WaitForLinkActivate]={
avmcrmr info 111 8 0010
}
[WaitForLinkActivate]={
avmcrms test 0 0 0x4000
}
[WaitForLinkActivate]={
avmcrms dsl 13 0 0x0002
}
[WaitForLinkActivate]={
avmcw cnfg 46 0 0xe
}
[WaitForLinkActivate]={
avmcrms info 111 8 0x0004
}
[WaitForLinkActivate]={
avmcrms dsl 13 0 0x0008
}

For Annex A:
#AVM ADSL Annex A
[WaitForLinkActivate]={
avmcrmr info 111 8 0010
}
[WaitForLinkActivate]={
avmcrms test 0 0 0x4000
}
[WaitForLinkActivate]={
avmcrms dsl 13 0 0x0002
}
[WaitForLinkActivate]={
avmcw cnfg 46 0 0xe
}
[WaitForLinkActivate]={
avmcw moni 5 0 0x204B
}
[WaitForLinkActivate]={
avmcw moni 5 1 0x0000
}
[WaitForLinkActivate]={
avmcrms info 111 8 0x0004
}
[WaitForLinkActivate]={
avmcrms dsl 13 0 0x0008
}


As you can see there are some AVM and non standard commands comparing
to LEDE/OpenWrt dsl_control flavour. Those are for eg.:
avmvig AVM_VersionInformationGet
avmcr AVM_CmvRead
avmcw AVM_CmvWrite
avmcrms AVM_CmvReadModifySet
avmcrmr AVM_CmvReadModifyReset
avmpet AVM_ProdEchoTest
avmhwrfit AVM_HWRFITest
avmdsmmcs AVM_DSM_MacConfigSet
cr CmvRead
cw CmvWrite


More can be found by looking into dsl_control file extracted from AVM
boards firmwares (Freetz buildroot can do that).
It also contains adsl.cfg commands if someone wants to debug this
further without access to the boards itself.

Example content of dsl_control:
avm_dsl_cli_DsmMacConfigSet
cw DSL_CPE_SCRIPT: CMV WR %s %d %d, value=0x%04x, retCode=%d
mw %s %s %s DSL_CPE_SCRIPT: Dbg Memory write address=%08x,
value=%04x, retCode=%d
dsl_control: mw %08x fail
mr dsl_control: error:mr parameter type mismatch!



Anyone got an idea or could spare a hint on how to debug what AVMs
dsl_control is actually doing/sending to the DSL PHY driver?

Could anyone with deep Lantiq knowledge look into this please? My
knowledge about Lantiq DSL tools/drivers ends here : (.

What needs to be done so the LEDE/OpenWrt dsl_control could also be
able to switch Annex on those and maybe other AR9/VR9 boards?


I can assist in some tests if you need. I also got all TP-Links VR9
boards (both Annexes) plus some other AR9/VR9/AR10 boards and also an
Annex A/M ADSL/ADSL2+ DSLAMs (can't test VDSL right now).


Greets.
Sylwester Petela
2017-07-10 18:10:44 UTC
Permalink
These are some findings that I've along with Mathias Kresin made quite
time ago (hardware part):

On F3 vs F1 near transformer was capacitor .022j630p (annex B) .027j630p
(annex A) You can check that as on most images I don't see its value. As
for differences between boards I'll check it tomorrow when I replace F3
with HH5 (need to flash it first).

After all in my case stats between F1 and ***@annexA are ~0,5dB, upload
sync is bit higher compared to when I was on F1 and HH5 as far as I
checked, download is same.


W dniu 2015-10-06 o 19:22, Mathias Kresin pisze:

> Hi Sylwester,
>
> the soldering on my HomeHub5a was done and I'm able to establish an
> Annex B ADSL connection with the device.
>
> The line stats are okay, but they do not match the values I had with
> the o2 Box 6431 before ripping of the Line Transformer. To confirm
> that nothing has changed with the phone line, I connected a VRX208
> based FritzBox (with the same xDSL Firmware Version) and I got the
> same values as with the o2 Box 6431.
>
> o2 Box 6431:
>
> Data Rate: Down: 17.296 Mb/s / Up:
> 1.180 Mb/s
> Line Attenuation (LATN): Down: 17.2dB / Up: 6.7dB
> Signal Attenuation (SATN): Down: 15.9dB / Up: 6.6dB
> Noise Margin (SNR): Down: 6.0dB / Up: 12.3dB
> Aggregate Transmit Power(ACTATP): Down: 18.2dB / Up: 11.1dB
> Max. Attainable Data Rate (ATTNDR): Down: 17.284 Mb/s / Up:
> 1.392 Mb/s
>
> HomeHub 5a @ Annex B:
>
> Data Rate: Down: 16.889 Mb/s / Up:
> 1.180 Mb/s
> Line Attenuation (LATN): Down: 14.6dB / Up: 7.1dB
> Signal Attenuation (SATN): Down: 13.4dB / Up: 7.1dB
> Noise Margin (SNR): Down: 6.3dB / Up: 12.5dB
> Aggregate Transmit Power(ACTATP): Down: 18.2dB / Up: 12.6dB
> Max. Attainable Data Rate (ATTNDR): Down: 17.016 Mb/s / Up:
> 1.356 Mb/s
>
> I had the impression that we still missed something. And yes, I was
> able to identify a few more different resistors (Line Transformer Pin
> counting is clockwise!):
>
> Annex A
> Line Transformer Pin 6 -> 24,95 Ohm R left -> empty solder pads
> -> VRX 208 Pin 37
> Line Transformer Pin 7 -> 24,95 Ohm R right -> empty solder pads
> -> VRX 208 Pin 45
>
> Line Transformer Pin 5 -> 68 Ohm R -> VRX 208 Pin 39
> Line Transformer Pin 8 -> 68 Ohm R -> VRX 208 Pin 43
>
> Annex B
> Line Transformer Pin 6 -> 10 Ohm R left -> 68 Ohm R -> VRX 208
> Pin 37
> Line Transformer Pin 7 -> 10 Ohm R right -> 68 Ohm R -> VRX 208
> Pin 45
>
> Line Transformer Pin 5 -> 0 Ohm R (bridge) between VRX 208 Pin
> 39/43 -> 0 Ohm R (bridge) -> VRX 208 Pin 39
> Line Transformer Pin 8 -> 0 Ohm R (bridge) between VRX 208 Pin
> 39/43 -> 0 Ohm R (bridge) -> VRX 208 Pin 43

What I see on F1, yes traces from inner pair of transformer goes through
49 ohm (between them) and then goes straight to (right resistor /cap
80/79pin) and somewhere else (cannot trace it) Outer pair goes straight
to ~70 ohm resistors each to somewhere under the vrx208 chip (need to
de-solder it to find out pins) and to (left/middle cap/resistor) 78/77
and 76/75.

> I used the following pictures for visualising and flowing the traces.
> The pictures are in the gimp format and have multiple layers:
>
> TD-W8980 - Annex A:
> https://www.dropbox.com/s/j6qoeoy1a479yrz/tp-link_w8980v1.xcf?dl=0
> o2 Box 6431 - Annex B:
> https://www.dropbox.com/s/jskzcnxvszdlraj/o2_6431.xcf?dl=0
>
>
> Can you confirm my findings with your devices?
>
> Do your line stats differ between your HH5 and your ***@AnnexA as well?
>
>
> I could not yet identify all matching R's/solder pads on the HH5,
> since the HH5 board layout is way to different and hard to read. I'll
> try again later, when my eyes are rested.
>
> Mathias
As for F3 traces, I'll send You them tomorow.

Best Regards
Sylwester Petela
------End of QUOTE------
W dniu 10.07.2017 o 14:23, Damian Kaczkowski pisze:
> Hello all.
>
> I have done some research regarding soft-switching DSL Annex. I got
> few boards which are able to operate in Annex A or B without hardware
> mods of the hybrid. Seems that dsl_control is able to send some
> commands to the DSL PHY so it can sync with Annex A line while being
> equipped with Annex B DSL transformer which is a part of hybrid I
> suppose. I have tested the following boards:
> - AVM/1&1 FRITZ!Box 7330 SL
> - AVM/1&1 FRITZ!Box 7362 SL
> - AVM/1&1 FRITZ!Box Fon WLAN 7320
> - AVM/1&1 FRITZ!Box Fon WLAN 7360 SL
> - AVM FRITZ!Box WLAN 3370
>
> Non of them is "international edition". All are marked by vendor as
> Annex B only editions and all of them are equipped with DSL
> transformers matched to Lantiq Chips Annex B (that's what datasheets
> says).
>
> They are equipped with the following DSL transformers:
> UMEC UTB01930S 270uH, 2:1, Annex B, Supplementary For Lantiq’s
> XWAY™ VRX208 Chip (3370)
> LinkCom LAL0530 270uH, 2:1, Annex B, Supplementary For Lantiq’s
> XWAY™ VRX208 Chip (7362 SL, 7360 SL)
> VOGT unknown, unknown, Annex B, Suplementary
> for Lantiq AR9 Chip (7320, 7330 SL)
> MNC EP-832SG 1.4mH, 2:1, Annex A, Supplementary For Lantiq’s
> XWAY™ VRX208 Chip (TD-W8970V1, TD-W8980V1, TD-W9980V1)
> MNC EP-833SG 270uH, 2:1, Annex B, Supplementary For Lantiq’s
> XWAY™ VRX208 Chip (TD-W8970BV1, TD-W8980BV1, TD-W9980BV1)
>
> On Freetz firmware I was able to soft-switch all above AVM boards from
> Annex B to Annex A and successfully sync to Annex A/M DSLAM/Line.
>
> After switching firmware to LEDE/OpenWrt on those boards I am getting
> the same error as Andre got on TP-LINKs:
> 'DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used!
> Please change one of it.'.
>
> To sum up:
> Freetz OS loaded with LEDE DSL firmware sync without a problem. So the
> problem is not the DSL firmware itself.
> Hybrid is also not a problem cause on Freetz OS I have successfully
> sync Annex B boards (soft-switched to Annex A) to Annex A line.
>
> I have done numerous tests and come to conclusion that dsl_control
> and/or driver implementation is the main problem and thing to focus
> on.
>
> LEDE dsl_control is not able to start the DSL PHYs (with Annex B
> transformers) loaded with Annex A firmware and sync them to Annex A
> line, but the same boards sync fine with Freetz OS + Freetz
> dsl_control.
>
> I spot that dsl_control on Freetz generates the adsl.cfg upon start.
> This adsl.cfg is generated with different sets of commands according
> to selected Annex.
>
> adsl.cfg content differs between board models/generation. Similar
> boards got the same adsl.cfg contents. This is probably due to
> different DSL transformer or whole hybrid? I need to double check and
> confirm this to be sure.
>
> Here is an example of adsl.cfg file content generated on 7320 SL board:
> For Annex B:
> #AVM ADSL Annex B, generated by dsl_control
> [WaitForConfiguration]={
> sics 1 1 1 3
> }
> [WaitForLinkActivate]={
> lfcs 1 1 1 1 0 0
> }
> [WaitForLinkActivate]={
> lfcs 0 1 1 0 0 0
> }
> [WaitForLinkActivate]={
> cw info 86 0 0x4801
> }
> [WaitForLinkActivate]={
> avmcrmw optn 25 0 0x2000
> }
> [WaitForLinkActivate]={
> cw cnfg 45 0 0xe
> }
> [WaitForLinkActivate]={
> avmcrmw info 103 1 0x2000
> }
>
> For Annex A:
> #AVM ADSL Annex A, generated by dsl_control
> [WaitForConfiguration]={
> sics 1 1 1 3
> }
> [WaitForLinkActivate]={
> lfcs 1 1 1 1 0 0
> }
> [WaitForLinkActivate]={
> lfcs 0 1 1 0 0 0
> }
> [WaitForLinkActivate]={
> cw info 86 0 0x4801
> }
> [WaitForLinkActivate]={
> avmcrmw optn 25 0 0x2000
> }
> [WaitForLinkActivate]={
> cw cnfg 45 0 0xe
> }
> [WaitForLinkActivate]={
> cw info 94 0 0x1467
> }
>
>
> Here is an example of adsl.cfg file content generated on 3370 board:
> For Annex B:
> #AVM ADSL Annex B
> [WaitForLinkActivate]={
> avmcrms info 103 1 0x2000
> }
> [WaitForLinkActivate]={
> avmcrmr info 111 8 0010
> }
> [WaitForLinkActivate]={
> avmcrms test 0 0 0x4000
> }
> [WaitForLinkActivate]={
> avmcrms dsl 13 0 0x0002
> }
> [WaitForLinkActivate]={
> avmcw cnfg 46 0 0xe
> }
> [WaitForLinkActivate]={
> avmcrms info 111 8 0x0004
> }
> [WaitForLinkActivate]={
> avmcrms dsl 13 0 0x0008
> }
>
> For Annex A:
> #AVM ADSL Annex A
> [WaitForLinkActivate]={
> avmcrmr info 111 8 0010
> }
> [WaitForLinkActivate]={
> avmcrms test 0 0 0x4000
> }
> [WaitForLinkActivate]={
> avmcrms dsl 13 0 0x0002
> }
> [WaitForLinkActivate]={
> avmcw cnfg 46 0 0xe
> }
> [WaitForLinkActivate]={
> avmcw moni 5 0 0x204B
> }
> [WaitForLinkActivate]={
> avmcw moni 5 1 0x0000
> }
> [WaitForLinkActivate]={
> avmcrms info 111 8 0x0004
> }
> [WaitForLinkActivate]={
> avmcrms dsl 13 0 0x0008
> }
>
>
> As you can see there are some AVM and non standard commands comparing
> to LEDE/OpenWrt dsl_control flavour. Those are for eg.:
> avmvig AVM_VersionInformationGet
> avmcr AVM_CmvRead
> avmcw AVM_CmvWrite
> avmcrms AVM_CmvReadModifySet
> avmcrmr AVM_CmvReadModifyReset
> avmpet AVM_ProdEchoTest
> avmhwrfit AVM_HWRFITest
> avmdsmmcs AVM_DSM_MacConfigSet
> cr CmvRead
> cw CmvWrite
>
>
> More can be found by looking into dsl_control file extracted from AVM
> boards firmwares (Freetz buildroot can do that).
> It also contains adsl.cfg commands if someone wants to debug this
> further without access to the boards itself.
>
> Example content of dsl_control:
> avm_dsl_cli_DsmMacConfigSet
> cw DSL_CPE_SCRIPT: CMV WR %s %d %d, value=0x%04x, retCode=%d
> mw %s %s %s DSL_CPE_SCRIPT: Dbg Memory write address=%08x,
> value=%04x, retCode=%d
> dsl_control: mw %08x fail
> mr dsl_control: error:mr parameter type mismatch!
>
>
>
> Anyone got an idea or could spare a hint on how to debug what AVMs
> dsl_control is actually doing/sending to the DSL PHY driver?
>
> Could anyone with deep Lantiq knowledge look into this please? My
> knowledge about Lantiq DSL tools/drivers ends here : (.
>
> What needs to be done so the LEDE/OpenWrt dsl_control could also be
> able to switch Annex on those and maybe other AR9/VR9 boards?
>
>
> I can assist in some tests if you need. I also got all TP-Links VR9
> boards (both Annexes) plus some other AR9/VR9/AR10 boards and also an
> Annex A/M ADSL/ADSL2+ DSLAMs (can't test VDSL right now).
>
>
> Greets.
> _______________________________________________
> openwrt-devel mailing list
> openwrt-***@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Damian Kaczkowski
2017-07-10 20:07:16 UTC
Permalink
Hello Sylwester.

On 10 July 2017 at 20:10, Sylwester Petela <***@gmail.com> wrote:
> I used the following pictures for visualising and flowing the traces.
> The pictures are in the gimp format and have multiple layers:
>
> TD-W8980 - Annex A:
> https://www.dropbox.com/s/j6qoeoy1a479yrz/tp-link_w8980v1.xcf?dl=0
> o2 Box 6431 - Annex B:
> https://www.dropbox.com/s/jskzcnxvszdlraj/o2_6431.xcf?dl=0

Your dropbox links does not work. Cloud you please look into this?
Thanks in advance.
Mathias Kresin
2017-07-10 20:37:51 UTC
Permalink
10.07.2017 22:07, Damian Kaczkowski:
> Hello Sylwester.
>
> On 10 July 2017 at 20:10, Sylwester Petela <***@gmail.com> wrote:
>> I used the following pictures for visualising and flowing the traces.
>> The pictures are in the gimp format and have multiple layers:
>>
>> TD-W8980 - Annex A:
>> https://www.dropbox.com/s/j6qoeoy1a479yrz/tp-link_w8980v1.xcf?dl=0
>> o2 Box 6431 - Annex B:
>> https://www.dropbox.com/s/jskzcnxvszdlraj/o2_6431.xcf?dl=0
>
> Your dropbox links does not work. Cloud you please look into this?
> Thanks in advance.

Most likely because these are links to my Dropbox. I'll send you a link
off-list. But I'm in doubt that it contains what you are looking for.

With a lot of help from Sylwester I've modified the Hardware of an Annex
A board in a way that it syncs on an Annex B line.

I had to change some bootstrap resistors to change the hybrid mode of
the VRX208. Afterwards I was able to load an Annex B firmware.
Unfortunately it was the last step I made.

Prior I changed some more resistors, some caps and the line transformer
to match the components to what I found on Annex B boards. Not sure if
it was really necessary.

I do not have a real clue what the AVM commands do. But it looks like
they are patching some (ram/register?) values of the VRX208. To my
knowledge, the VRX208 is an arc cpu and the xdsl firmware some kind of
operating system. But I could be wrong on this. There is literally no
information about Lantiq chips publicly available.

I already had a look at some AVM GPL tarballs, but none of them had the
xdsl driver/daemon source code included. Would be to easy for us...

Mathias
Andre Heider
2015-08-03 17:54:39 UTC
Permalink
Hi all,

On Fri, Jul 24, 2015 at 12:03 AM, Alexander Couzens <***@fe80.eu> wrote:
> I've seen the same. With annex b device, same firmware, the modem syncs to adsl, with annex a not.

meanwhile, I got an annex b device, and with the same openwrt build,
dsl firmware and config (sysupgrade backup) it just works with my
adsl2+ line.

I'll look for hardware differences next week, but I get the feeling
I'm not going to find anything.

PS: by poking around I found
target/linux/lantiq/patches-3.18/0007-MIPS-lantiq-add-basic-tffs-driver.patch
which looks like it reads the annex version off a mtd part I don't
have. Any idea what that is about?
Alexander Couzens
2015-08-03 19:25:00 UTC
Permalink
I've took a look on 2 devices.
They differ a lot, there might be different revisions.
I'll take some photos tomorrow.

> PS: by poking around I found
> target/linux/lantiq/patches-3.18/0007-MIPS-lantiq-add-basic-tffs-driver.patch
> which looks like it reads the annex version off a mtd part I don't
> have. Any idea what that is about?
good question... no idea


--
Alexander Couzens

mail: ***@fe80.eu
jabber: ***@jabber.ccc.de
mobile: +4915123277221
Andre Heider
2015-07-23 22:19:46 UTC
Permalink
Hi Martin,

On Thu, Jul 23, 2015 at 11:51 PM, Martin Blumenstingl
<***@googlemail.com> wrote:
>> This sounds like an annex incompability? Was I wrong and there is a
>> hardware difference and I cannot use the non B model with annex b?
> Indeed, I have read multiple times that the DSL modem should support
> all annexes - but as our tests have shown: it doesn't (at least for
> ADSL). My guess is that the modem physically supports it but there's a
> bootstrap pin (to which a resistor is soldered... or not) which
> configures it to be Annex A *or* B only.

thanks for the confirmation, I feared as much :\

Regards,
Andre
Continue reading on narkive:
Loading...