Rpi4 < $(community_build)

malikshi · 2021-11-30T07:00:17.501Z

malikshi:

I will do test with original adapter rpi4 tomorrow

Fix adjusted PCB stepdown mini ups.

malikshi · 2021-11-30T13:23:11.976Z

Lynx:

The script is designed to stay at the minimum set download and upload on zero load. Because without load the capacity of the connection is unknown. When there is a load it then increases the bandwidth until any RTT spike is detected, at which point it eases back.

So the idea is that it recovers otherwise lost bandwidth associated with having to set a compromise bandwidth which won't even work all of the time.

Thanks for detailed info. The schemes are good

@anon50098793 for this

-35) sqm-autorate re-enable using lynx's variant for rate logic

Is it fixed sqm hook with the script?

anon50098793 · 2021-11-30T13:32:37.235Z

procd_lock problem starting background script from sqm itself

i've spent the last few hours on it and thought it was fixed but have not nailed it yet...

maybe someone else knows what's going on... basically when the autorate script is spawned via sqm itself... (child process or something?) it hangs procd_lock() (so no subsequent stop/start/restart actions will run) maybe because it never exits or something...

starting it manually is ok... so i'll probably give up trying to start/restart from sqm soon unless someone knows a way around the lock problem...

and create a separate 'service' that spawns the autorate.sh scripts themselves... (and associated hotplug / other background detection of sqm service state change / reload sort of thing)

edit: updated the tar file to include a service 'autorate'

if you unzip the tar from '/' and enable and start the service;

/etc/init.d/autorate enable
/etc/init.d/autorate start

you can test it out... but it's very rough still in how it logs things etc. etc. ( it just runs sqm-autorate-init.sh start and sqm-auto-rate-init.sh stop but in silent mode... if you don't see something in ps wwww | grep autorate then just try those commands to start it yourself and see whats going on... it also has 'status' )

will likely take a week or so to properly iron out all the bugs...

Lynx · 2021-11-30T14:11:38.416Z

I am curious how you managed this. Did you put in restart call within the sqm service script? I wondered about that to address changes in sqm caused by interface going down and hotplug even restarting sqm, which should then restart the autorate service.

@Nomid are you presently using this community build for your funky RPi4 LTE setup? And how are you managing SQM for that? I am wondering about getting RPi4 myself like you have done. To replace my B818-263. Thing is the B818-263 works pretty well - with location optimisation (on its side next to window), I get these amazing stats:

anon50098793 · 2021-11-30T14:20:59.428Z

Lynx:

to address changes in sqm caused by interface going down and hotplug even restarting sqm, which should then restart the autorate service

if we can find a solution to the 'background script(s) running from sqm' issue described above... this would be the best way...

otherwise we end up monitoring state files from a secondary watcher 'daemon'... (or monitoring and reacting to ubus)

Lynx · 2021-11-30T14:27:36.257Z

At the moment I just use:

github.com

lynxthecat/sqm-autorate/blob/main/sqm-autorate

#!/bin/sh /etc/rc.common
# Copyright (C) 2007 OpenWrt.org

export PATH=/usr/sbin:/usr/bin:/sbin:/bin
export HOME=/root

exec &> /tmp/sqm-autorate.log

START=97
STOP=4

start() {
        /root/sqm-autorate.sh&
}

stop() {
        ps | grep sqm-autorate.sh | grep -v grep | awk '{print $1}' | xargs kill
}

And have set call to restart sqm-autorate inside SQM service script.

Isn't that enough?

sammutd88 · 2021-11-30T20:47:02.633Z

Running 151-32, login username/password persists after correct credentials entered. Bootstrap theme, is it theme related?

anon50098793 · 2021-11-30T20:51:32.920Z

yeah, i've seen this too (r18161)... thought it was due to some things i've been working on maybe... (nothing major really mostly the autorate stuff)... will run some test builds today with 'stable(edit:done r18086 is working ok)'+'next(edit: done r18217 worked ok)' and the current file mods to try to pin down where it's coming from...

edit: re-testing with r18161 first worked and then didn't which could mean the above tests are now void and need to be repeated more thoroughly... (bugger)

for a workaround you can ssh in and run /etc/init.d/rpcd restart

or

use an incognito/private-browsing window

or

just revert back to the stable version...

possibly related (tentative: i'm having a bad run so don't quote me on that)

sammutd88 · 2021-11-30T22:47:19.794Z

anon50098793:

possibly related (tentative: i'm having a bad run so don't quote me on that)

Sounds familiar!

sammutd88 · 2021-12-01T22:05:58.898Z

Just a general report, I've gone backwards to stable after experiencing inherently average network performance. I can't put my finger on it, but the network would "stall" and then come back to life consistently. Going back to stable has rectified the issue. I can't guarantee it was the firmware, but just thought I'd report f anyone else has similar issues.

rspierz · 2021-12-04T21:10:34.588Z

Just installed fresh this week on rpi4. One issue I have is if I issue a reboot takes 50 mins or more for the internet to come back online. I'm using ue300 dongle for lan and on board nic for wan. It's dhcp to fiber modem in bridge mode.

Not sure where to look to resolve this

anon50098793 · 2021-12-06T09:35:31.555Z

rspierz:

takes 50 mins or more for the internet to come back

suboptimal to say the least...

rspierz:

Not sure where to look to resolve this

best to start by stating which build version you are running... and any other customizations that may be relavent...

rspierz:

I'm using ue300 dongle for lan and on board nic for wan. It's dhcp to fiber modem in bridge mode.

this is good info... perhaps stating the ISP(company name) and modem version(model name) would also be relavent here...

probably a good time to remind peeps that 'current' is pretty experimental right now and has some known quirks (on my system they are relatively minor and managable but ymmv)

i've sort of been cheating for a while on github re: master version and only uploading the 'testing/current' so new users who have been downloading from github get 'current/testing'

this has generally been ok... but since r1806x-ish immediate downgrade/flash to 'stable'/'release' would be advised... (added benefit that your ROOTFS is expanded on the first upgrade anyway)

NOTE: the built in initial wrt.ini has UPGRADEsFLAVOUR set to 'stable' so you'd be prompted / track 'stable' if you click flash or check for updates[refresh] or whatnot anyway...

/dev/disk-by

fyi... one upcoming feature that's been added worth mentioning, especially for people who might plug alot of external disks...

i've added a 'quasi' debian like /dev/disk-by linker...

it's mostly for show really and only really functionally useful for a quick look or manually mounting and unmounting from a command line (temporarily would not rely on it for anything automated just yet) but has potential to be expanded to do a few fancy things such as autobackups or restores and whatnot (disk hooks)

############### dca632 /usbstick 51°# find /dev/disk-by-*
/dev/disk-by-label
/dev/disk-by-label/therest_ext4_sdc4
/dev/disk-by-label/wrtrootfs_ext4_sdc3
/dev/disk-by-label/snapback_ext4_sdc2
/dev/disk-by-label/wrtboot_ext2_sdc1
/dev/disk-by-label/storage_ext4_sda1
/dev/disk-by-partuuid
/dev/disk-by-partuuid/e5fe9b3c-04_ext4_sdc4
/dev/disk-by-partuuid/e5fe9b3c-03_ext4_sdc3
/dev/disk-by-partuuid/e5fe9b3c-02_ext4_sdc2
/dev/disk-by-partuuid/e5fe9b3c-01_ext2_sdc1
/dev/disk-by-partuuid/b13736bf-03d4-4e2a-b0c8-25fbe5f5359b_ext4_sdb2
/dev/disk-by-partuuid/dd013cd6-e0d9-4b42-a336-acc9676c2699_vfat32_sdb1
/dev/disk-by-uuid
/dev/disk-by-uuid/0333d354-1f42-4af4-80cd-128a5be90647_ext4_sdc4
/dev/disk-by-uuid/6b5d8ba6-14d0-45d4-b648-8eeb58298a2a_ext4_sdc3
/dev/disk-by-uuid/067dbfb1-e849-41c0-a9a1-6ab57b0ed795_ext4_sdc2
/dev/disk-by-uuid/98cde1ea-3c02-4633-a22e-fa81ed5e4463_ext2_sdc1
/dev/disk-by-uuid/06a3a14c-623f-4c9a-90d0-a9ec8201f1f4_ext4_sdb2
/dev/disk-by-uuid/1B31-8E92_vfat32_sdb1
/dev/disk-by-uuid/aa8fca3f-7077-4f41-a289-ca04fc22470d_ext4_sda1

rspierz · 2021-12-06T17:32:10.406Z

I am using "rpi4.64-21.02.1-27006-1.0.7-3-r16325". No other customizations really.

After some more digging. Every reboot grabs a new dhcp ip seems like behaviour might be starting from 21.02? I think perhaps my ISP is slow to allow a newly provisioned wan ip to route? I have a ticket open with them to investigate. I am coming from ubuiqiti edge router and it keeps the dhcp wan ip on reboots.

What would be the latest stable release? (maybe latest 19.x ?) I will switch to that and report findings.

anon50098793 · 2021-12-06T17:39:22.768Z

cheers...

i'd say the build you are on is best right now... especially for the issue described... (and it's technically also the latest stable release)

definately see what the isp has to say about what's going on... i've not come across a situation where openwrt receives valid wan addresses and won't route (but once had an issue on another device where all addresses were up but could not get traffic past the isp gateway but as mentioned it was a different device and quite a while ago but sound similar to the sort of issues you are experiencing)

rspierz · 2021-12-07T03:23:25.949Z

Curious to know if on reboots or renewals anyone here also gets new IP's instead of re-using the same one from DHCP? I really want to figure out how to get openwrt re-use the IP..

Mon Dec  6 21:58:37 2021 daemon.notice netifd: wan (20610): udhcpc: received SIGTERM
Mon Dec  6 21:58:37 2021 daemon.notice netifd: wan (20610): udhcpc: unicasting a release of X.X.X.X to X.X.X.X
Mon Dec  6 21:58:37 2021 daemon.notice netifd: wan (20610): udhcpc: sending release
Mon Dec  6 21:58:37 2021 daemon.notice netifd: wan (20610): udhcpc: entering released state
Mon Dec  6 21:58:37 2021 user.notice dhcp.script: deconfig IFACE6RD_DELEGATE=0 SHLVL=1 J_V_keep=0 HOME=/ T_J_V_interface=string interface=eth0 T_J_V_link_up=boolean T_J_V_action=int TERM=linux PATH=/usr/sbin:/usr/bin:/sbin:/bin J_V_interface=wan K_J_V= action link_up keep interface J_V_link_up=0 J_V_action=0 N_J_V_link_up=link-up INTERFACE=wan T_J_V_keep=boolean PWD=/lib/netifd/proto JSON_CUR=J_V
Mon Dec  6 21:58:37 2021 daemon.notice netifd: wan (30067): udhcpc: started, v1.33.1
Mon Dec  6 21:58:37 2021 user.notice dhcp.script: deconfig IFACE6RD_DELEGATE=0 SHLVL=1 J_V_keep=0 HOME=/ T_J_V_interface=string interface=eth0 T_J_V_link_up=boolean T_J_V_action=int TERM=linux PATH=/usr/sbin:/usr/bin:/sbin:/bin J_V_interface=wan K_J_V= action link_up keep interface J_V_link_up=0 J_V_action=0 N_J_V_link_up=link-up INTERFACE=wan T_J_V_keep=boolean PWD=/lib/netifd/proto JSON_CUR=J_V
Mon Dec  6 21:58:37 2021 daemon.notice netifd: wan (30067): udhcpc: sending discover
Mon Dec  6 21:58:37 2021 daemon.notice netifd: wan (30067): udhcpc: sending select for X.X.X.X
Mon Dec  6 21:58:37 2021 daemon.notice netifd: wan (30067): udhcpc: lease of X.X.X.X obtained, lease time 86400

anon50098793 · 2021-12-07T05:01:34.557Z

rspierz:

IFACE6RD

the other option available / next fastest way to rule out anything build related is to install official OpenWrt on a spare sdcard (configure from scratch)

I have a whole bunch of fancy ipv6 modules and not so much experience with what they do... so the above will rule out any adverse interactions here...

actually just looking there are not that many...

ip6tables-extra
ip6tables-mod-nat
kmod-ip6tables-extra
kmod-ipt-nat6
kmod-ipt-raw6
kmod-nf-nat6
6in4
6rd
kmod-gre6
kmod-iptunnel6
kmod-nf-conntrack6
kmod-nf-ipt6
kmod-nf-reject6
kmod-udptunnel6
luci-proto-ipv6

plikmuny · 2021-12-07T08:28:33.288Z

Wulfy23: is there a cron job for automatic rebooting or software updating preconfigured?
Because I am experiencing Internet breakup at around 6am or few minutes before that. After may be some 5 minutes that Internet is there again!!!
Is it only with me or known bug?
I am on latest stable release from you ( not snapshot).

Thanks for your hard work.

anon50098793 · 2021-12-07T08:41:44.883Z

Cronjobs Summary

ok... so your asking about any recurring automated stuff in the build...

(note: most things that happen in the build log something... so the quick answer to your question is just to check logread and dmesg from after this occurence once or twice)

it's a good question actually...

of course these things might vary depending on what INI options are enabled and whatnot... but it's good to give a brief overview of them anyway...

persistent nlbwmon/luci-statistics

there is a cronjob that saves the above data every... need to check... probably 3-5hours... initially it worked really well without cronjob (had a shutdown hook) but if power suddenly is lost it didn't capture stuff so a cronjob was implemented...

persistent logs

there is a cronjob that saves the logread ringbuffer...

there are two cronjobs, backup/tasks which don't really do anything... (but the latest build has an updated tasks that works)

well, well, well I though most of the jobs would be around midnight-3:30am but looking at my crontabs... the 'not working' backup/tasks are right on 5:59am (mondays only maybe)...

59 05 * * 1 /etc/custom/tasks.sh weekly
59 05 * * 1 /etc/custom/backup.sh
0 */6 * * * /etc/custom/shutdown.sh plog psave
0 */6 * * * /etc/init.d/persistentlucistatistics psave
0 */6 * * * /etc/init.d/persistentnlbwmon psave

there are a few other jobs that may be automated (i.e. wireguard watchdog) but they not commonly enabled or used so i'd have to lookup / check any logic if anyone finds additional jobs present...

the other jobs appear to run 4 times a day...

for now just comment out those lines maybe and restart cron service... (that said, those jobs as mentioned don't really do much so a little lost on whats going on)

best guess would be an ISP/UPSTREAM reset kindof thing (i see similar behavior sometimes on my cable connection around 3am where it stops working for maybe less than a minute)...

Lynx · 2021-12-07T09:19:47.624Z

In case this is helpful my LTE modem drops eth0 (NO-CARRIER using ip monitor) about every 48 hours as is apparent from checking the modem log and this needs to be detected and managed. Think this means udhcpc kill commands to release and renew.

On my RT3200 using the recent snapshots this is already correctly handled.

I wrote this script for Asus-Wrt Merlin:

#!/bin/bash

renew_wan_lease=0

ip monitor link dev eth0 | while read event; do

        logger "maintain-wan-lease detected eth0 event: "$event

        case $event in

        *'NO-CARRIER'* )
                if [ $renew_wan_lease -eq 0 ]; then
                        logger "maintain-wan-lease detected eth0 state change to: 'NO-CARRIER', so forcing udhcpc to release wan lease."
                        killall -SIGUSR2 udhcpc
                        renew_wan_lease=1
                fi
        ;;

        *'LOWER_UP'* )
                if [ $renew_wan_lease -eq 1 ]; then
                        logger "maintain-wan-lease detected eth0 state change from: 'NO-CARRIER' to: 'LOWER_UP', so forcing udhcpc to renew wan lease."
                        killall -SIGUSR1 udhcpc
                        renew_wan_lease=0
                fi
        ;;
        esac

done

This meant keeping my internet connectivity after the modem refreshes. Whereas otherwise internet connectivity would be lost until reboot.

May be worth just ruling this out.

Alternatively could this behaviour explain the constant refreshing IP?

anon50098793 · 2021-12-07T09:31:16.420Z

Lynx:

wrote this script

similar script here using failed neighbour entries...