<grift>
hmm, maybe, i dont see it like that though, either you do it or you dont. its not like anyone will ever find out if you do right anyway
<olmari>
mm.. openwrt specifically is still.. well... as far as I know an hobby to everyone involved, as in no one is getting paid to work with it, correct me if I'm wrong... and for broad general using actual name is just logical
<Borromini>
neat, i didn't know you could tell jffs2 what kind of compression to use
<rsalvaterra>
Borromini: You can. When this is accepted upstream, I'll take care of the OpenWrt (and fstools) part… ;)
<Borromini>
;)
<Borromini>
what's the compression gain?
<rsalvaterra>
Expect a compression *loss*, not gain. The point is to reduce the number o compression algorithms in the kernel to the least possible (ideally one which is good for everything, and the best candidate at this time is zstd).
<Borromini>
ok
<rsalvaterra>
Compression algorithms are relatively large beasts. Having just one is beneficial.
<Borromini>
ok
<Borromini>
does openwrt include multiple by default? sorry for the basic questions.
<rsalvaterra>
Yes, it does, especially for jffs2. It even includes lzma, which is not even part of the kernel proper. Just take a look at 530-jffs2_make_lzma_available.patch.
<Borromini>
ok
<rsalvaterra>
It's all the sorts of insane I can imagine, and most likely lot of them I can't.
<rsalvaterra>
Granted, it's an *old* patch… forward-ported since the dawn of days, I wager.
<Borromini>
lzma has been around for a while
<rsalvaterra>
The algorithm, yes. But there's no upstream kernel support for lzma (and it doesn't make sense, nowadays).
<Borromini>
as in newer and more efficient algorithms have popped up?
<rsalvaterra>
Borromini: Exactly. Case in point, zstd. :)
<Borromini>
guys, i can overrule dts properties right? if a dtsi has wifi0,0 blabla i can do &wifi0,0 in my top dts to override those settings?
hgl- has quit [Quit: Bye]
hgl has joined #openwrt-devel
hgl has joined #openwrt-devel
hgl has quit [Changing host]
<svanheule>
Borromini: that should work.
feriman has joined #openwrt-devel
<mangix>
The solution is to replace jffs2 with f2fs.
* mangix
hides
<stintel>
=)
<stintel>
I believe that also has problems with small sizes
<Borromini>
thing is the eeprom property used not to be in the dtsi.
<Borromini>
erm sorry the @ should be an &
<svanheule>
Borromini: no, that won't work (even with &)
<svanheule>
& can be used with a label
<svanheule>
i.e. "node_label: node {...}"
<svanheule>
alternatively, you can specify the full path: /pci_whatever/wifi@0,0 {...}
<rsalvaterra>
For those who might think f2fs is a good solution, remember f2fs assumes wear leveling at the lower layer. And don't get me started on the (space) overhead. :P
<Borromini>
svanheule: ok so i'd need to strip it from the dtsi again then
<svanheule>
Borromini: is this a new DTSI, or an existing one?
<mangix>
rsalvaterra: mtd-utils might need patching as well
<Borromini>
svanheule: it's an existing one, mt7621_netgear_sercomm_chj.dtsi
<mangix>
It's somewhat strange that LZMA is used
<rsalvaterra>
mangix: s/strange/insane/
<Borromini>
svanheule: commit 0cf889db00 has shuffled some stuff around.
<Borromini>
svanheule: there the wifi nodes do overrule the eeprom property, so i'm a bit confused
<rsalvaterra>
mangix: Have you seen the size of the lzma patch?
<svanheule>
Borromini: so "&pcieX { wifi@0,0 { ... } }"
<mangix>
I have not. Not on a computer ATM
<Borromini>
svanheule: ok, so i overrule the complete node in the top dts?
<rsalvaterra>
mangix: It's over 140 kiB. In a *single* patch.
<svanheule>
Borromini: well, I think that's just specifiying where the node is located in the tree, so that (property) overrides happen in the right place
<rsalvaterra>
mangix: Yep, that's why I went with zstd. :)
<Pepe>
Borromini: Hm, but what about if you are working under NDAs and such?
<Pepe>
(oh this one should be to "thread" about working as kernel dev, but can not link any work)
<Borromini>
Pepe: concerning the e-mail/real name stuff? i don't think that's what Festivenari is doing. he has a pile of old Broadcom stuff he's playing with
<svanheule>
Borromini: AFAICT only the mediatek,mtd-eeprom properties are different, so you don't have to specify the other ones. But then information is really scattered acros files, so reviewers may not like that
<Borromini>
svanheule: ok. as you can see from commit 0cf889db00 that's how it used to be (just the eeprom property). but if this works for this guy i'll send in the patch with the full nodes
<Festivenari>
Borromini: yep, you're correct. I do have a pile of broadcom-based routers (luckily a few are already supported by OpenWRT)
<Borromini>
a few extra lines that help readability won't annoy most people i reckon, like you say
<rsalvaterra>
lipnitsk: That's a patch from LEDE. Have you tested MT7621 without WEAK_REORDERING_BEYOND_LLSC in a recent kernel?
<Festivenari>
Borromini: I must admit that it is a shame that broadcom is not willing to open-source their drivers
<Festivenari>
I have to wonder how many vulnerabilities there are in their drivers
<Borromini>
Festivenari: it is, but most big companies seem to think security by obscurity is a good thing.
goliath has joined #openwrt-devel
victhor has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
koniu has quit [Remote host closed the connection]
<johnf>
so it looks like you can't build a single kmod like that
<johnf>
my target/linux/compile contains no references for xfrm_interface
<Borromini>
johnf: sorry
<Borromini>
make package/kernel/xfrm-interface/{clean,compile} V=s
<Borromini>
try that
<johnf>
ok, sure, just a moment
<Borromini>
although there's no subdir in package/kernel so that might not work either
<johnf>
make[1]: *** No rule to make target 'package/kernel/xfrm-interface/clean'. Stop.
<Borromini>
nope
<johnf>
ok, so I could give you the full build logs probably
<johnf>
CC [M] net/ipv4/xfrm4_tunnel.o
<johnf>
I do see other xfrm packages getting built
<johnf>
but nothing for xfrm_interface
<johnf>
this is very confusing
<stintel>
svanheule: that reminds me I should really get my OpenWrt build + deploy pipeline back up and running
<stintel>
I had staged deployments for my Raspberry Pi Zero W's - 1 testing, if it came back after sysupgrade, all others were auto sysupgraded too
<stintel>
can do the same for my ERL as I have two
<stintel>
(and only one of them running in production)
<johnf>
there's a kernel config, that get's generated from the settings in .config
<johnf>
right?
<stintel>
yes
<stintel>
tmp/.kconfig-target-subtarget or something
<stintel>
tmp/.kconfig-target_subtarget
<johnf>
CONFIG_XFRM=y
<johnf>
# CONFIG_XFRM_INTERFACE is not set
<johnf>
ok, so this is the root cause of my issue
<johnf>
now look, I'm not going to lie to you, I may have done a few things to this kernel
<johnf>
to free up ram
<stintel>
johnf: maybe rm -rf tmp/ and build again, just to be sure it's not a temp glitch
<johnf>
building
<Borromini>
stintel: would you mind sharing the code for that?
<johnf>
really appreciate the help stintel, Borromini
<stintel>
Borromini: it was OVH CDS based and I decided it's too hard to maintain my own CDS
<stintel>
other option is to use public gitlab and local runner but I don't trust cloud-based things enough to add an SSH key that allows root login to my OpenWrt devices
<stintel>
even if it's only on the runner
<stintel>
the runner can be controlled by the cloud, so there's a possibility that can be exploited
<stintel>
so a local CI/CD thing is the only acceptable thing for me
<stintel>
also I really don't like gitlab, that was my reason for looking at alternatives in the first place
koniu has quit [Remote host closed the connection]
* stintel
making it hard on himself since 1984
koniu has joined #openwrt-devel
<johnf>
lol
arnd has joined #openwrt-devel
arnd has quit [Changing host]
<johnf>
ok, it's still building, but I took a peek in tmp
<johnf>
same behaviour, that module isn't selected
<stintel>
johnf: then I'd suggest to look at the dependencies in the kernel source
<johnf>
kmod-ipsec6 isn't selected and I have disabled IPv6
<stintel>
did you disable IPv6? :)
<johnf>
fuck
<johnf>
yes, of course
<johnf>
it's so big
<stintel>
yeah, don't do that, it's 2021. there's no valid reason to do so
<johnf>
32MB of RAM says there's a reason
<johnf>
but I do see what you're saying
<rsalvaterra>
johnf: No, there isn't. I have IPv6 enabled on a 32 MiB device (AirGrid M2).
<stintel>
another option is: drop IPsec and use wireguard
<stintel>
I'm seriously considering that, unfortunately I'm having major issues with wireguard on openwrt
<stintel>
didn't get to debugging that yet
<stintel>
when I can get that fixed I'm even going to stop maintaining strongswan in the packages feed
dedeckeh has quit [Quit: Connection closed]
<johnf>
I have like 2000 routers running variants of this image
<johnf>
I'm not moving to wireguard any time soon
<stintel>
ok, that might be difficult :)
<johnf>
though I have used it for some other stuff quite well
<johnf>
rsalvaterra: not with strongswan, quagga/frr and some other stuff
<stintel>
I have only 4 OpenWrt devices with IPsec, and even that was enough to hold off on migrating to wg
<johnf>
hmm
<stintel>
spent a lot of time optimizing that setup, and don't fix if not broken etc
<johnf>
is there a way I can update that kconfig file without actually building?
mmlb has quit [Ping timeout: 256 seconds]
<Borromini>
johnf: if you throw out PPP you should still have quite a bit of wiggle room even with 4/32
<Borromini>
it sounds like actually if you disable ipv6 you shouldn't even be seeing xfrm-interface as selectable, if it needs ipv6
<Borromini>
johnf: make kernel_menuconfig
<johnf>
need PPP for mobile
<johnf>
it's giant too
<johnf>
I'm amply aware :/
dedeckeh has joined #openwrt-devel
<johnf>
man, I was so happy when I finally got this thing built
<stintel>
johnf: can you do vti instead of xfrm?
<stintel>
xfrm is nicer, sure, but maybe it's an acceptable solution
<johnf>
already have 300 XFRM devices deployed, and my cisco core needs this XFRM setup
<johnf>
it's these ancient routers that are proving particularly challenging
<johnf>
and I have rather a lot of them
<stintel>
hmmm
<stintel>
I believe one side can use XFRM while other side can use VTI no problem
<stintel>
actually I'm sure it can, I'm doing it
<johnf>
hmm
<johnf>
I really want to just get this module built
<johnf>
I've already put a lot of effort into this current config
<johnf>
don't want to fragment things further
<johnf>
but we'll see what options I have
<johnf>
where did you get that DEPENDS info above stintel?
<stintel>
well I guess you'd have to look into the possibility of dropping the IPv6 requirement for the xfrm_interface module, but that might be even harder :)
<johnf>
lol
<stintel>
johnf: linux.git net/xfrm/Kconfig
<johnf>
that's not in the cards
<johnf>
ah
mmlb has joined #openwrt-devel
<johnf>
ok, so I've brought kernel IPv6 back
<johnf>
but not userspace
<stintel>
I will add that dependency to the kmod
<johnf>
but when I'm building
<stintel>
saves other people the trouble in the future :)
<johnf>
that module appears to still not be selected
<johnf>
XFRM is definately selected, builds as well
<johnf>
CONFIG_IPV6=m
<johnf>
global v6 is present (as a module, is that a thing?)
<johnf>
but I don't know if you can express that dependancy
<stintel>
ok, so my change would actually mess up what you're doing
<johnf>
I sort of think no one should do what I'm doing
<stintel>
:D
luke-jr has joined #openwrt-devel
<ldir>
aha! it's bleeding edge sqm-scripts thing.
<rsalvaterra>
ldir: The sqm-scripts package should be split… :/
<rsalvaterra>
Lots of stuff depending on it which, most of which goes unused (kmod-sched).
<rsalvaterra>
I wager most people install sqm-scripts for cake.
<johnf>
stintel: so, for that patch, is there a way for you to validate the kernel IPv6 configuration?
<johnf>
I suspect not :/
<johnf>
or, at least, really not easily
<stintel>
actually: KERNEL_IPV6
<johnf>
# CONFIG_KERNEL_IPV6 is not set
<johnf>
that's strange
<stintel>
yeah, it doesn't check what happened in kernel_menuconfig
<johnf>
ah, I see
<stintel>
maybe I'll just nuke the patch
<johnf>
and there's no direct way to set that
<stintel>
indeed
<johnf>
what would be awesome
<johnf>
would actually be
<johnf>
if the build failed
<johnf>
if I'd known I'd created an ipkg with no file in it
<johnf>
I could have then figured out why then
<johnf>
not found out a month later that the package I installed didn't contain a .ko
<johnf>
oh wow, I think the upgraded version didn't boot
<johnf>
:/
<johnf>
let me get this onto the board with serial headers
<stintel>
problem is kmod packages can be empty while not being an issue, like when a specific target kernel config has something built-in and user still selects the kmod package (and buildbots enable all kmod packages)
<stintel>
so we can't really fail on empty kmod package
<johnf>
hmm
<johnf>
if it was in the package spec then you could detect issues like this
<johnf>
but that's not a small change
dorf has quit [Remote host closed the connection]
<johnf>
ok, so this is complete insane
<johnf>
things appear to be ok for the xfrm module
<johnf>
but my lan has stopped working
<johnf>
ifconfig: br-lan: error fetching interface information: Device not found
<johnf>
ifname is properly configured
<johnf>
option ifname 'eth0'
<johnf>
however, I see the interface in a bit of a strange state
<johnf>
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
valku has joined #openwrt-devel
feriman has quit [Ping timeout: 245 seconds]
feriman has joined #openwrt-devel
dangole has joined #openwrt-devel
SpaceRat has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 260 seconds]
Acinonyx has joined #openwrt-devel
DGDodo has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 245 seconds]
Acinonyx has joined #openwrt-devel
SpaceRat^ has joined #openwrt-devel
SpaceRat has quit [Read error: Connection reset by peer]
SpaceRat^ is now known as SpaceRat
<owrt-snap-builds>
build #747 of armvirt/64 is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F64/builds/747 blamelist: Daniel Golle <daniel@makrotopia.org>, Bj?rn Mork <bjorn@mork.no>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>
rsalvaterra has quit [Ping timeout: 245 seconds]
rsalvaterra has joined #openwrt-devel
plustwo has joined #openwrt-devel
<lipnitsk>
rsalvaterra: thanks, I'll take a look. Would love to just drop that weak reordering patch, but was thinking it was really needed by the platform. I'll do some testing without it, but it really depends on how intermittent the issue was in the first place
junland has quit [Quit: %ZNC Disconnected%]
<rsalvaterra>
lipnitsk: Hi! :) I'm running an image without that patch as we speak. ;)
<rsalvaterra>
So, give me a couple of days to make sure it's stable.
<rsalvaterra>
I can send a patch to delete it afterwards, how about it?
<lipnitsk>
rsalvaterra: thanks. Yeah good find on that kernel fix too
<lipnitsk>
rsalvaterra: sounds great to me
plustwo has quit [Quit: Connection closed]
<rsalvaterra>
Great! I'll cc you on the patch, then. :)
plustwo has joined #openwrt-devel
<rsalvaterra>
Makes me wonder how many obsolete hacks we've been carrying…
<lipnitsk>
rsalvaterra: yay! One of the patches did get accepted upstream too, so one less patch eventually.
<lipnitsk>
rsalvaterra: yeah I know. Btw I removed the lpj calibration hack locally, works fine on my er-x
<rsalvaterra>
lipnitsk: Ah, yes, I saw that one too! :)
<lipnitsk>
rsalvaterra: yeah. Or just leave 5.4 alone and let it die eventually. Though you might get a bit more testing with people still on 5.4?
<rsalvaterra>
lipnitsk: We need to remember there are more branches than master… ;) People are waiting for 21.02, it would be nice to give them as many bonuses as we can, no? :)
dedeckeh has quit [Quit: Connection closed]
<lipnitsk>
rsalvaterra: sure, but some of these cleanups don't really qualify as fixes so seems like an uphill battle to get them merged to 21.02
<lipnitsk>
Though the weak reordering thing might speed things up, just don't know how much testing it requires
Tost has quit [Ping timeout: 245 seconds]
<rsalvaterra>
lipnitsk: To be honest, it would be extremely strange for the 1004Kc to require WEAK_REORDERING_BEYOND_LLSC… from what I can tell, only a very restricted number of 64-bit MIPS CPUs select that kconfig option: Loongson GSx64(GS264/GS464/GS464E/GS464V) and Netlogic XLR/XLP.
<rsalvaterra>
The 1004Kc is just a 34Kc with an extra pipeline stage (thread selection, for SMT). And GCC doesn't even care, just treats it like a 24Kc. :P
<Rene__>
lipnitsk: i tried to test of the upstream changes but there were so many changes that I could not get a compilable upstream kernel with a propper dts
<lipnitsk>
Rene__: which changes are you talking about?
<Rene__>
do you have a repo of your upsteam kernel so I can test my ErXsfp
<Rene__>
yout trgmii patch, also saw nbd hw offload patch in the net mailing list and the clock patches
<rmilecki>
Rene__: did nbd post some netfilter offloading patch?
<lipnitsk>
Rene__: honestly, I have not tried compiling upstream, just testing with 5.10 openwrt as much as time permits
<lipnitsk>
Rene__: I'd like to clean up the openwrt patches a bit more - maybe then I'll attempt building and loading an upstream kernel. Will let you know when that happens, but may be a while.
<bkallus>
Dissecting a stock firmware, I found a file called cferam.000, but once I boot up the router into that firmware, the file's name is cferam.068. These files differ. Can someone tell me what's going on there? I wouldn't think the bootloader would change like that
<Rene__>
lipnitsk: this old commit added erxsfp dts and option to the upstream kernel a2e0e96ce20a335dae26dec1ebf9cdcc1b5379d7
<Rene__>
but a lot has changed and I fail to update to the lastest kernel, dts and all mt7621 patches