Yes, @ldir posted a script in the past that did that. However there are ISPs that will limit a dsl link not primarily via the sync but via a traffic shaper at the BNG/BRAS level, e.g. my ISP in the past connected me with a sync of ~116/37 Mbps and traffic shaped me dowm to the contracted 50/10. This illustrates that while this can work well in individual cases it will not work generically and hence it is not implemented in sqm.
It doesn't really make a difference whether it's from AVM or not. I'm on 8.13.1.12.1.7 (extracted from a Draytek-Image) and it works very reliably for me (VDSL2 without vectoring; the firmware supports it, my line doesn't).
I know that the most popular VDSL ISP in Germany (T-Online) lets the client know the speed they are shaping to remotely via a pppd remote message:
pppd-pppoe[15831]: Remote message: SRU=xxxxxxxxx#SRD=xxxxxxxxx#
I suppose that their own CPEs do parse this and setup local QoS accordingly...
1 Like
Yes Telekom's Speedports and AVM's Fritzboxen evaluate this information, which 1&1 also supplies albeit in a slightly different format (and with a different definition, see this pdf from AVM, also see this post in German). But popular ISPs like Vodafone (DSL) nor O2 supply this information...
IMHO this is decent for creating one's own script (assuming the sync rates actually change often enough, but not robust and reliable enough to merit an addition to sqm-scripts...
Yes that is a very good point about the sync not always limiting the throughput, thanks. In my case it would work OK I think with SQM set to about 90% of the sync rate.
My FTTC 'product' with Zen (UK) s 80/20 sync-wise but I'm >500m from the cabinet and I only sync at 54/9 and it IS the limiting factor in my case. It does vary from time to time, moreso on the upstream which is where SQM is most needed. I will investigate it further. I won't clutter up this thread with it though as it's a bit off topic.
made a build for the fritzbox 7530 if anyone wants to test before building their own or anything
latest master, latest glibc, various patches etc
it doesn't have any dsl firmware included but you can pretty easily obtain that and scp (don't forget to use "scp -O") it on, if you really want to know how to do that just let me know
latest master uses DSA so if you are running a swconfig build you absolutely cannot keep your config, you have to choose to wipe it and redo
EDIT: just did a quick rebuild where the userspace binaries are thumb mode for what I assume are some memory savings
eg.
before: 6420 S /usr/sbin/hostapd
after: 5184 S /usr/sbin/hostapd
1 Like
And now they've shut down anonymous access to that issue tracker.
I guess that means they don't want to hear it and couldn't care less. So much about "open-source, community-driven".
1 Like
I don't think that is the intention. They are just migrating to the cloud instances of the Atlassian tools.
Let's hope. I checked first, but couldn't find anything about any migration
I checked out the current version from vr11 brach of https://github.com/dhewg/openwrt.
The dsl sync is working like a charm in my Fritzbox 7530.
But I have persistent problems with the vlan tagging.
tcpdump shows untagged pakets on dsl0.7 as it should be but there is not any paket visible on dsl0.
Effect is a PADO timeout in PPPOE handshake.
the network config is as follows:
config interface 'wan'
option proto 'pppoe'
option password 'xxxx'
option delegate '0'
option ipv6 '0'
option username 'xxxx'
option device 'dsl0.7'
config interface 'wan6'
option device '@wan'
option proto 'dhcpv6'
option reqprefix '56'
option reqaddress 'try'
option ip6assign '64'
and is proven to work on a current openwrt 23.x on a Fritzbox 7412.
Explicit bridge definition with 802.1q or as bridge-vlan i.e. as below does not change anything.
config device
option name 'br-wan'
option type 'bridge'
list ports 'dsl0'
list ports 'dsl0.7'
config bridge-vlan
option device 'br-wan'
option vlan '7'
list ports 'dsl0:t'
list ports 'dsl0.7:u*'
Even if I connect wlan pppoe interface directly to dsl0 device I cannot see any paket with tcpdump on dsl0.
The problem is the same on kernel 5.15 and on 5.10.
So I assume that either vlan tagging is not working in vrx518 driver or the device handling of dsl0 is a general problem.
How can I proceed in debugging to find the root cause?
1 Like
have you tried not setting it up the vlan via the bridge device ? Instead just make a vlan device directly off dsl0 and then put that in a bridge if you want
if you're trying to bridge a tagged dsl to the enternet ports basically you'd have your dsa-bridge device with the filtering set up on that and then you again can have your br-wan and it would have dsl0.7 and dsa-bridge.2 as bridge ports with no vlan filter setup on br-wan as an example
I mean technically there's no reason to use the bridge vlan filter method on the dsl0 device anyway since it's not a dsa device
This works for me, without wan6 or weirdo dsl* bridges:
config dsl 'dsl'
option annex 'b'
option tone 'bv'
option xfer_mode 'ptm'
option line_mode 'vdsl'
option ds_snr_offset '0'
config device
option name 'dsl0'
option macaddr 'xx:...'
config device
option name 'dsl0.7'
option ifname 'dsl0'
option type '8021q'
option vid '7'
config interface 'wan'
option device 'dsl0.7'
option proto 'pppoe'
option username 'xxx'
option password 'xxx'
option peerdns '0'
option ipv6 '0'
I already tried that config - with and without explicit 8021q device - the effect is always the same: no paket on dsl0 visible with tcpdump.
The effect is also persisting with most actual DSL firmware from AVM image.
As the issue is not happening on FB7412 it is not a kernel 5.10 issue.
It may be a driver issue in vrx518 driver or even a hardware problem which then is only triggered by the driver in kernel 5.10 / 5.15 and not by the driver and kernel versions in the original AVM image.
I currently need ideas how to debug this.
The driver doesn't care about VLAN at all, and I don't see why it would need to. As already mentioned here, it works fine for others (myself included, although I use the device as a bridge only and don't terminate PPPoE on it).
Maybe your issue is not related to VLAN at all? There have previously been reports that the data path is broken on devices where dc_ep_clk_on failed shows up in the kernel log. As far as I know, a fix for that issue hasn't been found yet (but there must be one, because the affected users reported that the device works with vendor firmware).
Thanks for the hint. I gave it a try on a second 7530 and there the problem is gone.
So yes it is box specific.
I need to check the logs on the not working box for above error.
Yes, my problem on the failing box is the same:vrx518 0000:01:00.0: dc_ep_clk_on failed
Was there are different vendor firmware version installed before OpenWrt?
Its last version and more are part of fritz_tffs_nand -a -b -d /dev/mtd7. Maybe a diff from both boxes hints at anything.
Do you have serial set up? If so, are the bootloaders the same version? Diff their output?
Here is a copy of pcie-qcom.c in the latest GPL release from AVM, if anyone wants to have a look without downloading the full archive: https://gist.github.com/janh/8ca3609af7901b279516a2da3a4dec30
After having a quick look, I noticed one obvious addition: There is a avm,host_magic DTS property, and if it is set the function qcom_pcie_prog_magic does some magic stuff.
The "magical PCIe vendor ID" at the end of that function seems to be the one of the GRX350/GRX550 PCIe host. If we compare the kernel messages from AVM firmware to OpenWrt, this ID appears in the same place where the Qualcomm vendor ID (17cb:1001) appears on OpenWrt. So it looks like this code actually fakes the vendor ID.
next to obvious differences like MAC addresses, serials, passphrases,...
on the working one:
SerialNumber=K471*****
autoload=yes
linux_fs_start=1
wlan_ssid=FRITZ!Box#7530#NW
on the failed one:
SerialNumber=K344*****
ptest=
wlan_ssid=FRITZ!Box#7530#PB
the rest is identical.
If SerialNumber is a hint for the age of the box, then it may be an issue for certain revisions.
There's HW[Sub]Revision for that, supposed to at least.
For me it's:
HWRevision=247
HWSubRevision=2
SerialNumber=L1337*
I haven't modified tffs vars, but I did buy this 7520 used, so w.r.t. the serial, dunno if that's vanilla or the pre-owner being funny 
Can you try if the mentioned magic pokes make a difference on the non-working box?