@altuntepe would you mind sharing your config and dsl stats output?
@bill888 that is correct, however this seems to be how it is with vdsl, I can only get a connection with annex a firmware and it will say it’s on annex b when connected. But I could be wrong, so anyone who has a working vdsl connection, please share configs.
My plan is 50/5, from which I get 77/23 (and I don't complain). The max attainable data rate is even higher.
Data Rate: 77.848 Mb/s / 23.120 Mb/s
Max. Attainable Data Rate (ATTNDR): 110.820 Mb/s / 31.800 Mb/s
My config:
config dsl 'dsl'
option tone 'bv'
option line_mode 'vdsl'
option xfer_mode 'ptm'
option firmware '/lib/firmware/575617.bin'
option annex 'a'
option ds_snr_offset '0'
That firmware is not the stock from the Telfort 2812, it's extracted from my ISP (DDS) provided modem (Experiabox v8). DDS uses KPN Wholesale, so I would expect it to work as good on a Telfort line, but I'm not sure about that.
My dsl status:
ATU-C Vendor ID: Broadcom 192.244
ATU-C System Vendor ID: Broadcom
Chipset: Lantiq-VRX200
Firmware Version: 5.7.5.6.1.7
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Profile: 17a
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 0 / Far: 1
Errored seconds (ES): Near: 1 / Far: 3
Severely Errored Seconds (SES): Near: 0 / Far: 1
Loss of Signal Seconds (LOSS): Near: 3 / Far: 1
Unavailable Seconds (UAS): Near: 491 / Far: 491
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 0.14 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 77.848 Mb/s / Up: 23.120 Mb/s
Line Attenuation (LATN): Down: 2.2 dB / Up: 1.0 dB
Signal Attenuation (SATN): Down: 2.2 dB / Up: 0.8 dB
Noise Margin (SNR): Down: 4.6 dB / Up: 5.0 dB
Aggregate Transmit Power (ACTATP): Down: -11.7 dB / Up: 11.8 dB
Max. Attainable Data Rate (ATTNDR): Down: 110.880 Mb/s / Up: 31.800 Mb/s
Line Uptime Seconds: 45891
Line Uptime: 12h 44m 51s
As you can see my LATN, SATN, SNR and further are worse than yours.
root@OpenWrt:~# /etc/init.d/dsl_control status
ATU-C Vendor ID: Broadcom 164.27
ATU-C System Vendor ID: Broadcom
Chipset: Lantiq-VRX200
Firmware Version: 5.9.1.4.0.7
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.2 (VDSL2)
Profile: 17a
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 65 / Far: 10008
Errored seconds (ES): Near: 2 / Far: 82
Severely Errored Seconds (SES): Near: 0 / Far: 0
Loss of Signal Seconds (LOSS): Near: 0 / Far: 0
Unavailable Seconds (UAS): Near: 29 / Far: 29
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: 2 / Far: 0
Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 0.0 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 79.865 Mb/s / Up: 4.095 Mb/s
Line Attenuation (LATN): Down: 8.8 dB / Up: 7.5 dB
Signal Attenuation (SATN): Down: 8.8 dB / Up: 10.3 dB
Noise Margin (SNR): Down: 11.7 dB / Up: 31.1 dB
Aggregate Transmit Power (ACTATP): Down: -5.5 dB / Up: 14.5 dB
Max. Attainable Data Rate (ATTNDR): Down: 92.585 Mb/s / Up: 45.951 Mb/s
Line Uptime Seconds: 207682
Line Uptime: 2d 9h 41m 22s
config dsl 'dsl'
option annex 'a'
option line_mode 'vdsl'
option ds_snr_offset '0'
option firmware '/lib/firmware/vdsl.bin'
For LATN, SATN smaller numbers indicate a considerably better/shorter line than the OP. As does the smaller ACTATP (on a shorter lines less amplification is required, as the lower attenuation will "eat" less of the transmitted signal, so for a similar signal level at the receiving end less transmit power is required).
SNR margin is partly configurable by the ISP.
Thanks all! The only config diff I could find was "tone bv" vs. "tone av" but that does not make a difference. I just had an issue where it wasn't syncing at all after having the DSL cable out for a bit. Perhaps there is a hardware issue. I will post more info in a few days, when I have another 2812 to play with.
I just got another 2812 with the latest Telfort branded firmware on it. It immediately syncs on 108/31Mb. I have root shell access and I have already found the following:
- I was using identical DSL firmware as stock
- Stock contains a shell script S1_98telfort which sends a complex string to the "g997lis" command. I have not yet found any other specific settings
My next step is to rule out hardware issue with the OpenWRT one. I have tried to restore the NAND backup but so far it boots the kernel, which then panics because of init=0 or something, I will spend some more time on this, maybe copy the NAND from the working stock to the now bricked one.
Definitely, make a note of the exact command, as you should be able to do the same with openwrt, if you get that working well enough.
1 Like
Well, I unfortunately was not successful restoring the original telco firmware to my old 2812. A nand restore in u-boot was OK but the kernel kept panicking. So I will continue assuming it has no hardware issue. On the new 2812 (that runs telco firmware and syncs at full speed) I luckily have a root shell and have found the scripts that initialize the dsl connection by calling "dsl_cpe_pipe.sh". I am going to add some logging to it to understand what is being sent to the modem.
Short update. I have managed to extract a number of low-level commands from the telco firmware and have modified my dsl script accordingly. I now get almost exactly the same numbers as @Mijzelf. That is a definitive improvement but instead of 78M down I should get 108M down. Why is it not syncing at the attainable rate? So there is some fiddling to do there, will continue looking, also to find out what the exact command/config is that is making a difference.
I have run into another problem, and that is that I now cannot get an IP address anymore. I can't remember what my working network setup was. @Mijzelf would you mind sharing the relevant wan/dsl/atm bits from /etc/config/network? Many thanks again 
Sure. This is my config:
config dsl 'dsl'
option tone 'bv'
option line_mode 'vdsl'
option xfer_mode 'ptm'
option firmware '/lib/firmware/575617.bin'
option annex 'a'
option ds_snr_offset '0'
config interface 'wan'
option proto 'dhcp'
option iface6rd 'wan6'
option ifname 'dsl0.34'
config interface 'wan6'
option proto '6rd'
BTW, wan6 doesn't work for me. Have you seen the wiki?
Thanks. Interestingly I seem to be back at square one. This morning the attainable rate was 50M again even when using the modified dsl control script with Telfort magic commands added. And also magically I did have a working WAN connection without changing anything.
I am going to switch my other 2812 to OpenWrt today and try that one (I could not recover stock firmware even though I figured out how to switch to 2nd image). Maybe my first 2812 is blacklisted by the DSLAM somehow.
Okay here is a mildly positive post for a change.
Giving it one more try, with 15 minutes of no modem attached to the line when switching hardware, the 2812 immediately synced at the correct speeds: data rate 78/23, attainable 108/31. I now have 24+ hours uptime on firmware 5.7.8.12.0.7 (5.7.8.C.0.7).
What is even more interesting, is that at least on my upload, I am actually getting 30 Mbps using iperf3 TCP instead of the 23 reported by the DSL script! So maybe there is a bug in the reporting of the data rate somehow? Downstream is fixed at 61 Mbps because it is capped by my current ISP, early May I switch and will report here again.
Whenever someone hits this post in the future: this is concerning OpenWRT 19.07.2.
For reference, what has changed since my opening post?
- I am no longer using any "tone" in the config, this avoids sending a low level config to the firmware altogether. Here is the relevant part of /etc/config/network:
config atm-bridge 'atm'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
option vci '34'
option vpi '0'
config dsl 'dsl'
option annex 'a'
option ds_snr_offset '0'
option line_mode 'vdsl'
option xfer_mode 'ptm'
option firmware '/lib/firmware/vdsl-578C07.bin'
config interface 'wan'
option ifname 'dsl0.34'
option proto 'dhcp'
- I am using the firmware 5.7.8.C.0.7 which is mentioned on the firmware collection page and easy to find/extract.
- I have changed /etc/init.d/dsl_control to create a /tmp/dsl.scr autoboot script as follows (you need to ds_snr_offset line in your config to trigger creation of this autoboot script):
autoboot_script() {
echo "[WaitForConfiguration]={
locs 0 $1
}
[WaitForLinkActivate]={
dms 5048 0 1 102
dmms f45 0 1 36 36
g997xtusecs 4 0 4 0 C 1 0 7
lfcs 0 1 1 1 1 0
lfcs 1 1 1 1 1 0
g997racs 0 0 3
g997racs 0 1 3
g997racs 1 0 3
g997racs 1 1 3
}
[WaitForRestart]={
}
[Common]={
}" > /tmp/dsl.scr
}
I do not have the time to figure out which config setting ultimately helped created a stable config. I am now letting this sit in early May and will report back on the actual TCP speeds measured instead of reported.
Thanks everyone for their insights and help so far.
The iperf3 results is suspicious, could you post the exact values from the modem, the whole report OpenWrt gives e.g. in the GUI, and the iperf results? Even with a sync of 31.0 Mbps the theoretical limit is 29 Mbps, so 30 really is beyond possible (unless there is some rounding involved). I would trust the modem's reported sync though, if the modem gets this wrong I would expect the sync not to hold.
Full DSL report. Notice that the actual data rate reported is identical to the numbers of @Mijzelf which is suspicious.
root@OpenWrt:~# /etc/init.d/dsl_control status
ATU-C Vendor ID: Broadcom 177.191
ATU-C System Vendor ID: Broadcom
Chipset: Lantiq-VRX200
Firmware Version: 5.7.8.12.0.7
API Version: 4.17.18.6
XTSE Capabilities: 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex: B
Line Mode: G.993.5 (VDSL2 with down- and upstream vectoring)
Profile: 17a
Line State: UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 0 / Far: 8
Errored seconds (ES): Near: 0 / Far: 8
Severely Errored Seconds (SES): Near: 0 / Far: 1
Loss of Signal Seconds (LOSS): Near: 0 / Far: 1
Unavailable Seconds (UAS): Near: 153 / Far: 153
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: 0 / Far: 0
Pre-emtive CRC errors (CRCP_P): Near: 0 / Far: 0
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 0.13 ms [Fast] 0.0 ms [Fast]
Data Rate: Down: 77.848 Mb/s / Up: 23.120 Mb/s
Line Attenuation (LATN): Down: 9.2 dB / Up: 7.8 dB
Signal Attenuation (SATN): Down: 9.3 dB / Up: 7.8 dB
Noise Margin (SNR): Down: 5.4 dB / Up: 5.0 dB
Aggregate Transmit Power (ACTATP): Down: -6.2 dB / Up: 11.8 dB
Max. Attainable Data Rate (ATTNDR): Down: 100.025 Mb/s / Up: 31.277 Mb/s
Line Uptime Seconds: 97724
Line Uptime: 1d 3h 8m 44s
root@OpenWrt:~#
iperf3 results from Windows laptop, temporarily setup behind double NAT, all ethernet:
iperf3 -c RemoteHostOnTheInternet -i -t30
Connecting to host arch.hazejager.nl, port 5201
[ 4] local 192.168.2.130 port 51615 connected to 195.43.158.202 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 34.1 MBytes 28.6 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 34.1 MBytes 28.6 Mbits/sec sender
[ 4] 0.00-10.00 sec 34.0 MBytes 28.5 Mbits/sec receiver
iperf Done.
These results are fully reproducible and within 1% of the speeds I got with the Telco firmware (in bridge mode, single NAT, see first post). The Telco firmware did report an upstream of 31 Mbps.
Thanks! I agree 28.5 * 65/64 * (1522/(1500-20-20)) = 30.174 Mbps, which is clearly larger than 23.120, but would work for a 31 Mbps sync...
I wonder whether the issue now is interference between Firmware Version: 5.7.5.6.1.7 of the blob and API Version: 4.17.18.6 of the driver and dsl_tool?
Looking at the command line reference maybe iperf3 -c RemoteHostOnTheInternet -i 10 -t 30 would work better ;).
That's interesting. I did an iperf either, and also got 29 Mbits/sec, while my DSL still reports a data rate of 23.120 Mb/s. I also tried the other way, but that capped at 48Mbit. First I thought is was my ISP, as I have a 50Mbit plan, but then I saw I have an 52 Mbit upload at the other side. So that is undecided.
@SvenH
You replied to my old topic. The topic has been automatically closed, so I reply here; sadly I wasn't able to fix it at the time.
OK I promised to get back here. This morning the switch to my new ISP (Budget) was completed with no DSL downtime (both Telfort and Budget use KPN wholesale DSL), only a new IP address.
With the following values reported by dsl_control:
Data Rate: Down: 77.848 Mb/s / Up: 23.120 Mb/s
Line Attenuation (LATN): Down: 9.2 dB / Up: 7.8 dB
Signal Attenuation (SATN): Down: 9.3 dB / Up: 7.8 dB
Noise Margin (SNR): Down: 5.0 dB / Up: 5.0 dB
Aggregate Transmit Power (ACTATP): Down: -6.2 dB / Up: 11.7 dB
Max. Attainable Data Rate (ATTNDR): Down: 97.694 Mb/s / Up: 31.277 Mb/s
I get an iperf3 TCP bandwidth (sustained) of 90.0 Mb/s downstream and 29.4 Mb/s upstream. So, I am happy. I suspect that the stock firmware would have gotten a bit more downstream but I am not going to spend more time on that Thank you all for contributing.
1 Like
I guess it is official now, the reported "Data Rate" for this firmware/blob/driver combination is rather a approximation 
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.