I will have to look into this - sounds like that can make a huge difference.
Also, I hope that I can connect the FB7530 again this evening to finally run ubus call dsl metrics and see what's going on there.
1 Like
I connected the FB7530 with OpenWRT again, with the following results.
It took some time after booting for the dls0 interface to show up, but I'd guess that is normal behavior. It synced, and after changing it to dsl0.7 again, it actually successfully connected. This was the result of running
$ ubus call dsl metrics
{
"api_version": "4.23.1",
"firmware_version": "8.13.1.5.0.7",
"chipset": "Lantiq-VRX500",
"driver_version": "1.11.1",
"state": "Showtime with TC-Layer sync",
"state_num": 7,
"up": true,
"uptime": 44,
"atu_c": {
"vendor_id": [
181,
0,
66,
68,
67,
77,
194,
26
],
"vendor": "Broadcom 194.26",
"system_vendor_id": [
181,
0,
66,
68,
67,
77,
0,
0
],
"system_vendor": "Broadcom",
"version": [
49,
57,
46,
48,
46,
52,
48,
46,
51,
32,
86,
69,
95,
49,
50,
95
],
"serial": [
65,
65,
49,
57,
48,
57,
70,
83,
50,
83,
48,
45,
50,
54,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
]
},
"power_state": "L0 - Synchronized",
"power_state_num": 0,
"xtse": [
0,
0,
0,
0,
0,
0,
0,
2
],
"annex": "B",
"standard": "G.993.2",
"profile": "35b",
"mode": "G.993.2 (VDSL2, Profile 35b, with down- and upstream vectoring)",
"upstream": {
"vector": true,
"trellis": true,
"bitswap": true,
"retx": true,
"virtual_noise": false,
"interleave_delay": 0,
"data_rate": 23357000,
"latn": 9.200000,
"satn": 9.200000,
"snr": 25.500000,
"actatp": -1.700000,
"attndr": 53047000
},
"downstream": {
"vector": true,
"trellis": true,
"bitswap": true,
"retx": true,
"virtual_noise": false,
"interleave_delay": 90,
"data_rate": 204404000,
"latn": 13.300000,
"satn": 13.300000,
"snr": 16.300000,
"actatp": 13.400000,
"attndr": 294263848
},
"errors": {
"near": {
"es": 5,
"ses": 0,
"loss": 0,
"uas": 125,
"lofs": 0,
"fecs": 43,
"hec": 0,
"ibe": 0,
"crc_p": 0,
"crcp_p": 0,
"cv_p": 0,
"cvp_p": 0,
"rx_corrupted": 4168,
"rx_uncorrected_protected": 16,
"rx_retransmitted": 0,
"rx_corrected": 4152,
"tx_retransmitted": 0
},
"far": {
"es": 3862,
"ses": 259,
"loss": 2,
"uas": 125,
"lofs": 0,
"fecs": 1429552,
"hec": 0,
"ibe": 0,
"crc_p": 0,
"crcp_p": 0,
"cv_p": 0,
"cvp_p": 0,
"rx_corrupted": 88976880,
"rx_uncorrected_protected": 4239205,
"rx_retransmitted": 0,
"rx_corrected": 84737675,
"tx_retransmitted": 224601219
}
},
"erb": {
"sent": 251,
"discarded": 0
}
}
Well, turns out it is even using the 35b profile and working properly...problem is, I can't figure out what the difference is to last time. Maybe I was just unlucky with my timing?
As a small bonus, I believe I (finally!) found my APL today, at least I think so. I searched through the entire house multiples times before but couldn't figure anything out. Well, today, I found this about 20-30m down the telephone line outside the house (but still on the property) - could this be the APL? I couldn't take a better photo due to lighting, but for figuring out what this is it might be enough.
If this is the APL, then I can't think of a way I could fix signal issues...other than buying 30m of some cable that is suitable for outside.
There appears to be some corrosion. It also looks like the isolation of the wire on the top right is damaged. However, the cable itself is fine. This is the good type which is installed by Telekom themselves, so there is no reason to replace the entire cable (and if you don't know for sure this is actually your APL, then you probably shouldn't touch it anyway).
Does the same cable end in the phone socket (black cable, red wires with black stripes)? If not, then there must be another connection at the house (and you should probably try to find it, because the bridge tap mentioned earlier shows very clearly in the SNR graph, now that the influence from the PLC adapters is gone).
1 Like
Great! Could you try go-dsl again and post the data (especially the SNR and bitloading spectra)?
It looks like you cleaned up your RF environment, well possible that it wad too noisy for getting a robust 35a sync.
That might well be the APL, however the wires look OK, so if you would need to deal with the wires inside the house (assuming there is no "flickstelle" in between).
But if you want you can run a cable of your choice from the house to the APL, IIRC you should get a Telekom technician to connect you wires inside the APL (the APL belongs to the telco).
I would rather look what happens inside the house and what kind of wire "tree" structure might be in your apartment/house. Technically telephone sockets (TAE or other) always should have been mounted in series* but quite often things were connected in parallel building a tree, as that worked just as fine for analog telephony and was conceptually simpler. But all the branches in such a tree that are not connected with the modem act as antennas and "collect" noise, so especially for 35a a tree-wiring should be undone and either properly serialized or just removed (put a single socket at the trunk of the tree and cut all the branches, or connect the modem to one branch and cut all the others).
- IIRC the Telekom sockets then would internally disconnect the link to the next socket when a device was plugged in.
For some reference what a bridge-tap is see:
and for diagnosis:
This is good to hear, then I will not worry about that for now.
I'm going to check the cables in the phone socket asap, when I'm done with the go-dsl measurements.
I tried but I couldn't get it to load data from OpenWRT! I tried the Lantiq (SSH) and Fritz!Box options, but I was unable to read anything. Which option do I need to choose when running OpenWRT?
I will start with that, as soon as the measurement is done. But I'm going to search for any bridge-tap issued first, and just try to find anything relevant in the connections.
Edit:
Thanks for the PDF, this is really interesting information!
Use the "Lantiq (SSH)" client, and set the command in the advanced options to dsl_cpe_pipe.sh.
Thanks, that's working flawlessly 
I know I could've probably found this easily in a forum post or docs, but I tend to just ask away when I'm already in a conversation in a thread... I hope I'm not bothering you all too much
I made three measurements about 5-10 minutes each. During the first one, I took several speed tests (both to check how the connection performs and to see if it stays stable). I then realized I plugged my Powerlan back in and was doing the speedtest over (Power)LAN directly from my PC to the router. Whenever a test was running, the SNR went all this way down, across the board! (I measured ~25Mbit/s)
The second measurement, I also took bandwidth tests but over WLAN and after unplugging the Powerlan devices. This time, the SNR didn't seem to be affected at all, as you can see in the much higher minimums. (I measured ~40Mbit/s)
Lastly, I took one last measurement without any noteworthy traffic over the connection.
I still can't really make anything of the Bitloading spectrum, but I believe that for the SNR, I have nicely visualized (and thus proven to myself) that the Powerlan devices had a huge impact - even though the sync was still stable this time. My question now is: could the lower speeds I measured when using Powerlan (25 vs. 40 Mbit/s) be connected to the lower SNR? I know that speeds can be dynamically adjusted, but is it done in realtime like this?
Otherwise, if I'm somehow able to stabilize the sync - would I theoretically be fine to continue using the Powerlan devices?
In theory it is possible for the data rate to be adjusted automatically, but this is not enabled on your line (look at "Seamless rate adaption").
However, if the SNR drops enough, this causes transmission errors. These are compensated by retransmissions, but in the end the throughput of error-free data will be reduced. If you look at the "Minimum error-free throughput" value, you'll see that your downstream data rate was reduced by 80 Mbit/s due to transmission errors during at least one second.
This doesn't explain the numbers you mentioned though, at least in downstream direction the line should allow much higher rates in any case (maybe you are limited by the PLC or wireless connection?).
You may be able to reduce the interference caused by the adapters by changing their configuration. But that will also reduce the speeds achieved by the adapters, and it likely won't make the interference go away entirely. So ideally, you should really look into alternatives.
Were all of the adapters turned off for the second and third image? It looks like there is still some interference around 20 and 26 MHz.
Also keep in mind that ASSIA/DLM is used in the Telekom network to adjust line stability. If that system detects errors, it can reduce the maximum data rate of the line (this happens at most once every night). It looks like your line is currently limited to ~200 Mbit/s in downstream (see "Actual net data rate"). If your line remains stable without significant errors for some time, then the configured maximum speed will likely increase to 292032 kbit/s.
Your upstream rate is also below what it could be (it could be up to 46720 kbit/s if DLM assigns the highest profile). The current rate doesn't look like it is set by DLM, so you may be able to increase it by reconnecting while all of the PLC adapters are off.
From this new data, it is also clear that the bridge tap has an even larger effect with profile 35b, so you should really look into that (you may also find more information in German using the terms "Parallelschaltung" or "Abzweigung").
1 Like
The connection to the router does seem to be the bottleneck. When using WiFi from directly next to the router, it goes up to ~80Mbit/s, using a LAN cable directly from a laptop to the router, I actually get the 175Mbit/s that are supposed to be minimum for this line. As soon as there is a wall / floor in between, I measure a maximum of ~40Mbit/s over WiFi. The PLC should also be able of a throughput of more than 25Mbit/s (I have two of these devolo dLAN 550 duo+), so I guess the interference introduced by them leads to a much higher error-rate?
There was still a single one plugged in - the one directly next to the router. Can a single PLC device without anything its connected to still make a noticable difference? I will take another measurement later today.
Edit: According to the configuration guide you sent me (section "devolo-Adapter für den Einsatz am VDSL- bzw. (Super-)Vectoring-Anschluss optimieren"), the model I'm using (550) doesn't support manual configuration since it already uses SISO-mode. Since it's still affecting my connection, I guess the adapters are useless to me for now.
According to theory it should not, but that is easy to test 
Yes, PLC and VDSL2 (with profiles 17b and 35a) do not mix well, by virtue of using the same frequency bands over wires/cabling that is not all that well suited for such frequencies.
Other access technologies like docsis/cable, PON/fiber will be "immune" so you might want to keep the adapters on a shelf for the inevitable sun-setting of the copper network...
Your options currently really are:
a) flat unobtrusive ethernet cables
b) a WiFI mesh network (which will work better if the nodes themselves are connected via ethernet, making it less of a mesh ;))
I am soon going to set up something similar to this setup/combo, however I am going to use a Zyxel VMG3925-B10B as the modem in bridge mode (NAT, Firewall & DHCP disabled) instead, and the 7530 as the OpenWrt router & AP (NOT just a dumb AP).
@slh , we had a conversation about a similar combo almost 2 years ago here, that time with the Zyxel + a BT HH 5A. I bought the R7800 as discussed (soon after, I decommissioned the Zyxel too because I moved to a home that offered FTTH), and set up the Zyxel + BT HH5A combo to my father's home, which works till now.
I want to replace the BT HH5A in my father's home with a spare FB 7530 with OpenWrt for various reasons, but mainly because it has a newer processor and I trust the overall performance would be better.
Where I am with FB 7530 at the moment is here (the default OpenWrt setup):
Similar to the previous setup, I trust that I need to create a new WAN interface with PPPoE protocol (and DHCP server enabled ?) and link it to the relevant VLAN ID (eth0.xx). However I struggle to define what the new VLAN should be, because FB 7530 does not have a dedicated WAN port but 4 LAN ports instead. I understand that a VLAN ID should "simulate" the hypothetical WAN port via assigning a LAN port.
I have read the below in the ToH VLAN Setup for FB 7530, but I am unsure what to do next.
For sure I do not need the Guest network, so I will delete the 2nd VLAN ID and untag LAN4. I will also avoid ID 1 as suggested with sth else (e.g. 42). But how am I supposed to set the desired VLAN for the "simulated" WAN port?
The added difficulty (for me at least) is that I have to do this on a plug-and-play basis (ie prepare everything in advance if possible), because I won't have much time available for experiments in my father's home..
There is currently no xDSL modem support for the 7530 yet, it's under development (and available/ usable in external development trees, but you have to hunt down the patches and and build the images yourself). Unless there is a pressing need for the 7530, I wouldn't pick that one yet (fine as long as you don't need neither xDSL (WIP) nor DECT/ FXS (never) from it).
I do not plan to use the 7530 as a VDSL router. I will keep using the Zyxel which is rock solid in bridge mode.
I have an 7530 as a spare unit and I think it is a good replacement for the BT HH5A which is in router mode now (not gateway mode).
However BT HH5A had a dedicated WAN port, which was easier for me to understand and set up in terms of VLANs, interfaces, etc
The you just need to redefine one of the LAN ports as WAN (LAN1 would make sense, as that's what AVM does in this scenario). Take it out of the (br-)lan bridge and use it as WAN, very similar to the bthub5 setup.
1 Like
@slh Got it. Thanks. Not as simple as it sounded first, but got there to some extent.
I had to actually amend the LAN interface to point to a new VLAN eth0.42 (my LAN VLAN) and to create a new WAN interface to point to eth0.43 (my WAN VLAN).
I am going to test the setup here at my home with FTTH before I go to the other home; I have created a temporary WAN_FTTH interface (eth0.44) to test the whole setup and then I will delete it.
Now I am at the following stage and I do not have access to the internet, although WAN_FTTH gets traffic as you can see. I think it is because I need to bridge somehow LAN with WAN_FTTH :
Am I right in saying that I have to either amend the br-lan device and bridge eth0.44 with eth0.42 or create a new bridging device doing exactly this?
Also I think that I do not need to set up DHCP server on the WAN_FTTH interface, as the LAN does that in the 192.xxx range , correct?
Any mods required in the Bridge VLAN Filtering as well?
Thanks in advance
ipq40xx and VLANs is a bit, …strange
This got a a lot better and easier in master (snapshots), with the switch to the new DSA switch drivers (personally, that alone would make me want to use snapshots for the time being).
1 Like