Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
On Fri, Jul 24, 2015 at 12:55 AM, Aleksander Wałęski 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
> 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
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 wrote: > On Sat, Jun 6, 2015 at 3:23 PM, Sylwester Petela 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
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 wrote: > On Fri, Jun 5, 2015 at 4:56 AM, Aleksander Wałęski 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
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
wrote:
> On Tue, Jun 2, 2015 at 1:54 AM, Aleksander Wałęski 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
>> 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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
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
wrote:
> Hi Aleksander,
>
> On Wed, May 27, 2015 at 9:20 PM, Aleksander Wałęski
> 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/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
On Mon, May 25, 2015 at 4:08 PM, Aleksander Wałęski 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
On Mon, May 25, 2015 at 1:34 PM, Martin Blumenstingl 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. > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
On Mon, May 25, 2015 at 8:52 AM, Sylwester Petela 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
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
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]
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
Sylwester Petela 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.64] 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.76] DSL[00]: MEI_InternalXtmSwhowtimeEntrySignal(nFast=0, > nIntl=928000) > [ 70.768000] enter showtime, cell rate: 0 - 2188, 1 - 2188, xdata > addr: 0x86d1 > [ 70.784000] enter showtime, cell rate: 0 - 2188, 1 - 2188, xdata > addr: 0x86d1 > [ 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.80] 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-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
