Ok thanks @anon50098793
Your hard work is appreciated 
2 Likes
stable uptodate: 3.5.101-5
I want to ask, some time ago you mentioned pppoe issue. Is it still there? Because I have been noticing desync during downloads.
just passed the pee-pee-pee-ow-wee report on... (no idea on particulars... most others did not concur)
ideas;
- isp is intervening to treat download addiction
- modem is overheating (summer?) or component failing/flapping on load
- power comes onto the picture... but hard to pin down and less likely
- keep an eye out on the forum for mass reports / try 21.02.1
- (line quality is always worth keeping an eye on for dsl regardless)
1 Like
hi. seeking for help. again.
i have slow wireguard speeds. havent noticed it instantly. probably since two days.
i did not changed config on purpose.
it used to be good. when i test the same wireguard config on another device, speed is good.
i am currently at 101-5, also tried downgrading to 75-7 with no luck.
is it possible that there is something limiting the bandwidth/rate? it seems to be capped at 40mbit.
as said if i try the same wireguard config on another device (not rpi4) speed is good.
and it was always as good on rpi4 too before.
all qos and sqm stuff is disabled.
1 Like
grep wireguard /etc/crontabs/root
21.02.1 ( 'release' ) would be the next point of call
UPGRADEsFLAVOUR="release" at /root/wrt.ini
(or wait for other build users to report similar issues or absence of - i.e. latent config complications )
there is apparently a master target related issue discussed here: https://github.com/openwrt/packages/issues/16773 which may or may not be related... although I would not expect if this was related for failures to be silent drop in throughput
1 Like
no output, does not return anything.
1 Like
ok. thanks.
1 Like
one more issue.
When I am downloading torrents Luci refuse to work. It just stays stuck in loading screen, for Microsoft edge but for Firefox it does load after some time.
is this 'over' the router or 'on-to' the router?
Can you please explain what you meant by these terms? I have no idea.
I am downloading torrents on my local machine. If thats what you are asking.
1 Like
yes... that would be 'over' ( files are not saved on router )...
ideas
can't really say for sure... especially considering your bandwidth afaik is not anything massive...
I know that;
- high connection counts crash realtime graphs / rpcd ( low chance this is related here )
- high disk write levels slow if not cripple luci ( excluded here )
May take some time to identify... the only really new thing which may have some background influence is nft-qos ( monitor ) if you enabled it... so might be worth stopping and disabling that to test...
The fact that one browser sort of works better than another tho', leads me to think this is more of a 'core luci' not build related change...
But does seem to tie in with the occasional css fail to loads symptoms...
Worst case scenario... drop down to 'release' 21.02.1... suspect these issues would be better there...
or drop your max connection counts / bandwidth in your torrent client and see if that helps...it was always like that even without nft-qos
I have lowered speeds to only 100KB still luci refuces to load on edge browser.
something to do with Microsoft defender?
and what is this error?
Error
XHR request aborted by browser
1 Like
wish I knew more... all I can say right now is that firefox is most immune to these XHR timing/proto-redir related quirks...
where they came from I can't really put my finger on... looks like you are using bootstrap... and i've not seen them there yet... suspect what you are seeing is a combination of these and some load related pressures...
1 Like
Hey wulfy23, is there any chance of the previous 75 image being available until the new Argon glitches get fixed?
I find it rather hard to use with all the tight spacing.
Thanks!
new argon is no longer the default
previous images are found: https://rpi4.wulfy23.info/builds/legacy/
2 Likes
You are, once again, awesome. Thanks!
1 Like
@anon50098793 sorry for off topic
but can you please tell me what banIP source to use? is it good to turn on?
and can you use both simple ad block and banIP
no expert but i've been running these lists for 12+months and they've worked well for me;
list ban_sources 'bogon'
list ban_sources 'darklist'
list ban_sources 'debl'
list ban_sources 'drop'
list ban_sources 'dshield'
list ban_sources 'firehol3'
list ban_sources 'threat'
list ban_sources 'voip'
list ban_sources 'yoyo'
simple-adblock + banip should work together...
the thing with banip is... as openwrt is typically closed from the outside... what it's mostly catching is rogue client traffic on a typical home install... ( still really good... )
i'd recommend everyone enable and run it... on our devices it's no sweat for it... and it's an extra layer to keep out / be aware of dubious transmissions, that's pretty much a set and forget service... with little to no false positives...
3 Likes
kinda ot. pardon me.
i am in a bit of a dead end for me.
i am running latest snapshot, r17900.
rpi4 is a wireguard client.
i can ping ip's and domains from clients connected to lan-side of rpi4 inside of the vpn and wan-side.
so the wireguard tunnel works and internet works.
but i still can't access any websites. opkg update and the rpi4 update-check also don't work.
so its seems like dns-problem, but pinging ip's works, so does pinging domains, they get resolved...
it is clearly not build releated, but i already wasted 2 nights.
maybe someone has any ideas to try. already messed with mtu of wireguard and nat-rules with no success.
thanks in advance.
first thing i'd say is to run 'release' (21.02.1)...
UPGRADEsFLAVOUR="release"
verbage
i'm just not that confident in master at the moment (when it comes to wireguard I also had a failed attempt in the last few days on r17900 but I'm not super familiar with wireguard so was difficult to pin down cause)...
basically at the moment 'stable' means;
the most functional recent master without getting too old
in the RELEASE_NOTES you'll see some comments about potential reported wg issues... which are a good indicator to drop down to 'release' if you require wg, nmap, zerotier...
after you whack on 'release'... then you should probably create a new thread with all the troubleshooting specifics... (the kind of information I posted in the link above)
not sure if I should assign 21.02.1 to everyone on 'stable' although that makes sense in principle given the above issues (if they are proven to be non user-level)...
- users are free to run 'release' at any time...
- alot of people are still getting by on r17900
and current/stable have always been master based... just happens that at the moment... issues are piling up in these...
could be fixed tommorrow but I get the feeling we are likely looking at month/s before master is sufficiently robust across the board... ( have not been able to build it for some time due to wpa-cli missing in action ) (edit: fixed thankyou!)
see: request for help with several issues on master (woohoo this is also now fixed as of r18086)
there is also this: wifi hangs console issue to be aware of for anyone on master using wifi... (edit fixed thankyou! )
there are only 3 key issues i'm aware of on 21.02.1 (not mentioning the packages repo i.e. new or small fixes to packages)
- overlay problem with squashfs (does not effect us)
- auc segfault (does not effect us)
- bootstrap header is aligned left (localfix implemented)
- wifi wont work by default on CM4 WIFI boards (localfix implemented)
- stage2 'out of range' bug (localfix implemented) ( edit: fixed today yay )
- luci docker blk_io_weight bug ( workarounds exist )
- routing repo: naywatch will crash your router
so if you dont install naywatch... all is ok...
1 Like