The OP can't fix RF pollution if the cable modem is not accessible.
IMO, the fix is to get a device you can control...
Approved up to 100 Mbps (OP needs to find out what tier he's on) -
??? First, let's see whether this is the root cause or not, maybe switching his router to a different channel can already help, but for that we would need to see information about his RF environment. I guess until @Kampfkarren re-joins the thread I will stay quiet...
If nothing is connecting to the cable modem, the amount of RF pollution is
minimal, "I exist" broadcasts are small.
David Lang
Which it appears, is never the case...
Okay, but that is easy to tests, simply wrap the ISs modem router in aluminum foil to effectively disable its RF output (if need be be ground the foil). That should certainly silence that sucker. But from my reading it is not at all clear, that the other users went around the OP's wrt1900ACS, he simply stated that there was traffic he could not "silence"...
other devices using the Internet != other devices connecting the the cable modem
supplied wifi.
but even if there are people connecting to the cable modem wifi, all you have to
do is set the LEDE to a different (suitable) channel, just like you would to
avoid an AP in the apartment next door.
It still doesn't result in a 'nothing you can do until you replace the
cablemodem' situation.
Don't see where that was stated.
All of these mental gymnastics are interesting, and maybe fun for those who really enjoy deep dive troubleshooting
It's the OP's call how he wants to continue.
If he were my client, I would recommend getting a device he can control, whether he wants to bridge or not.
The next time he needs to get access to the cable modem, it's one less complication.
I'm out.
Don't see where that was stated.
It seemed to be that the conversation was focusing on replacing the cablemodem
to the point that it was at least implying, if not outright stating, that he
should either replace the cablemodem, or revert to stock firmware, there was no
path forward with LEDE until the cablemodem was replaced.
If that wasn't what you are intending, my apologies. But that's what I was
understanding from the posts.
David Lang
Okay, following https://forum.openwrt.org/t/getting-bad-bufferbloat-sqm-only-makes-it-worse/10396/89?u=moeller0 OP owns a cisco DPC3216,. According to https://www.cisco.com/c/dam/en/us/td/docs/video/at_home/Cable_Modems/3200_Series/Cisco-Model-DPC3216-and-DPC3216C-DOCSIS-3-0-16x4-Cable-Modem-with-Embedded-Digital-Voice-Adapter-User-Guide.pdf it does not look like this device actually has a wifi radio, so let's skip the packing in tin-foil part and go straight to measuring the WIFI surround and signal strength from computer at its normal position to the router (and the load on the router with concurrent traffic shaping and wifi).,,
Best Regards
P.S.: as far as I know most DOCISIS modems will respond as 192.168.100.1 on their "lan" interface, while this might not give you administrative access, it might reveal a bit more over the modem's options and configuration.
Hello.
Thanks to everyone who went through the time and effort to help me. However, as of writing this, I have switched back to the old firmware. I do not think LEDE is for me at this time.
Ah, fair enough, but could I convince you to run both a wired and a wifi dslreports speedtest (the wifi one from the exact position where you had the less than stellar lede results from), please?
If you do, could you follow the instructions in https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 how to post a link to the detailed results, please?
And finally it would be awesome if you could also post a link to the detailed result from either the good lede wired speedtest or/and the abysmal lede -wifi speedtest, that way I might get a glimpse of what might be wrong.
The reason why I ask is that this thread will from now on show up for people searching for SQM and bufferbloat, so I would like to have some closure on whether sqm was to blame or not...
And sorry for all the confusing side-conversations going on in your thread...
Best Regards
Lots of "bufferbloat" info on the forums...
https://forum.openwrt.org/search?expanded=true&q=bufferbloat
Yes, so it seems; my observation is that it is the unresolved cases that people stumble over, and I really want to avoid leaving false impressions.
From my understanding, the OP was/is suffering from bad wifi with lede, while the topic/title pins this on sqm, so I would like to have this addressed rather now than having to re-hash this in a later thread.
Otherwise this acts like (at least some of) the reports at the dslrepost forum about problems with the speedtest 
(too little data to asses the severity and now real conclusion/closure).
The resolution for this specific issue has been posted by the OP.
Some do revert back to stock and later on, try again...others not.
Starting from a clean slate is sometimes the best way to go.
Have a good day.
1 Like
With all due respect for @Kampfkarren and his decision, calling this a "resolution of the specific issue" seems a bit euphemistic. IMHO, the issue has been side-steped/avoided but not resolved, you are free to differ though. But be that as it may, I still would appreciate if @Kampfkarren could post the results of the speedtests with the stock firmware.
I am aware of that, and as you might notice, I did not try to convince the OP to change his decision, all I am asking for is like two more minutes of his time to run and post the speedtests. This, BTW, is only possible due to his decision to revert...
We violently agree ;).
The OP decides that, and apparently has.
I agree, and here I am 6 years later with the similar problem and this is only topic I found with a similar description in the title, but using cable and my problem maybe is the interface, is wan selected (vlan translation by bridged ont).
I created a topic about my case, but now I've tried all the interfaces and I wasn't successful, choosing the "br-lan" interface inverts the download and upload sqm limits, I don't know why, but it's still worse than my results with original firmware., when expected would be better with cake+piece_of_cake.
This is easy to answer, each ethernet/network interface typically has two functions receive data (called ingress) and transmit data (called egress), sqm attaches one qdisc to the egress side and one to the ingress side (since Linux does not allow that directly, we have to use an IFB so we can construct a virtual egress for the veridical ingess side on which to attach the qdisc intended for ingress traffic).
In the typical configuration with sqm on the wan interface, sqm's ingress direction is aligned with the internet download direction and its egress direction with the internet upload direction.
However if instantiated on a LAN interface the ingress/egress directionality flips in regard to the internet directions. The verbiage in the GUI is intended to give enough intuition for the normal sqm on wan case, so only users with uncommon set ups need to wrap their head around the true directionality, the alternative would have been to explain this to everybody and hence complicate the normal case. Let's discuss your other problems in the new thread, okay (might take a while).
1 Like
Ok, I'll wait for you there when you can.