| Message ID | 1449088692-4597-2-git-send-email-a.heider@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
Am 02.12.2015 um 21:38 schrieb Andre Heider: > Unused since r46920. I think the removal of the tone setup in r46920 should be reverted. It is still the only way to exactly control which pilot tones are sent by the DSL firmware. I would not trust the default setting of the dsl_cpe_control daemon. Especially in Germany you may not send a V43 tone on a Deutsche Telekom port according to 1TR112 specification, only B43 is allowed. > > Signed-off-by: Andre Heider <a.heider@gmail.com> > --- > target/linux/lantiq/base-files/etc/uci-defaults/02_network | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/target/linux/lantiq/base-files/etc/uci-defaults/02_network b/target/linux/lantiq/base-files/etc/uci-defaults/02_network > index b22060c..4974b48 100644 > --- a/target/linux/lantiq/base-files/etc/uci-defaults/02_network > +++ b/target/linux/lantiq/base-files/etc/uci-defaults/02_network > @@ -41,13 +41,11 @@ EOF > set_vdsl_modem() { > local annex=$1 > local firmware=$2 > - local tone=$3 > local xfer_mode=$4 > uci batch <<EOF > set network.dsl='vdsl' > set network.dsl.annex='$annex' > set network.dsl.firmware='$firmware' > -set network.dsl.tone='$tone' > set network.dsl.xfer_mode='$xfer_mode' > EOF > } > @@ -198,7 +196,7 @@ esac > [ -z "$(ls /lib/modules/`uname -r`/ltq_atm*)" ] || set_atm_wan "$vpi" "$vci" "$encaps" "$payload" > > if [ -n "$(grep "system type.*: VR9" /proc/cpuinfo)" ]; then > - set_vdsl_modem "$annex" "/lib/firmware/vdsl.bin" "av" "ptm" > + set_vdsl_modem "$annex" "/lib/firmware/vdsl.bin" "ptm" > else > set_adsl_modem "$annex" "/lib/firmware/adsl.bin" > fi >
Hi, On Wed, Dec 2, 2015 at 10:07 PM, Daniel Schwierzeck <daniel.schwierzeck@gmail.com> wrote: > I think the removal of the tone setup in r46920 should be reverted. It > is still the only way to exactly control which pilot tones are sent by > the DSL firmware. I would not trust the default setting of the > dsl_cpe_control daemon. Especially in Germany you may not send a V43 > tone on a Deutsche Telekom port according to 1TR112 specification, only > B43 is allowed. works for me, but then I'm not an expert on DSL internals. On the other side, how do vendor firmwares handle that? It's been some time I looked at one, but I don't remember seeing a dsl tone setting. Regards, Andre
On 03/12/2015 09:07, Andre Heider wrote: > Hi, > > On Wed, Dec 2, 2015 at 10:07 PM, Daniel Schwierzeck > <daniel.schwierzeck@gmail.com> wrote: >> I think the removal of the tone setup in r46920 should be reverted. It >> is still the only way to exactly control which pilot tones are sent by >> the DSL firmware. I would not trust the default setting of the >> dsl_cpe_control daemon. Especially in Germany you may not send a V43 >> tone on a Deutsche Telekom port according to 1TR112 specification, only >> B43 is allowed. > > works for me, but then I'm not an expert on DSL internals. > On the other side, how do vendor firmwares handle that? It's been some > time I looked at one, but I don't remember seeing a dsl tone setting. > > Regards, > Andre independent of it working, we are supposed to send B43 on DTAG lines. so we need to add back the tone settings. i noticed this as well last week while setting up a router and wondered where the tone settings had gone. John > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
Hi! On Thu, Dec 03, 2015 at 09:07:22AM +0100, Andre Heider wrote: > Hi, > > On Wed, Dec 2, 2015 at 10:07 PM, Daniel Schwierzeck > <daniel.schwierzeck@gmail.com> wrote: > > I think the removal of the tone setup in r46920 should be reverted. It > > is still the only way to exactly control which pilot tones are sent by > > the DSL firmware. I would not trust the default setting of the > > dsl_cpe_control daemon. Especially in Germany you may not send a V43 > > tone on a Deutsche Telekom port according to 1TR112 specification, only > > B43 is allowed. > > works for me, but then I'm not an expert on DSL internals. > On the other side, how do vendor firmwares handle that? It's been some > time I looked at one, but I don't remember seeing a dsl tone setting. Usually by differentiating firmware by target markets. Ie. depending on where you buy the device, you end up with different xDSL settings, similar to how allowed wifi channels are handled by most vendors as well. T-Com-land has always been a bit special in many regards and there are only very few xDSL-cabable devices being sold on the streets. VDSL2 made things a bit easier and if you are on a VDSL2 port, things may just work regardless. However, ADSL2+ is still being used as well, especially in rural areas, and depending on the condition of last-mile copper-pair also as a fall-back whenever the line is too bad for VDSL2. I reckon in order to support such things nicely in OpenWrt, we'll need something like by-country-by-carrier config templates, so users will only have to select their carrier+ISP and enter their credentials. In technically more advanced areas of the world, law-makers have decided to enforce a clean separation of access-network-infratructure (xDSL, DOCSIS, GPON, ...) and ISP services. In those markets a user will have to select her access-network as well as ISP, as all combinations on both layers are possible. Having a schema to cover-them-all would be nice, this is as far as I got for now: infrastructure-specific parameters: * xDSL tones and annex * VTI/VCI for ADSL * 802.1Q VLAN(s) for VDSL * MTU * infrastructure may provide IPTV (multicast) or VoIP services idenpendently of the ISP chosen. isp-specific parameters: * 802.1Q VLAN(s) for VDSL may differ for ISPs as well * layer-2 management protocol: DHCP, PPPoE, PPPoL2TP, ... * authentication mode: CHAP/PAP for PPP-based, 802.1X, ... * addressing mode: v4-only, dual stack, DS-lite, ... * multicast mode * DNSsec? * IPsec? * IP mobility? * ... Cheers Daniel
Hi, On Thu, Dec 3, 2015 at 10:46 AM, Daniel Golle <daniel@makrotopia.org> wrote: > Usually by differentiating firmware by target markets. > Ie. depending on where you buy the device, you end up with different > xDSL settings, similar to how allowed wifi channels are handled by most > vendors as well. > T-Com-land has always been a bit special in many regards and there > are only very few xDSL-cabable devices being sold on the streets. > VDSL2 made things a bit easier and if you are on a VDSL2 port, things > may just work regardless. > However, ADSL2+ is still being used as well, especially in rural areas, > and depending on the condition of last-mile copper-pair also as a > fall-back whenever the line is too bad for VDSL2. > > I reckon in order to support such things nicely in OpenWrt, we'll need > something like by-country-by-carrier config templates, so users will > only have to select their carrier+ISP and enter their credentials. maybe, well it does sound like a nice solution, but then someone has to maintain and update those templates. Reviving the tone setting, as John and you agree on, would be the first step then. Which makes this patch redundant, so please ignore it. Regards, Andre
On 03/12/2015 12:07, Andre Heider wrote: > Hi, > > On Thu, Dec 3, 2015 at 10:46 AM, Daniel Golle <daniel@makrotopia.org> wrote: >> Usually by differentiating firmware by target markets. >> Ie. depending on where you buy the device, you end up with different >> xDSL settings, similar to how allowed wifi channels are handled by most >> vendors as well. >> T-Com-land has always been a bit special in many regards and there >> are only very few xDSL-cabable devices being sold on the streets. >> VDSL2 made things a bit easier and if you are on a VDSL2 port, things >> may just work regardless. >> However, ADSL2+ is still being used as well, especially in rural areas, >> and depending on the condition of last-mile copper-pair also as a >> fall-back whenever the line is too bad for VDSL2. >> >> I reckon in order to support such things nicely in OpenWrt, we'll need >> something like by-country-by-carrier config templates, so users will >> only have to select their carrier+ISP and enter their credentials. > > maybe, well it does sound like a nice solution, but then someone has > to maintain and update those templates. > had a chat with hauke about this last night and the list of options that daniel listed is pretty much what i though of aswell. this would also be able to integrate nicely with the new config-generate infrastructure we have. i'll try to cook up a json scheme for storing the info during the weekend > Reviving the tone setting, as John and you agree on, would be the > first step then. > Which makes this patch redundant, so please ignore it. thanks ! > Regards, > Andre > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
diff --git a/target/linux/lantiq/base-files/etc/uci-defaults/02_network b/target/linux/lantiq/base-files/etc/uci-defaults/02_network index b22060c..4974b48 100644 --- a/target/linux/lantiq/base-files/etc/uci-defaults/02_network +++ b/target/linux/lantiq/base-files/etc/uci-defaults/02_network @@ -41,13 +41,11 @@ EOF set_vdsl_modem() { local annex=$1 local firmware=$2 - local tone=$3 local xfer_mode=$4 uci batch <<EOF set network.dsl='vdsl' set network.dsl.annex='$annex' set network.dsl.firmware='$firmware' -set network.dsl.tone='$tone' set network.dsl.xfer_mode='$xfer_mode' EOF } @@ -198,7 +196,7 @@ esac [ -z "$(ls /lib/modules/`uname -r`/ltq_atm*)" ] || set_atm_wan "$vpi" "$vci" "$encaps" "$payload" if [ -n "$(grep "system type.*: VR9" /proc/cpuinfo)" ]; then - set_vdsl_modem "$annex" "/lib/firmware/vdsl.bin" "av" "ptm" + set_vdsl_modem "$annex" "/lib/firmware/vdsl.bin" "ptm" else set_adsl_modem "$annex" "/lib/firmware/adsl.bin" fi
Unused since r46920. Signed-off-by: Andre Heider <a.heider@gmail.com> --- target/linux/lantiq/base-files/etc/uci-defaults/02_network | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)