<notlistening>
Hi all, been wrestling for longer than I care to admit with usbmode to get my 3.5G modem working under openwrt. What I am looking to do is just drop the usb_storage driver and then start use the option module to enable the modem endpoints, however I don't know how to just drop the current device driver and it seems to want to reconnect as a cd-rom device every time. Any points would be really appreciated.
<notlistening>
[ 695.776068] usb 2-1.4.4: GSM modem (1-port) converter now attached to ttyUSB0
<notlistening>
[ 695.900202] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
<notlistening>
Right got it after trial and error and looking through the source :)
<rsalvaterra>
mangix: Scratch that. I don't think this MGLRU version has ever been tested on anything but x86, my router becomes unusable after a while. Oh, well.
notlistening has quit [Ping timeout: 480 seconds]
notlistening has joined #openwrt-devel
Piraty_ has quit [Remote host closed the connection]
<mangix>
this selinux stuff needs to use meson or cmake
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
noahm has quit [Quit: reboot...]
rsalvaterra has quit [Ping timeout: 480 seconds]
noahm has joined #openwrt-devel
ptudor_ is now known as ptudor
Luke-Jr has quit [Ping timeout: 480 seconds]
notlistening has quit [Read error: No route to host]
notlistening has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
amaumene has quit [Quit: amaumene]
ecloud has quit [Ping timeout: 480 seconds]
notlistening has quit [Ping timeout: 480 seconds]
Misanthropos has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
notlistening has joined #openwrt-devel
amaumene has joined #openwrt-devel
gch981213 has quit [Quit: Lost terminal]
ekathva has joined #openwrt-devel
cbeznea has joined #openwrt-devel
lelux_ has joined #openwrt-devel
lelux has quit [Read error: Connection reset by peer]
notlistening has quit [Ping timeout: 480 seconds]
notlistening has joined #openwrt-devel
ekathva has quit [Ping timeout: 480 seconds]
dansan has quit []
dansan has joined #openwrt-devel
Tapper has joined #openwrt-devel
goliath has joined #openwrt-devel
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
ekathva has joined #openwrt-devel
hauke has quit [Server closed connection]
hauke has joined #openwrt-devel
rsalvaterra has joined #openwrt-devel
blocktrron has quit [Server closed connection]
blocktrron has joined #openwrt-devel
<rsalvaterra>
Yeah, good think 5.15 on ramips is TESTING… I just woke up to a dead router.
zorun has quit [Ping timeout: 480 seconds]
<mrkiko>
rsalvaterra: did a reboot fix it or did something happen to flash ?
<rsalvaterra>
mrkiko: Came up fine after reboot. It's something else.
<mrkiko>
rsalvaterra: and no way to collect kernel messages I guess
<rsalvaterra>
I'm seeing it swapping (to zram) for the first time ever…
<mrkiko>
uhm
<rsalvaterra>
I wonder if we might have a leak somewhere…
<mrkiko>
rsalvaterra: was thinking the same, and was wondering how one should proceed in these cases. Is KASAN or something an option here?
<rsalvaterra>
On a device like this? I don't know, possibly… I never used KASAN, though.
<rsalvaterra>
I dropped my MGLRU backport since I thought it was the culprit (and it indeed exacerbated the problem), but the problem seems to persist.
<rsalvaterra>
Heh… keep forgetting I don't have -h in the router. :P
<rsalvaterra>
Not good. It just keeps increasing.
<rsalvaterra>
I wonder if hardware flow offloading has something to do with it…
zorun has joined #openwrt-devel
<rsalvaterra>
… also nope. Still increasing.
danitool has joined #openwrt-devel
<rsalvaterra>
Nasty…
decke has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<xback>
blocktrron: just noticed you are also working on ath79 5.15. anything particular you bumped into?
Tapper1 has quit [Read error: Connection reset by peer]
robimarko has joined #openwrt-devel
Tapper has joined #openwrt-devel
* f00b4r0
notices 19.07 is not happy being built on a modern distro :P
<robimarko>
Failing on prereq checks?
<f00b4r0>
yup. It doesn't detect gcc10
<f00b4r0>
asks for 4.8 or later
<robimarko>
Kind of expected
<robimarko>
Cause it was checking 0-9
<f00b4r0>
indeed, this would explain that :)
<robimarko>
You can manually backport the later fix for that
<zorun>
the question is: will everything build with gcc10? I doubt so
<robimarko>
Probably not
<f00b4r0>
hmm
<robimarko>
Cause of the redefinition default being changed
<f00b4r0>
let's hope gcc-9 would work then, cause I can't go any lower :P
<f00b4r0>
funny. Now it detects gcc-9, but not g++-9
<rsalvaterra>
Argh… having to build the toolchain to refresh a subtarget kconfig… -_-
* rsalvaterra
is bringing up 5.15 on mvebu
<zorun>
apparently you can force the version with: CC=gcc-9 CXX=g++-9 make prereq
<f00b4r0>
I just noticed, thanks :)
<f00b4r0>
CXX=g++-9 make oldconfig worked
bluse-blue[m] has quit [Server closed connection]
bluse-blue[m] has joined #openwrt-devel
fpsusername[m] has quit [Server closed connection]
fpsusername[m] has joined #openwrt-devel
<f00b4r0>
starting make world, fingers crossed
<Tapper>
Hi any one use ksmbd on master?
<zorun>
f00b4r0: are you sure you're using the latest 19.07? from what I can see everything related to gcc10 has been backporting
<zorun>
backported*
<f00b4r0>
zorun: I'm sure I'm not, I should have mentioned that sorry :)
ekathva has quit [Quit: Leaving]
<zorun>
ah
<f00b4r0>
I'm trying to unfuck a silly situation for someone, requiring a custom 19.07.2 build
<f00b4r0>
sorry for the confusion :)
<f00b4r0>
but it looks like I'm gonna have to find another way, it fails to build mksquashfs :(
<zorun>
well, you're on your own then ;) re-backporting everything that was already backported does not sound very fun
<f00b4r0>
no, indeed not. I'm gonna take my chances with 19.07.9
<f00b4r0>
and try to shoehorn it into what I need :)
<Tapper>
Hi any one know how I can fix Tue Mar 29 09:54:05 2022 kern.err kernel: [ 2075.363502] ksmbd: No IPC daemon response for 20s
<Tapper>
samba was working for me but I wanted to save some space.
<blocktrron>
xback: generic should just work
<blocktrron>
I'll push it later, I do not have a NAND device at hand
<xback>
ok. i'll rebase on your work then. i've tested it yesterday on some nand devices (see my staging)
ecloud has quit [Ping timeout: 480 seconds]
notlistening has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
notlistening has joined #openwrt-devel
\x has quit [Server closed connection]
\x has joined #openwrt-devel
agb[m] has quit [Quit: Idle for 30+ days]
GuruPrasathGovindarajan[m] has quit [Quit: Idle for 30+ days]
<rsalvaterra>
Cute. The PCIe Aardvark driver hasn't been build-tested on 5.15.
<rsalvaterra>
It's broken.
<robimarko>
On which board are you testing?
<rsalvaterra>
None.
<robimarko>
Oh, so even compiling
<rsalvaterra>
Build-testing. ;(
<robimarko>
I know that CZ.NIC and Pali Rohar have been fixing the aardvark driver for a while now
<rsalvaterra>
And now to find which patch touches the erroring function… also fun.
mkresin has quit [Server closed connection]
mkresin has joined #openwrt-devel
<notlistening>
So still stuck on my 3G modem, what I think is the solution is to remove/disable usb_storage and then the modem will attach properly. Anyone got a good trick to do that I am struggling to make that happen? The problem I see is that usb_storage attaches just before the usb_serial_option module and cause option to disconnect ttyUSB0.
<notlistening>
In Ubuntu land I can use usb_modeswitch -r which just removes usb_storage, but there isn't an option like that on openwrt and also usb_storage looks like it's being built with the kernel
amaumene has quit [Quit: amaumene]
<notlistening>
Was trying to avoid a custom build ;)
YSC has quit [Server closed connection]
YSC has joined #openwrt-devel
<jow>
notlistening: OpenWrt has a usbmode package
<jow>
kind of a tiny usb-modeswitch implementation using the same databases
<notlistening>
Yeah been using that but not being able to create the same behaviour
<jow>
ah, ok
<notlistening>
Probably due to the usb_storage being built in
tmn505 has quit [Server closed connection]
tmn505 has joined #openwrt-devel
<notlistening>
and a lack of knowledge on how to achieve disabling the usb_storage module kicking in for this device
<notlistening>
blacklisting isn't a thing on openwrt?
<notlistening>
Note to self, don't buy cheap 4G hardware ...
<ynezz>
you can't blacklist built-in module, can you?
znullptr[m] has quit [Server closed connection]
znullptr[m] has joined #openwrt-devel
<ynezz>
and making it module, folks are going to complain, that it's not possible to boot from USB...
<notlistening>
In past history i was optional
<notlistening>
but I can make it a module and rebuild
<notlistening>
*it
<rsalvaterra>
Aw, fsck it. I'll just push this out as is with a WIP tag. Will get back to it later. The cortexa9 subtarget builds fine, I'll just test it and deal with the Aardvark driver later.
<jow>
did you try echo vid:pid > /sys/bus/usb/drivers/usb-storage/unbind
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<mrkiko>
robimarko: hi!
srslypascal is now known as Guest656
srslypascal has joined #openwrt-devel
<mrkiko>
robimarko: I would like to test DS conversion of the gl-b2200
gch981213 has joined #openwrt-devel
<mrkiko>
robimarko: @wwortel very nicely provided a dts conversion to test. Would like to know how I might test it out - if the diff from the PR is enough or what I am better doing right now, even seeing the 5.15 switch
<aparcar[m]>
so I'd just do the same for mksquashfs
<aparcar[m]>
ynezz: okay so I add `hash` and `hash_unsigned`?
<ynezz>
aparcar[m]: either way, you're still adding a lot of duplicate data
<ynezz>
on one hand you want them small, on the other you're making them bigger :)
<aparcar[m]>
well the unsigned bit is the interesting part
srslypascal has quit [Ping timeout: 480 seconds]
<aparcar[m]>
I want multiple upgrade server instances running in parallel verifying that every build is reproducible. For that I need some unsigned hash
<ynezz>
then just add `sha256_unsigned` ?
<aparcar[m]>
the API details are up to whosever convenience
<aparcar[m]>
bueno fine with me
<stintel>
aparcar[m]: if you add that reasoning to the commit message, fine
<aparcar[m]>
stintel: from my understanding adding the -j value to mksquashfs doesn't help since make itself uses i.e. 12 threads and then mksquashfs would use 12 more, resulting in 23 total threads
<aparcar[m]>
I don't think we win anything if we'd use all threads to builds the squashfs and pause everything else in the meantime
<stintel>
I'm confused, my change would result in mksquashfs using all available CPUs ...
<stintel>
but at that point of the build process, make probably doesn't have many jobs left to run anyway
<stintel>
the concern is that if a user has 4 cores does make -j2 to have CPU left for playing media or so, and we do not respect that -j2 with mksquashfs, the process could take all CPU and the user's media could stutter
<aparcar[m]>
yea I hate when that happens
<aparcar[m]>
so I guess we just need the value of -j
<stintel>
yes, but that's tricky because the variable is not available where we call mksquashfs
<stintel>
and like I said in my comment on the ML, I'm not familiar enough with that part of the code to just add some include to fix that
<aparcar[m]>
stintel: and that's what I meant to say earlier, if we run mksquashfs with 2 threads, make will happily do something else in one more thread (since make is allowed to use 2 threads). Now it may end up running two mksquashfs jobs in parallel, which results in a total of 4 CPUs being used
<stintel>
29|14:12:48 < stintel> but at that point of the build process, make probably doesn't have many jobs left to run anyway
<stintel>
as there is nothing left to compile
<aparcar[m]>
either way you end up with mksqaushfs using more cores than -j, but actually j * j
mirko has quit [Server closed connection]
mirko has joined #openwrt-devel
<stintel>
that doesn't make sense to me (j*j)
<stintel>
make is not going to call mksquashfs more than once?
<aparcar[m]>
stintel: why not, some people build multiple images
<stintel>
rightm did not think of that
<stintel>
so we should just leave -processor 1 or what
<aiyion>
Grommish: Ayn suggestions on how you dumped the nand of your edgerouter as backup in case something goes south?
<aparcar[m]>
I'd just remove it since it's the same as for imagebuilder/sdk builds
<stintel>
well ok, back to this then: 29|14:09:20 < stintel> aparcar[m]: if you add that reasoning to the commit message, fine
<aparcar[m]>
ynezz: I've seen your toolchain "fixes", ideas on how to upstream it? I'd be nice for the CI
gch981213 has quit [Quit: leaving]
<mirko>
ynezz: i've seen you were involved in the urngd/urandom-seed things (correct?)
Misanthropos has joined #openwrt-devel
<mirko>
I've mainly 2 questions - 1) rng-tools' docs say, if i don't have a hw-rng i should specify /dev/urandom as device and i'm failing to see what's its purpose, as the userspace daemon is supposed to feed the kernel's prng, not read from it 2) urandom-seed creates /etc/urandom.seed after initial boot - when there's very little entropy available. if it's not so little during boot why have it at all and
<rsalvaterra>
ynezz: Have you noticed any memory leaks with 5.15 on sunxi? :/
<mirko>
if it's little indeed, what's its purpose then?
<rsalvaterra>
mrkiko: I don't use urandom-seed at all. I also don't use urngd on systems with a hwrng (e.g. PCIe ath9k adapters, for example).
<mirko>
rsalvaterra: so you use rng-tools?
<mirko>
3) does rng-tools' rngd contains urngd's functionality of (also) collecting CPU jitter?
<karlp>
can we just call mksquashfs with nice and leave it at j? even j*j is "fine" if it's niced. it's _always_ the slowest part of a build _by far_ for me, and it's always efectively single threaded at that point, make's not doing anything else. I mean, yeayeah yeah, people need knobs to let them do their special things, but the basic "make -j $(NPROC)" results in you sitting there
<karlp>
staring at your (currently) single threaded mksquashfs and twiddling your thumbs hating it...
<mirko>
karlp: if you have the space, don't use lzma for dev purposes :)
<karlp>
I just feel like we're making a _lot_ of people keep paying a high price for the few people that want the weirder combinations of options here
<karlp>
this patch has been proposed by various people for years, and we're still sitting around being held back by these weird corners of theoretical use cases.
<f00b4r0>
karlp: j*j may be "fine" for load, but what about mem usage?
<f00b4r0>
or disk io for that matter
<karlp>
it's only "j*j" in the theory that you actually made a build that ran on all processors that actually ended up trying to make j mksquashfs tasks as the same time
<karlp>
and that's a "in theory it might break" situation so far.
<f00b4r0>
wouldn't that be a typical case on buildbots?
<karlp>
vs a "guaranteed that things will take way longer than they need" right now.
<karlp>
can't the buildbots get the special casing then?
<karlp>
if it even proves to be a problem in practice?
<f00b4r0>
dunno. Just pointing out likely pitfalls :)
<karlp>
yeah, the same theorertical ones that have been blocking this for years.
<f00b4r0>
maybe for a good reason?
<karlp>
well, no-one ever reported a fail with it, they just rejected it.
<karlp>
it still sucks that it's a huge visible low hanging fruit for users, and it just gets blocked time and time again.
<f00b4r0>
should be fairly easy to run a buildbot-like build on a multicore machine, building e.g. ath79 which has hundreds of images, and checking what happens?
<f00b4r0>
cause I mean, generally speaking the burden of proof is on submitter, or have things changed in opensource lately? :)
<rsalvaterra>
mirko: I don't use rng-tools. I just let the kernel find and use an available hwrng to feed the entropy pool, which it does automatically.
<karlp>
submitters can't test every hypothetical that maintainers come up with. yes, the idea of submitter proves benefits is good, but "submitter must disprove alllllllll counter claims" is also kinda absurd.
<f00b4r0>
karlp: sure. As I said, doing what I suggest above should be fairly easy
<rsalvaterra>
nbd: I don't know if you're aware if it already, but I've been bitten by a massive memory leak in ramips/mt7621 with 5.15… :/
<f00b4r0>
(as far as I'm concerned I just don't see what the fuss is all about, mksquashfs is fast enough, but to each their own)
<karlp>
f00b4r0: how many cores would "count" ?
<karlp>
because that's been used as counter arguments before, already....
m has joined #openwrt-devel
<f00b4r0>
karlp: 16 or 32 would probably make a point I suppose
<karlp>
ohno, you didnt' test on 32cores with 32gig tmpfs..
<karlp>
yeah, not every submitter has that sort of hardware available. and I don't think they should be required to come up with it.
<karlp>
bat I'm glad you're machine is faster than mine :)
<nbd>
rsalvaterra: on what kind of device, and what is the device doing?
<stintel>
paul just pushed it
<f00b4r0>
heh. Let's see if anything blows now :)
<mirko>
rsalvaterra: point is, lot's of hw-rng's drivers do not feed the kernel's internal prng but only expose themselves as character dev (e.g. /dev/hwrng) - you have to take care of the feeding yourself (as in: configure rng-tools to do so)
<karlp>
:)
<m>
csharper2005, I'm here)
<aparcar[m]>
karlp: I'm confused, you're happy or mad this was merged?
<mirko>
rsalvaterra: but, yes, i'm scratching my head ever since about why - if already having a generic kernel subsystem for hw rngs - they do not implicitly feed the kernel's prng by default, but instead rely on userspace to do so
<karlp>
happy it's merged, very.
<rsalvaterra>
nbd: Ok, I migrated my normal configuration, so it's a bit of a "frankenconfig" (Linux 5.15 with fw3), not the default. The device is a Redmi AC2100 (128 MiB of RAM). I can provide you with my config/kconfig, if it helps.
<aparcar[m]>
karlp: if you have a hunch for further improvements please let me know
<rsalvaterra>
mirko: Really? Have you tried to cat both /sys/devices/virtual/misc/hw_random/rng_available and /sys/devices/virtual/misc/hw_random/rng_current?
<mirko>
rsalvaterra: surely i verified this - several times.. :)
<rsalvaterra>
That's… weird.
<mirko>
rsalvaterra: without any userspace tools, after `cat /dev/random > /dev/null`, my entropy very barely increases (way below 100). with rng-tools running - but explicitly setting the hwrng option to /dev/zero - it's still the same. setting it to /dev/hwrng immediately gets the gathered entropy into the thousands and i can't empty it anymore as the hwrng continues to deliver
csharper2005 has quit [Remote host closed the connection]
<mirko>
i can't rule out there's rng drivers implicitly feeding the internal's prng by default - but that's hardly the case for any of the common SoC's RNGs
Tapper has joined #openwrt-devel
<robimarko>
mrkiko: DTS+02_network diff should be enough
<aparcar[m]>
hauke: thanks for the merges
<mrkiko>
robimarko: ok, so I might need some guidance
matteo has joined #openwrt-devel
shoragan has quit [Server closed connection]
shoragan has joined #openwrt-devel
<robimarko>
mrkiko: What kind of guidance?
<minimal>
mirko: AFAIK no hwrng directly feeds entropy, rngd is needed for that. However a suitable bootloader (if so configured and also kernel so configured) *may* obtain entropy from a HWRNG and feed that to the kernel
<stintel>
minimal: hwrng directly feeds entropy if quality property is high enough (iirc)
<stintel>
let me find a thread
<minimal>
mirko: if you're using a recent rngd you could/should also enable the jitter entropy source (in addition it can also use x86 (rdrand) and Arm (forget name of rdrand-equivalent) CPU instructions for entropy)
<mrkiko>
robimarko: I will apply the PR diff, then replace my dts with the one provided by @wwortel?
<robimarko>
Yeah, apply the whole PR, then replace the DTS and update the 02_network script
<minimal>
stintel: that's patches to the RPI's HWRNG - I use that on my RPI via rngd - rngd is *still* needed to do the feeding of entropy from the HWRNG to the kernel
<minimal>
if you don't run rngd that that patch has no effect
<stintel>
I understood it differently - with this patch kernel uses the hwrng to feed entropy and as such running rngd is no longer needed
John[m]12345678 has quit [Server closed connection]
John[m]12345678 has joined #openwrt-devel
<stintel>
if what you are saying is true, this means rpi0/rpi will be back to slow boot times
<ynezz>
BTW that "priv->rng.quality = 1000" is probably just a hack/copy&paste, that value is going to be certainly lower
<stintel>
yes, there's a thread about it on some kernel mailing lists
<minimal>
the RPI's bootloader has the potential to past some initial entropy to the kernel that the bootloader gets from the hwrng *IF* kernel setting RANDOM_TRUST_BOOTLOADER is set to "y" and if the bootloader passed said seed
<stintel>
we don't set RANDOM_TRUST_BOOTLOADER
<minimal>
stintel: I maintain the rng-tools package for Alpine Linux and I've done quite a bit of testing of rngd to resolve some RPI-related issues (mainly to do with the jitter entropy source).
<minimal>
stintel: right - so on a RPI the kernel then will not get any initial entropy from the bootloader (which could get it from HWRNG)
<minimal>
therefore during RPI boot the kernel itself has a limited form of jitter entropy builtin
<stintel>
rngd -r /dev/hwrng works fine on rpi0 without those quality patches - I am 100% sure I used that before that patch was added
<stintel>
rpi0/rpi1 cannot use jitter entropy at all
<stintel>
we've talked about this before
<minimal>
stintel: I can point you to the long rng-tools discussion where I ended up coming up with rngd jitter tuning setting to handle rpi0 machines taking a long time to initialise rngd's jitter source
<minimal>
but that's a separate discussion
<stintel>
so urngd doesn't solve anything there, and we can not add rng-tools to default packages as it's in the packages feed
<stintel>
and at that point noltari_ came up with that patch
<stintel>
afair
<mirko>
stintel: i'd be *very* interested in some (written) reasoning about what implicitly feeds the kernel and what needs userspace
<minimal>
and I said earlier in a kernel with RANDOM_TRUST_BOOTLOADER set to "n" then then a hwrng will not be used by the kernel itself to initialise. It may however used CPU instructions (rdrand on x86) if RANDOM_TRUST_CPU is set to "y" but that's strictly speaking not a HWRNG, its a CUP instruction
<minimal>
s/CUP/CPU/
<mirko>
khwrngd? what the heck is this? slowly i'm getting confused..
<mrkiko>
robimarko: clear; how may I update the 02_network script?
<minimal>
marko: khwrngd is for virtio-rng
<minimal>
which is a "virtual" hwrng provided to a VM by the hypervisor (i.e. QEMU)
<mirko>
minimal: are you by any chance also able to answer the rest of my questions? e.g. what'S the purpose of configuring rngd (from rng-tools) to use /dev/urandom as hw rng device?
isak has quit [Server closed connection]
isak has joined #openwrt-devel
<stintel>
minimal: you should probably read drivers/char/hw_random/core.c
<mirko>
to me it stil doesn't explain why potentially not sufficiently random sources are not included by default. my understanding is, that a "bad" source doesn't weaken the pool otherwise fed by "good" sources
<mirko>
the more the at-least-not-worse
<stintel>
well ... would have to know for sure a good enough source is already there, probably hard to prove
<stintel>
if you allow a bad source unconditionally and it's the only one ..
<minimal>
mirko: there's a distinction between feeding into the entropy pool, and whether what is fed is "credited" or not
<mirko>
stintel: linux said good bye to the need of at least one good source already by making /dev/random non-blocking
<mirko>
minimal: ok, so which hwrng feeds by default and which doesn't? according stintel that's determined by the quality field
<minimal>
from memory you can use the likes of "dd" to add data to the pool but its not credited, you have to use a library call to credit it
<stintel>
I am building an image for rpi0w without rngd to confirm/deny what I think should happen
<mirko>
so who decides which SoC's RNG is sufficient to implicitly feed the pool and which needs userspace tools?
<stintel>
I'm not an expert on rng at all, I just remember a thing or two because not enough entropy was horribly slowing down boot-to-network on rpi0w
<mirko>
stintel: keep in mind behaviour of /dev/random changed recently - just to spare some additional confusion
<minimal>
stintel: you don't need to build a new image - just disable the rngd and "cat /proc/sys/kernel/random/entropy_avail" shortly after boot
<minimal>
then do the same with rngd enabled
<mirko>
minimal: back to rngd/urngd: so you're saying recent versions of rngd habe urngd's functionality included?
<minimal>
stintel: the kernel collects entropy from things like disk activity, network activity, keyboard/mouse activity, etc - things that embedded systems tend to have less of
<minimal>
mirko: I know nothing about urngd, I'm only familiar with rng-tools rngd
<stintel>
minimal: my rpi0w are headless, entropy is needed to bring up network in the first place
<minimal>
stintel: why is entropy needed to bring up network?
<stintel>
minimal: because wireless only
<minimal>
stintel: ok, I guess the entropy is required for WPA2 or similar crypto stuff
<stintel>
yes
<stintel>
[ 36.773450] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
<stintel>
after 36s without rngd
<stintel>
so quality above certain threshold is enough
<stintel>
I rest my case
<minimal>
to clarify, my understanding is that there are actually 2 kernel entropy pools, its own private one, and the "general" one used for /dev/random and /dev/urandom
<mirko>
stintel: what does /proc/sys/kernel/random/entropy_avail say?
<mirko>
if a hwrng is being used it should be >1000 even shortly after emptying
<minimal>
the poolsize (on x86) in 4096
<stintel>
command just hangs
<mirko>
stintel: just because it's being registered by the kernel doesn't mean it's feeding the kernel's pool
<minimal>
the entropy_avail should quickly run up to 3072 (3/4 of 4096) and stay around there
<mirko>
stintel: sory, the cat doesn't quit
<mirko>
ctrl+c
<minimal>
if you have good source(s) of entropy
<mirko>
stintel: just make it two cmd lines then: (1) cat /dev/random > /dev/null (2) cat /proc/sys/kernel/random/entropy_avail ; sleep 5 ; cat /proc/sys/kernel/random/entropy_avail
<mirko>
and ctrl+c the first
<mirko>
minimal: re urngd: https://git.openwrt.org/?p=project/urngd.git;a=summary - i'm juts curious if rng-tools implements the same way of gathering jitter for entropy
<rsalvaterra>
nbd: Wait… I'm seeing this leak on 5.10 too, could it be…? The latest mt76 update? Will revert and test…
PtitGNU has quit [Server closed connection]
<minimal>
mirko: rng-tools uses the jitterentropy-library
PtitGNU has joined #openwrt-devel
<Slimey>
how do i built against 5.15 kernel
<stintel>
1379
<stintel>
1382
<mirko>
minimal: urngd does so, too: https://git.openwrt.org/?p=project/urngd.git;a=tree;f=3rdparty;h=d78b4249c6daa171e059db52f40cfb1bbf1240e9;hb=HEAD
<stintel>
Slimey: CONFIG_TESTING_KERNEL - only works if target already supports 5.15
<mirko>
stintel: congrats, if not running *rngd or haveged or similar, your system most likely uses a HW RNG
<minimal>
mirko: urngd appears to be a fork of jitterentropy-rngd by the same author as jitterentropy-library
<Slimey>
gotcha
<stintel>
Slimey: check KERNEL_TESTING_PATCHVER in target/linux/foo/Makefile
<mirko>
minimal: so i can drop urngd if i'm running rngd already anyway
<Slimey>
i use the entropy from wifi noise :P
<olmari>
> stintel: linux said good bye to the need of at least one good source already by making /dev/random non-blocking
<olmari>
Is it non-blocking also when initially empty?
<minimal>
mirko: I used to use jitterentropy-rngd until rng-tools' rngd gained the ability to use that in addition to any other entropy sources it supports
<mirko>
olmari: as far as i know it never blocks since some kernel release, yes
<stintel>
even with cat /dev/random > /dev/null running, available entropy is > 1000
<olmari>
Sounds.. interesting
<mirko>
stintel: and no *rngd running, rught?
<nbd>
rsalvaterra: in mt76 master i reverted a commit (haven't pushed the update to openwrt yet)
<nbd>
rsalvaterra: maybe that revert helps
<mirko>
olmari: it's a rabbit hole, i'm still having so many questions..
<rsalvaterra>
nbd: I just did it locally and I'm building a new image as we speak.
<stintel>
mirko: ack, no *rngd, no haveged
<mirko>
olmari: ah, wait, i might be wrong
<mirko>
olmari: "with Linux 5.6 /dev/random behaves more like /dev/urandom now for polling RNG data in user-space. The changed behavior causes /dev/random to behave the same as /dev/urandom except for reads being blocked until the CRNG (the Linux cryptographic-strength random number generator) is ready."
<mirko>
so it might still block if there's absolutely nothing sane to provide
<stintel>
anyway, enough distraction :P
<mrkiko>
robimarko: maybe you could send me in irc pm wsome hints on where I can find some hints on how to update that script.
<olmari>
I get the non-blocking part on general, just the initializing part.. after once done one can save current content for reboot etc in poor env like some do ;)
<minimal>
mirko: I think that once the kernel's "private" pool is initialised then no blocking happens
ecloud has joined #openwrt-devel
<mirko>
i still want to checkmark my question about who decides on which linux kernel supported rng is allowed to natively feed the entropy pool and which requires userspace software such as rngd
<olmari>
mirko: thought so too, otherwise whole concept of random wouldn't work
<minimal>
stintel: does openwrt write any random seed data to a file to be loaded on subsequent boots? most distros do that
<mirko>
minimal: yes, it does
<mirko>
see urandom-seed package
<stintel>
I don't use that
<minimal>
mirko: ok, so that then will potentially distort (i.e. increase) the entropy_avail value stintel is seeing when testing with/without urngd
<mirko>
unfortunately it writes the file after boot, which is one of my still reamining questions for petr / ynezz
<mirko>
*right* after boot
<stintel>
just the quality=1000 patch to bcm2835-rng is seemingly enough to have enough entropy for fast wifi bringup
<stintel>
~35s vs >100s before that patch (without any rngd)
<mirko>
i don't like mostly all if it, it gives me more headaches the more i seemingly understand
<mirko>
stintel: do you have a /dev/hwrng character device or similar?
<stintel>
I have /dev/hwrng yes
<stintel>
all rpi have a hwrng
<hurricos>
Is it possible to backport two "fixup" patches for a board back to 22.03? They cause LEDs to work on the WS-AP3825i by moving that section of the device tree down. Specifically:
<hurricos>
They were committed *right* after the branch-off.
<mirko>
"< stintel> I don't use that" - urandom-seed ias (or was?) part of the default package set for afaik all platforms
<stintel>
mirko: # CONFIG_PACKAGE_urandom-seed is not set
<mirko>
stintel: ack
<stintel>
package not installed either, I don't see why I would use it if I have a hwrng
<mirko>
stintel: yep, then no need
<stintel>
also better for the sd card :P
<mirko>
minimal: rng-tools though doesn't implement what haveged e.g. does, right?
<rsalvaterra>
nbd: At a much slower rate than in 5.15, but I definitely see the constant increase in memory usage in 5.10 too.
<minimal>
mirko: yes it does - the jitter is a newer "better" algorithm to the old HAVEGE algo
<mirko>
stintel: by default urandom-seed only writes *once* - not even *once* per boot, but ever touches /etc/urandom.seed only to once create it
<mirko>
minimal: ah, next questionmark resolved - thanks!
<rsalvaterra>
Maybe Linux 5.15 is innocent after all…
<minimal>
indeed its similar to the (more limited) "jitter" algo put into the kernel itself a while ago
<stintel>
rsalvaterra: chasing a bug similar to the memleak in octeon since 5.10? :P
<rsalvaterra>
stintel: Nastier. This one kills my box in less than an hour.
<stintel>
rsalvaterra: eek
<stintel>
well, you hipsters and your testing kernels ;p
* stintel
hides
* rsalvaterra
gets off of stintel's lawn
<stintel>
there is of course a bunch of breakage with CONFIG_KERNEL_FTRACE enabled
<stintel>
we should probably add a CI run with all those CONFIG_KERNEL_* options enabled
<minimal>
stintel: https://www.kernel.org/doc/Documentation/hw_random.txt, "Those tools use /dev/hwrng to fill the kernel entropy pool, which is used internally and exported by the /dev/urandom and /dev/random special files.", where "those tools" is referring to rng-tools' rngd
<rsalvaterra>
And since the leak seems to be kernel-side, the poor oom-reaper starts killing everything in userspace, but eventually the system just dies.
<mirko>
minimal: it still doesn't answer the question why some rngs need userspace to actually feed the kernel and why some don't - if you by any chance shed some actual light on that question or know somebody who could: i'm *really* curious
<stintel>
I conclude again that the kernel feeds entropy itself when a hwrng with high enough quality exists
<rsalvaterra>
nbd: Indeed, reverting the last mt76 bump seems to have tamed the beast.
<mirko>
stintel: it's the most plausible theory for the moment, yes
<mirko>
which doesn't explain a lot of other things though, e.g. why the kernel doesn't qualify a hwrng enough for internal feeding, but then explicitly recommends using rng-tools to feed the pool from /dev/hwrng
<rsalvaterra>
mrkiko: The last mt76 update seems to be the culprit.
* stintel
checks his EAP615 memory graphs
c0sm1cSlug has quit [Server closed connection]
c0sm1cSlug has joined #openwrt-devel
<stintel>
not a problem here
<minimal>
mirko: "why some rngs need userspace to actually feed the kernel and why some don't" - as I said earlier I do not believe this is a correct statement
<stintel>
rsalvaterra: I guess chip specific - flashed ~6h ago and mem usage graphs are flat
<stintel>
rsalvaterra: bisect with CONFIG_SRC_TREE_OVERRIDE ?
Pepes has quit [Server closed connection]
Pepes has joined #openwrt-devel
<robimarko>
mrkiko: just look at the existing conversion
<robimarko>
Its just a matter of populating the LAN and WAN interfaces
<mirko>
minimal: is the statement still wrong if i replace "feed the kernel" with "provide entropy to /dev/*random"?
dangole has quit [Remote host closed the connection]
rmilecki has quit [Server closed connection]
rmilecki has joined #openwrt-devel
<minimal>
mirko: yes I don't believe there is any difference in behaviour for different hwrngs. The rate that various hwrngs can provide entropy will differ but that's a different matter
<minimal>
mirko: also regarding the question of the kernel using hwrngs directly, at the very least if either (or both) the hw_random and the hardware-specific HWRNG drivers are built as modules then obviously it would not be possible for the kernel to use them until the relevant modules are loaded
<mirko>
minimal: i can tell you that on my imx6 platform entropy is very low without having rngd -c /dev/hwrng running - despite its hwrng being there, supported and initialized
<mirko>
minimal: which pretty much sounds like the general disadvantage of kernel modules in general
<mirko>
as in: if the code is not loaded, you can't use it
<nbd>
rsalvaterra: can you please test latest mt76 master?
<nbd>
(with that revert commit in place)
owrt-1907-builds has quit [Server closed connection]
owrt-1907-builds has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
decke has quit [Quit: Leaving.]
<f00b4r0>
uci cannot be built without ubox, correct?
<f00b4r0>
I'm trying to build a minimal tool that would just give me "uci validate" on a linux host, to validate uci config files syntax before inclusion in image
Tapper has joined #openwrt-devel
<rsalvaterra>
nbd: Sure. Will I just cloning your repo and setting a git-src link in mt76 do the trick?
<rsalvaterra>
*Will just
<stintel>
only if CONFIG_SRC_TREE_OVERRIDE=y
<rsalvaterra>
stintel: I have that enabled, sure. For science. :P
Luke-Jr has quit [Ping timeout: 480 seconds]
clayface_ has quit [Server closed connection]
clayface has joined #openwrt-devel
<nbd>
rsalvaterra: should wor
<nbd>
k
<rsalvaterra>
And Linux 5.15 will very likely be the end for (official) 64 MiB devices. I see 5.15 weighing +10 MiB than 5.10 for the exact same config.
<f00b4r0>
ugh
<Grommish>
aiyion: I didn't.. I was testing via initramfs tftp
<rsalvaterra>
nbd: Compiling…
Larhzu has quit [Server closed connection]
Larhzu has joined #openwrt-devel
<nbd>
rsalvaterra: i think we need to investigate where that extra memory use is coming from
<nbd>
that's way beyond the typical kernel release bloat increase
<rsalvaterra>
If it helps, these are MT7615e and MT7603e devices. I see most of the lastest activity has been around MT79xx, though.
<rsalvaterra>
Oh, my…! The RAM usage just dropped by about 10 MiB. Back at 5.10 levels, nice!
<rsalvaterra>
I guess now I can retest the MGLRU patch set… :D