Configuring LEDE router with a PPPoE Modem/Router

@RogueWolf sqm should be independent of the ATM QOS settings (at least there should be a set of sqm parameters that make both independent). Please let me know whether you still have sqm issues, I would be happy to assist in getting sqm-scripts configured satisfactorily.

Best Regards

P.S.:

This is not how one should configure this, independent of the netmasks you should use fully separate networks, so if the dlink is set to 192.168.1.0/24, then set the lede router to say 192.168.2.0/24, so make sure to not use overlapping ranges...

I think you havent noticed the > 191.168.1.1 on the Archer C7 IP adress. Dlink2730b is > 192.168.1.1

By the way,I'm having trouble finding the Peak Cell Rate (PCR) value that adapts to my connection,I found this https://supportforums.cisco.com/discussion/9521626/calculating-atm-vbr-rt-peak-cell-ratepcr-kbps

P.S.:
I also found this!
http://www.calculator.org/property.aspx?name=data+rate

I missed that also - the info I gave will -not- apply, unless both devices ( modem and router ) are in the "192" segment ..

IIRC, there is a hard 'boundary' between the class B / class C networks, so trying to include (both) using a Netmask will be problematic:

AFAIK, a class B 191.xx.xx.xx "255.255.0.0" netmask will not "see" / talk to a class C 192.xx.xx.xx segment, without some additional form of help, such as a specific route definition.

Edit: A "191" octet is considered a "Public" Class-B network address: it should not be used internally, the "192" Class-C network address range is specifically defined as a (Private) network range, so this range is defined / recommended for internal (Private) network use.

Ah, right I had not noticed that. BUT 191.168.0.0/16 is not a valid private address, so unless you are a customer of Tim Celular S.A. in brazil you better not use this in your private network...

whois 191.168.1.1

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#


#
# Query terms are ambiguous.  The query is assumed to be:
#     "n 191.168.1.1"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=191.168.1.1?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#

NetRange:       191.0.0.0 - 191.255.255.255
CIDR:           191.0.0.0/8
NetName:        NET191
NetHandle:      NET-191-0-0-0-0
Parent:          ()
NetType:        Allocated to LACNIC
OriginAS:
Organization:   Latin American and Caribbean IP address Regional Registry (LACNIC)
RegDate:        1993-05-01
Updated:        2010-07-21
Ref:            https://whois.arin.net/rest/net/NET-191-0-0-0-0

ResourceLink:  http://lacnic.net/cgi-bin/lacnic/whois
ResourceLink:  whois.lacnic.net

OrgName:        Latin American and Caribbean IP address Regional Registry
OrgId:          LACNIC
Address:        Rambla Republica de Mexico 6125
City:           Montevideo
StateProv:
PostalCode:     11400
Country:        UY
RegDate:        2002-07-27
Updated:        2011-09-24
Ref:            https://whois.arin.net/rest/org/LACNIC

ReferralServer:  whois://whois.lacnic.net
ResourceLink:  http://lacnic.net/cgi-bin/lacnic/whois

OrgAbuseHandle: LACNIC-ARIN
OrgAbuseName:   LACNIC Whois Info
OrgAbusePhone:  999-999-9999
OrgAbuseEmail:  whois-contact@lacnic.net
OrgAbuseRef:    https://whois.arin.net/rest/poc/LACNIC-ARIN

OrgTechHandle: LACNIC-ARIN
OrgTechName:   LACNIC Whois Info
OrgTechPhone:  999-999-9999
OrgTechEmail:  whois-contact@lacnic.net
OrgTechRef:    https://whois.arin.net/rest/poc/LACNIC-ARIN


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#


% Joint Whois - whois.lacnic.net
%  This server accepts single ASN, IPv4 or IPv6 queries

% Brazilian resource: whois.registro.br


% Copyright (c) Nic.br
%  The use of the data below is only permitted as described in
%  full by the terms of use at https://registro.br/termo/en.html ,
%  being prohibited its distribution, commercialization or
%  reproduction, in particular, to use it for advertising or
%  any similar purpose.
%  2017-07-29 14:27:37 (BRT -03:00)

inetnum:     191.168.0.0/14
aut-num:     AS26615
abuse-c:     TISOC3
owner:       Tim Celular S.A.
ownerid:     04.206.050/0001-80
responsible: Nelson de S?
country:     BR
owner-c:     MAN173
tech-c:      TISOC3
inetrev:     191.168.0.0/14
nserver:     snepns01p01.isp.timbrasil.com.br
nsstat:      20170729 AA
nslastaa:    20170729
nserver:     snepns01p02.isp.timbrasil.com.br
nsstat:      20170729 AA
nslastaa:    20170729
created:     20131024
changed:     20161013

nic-hdl-br:  MAN173
person:      Marcello do Nascimento
e-mail:      marcello@daviddonascimento.com.br
country:     BR
created:     20000515
changed:     20170203

nic-hdl-br:  TISOC3
person:      TIM SOC
e-mail:      abuse@timbrasil.com.br
country:     BR
created:     20090826
changed:     20091110

% Security and mail abuse issues should also be addressed to
% cert.br, http://www.cert.br/ , respectivelly to cert@cert.br
% and mail-abuse@cert.br
%
% whois.registro.br accepts only direct match queries. Types
% of queries are: domain (.br), registrant (tax ID), ticket,
% provider, contact handle (ID), CIDR block, IP and ASN.
hms-beagle2:~ smoeller$
1 Like

Back to your sqm issues, double NAT or even ATM level QoS should not affect a properly configured sqm instance, so could you please post the output of:
cat /etc/config/sqm

Best Regards

For this ATM level QoS to have any effect your ISP need to support it on his gear too... But properly configured sqm will not cause your modem to create a queue and hence should completely side step the ATM level QoS issues. (Almost on ingress you might still see some residual effects of it but on ingress it is mostly your ISP that would need to configure it).

Best Regards

I managed to do everything works, according with @RobertH guide, The only issues remaining are SQM QoS not working, and my Lan plugged computer not being able to get a IP from the router (every single wifi device works great),I have to manually set a IP on IPV4 Adapter's setting's, what makes my device unable to acess the Dlink2730b,while other devices that are receiving a automatically IP adress can.

Oh by the way, I used Service Category CBR - PCR:1460 on the e ATM setting,it required a number between 1-1460, I saw no difference at all,so I'm currently using CBR-1460. Thanks for helping!

I am not fully convinced your use of 191.168.X.X really is kosher, but...

Please post the output of:
cat /etc/config/sqm
(from the cli of your router) to get things started...

Best Regards

I'm using Archer C7 192.168.1.1
Dlink2730b 192.168.0.1
Both with 255.255.255.0

config queue
option verbosity '5'
option qdisc 'fq_codel'
option script 'simple.qos'
option linklayer 'none'
option enabled '1'
option interface 'pppoe-wan'
option download '5600'
option upload '500'
option debug_logging '1'
option qdisc_advanced '0'

I also tried cake w/ piece.of.cake, no change at all.
My actual internet speed is 572kbytes down/56kbytes up
but in practice i get 630kbytes down(Peak)/60kbytes up(Peak)

Of course,talking about a 5Megabits plan.

Ah, finally got it, That looks correct (but entails double NAT)

Okay, from /etc/config/sqm I see that you are running a pretty basic configuration that can be tailored much better to your link. Most of that is covered by https://lede-project.org/docs/howto/sqm but in short on an ATM link you have to deal with 9% encoding cost as well as weird ATM cell quantization effects, the best you can do is to tell sqm that you are using an ATM link by going to the "Link Layer Adaptation" tab in the sqm GUI and set the field labeled "https://lede-project.org/docs/howto/sqm" to "ATM..." that will take care of the static 9% loss as well as cell quantization. Now for this to work well you also need to select the correct overhead (Per Packet Overhead (byte):); a conservative vaue to start with would be 48 bytes (one full ATM cell payload); but if you have time try follow the instructions given at https://github.com/moeller0/ATM_overhead_detector to actually empirically deduce the per-packet-overhead on your link and put that value into the GUI field.

How did you measure these values and more importantly what are the sync values your modem reports? As the first things to get right is the applicable bandwidth and link layer adjustments, everything else, like selection of qdisc and script really are secondary (or rather only make sense after getting link layer and bandwidth approximately right).

But before you embark on this quest, please also post the output of:
tc -d qdisc
tc -s qdisc
tc class show dev pppoe-wan
tc class show dev ifb4pppoe-wan
to get an idea about the current starting point.

It would also be a good idea to record measurements along the way to document test whether/which configuration changes have hich effects. I would recommend to follow the advise given in https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 for which speedtest to use and how to configure that test.

Happy de-bloating!

Best Regards

Sorry for too many doubts,but my lan pc still with problems,I can't connect to some sites(netflix,microsoft,even lede-project.org)with my computer(timed out),can't leave it to get an automatic ip,otherwise it won't connect(I have to assign an IP)
Also,there are some services like uplay and discord,that I can't connect on all devices!
Probable my informations aren't that accurated,but I would like to fix that first!

P.S.:Is that correct?

Okay, you have no working IPv4 DNS servers on the archer, so expect issues for computers using DNS servers distributed via DHCP from that archer. For a test try to configure your PC to use 8.8.8.8 (google's dns service) instead of DHCP supplied DNS, this might work, if you actually have IPv4 connectivity at all. Please report back whether that worked out okay...
(I still believe the best for your setup would be to relegate the "modem" to pure modem duty and have your archer handle the PPPoE connection all by itself)

Best Regards

I cant even acess the router from my pc set to get automatic ip adress.