<dangole_>
fda: i'm afraid there is very little to nothing for now. I just mastered to understand it by reading the code and fixing a lot of issues which surfaced once I started using it. probably this is my call to write the docs...
<fda>
dangole_: bridgeboxes for a device with 1Xlan + 1Xwlan looks a little empty: https://ibb.co/2qJSSKV
<dangole_>
fda: basically you can add an option 'autofs' '1' to mount-sections in /etc/config/fstab. then those will be handled in an autofs-like way. you can identify them using option device or option uuid.
<fda>
in which script flle is this handled?
<fda>
ah, blockd
<dangole_>
fda: it's all C code in blockd, which calls block for initial coldplug of devices and handle mounts and umounts
<dangole_>
fda: as we are using basename(), which makes sense for things in /dev... obviously that ruins the NFS URL. apart from that, I can't think of many other changes which would be needed. just handling of the NFS URL, as calling mount-helpers for filesystem-types not supported by mount() syscall is already implemented and would work for mount.nfs. and instead of waiting for the device via hotplug we just add all network mounts once
<dangole_>
network is up.
<Thermi>
How can I model a dependency of a package to at least one of several packages?
<Thermi>
e.g. package A requires either B logical OR C to be installed
<dangole_>
Thermi: afaik only by adding PROVIDES in the packages you depend on.
<dangole_>
Thermi: and then depend on that
<fda>
plan kconfig syntax: select A if !B
<Thermi>
dangole_, tyvm, that is already helping me a lot. Is there a convention for the name of the symbols?
<fda>
plain
<dangole_>
fda: kconfig dependencies won't actually end up in the package, unfortunately. that's only visible to menuconfig in the buildroot.
<slh>
just keep in mind that opkg and the buildsystem are not that good at coping with alternative dependencies
<Thermi>
Well, stintel just complained about a missing dependency. ;)
<fda>
want you really implement this all? is it not easier to use autofs itself? the only later work is then to bump the package
<fda>
blockd for local storages, autofs for remote
<dangole_>
fda: yes, seen that one before. in UCI would look slightly different as you have to explicitly state the filesystem type.
<dangole_>
fda: i don't think there is much to implement as long as mount.$fstype helpers exist... just handle device name differently for a bunch of fstypes (the network ones) and that's it.
<dangole_>
fda: but true, if autofs can be used in coexistence with blockd and handle network mounts, that would also be great and i won't have to reinvent the wheel
<dangole_>
Thermi: add PROVIDES:=strongswan-mod-socket to strongswan-mod-socket-default and strongswan-mod-socket-dynamic packages and let strongswan-swanctl depend on strongswan-mod-socket
<fda>
on my repeater (accesspoint) i used it for all logs etc, as it has no usb
<dangole_>
fda: yes, useful. i was missing better support for storage for a while. server side can now easily improved because made blockd send notifications to procd when ever a new mountpoint becomes ready (ie. mounted or autofs-mountable). client side i would like to support at least NFS. cifs would be nice too. and proper handling for nbd and iSCSI initiator would be at the end of the list ;)
<dangole_>
fda: i'll build a new procd-trigger shell hook for that and make use of it for NFS server side in the next days, so NFS exports get reloaded when mountpoints become available
<dangole_>
fda: for samba it's not even really needed afaik because autofs on-access mounting already solves it.
<fda>
autofs can handle all these systems, but it needs the modules available
<fda>
and for some additional fuse ko
<dangole_>
fda: but obviously every service which may write to mountpoints should be notified (SIGHUP or restart, depends) once the filesystem situation has changed
<fda>
autofs works the other way: is is mounted if you access it! look at my paste: not mounted > ls to it > mounted
<fda>
umount after 5min or so
<fda>
it gets only not mounted if the remote is not available
<dangole_>
fda: i know. was talking about server side, where nfs exports need to be reloaded once filesystem becomes available.
<dangole_>
fda: and yes, automount-on-access (and umount after 30 seconds) already works using blockd
<fda>
ah, yes
<dangole_>
fda: my goal there was mainly allowing users to create additional volumes on local built-in storage (UBI or block device). for that i made 'uvol', a CLI tool which allows creation of read-only (ie. squashfs) and read-write (automagic ubifs, ext4 or f2fs, depends...) volumes for containers or persistency needs which aren't nicely handled in overlayfs (and sysupgrade), ie. logging, stats, databases, media stuff, ...
<fda>
dangole_: i have to say i wont use it - to have less flash-writes as pissible
<dangole_>
fda: but i thought about network storage at this point, and at least NFS client support in block/blockd wouldn't be more than a couple of lines added
<fda>
i like to use rrd(tool) and it destryed many usb storages until now!
<dangole_>
fda: yes, rrdtool is notorious with that. reliably kills all black-box flash-abstraction bull$%^& out there
<fda>
so i have now a rapberry cifs with a small ssd to collect such databases
<fda>
before that i synced the usb devices to davfs to have a backup when the usb device dies
<dangole_>
fda: right now i'm running full grafana+prometheus in a alpine linux container on the eMMC of my BPi-R2 (using uxc and uvol). we'll see how long the eMMC survives that....
<dangole_>
fda: but usb pendrives and consumer-grade sd cards are definitely the worst. can't use those for database and especially not for rrdtool...
<fda>
dangole_: to much words i dont know! :)
<fda>
i've a small and old ssd and this works well with fedora aarch64 an raspberry
<fda>
as there are 50gb free there is enough space for dead blocks
<fda>
3.287 days uptime until now ^^
<Thermi>
dangole_, that would be wrong, because -swanctl doesn't contain any libs.
<dangole_>
Thermi: maybe i don't understand the issue. why is that a problem?
<Thermi>
dangole_, Either of the plugins is required to provide a socket abstraction implementation for strongswan. strongswan-swanctl contains only configuration scripts, but not any shared objects or binaries. the -socket-default and -socket-dynamic packages contain plugins in the form of shared objects for the charon daemon container in strongswan-charon.
<Thermi>
There's no good reason for the package with only scripts to depend on a shared object that it itself can't even use
<Thermi>
I'll implement the correct fix this weekend, as soon as I have my local packages repo in order.
<Thermi>
*charon daemon service
<Thermi>
(I don't know where the word "container" came from, sorry)
<dangole_>
Thermi: ah ok, get it. so strongswan-charon should depend on strongswan-mod-socket which is provided by either strongswan-mod-socket-default or strongswan-mod-socket-dynamic then, right?
<Thermi>
dangole_, something like that (because I didn't yet decide on the virtual package/symbol that should be provided by the two plugins)
<stintel>
hmm, I might have left out prometheus-node-exporter-lua
Rentong has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
<stintel>
one nice thing I noticed is that this DPAA thing seems to spawn multiple ksoftirqd threads
Acinonyx has quit [Ping timeout: 480 seconds]
Rentong has quit [Ping timeout: 480 seconds]
<Thermi>
stintel, I worked with DPAA2 recently. If you have questions about how it works, you are free to ask.
<Thermi>
DPAA2 is not DPAA though. It's much better.
<stintel>
Thermi: cool, this is all relatively new to me, I just managed to get OpenWrt running without crashes and with the non-switched interfaces working on a WatchGuard Firebox M300. I replaced my APU2 (main router) with one of them, and I'm really pleased by the performance
<stintel>
it is oldish hw though
<stintel>
it's on this device that I discovered the missing dependency
<stintel>
still wondering if I can move the ethernet interface order around just by messing with the DTS
<stintel>
I'm going to try the stock OS
<Thermi>
stintel, AFAIK even with DPAA, you can configure the underlying HW configuration using the DPC and DPL files
<Thermi>
(I am not aware if DPC and DPL are a thing with DPAA, too)
Rentong has joined #openwrt-devel
<fda>
stintel: if you cpu was @variable-100mhz before, and now @static1ghz there is nothing you got
<fda>
i wondered also afte renabling ondemand governor
<stintel>
fda: ?
<fda>
it depends on the current frequency of the cpu stintel
<fda>
i have @300mhz 93% idle, with 1,3 ghz >99%
<stintel>
ah you might be on to something, the APU2 is x86/64 and I believe has ondemand by default
<stintel>
my other APU2 seems to be at ~600MHz (max is 1GHz)
<fda>
i enabled ondemand for e8450 last week and was wondering about different load too
<stintel>
well I'm still happy to see ~750Mbps with SQM enabled
<stintel>
on the apu2 trying that dropped the speed below 200Mbps
<fda>
but with ondemand the cpu has ~5°C less
<fda>
what is the maximum without sqm, have you tested?
<stintel>
wirespeed gigE
<fda>
thx, good to know
<fda>
when i move sometime i may need a device for 1gbit downstream. not sure how much e8450 could handle
<notcreativehere>
running into some issue here. building 19.07.7 images with image builder ramips rt305x and while 2 days ago everything worked completely smooth, today i get opkg throw an error unable to satisfy dependencies for iwinfo, complaining libubus20191227. looking at the package directory listing i do see that right a few hours after my successful image building there has been an update done to the package repo, base repo in this case
<notcreativehere>
packages show upload date Sat, 31st of July. can someone please look what went wrong here? ty
<fda>
swalker: i saw it in ./package/utils/util-linux/Makefile:PKG_CPE_ID:=cpe:/a:kernel:util-linux
<fda>
so such a line should be avoided except it was added manually?
<philipp64>
If ntpd is started from /etc/init.d/system, how do you reload it manually?
<philipp64>
other than rebooting, I mean...
<philipp64>
oh, never mind... it's launched by a hotplug starter...
<notcreativehere>
that is to say the only logic i can do to this, judging by some Sat, 31st July upload stamp to the packages in base repo is that something was modified in it at that date, few hours after using image builder successfully and now it chokes for some reason. all i did change on my end is patching i2c into a DTS file and build with the very same image builder as i did before, which was working ok, related to iwinfo dependencies. t
<fda>
philipp64: "service"
Borromini has quit [Quit: Lost terminal]
<notcreativehere>
reading up on this further, i find: https://forum.openwrt.org/t/cant-use-image-builder-due-to-library-version-changes/98450/3 , exact same issue i do have now in 19.07.7 ramips rt305x since July, 31st, 21 and herewith report it. i think there is not much more i could do in helping there with it, other than reprting it. i lurk around still a bit, in case someone reacts. image builder chokes on iwinfo VS libubus20191227, is brok
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<Slimey>
stintel sorry it was the m200 i ment not the 300
<stintel>
Slimey: gotcha :)P
<stintel>
bloody hell, what a half-assed package is kea :/
<Slimey>
lol im having a start over for sure cause i cant even build ppc targets anymore
<stintel>
no init script, python scripts with this as shebang line: #!/home/stijn/Development/OpenWrt/openwrt/staging_dir/hostpkg/bin/python3
<stintel>
seriously
<Slimey>
yea i made backups of what iv done so far
<stintel>
you could probably take a lot of things from my m300 branch
<stintel>
I'd give it a go but I'm busy with other stuff
<stintel>
and need to go to bed soonish
<stintel>
another weekend gone
<Slimey>
im starting with the p1010 target thats close to the sophos red 15
<Slimey>
maybe ill move to the t1023 if i get it working afterwards
<stintel>
Sophos red is already supported ?
<stintel>
ah, you mean your p1010 device, not your sophos red 15
<Slimey>
no the p1010 device i have is a adtran bsap-2030 and a adtran bsap-3040 with is a T1023
<blocktrron_>
Slimey: that bluesocket unit looks like the same wistron OEM hardware like Aerohive AP-330 / Enterasys WS-AP3825 et al
<blocktrron_>
The P series were largely pin-compatible (with exceptions)
<Slimey>
it is
<Slimey>
the only one i've gotten to boot on the 2030 is the sophos red 15w image
rsalvaterra has joined #openwrt-devel
<stintel>
rsalvaterra: o/
<rsalvaterra>
stintel, \o
<rsalvaterra>
How's the M300 going? :)
<stintel>
it's running in production :D
<stintel>
retired the APU2, RIP!
<rsalvaterra>
Hahah!
<stintel>
keeping the 2nd one on my desk to finalize + test my work before submitting
<rsalvaterra>
All connected eths and switches? :)
<stintel>
no
<stintel>
but I was only using 2 eth's on the apu2
<stintel>
it's so much faster
<rsalvaterra>
Ahhh, whatever. Good enough.xD
<stintel>
yeah, I'll try to get the switchports properly working too before submitting
<stintel>
right now I'm messing with my 2 OC200's, configuring kea dhcp in ha mode
<stintel>
once that's ready I'm going to completely nuke dnsmasq from my OpenWrt devices :P
<rsalvaterra>
I find that a bit sad, since i actually like dnsmasq.
<rsalvaterra>
Unfortunaly it has problems with DHCPv6 and the DNS forwarding could (and should, even for my use cases) be much more featured and flexible.
<rsalvaterra>
*Unfortunately
* rsalvaterra
is writing from a laptop with a broken keyboard
<stintel>
:P
<stintel>
my network is getting even more nuts
<rsalvaterra>
I didn't say anything. I thought, though. :P
<stintel>
can't wait for a decent mt-based 11ax AP with >1GbE PoE-PD uplink and console port
<rsalvaterra>
stintel: The UniFi 6 LR, no?
<stintel>
well, unfortunately it has no console port, and once you open it, it doesn't really close very well anymore
<stintel>
or so I've been told :)
<rsalvaterra>
It has 2,5 GbE, unfortunately still stuck at 1 GbE, due to firmware blob magic.
dedeckeh has quit [Remote host closed the connection]
<rsalvaterra>
The ubnt bootloaders are usually nice enough, I never felt the need for serial console on my AirGrid M2.
<rsalvaterra>
Actually, we still don't have a .dts for the AirGrid M2, specifically. I've been using Nanostation Loco M images on it. I don't know if that's a good or a bad thing.
figgyc_ has quit [Ping timeout: 480 seconds]
figgyc has joined #openwrt-devel
Shiz has joined #openwrt-devel
<Shiz>
not sure if it's been reported yet (was idling on the libera channel instead), but ath79/generic 19.07.7 seems to have a broken luci now in imagebuilder, likely due to this change:
<notcreativehere>
Shiz: very same issue i have in 19.07.7 image builder ramips rt305x target installing iwinfo. is broken. i reported it a few hours ago, no response yet.
<notcreativehere>
Shiz: depends libubus20191227, there is, as of July 31st, 21 no libubus20191227
<Shiz>
yep
rsalvaterra has quit [Quit: Leaving]
<notcreativehere>
that issue i sit in front a broken builder for a few hours already. can't work any longer. are you able to hang around still?; to further try to raise attention. i must go to bed unfortunately. package iwinfo is affected, ramips target rt305x
<Shiz>
yeah it's suboptimal :p
<notcreativehere>
yea :p i was working the entire day on a DTS, hit image builder again and get greeted by a libubus20191227 dependency error
Tusker has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<notcreativehere>
Shiz: do you happen to know if there is a backup somewhere, like an archived state of a repository? before the flush on 31st July 21. to eventually locally host libubus20191227 for image builder. 2 days ago when i was working on this all was cool. now it's no longer. i was assuming this not to happen to a released version of OpenWrt but only versions in active development, but i was apparently wrong.
Tapper has joined #openwrt-devel
<Shiz>
i don't think so i'm afraid
<notcreativehere>
Shiz: ok, i sign off. it's at the end reported twice now in this log, to be eventually recognized later by a person that's currently not available. ty all. good night.
<Shiz>
:) gl!
<Shiz>
hoping for the best here too :p
<Shiz>
at least 19.07.8 seems to be built now
<Shiz>
so worst case that'll likely be available when you wake up
fda has quit [Remote host closed the connection]
fda has joined #openwrt-devel
<notcreativehere>
we will see. same for you
notcreativehere has left #openwrt-devel [#openwrt-devel]