IIRC this is not how this works... this option needs to be enabled in the Kundencenter and then simply does not care about username/password, however the PPPoE endpoint at the users home also needs to support empty passwords (some, especially GUIs do not seem to allow that), this can easily be tested by supplying a wrong username and password...
This works by having the MSAN (or some other node close to the customer) insert some lineID into the process and DTAG then uses that lineID to figure out the matching contract.
As far as I know tr-069 and its successor are not required...
Thanks for the insight.
The AVM Fritz!Box 7412 is known to be particular bad for modem use, especially above 50 MBit/s, apparently due to filtering issues on the analogue side of it, replacing it does make (a lot of-) sense.
Personally I've used a Draytek Vigor 130 on a DTAG line (with IPv6 and everything) between 2017 and 2021, worked really well - the modern -super-vectoring/ profile 35 capable- successor of that would be the Vigor 167, which should work just the same. If you don't have super-vectoring enabled in your neighbourhood, there'd be plenty of cheap(er) lantiq VRX2x8 second hand options available for a song (including a couple of Broadcom ones without OpenWrt support, but which would still do as a mere external modem); moeller0 also knows a cheap entry level modem from DTAG (which I always forget about).
DTAG is heavily pushing for passwordless PPPoE (and Kundencenter) access, even if you do disable that, it will get re-enabled at the next opportunity, which means you can enter just about anything for username and password (if enabled). The config snippet below has been in service for me until I switched ISPs (to fibre), it's not obfuscated or censored, it really worked with those fake access credentials:
config interface 'wan'
option proto 'pppoe'
option ipv6 '1'
option device 'eth0.7'
option username 'user@t-online.de'
option password 'pass'
config interface 'wan6'
option device '@wan'
option proto 'dhcpv6'
(bthub5 as router (pre-DSA), albeit using a vigor 130 as modem and not the bthub5's internal one, via its (ethernet-) WAN port; no this setup didn't make sense, it was a temporary one for the overlap between VDSL and ftth, exploiting existing cabling and leaving the vigor 130 where it was).
1 Like
While the text output of the application alone doesn't provide much more information than the stats from the OpenWrt web interface, the downstream MINEFTR value looks very bad, i.e. there are so many retransmissions that the throughput is reduced to almost nothing (the upstream value is not valid due to a driver issue).
However, the spectrum data may be more interesting. Could you upload the graphs that are created by the application? (As uploading SVG files is not allowed here, it may be easier to use the GUI or web interface and create a screenshot. That would also give you minimum/maximum lines in the SNR graph which might be useful.)
Of course, it as also possible there is just an issue with this particular device, as others already suggested. That's why it would be useful to know if you have used another modem (or this device with vendor firmware) before on this line.
Speedport entry/entry2, however ZYXEL VMG1312-B30A currently are dead cheap on e-bay and will work well on DTAG lines (DTAG used to offer these for business customers), the only draw back is this router only has 100 Mbps ethernet ports so on a 100/40 access link (with maximum sync of 116.8 Mbps) you will not get the maximum throughput as ethernet limits you to something in the range of ~95 Mbps, but with your 50/10 speed that is no problem at all and the zyxel's broadcom modem (while not supported by OpenWrt) harmonized pretty well with DTAG's broadcom linecards...
1 Like
@janh these are the graphs I got this morning. can you make something of them?
Unfortunately... it looks like I have killed the Fritz!Box7412 by messing up the flashing process. I had the idea that an earlier version of OpenWrt reported to be working bould be a good idea.
Trying out a different router, which also seems to connect briefly, then disconnect. Which encourages me that the error is not on my side...
I'm not entirely sure what to make of this, but maybe the slight dip at ~10 MHz with relatively flat area afterwards could be an indication of a bridge tap with short branch length (only around 5 meters or so)?
A common type of bridge tap are multiple phone sockets wired in parallel, so it might be worth checking for those.
Unless you managed to overwrite the bootloader (which should be impossible from OpenWrt as the partition is marked read-only), it should always be possible to recover using the same method you used to install OpenWrt in the first place.
You should avoid using any older releases of OpenWrt, as vectoring only works properly since 22.03. Any older version will only make the stability of the DSL connection worse.
2 Likes
For best performance of any DSL, it's important to find the point in the wiring that is closest to the phone company (that you have legal access to) and connect the modem there. Disconnect any existing leftover wiring in the house from that place, so there is just one pair of wires straight from the modem to the phone company. The link should be short, and as much as possible done with modern cat rated twisted pair wire.
(Unless you also have combined analog service on the line, which I don't think is common at all any more. Then you should install a DSL filter at the tee to the modem and connect all analog phones and wiring to the filtered side of the filter.)
2 Likes
Speedport entry/entry2, however ZYXEL VMG1312-B30A currently are dead cheap on e-bay ...
Thanks for the tip. Do you mean these modems with OpenWrt or as they are?
Those are (both, zyxel and speedport) broadcom based, they aren't supported by OpenWrt and will never be - but they are cheap and plenty, and can do a decent job as mere VDSL modem (as they are, with their OEM firmware, not as router, but as pure modem). They are designed as (business-) xDSL modems (modem-only, in front of a more capable (business-) router), while they technically can be configured as router as well, that mode is just an afterthought and not recommended.
1 Like
None of these support OpenWrt, but they can be configured as bridged-modems, so that OpenWrt terminates the PPPoE link. The speedport in bridge mode will give you very little diagnostics, the Zyxel can be queried with DSLstats to get reasonable diagnostic plots...
However if you want a OpenWrt all in one, have a look at fritzbox 7520 or 7530, which can run OpenWrt snapshots.... I just got a 7520 and literally installed it as OpenWrt-based bridged modem today (to replace a somewhat suspicious BT HomeHub5A doing duty as OpenWrt bridged modem as well) pretty sweet given that I payed 45EUR (including shipping) on ebay...
Dear all,
the Fritz!Box 7412 has now been running successfully at about 25-30 Mbit/s for about 2 days and a max of 35 Mbit/s (the line is supposed to do 50Mbit/s). I will post the exact settings below. We will see in the future if 50Mbit/s is possible with this setup.
However, the main reason for the recurring failure and slow speed lies outside the house: It turns out the line of this flat was probably not used by the previous tenant (it is believed they had no internet at all). The additional load that came basically with us moving in and using the line caused the lines in the bundle to interfere more with each other than at any time ever before. This also explains why the neighbours started having issues (regular disconnect/reconnects but apart from that full speed).
It took 3 visits of a technician to get to this point.
Also, D-Telekom reported short circuits on our line during the days of this thread. I don't know what changed in the meantime so that we went from very short connects to now having at least stable ~30Mbit/s.
So, as a result, the local authorities are supposed to come by and tear open the street to get rid of the interference - I'm cautiously excited about what exactly will happen.
You were of course right with that, and I was happy to find that the initial failure to apply the same procedure was only due to my host PC's networking device (a Raspberry Pi then did the trick).
Thanks for that info, too, I would not have guessed.
I then did try another router btw., only to find similar issues (constant connect-reconnect cycles).
Thanks and credits to @janh @_bernd @mk24 @slh @moeller0 to get together these settings which now seem to be a good way to go with OpenWrt and Fritz!Box 7412 for DTAG:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd03:83c4:***::/48'
config atm-bridge 'atm'
option vpi '1'
option vci '32'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
config dsl 'dsl'
option annex 'b'
option tone 'bv'
option xfer_mode 'ptm'
option line_mode 'vdsl'
option ds_snr_offset '0'
option firmware '/usr/lib/modules/firmware/5.9.1.4.0.7-5.9.0.D.0.2/vr9-B-dsl.bin'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan'
config device
option name 'lan'
option macaddr '7C:FF:4D:**:**:**'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device
option name 'dsl0'
option macaddr '7C:FF:4D:**:**:**'
config interface 'wan'
option proto 'pppoe'
option ipv6 '1'
option device 'dsl0.7'
option username '<Zugangsnummer>@t-online.de'
option password '<password>'
config interface 'wan6'
option proto 'dhcpv6'
option device 'dsl0.7'
option reqaddress 'force'
option reqprefix 'auto'
config device
option type '8021q'
option ifname 'dsl0'
option vid '7'
option name 'dsl0.7'
config switch_vlan
option device 'dsl0'
option ports '0t'
option vlan '7'
I guess you mean Mbit/s above?
But that is partially what vectoring is supposed to help with, so there probably is still an additional problem in action, like a hardware problem with the wires ("abgesoffene Muffe" short circuits) or some EM noise sources like PLC powerline adapters in use by some party in your house. (PLC is not "bad" per se, but it uses the same frequencies that DSL does albeit at higher levels and hence can easily interfere with VDSL, while VDSL signals typically are too weak to affect PLC, I say this categorically without knowing whether PLC is actually in use, because this is not a totally uncommon situation, as PLC is quite a convenient solution if one wants to avoid cables/wires in one's apartment).
Absolutely!
Well I have little understanding of everything happening from the phone socket and beyond, but I can tell the technician did measure the problem between the main distributing box in the basement to the distributor on the street (~550m), so I guess that's outside any of the house's tenants' reach? According to him the line between our phone socket and the basement is fine.
PLC only interferes when in use (so when traffic is flowing) and can be an additional problem...
Do you have any recollection what he measured there and what measurement tool he used?
A rather big box with two wires and a screen, the spectrogram looked similar to that of @janh 's tool... That's all I can tell :-/ . But he did measure the same speed as my FritzBox shows when conencted, as well as a similar number of of connection errors (in the 1000s range).
1 Like
Wow. I was under the impression that around 100 m from the basement to the DSLAM was the supposed maximum... I had no idea. Maybe I'm really lucky that all my flats where just in sight of the DSLAM an never further apart then max. 50 m.
Good to hear that there was a somehow good outcome in the end.
That might be Nahbereich, with the DSLAM/MSAN sitting in the central office/Vermittlungsstelle (or it might not, IIRC the maximum length for those is in the reported 550m range, but that alone is proof of nothing 
)
The idea behind the Outdoor-DSLAMs was/is to reduce the length of the copper section of internet access links, so the aim is certainly to keep that as short as possible, it is just sometimes that the "as possible" is way longer than desirable
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.