<mangix>
libarchive: DEPENDS:=+zlib +liblzma +libbz2 +libexpat . never mind then.
<stintel>
jow: yes
<mangix>
aparcar: busybox' unzip.c is 1070 lines
goliath has quit [Quit: SIGSEGV]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
mva_ has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
Grommish has joined #openwrt-devel
amaumene has quit [Remote host closed the connection]
amaumene has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
zorun has joined #openwrt-devel
Thagabe has joined #openwrt-devel
<Thagabe>
#LFG
minimal has quit []
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<Thagabe>
Does Marvell switch config have vlan tagging?
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
valku has quit [Quit: valku]
nitroshift has joined #openwrt-devel
snh- has joined #openwrt-devel
Thagabe has quit [Quit: Page closed]
snh_ has joined #openwrt-devel
snh- has quit [Read error: Connection reset by peer]
snh has quit [Ping timeout: 480 seconds]
snh_ has quit []
snh has joined #openwrt-devel
tchebb has quit [Ping timeout: 480 seconds]
tchebb has joined #openwrt-devel
AndyCap has joined #openwrt-devel
Tapper has joined #openwrt-devel
srslypascal is now known as Guest1739
srslypascal has joined #openwrt-devel
Guest1739 has quit [Ping timeout: 480 seconds]
amaumene has quit [Remote host closed the connection]
amaumene has joined #openwrt-devel
lipnitsk has quit [Server closed connection]
lipnitsk has joined #openwrt-devel
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
<rsalvaterra>
tohojo: I don't think the new sqm-scripts dependencies are correct… right now, if one selects fw3 instead of fw4, sqm-scripts stop being selectable at all. :/
<stintel>
for octeon 5.10 bump and source-only ... I'm not seeing a leak anymore. could it be that vlan/bridge leak that was plugged in 5.10.96? I guess I'll revert the 5.10.96 bump and try
<aparcar>
stintel: are you sure it should be source-only?
<stintel>
that suggestion came from hauke
<stintel>
what I just wrote is in response to that
pmelange has left #openwrt-devel [#openwrt-devel]
<aparcar>
okay fine with me
<stintel>
so given my observations I would wait just a bit longer to give me a bit more time
<stintel>
and not bump + source-only just yet
<rsalvaterra>
stintel: What about the dnsmasq issue Grommish mentioned?
<Grommish>
Is there another release gearing up that is necessitating the immediate decision? Given the way Kernel Versioning is done now being self-contained, is there a real impetus in removing 5.4 just go you can put 5.15 as testing?
mattytap has joined #openwrt-devel
<Grommish>
"Maintaining" means leaving the existing backport/patches/pending and the include/kernel-5.4 file, right?
<stintel>
we want to branch soonish, afaik
<Grommish>
*nod*
<Habbie>
oh, 22.x is happening?
Tapper has joined #openwrt-devel
<f00b4r0>
6 months after 21.x? That'd be quick. I might skip 21.x altogether then ;-)
goliath has joined #openwrt-devel
<Habbie>
branching is not yet releasing :)
<f00b4r0>
true :)
<rsalvaterra>
f00b4r0: I guess we're trying to redeem ourselves from the huge 21.x delay. :)
<f00b4r0>
rsalvaterra: heh. Personally I don't see a problem with long release cycles for openwrt, so I'm not one to complain. I'd rather have one release with a long maintenance schedule; so I don't have to worry when I upgrade
<jow>
+1
<f00b4r0>
avoiding the scenario that stintel had to endure :)
<stintel>
well that and people pushing for 5.15 but adding 5.15 will distract everyone and further delay a release
<stintel>
oh well
* rsalvaterra
likes to play with new shiny toys… :P
<Grommish>
f00b4r0: Hard agree.. When I was doing Android ROMs, we didn't release just to release, wasn't worth the aggrivation :D
<f00b4r0>
:)
<Grommish>
rsalvaterra: But, you can build from source, would use master, and the release schedule has no hold on you
<Grommish>
hehe
robimarko has joined #openwrt-devel
<rsalvaterra>
stintel: True. The push for 5.15 is premature, in my opinion, but there's nothing stopping people from sending pull requests…
<rsalvaterra>
robimarko: Because we don't even have all targets at 5.10.
<jow>
that too
<robimarko>
And that is really not gonna change
<jow>
size increase will mean losing another round of supported devices
<\x>
robimarko: I have been running pr 4721 since november, It is stable so far. just want to thank you man. now configuring vlans is not a big issue on my ipq40xx anymore, I do have three of them :D
<robimarko>
jow: We have some weird targets that dont have users at all
<rsalvaterra>
jow: We still have some tricks up our sleeves to reduce image sizes.
<rsalvaterra>
But I don't know how acceptable they would be.
<robimarko>
Like?
<robimarko>
\x: Thanks
<rsalvaterra>
robimarko: Monolithic kernel builds and -Os for the kernel.
<jow>
drop printk
<\x>
robimarko: 3x R619AC here, im only running untagged lan and tagged guest, been running so stable ever since.
<jow>
drop opkg
rua has joined #openwrt-devel
<stintel>
actually we're getting quite close to having all targets on 5.10 I think?
<stintel>
arc770 was nuked
<robimarko>
stintel: Yeah, I think that Hauke is pushing those now
<robimarko>
ath25 has a PR, but nobody reported on it
<stintel>
so ath25 can be nuked too if nobody reports anything
<robimarko>
Well, there was a PR to nuke
<robimarko>
But then somebody volunteered to port it
<stintel>
octeon ... I'm testing, but this exotic unaccounted FPA memory shite is shite
<rsalvaterra>
jow: Dropping printk…! Now there's a bold move… ;)
<f00b4r0>
i don't want to sound dismissive but that pattern (of accelerating releases and dropping targets) reminds me of Debian at the time I left the project. Dunno if that's a good or bad thing tho :)
<Grommish>
*facepalm* rsalvaterrais bad in bit-hunting mode! Run busybox, run!
<robimarko>
f00b4r0: But what can be done about targets that arent used?
<Grommish>
err is back in
<stintel>
f00b4r0: there's been plenty of time for people who care to fix their targets
<robimarko>
It seems nobody cares about them
<rsalvaterra>
LOL! xD
<stintel>
we're actively informing known users
<stintel>
so if they don't care, why should we ?
<f00b4r0>
robimarko: well, what would be really nice here is some download stats. So we know what targets are / aren't used. Dunno if that's already available?
<robimarko>
There should be some
<stintel>
download stats have been available for ages
<robimarko>
But what are download stats good for if there are no devs
<robimarko>
And boards for a lot of those are getting really rare
nitroshift has quit [Quit: Gone that way --->]
<stintel>
lol people are still downloading 17.01 :D
<f00b4r0>
stintel: I do :D
<Grommish>
People are still asking about ChaosCalmer
<f00b4r0>
ah no, not 17. 19
<stintel>
CC is because vendor SDKs
<robimarko>
You can ask the vendors
<robimarko>
They are the culprits
<robimarko>
They are just slowly moving to 19.07
<robimarko>
I mean, just look at the forum
<robimarko>
Every day its multiple questions about why is their board not supported when it runs OpenWrt
<Grommish>
Realistically, I'm going to continue using my MIPS64 devices until they let out the blue smoke, but I build from source, and my device only had like 500 units made, of which I own 2
<f00b4r0>
robimarko: you have a point, but my perspective is that of OpenWRT being a "second life" for hardware that's no longer supported by vendors. I strongly support the idea of reducing landfill this way. Then again, I'm ever the idealist :)
<robimarko>
And guys like Wallys etc arent helping
<Grommish>
So, while I'd rather not see Octeon go away for people who can't or don't know better, eh..
<Grommish>
Practically, I'm sure those resources could be used elsewhere on the buildbot
<robimarko>
f00b4r0: Trust me, I dont want HW to be just thrown away
<stintel>
f00b4r0: people can use the targets feed
<robimarko>
But somebody has to maintain it
<f00b4r0>
stintel: the targets feed? how do you mean?
<robimarko>
And it seems that there is less and less people willing
<stintel>
or someone can step up and commit to maintain OpenWrt with older kernel
<Grommish>
Not if the tree goes away :
<stintel>
but good luck :)
<f00b4r0>
robimarko: agreed. And that's where slow release cycle reduces the pressure
<robimarko>
Well, we already have slow release cycles
<Grommish>
stintel: That's a good question.. if Octeon goes away, I'm assuming the feeds generated for it will also go?
<Grommish>
I'd imagine so since no images would be created.. It just means you have to bake everything in
<stintel>
I guess that thing is a dead end
<robimarko>
Or run your own feed
<jow>
sigh, who on earth invented that atrocious ethtool api
<robimarko>
In kernel or netlink/IOCTL?
<f00b4r0>
stintel: last update 6 years ago, yes, I think it's dead, Jim ;)
<jow>
to obtain a single extended feature flag (something you used to be able to scrape out of sysfs) you now have to do a "stringset" request to obtain a list of named features
<jow>
than precalculate some ioctl buffer based on that
<jow>
then actually request those features
<Grommish>
robimarko: You can use the standard feeds, but opkg update/remote installs wouldn't work anymore would it?
<robimarko>
Yeah
<jow>
then reverse map that string set list to bits within a dynamically sized bitfield array
<stintel>
f00b4r0: not my fault, again nobody cares
<f00b4r0>
ack
<robimarko>
Grommish: Thats what I mean, by run your own feed
<Grommish>
robimarko: but, if it isn't generating the images, then it doesn't matter anyway and you're building from source
<f00b4r0>
interestingly ar71xx wasn't moved there
<robimarko>
Yeah, but if you want opkg then you can build everything
<robimarko>
And run a public feed
<robimarko>
f00b4r0: I think it was because ath79 replaced it
<robimarko>
It wasnt just dropped
<Grommish>
robimarko: Eh, I've done that before I got the Itus put in place.. it's a huge pain to support a userbase that way
<Grommish>
and CONFIG_ALL takes forever :X
<robimarko>
Well yeah
<robimarko>
That is why buildbot reasources are precious
<stintel>
can we check top downloads for previous months in awstats?
f00b4r0 has quit [Server closed connection]
<stintel>
right now it seems x86/64 and raspberry pi are most popular but february just started ...
f00b4r0 has joined #openwrt-devel
<stintel>
most popular package: /releases/19.07.0-rc2/packages/arm_cortex-a9_vfpv3/base/wpad-openssl_2019-08-08-ca8c2bd2-2_arm_cortex-a9_vfpv3.ipk
<stintel>
what the
<stintel>
also Downloads (Top 10) doesn't agree with OpenWrt firmware image downloads
<jow>
stintel: there's a lot of fear eastern strangeness going on
<wigyori_>
we had a similar exercise with the archives couple years back - some packages from 8.09 were the most downloaded packages because of mikrotik worms
<f00b4r0>
robimarko: ath79 did replace it but does not support as many devices AFAICT. As for buildbot resources, I can't help but think that building identical images that only differ in device names are quite a waste, but that bird has flown :)
<jow>
assembling redundant images is the least problem
<jow>
redundant pkgarches are the big ressource killers
<f00b4r0>
true
<robimarko>
f00b4r0: Well, nobody stepped up to port those some boards
<robimarko>
f00b4r0: Chunkeey replied again, I really dont understand what is his point
robimarko has quit [Remote host closed the connection]
<f00b4r0>
if I may be blunt, I think he's being dense here.
<jow>
I suppose the basic points seems the be 1) not patch ath*k 2) utilize any of the various existing solutions instead of adding yet another one
<f00b4r0>
jow: what he describes isn't the reality. The kernel doesn't look on the filesystem. The kernel emits a hotplug call. However that call is served is entirely implementation dependent.
<jow>
/maybe/ he thinks that ath10k change somehow isn't worth introducing because it is (so far) only used in conjunction with a facility (sysfs path) that is not upstreamable
<jow>
(my interpretation, not my opinion)
<robimarko>
f00b4r0 already told him multiple times that it can be upstreamed
<robimarko>
I dont see whats his issue with the platform driver
<robimarko>
It replaced the various userspace stuff in a much better and universal way
<robimarko>
Even if this is the only current user, who is to say that there wont be another one
<robimarko>
It would be ideal if we can just generate API2 board-2.bin-s on the fly
<jow>
and what is preventing this on-the-fly-generation?
xes_ has quit [Server closed connection]
<robimarko>
Well, you need to generate it
<jow>
jsut read that statement on your patch description. I do not know enough about API 1 vs. API 2 format
<robimarko>
Its a wrapper around the BDF
<robimarko>
API1 is just the BDF itself
<f00b4r0>
jow: one could arguably construe that the ath10k patch is a *bugfix*, since sending the same path for two different devices is a *bug*
xes_ has joined #openwrt-devel
<f00b4r0>
robimarko: in fact you should probably reword your commit to point that out
<robimarko>
API2 is the wrapper they invented so you can have X number of BDF-s inside of the same file
<jow>
I suppose each accompanied with some kind of selector
Habbie has quit [Server closed connection]
Habbie has joined #openwrt-devel
<jow>
so the driver receives the whole wrapper bundle with multiple BDFs embedded and then selects a matching one based on some criteria like PCI IDs?
<robimarko>
Yes, you provide the driver with the variant string in the DTS
<robimarko>
And then it matches that along with the BMI ID-s that are baked in the caldata
<jow>
ahh, so like a static key
<robimarko>
Yeah
<robimarko>
And thats the limit
<jow>
whicb in turn would imply the need to have multiple images
<robimarko>
At best
<f00b4r0>
jow: basically this requires hard-coded def in DTS, whereas the BDF-1 approach is self-sufficient.
<robimarko>
Cause Mikrotik just changes them as they wish
<jow>
which is not ideal since customer-facing the hardware revs are indistinguishable
<robimarko>
And the boards are the same revision
<f00b4r0>
neggles pointed out yesterday a case where BDF-2 is simply not practical at all
<robimarko>
Yeah, regional BDF-s are really ment to be on the fly
<f00b4r0>
jow: it may be that to robimarko and I the rationale is so obvious that we're not explaining it clearly enough, but I hope you can see it now
<jow>
and constructing API 2 format on the fly will not work because of the fact that two radios phys request the same board.bin but expect different BDFs
<robimarko>
Well, actually it would
<robimarko>
Cause each of them has a different BMI ID
<f00b4r0>
jow: and even if it were possible, it requires "more work" than simply passing the BDF-1 binary data. At which point you might end up in a situation where you're not serving the firmware fast enough and loading fails.
<robimarko>
But its not easy to generate it on the fly at all
<robimarko>
While just passing the BDF-1 is easy
<f00b4r0>
^
<jow>
ah okay, so its not "not possible" but "not easy"
<robimarko>
To say the least
<jow>
and arguably the complexity of the on-the-fly solution would surpass the proposed one
<robimarko>
Yeah, that is for sure
<f00b4r0>
definitely
<robimarko>
Cause this is really simple
<f00b4r0>
it can't be any simpler
<robimarko>
Just utilize existing infrastructure and just request the BDF with a specific name
<robimarko>
And not just blindly use whatever is named board.bin
<Grommish>
I was trying to figure out what BDF stands for
<jow>
on-the-fly API 1 BDF-s: officially legacy, yet supported
<robimarko>
Its all data related on how the radio/board RF is configured
<robimarko>
But its vital in order for WLAN to work
<Grommish>
Thanks!
hexa- has quit [Server closed connection]
<neggles>
robimarko: "Cause each of them has a different BMI ID" - about that...
<jow>
prepackage board.bin: requires different images; not practicable
<neggles>
Sophos APX530 says "hahahahahahahahahaha NO THEY DON'T"
hexa- has joined #openwrt-devel
<robimarko>
Well, then they managed to break that as well
<robimarko>
So you cant use BDF2 at all then
<neggles>
the driver in the OEM firmware...
<neggles>
requests...
<neggles>
boarddata-0.bin and boarddata-1.bin
<f00b4r0>
robimarko: honestly, I'm now thinking you would get more traction by opening a kernel bug about the same path issue, and posting your fix for it
<neggles>
for radio 0 and radio 1
<jow>
f00b4r0: which is, I suppose, exactly what Christian wants
<f00b4r0>
jow: well he has a very convoluted way of saying so :)
<robimarko>
Well, then he has a weird way of saying it
<neggles>
like... QSDK *already* requests files from different paths depending on which radio it's asking for data for
<robimarko>
Cause QSDK never moved to BDF2
<robimarko>
Even ath11k supports BDF1
<neggles>
if the company that makes the chips doesn't do it like this
<robimarko>
Cause of QSDK
<f00b4r0>
jow: at least I hope the benefits of robimarko's PR are more obvious to you now
<neggles>
why on earth
<neggles>
do we
<jow>
f00b4r0: the benefits were always obvious, I was trying to understand the arguments
<f00b4r0>
ok
<f00b4r0>
i hope you haven't been disappointed then :)
<robimarko>
neggles: Cause its usually easier to just package all of the BDF-s in one place and have the driver match the correct one
<neggles>
robimarko: fair, but, as we've demonstrated, that doesn't always work
<robimarko>
Yeah
<robimarko>
Hence the usually
<neggles>
it just seems incredibly backwards to request a file per radio for pre-cal, but not board data - you can say API v1 is deprecated all you like, but the vendor isn't using it, and what's the harm in looking for a radio-specific file first?
<neggles>
er, s/isn't/is
<robimarko>
Well, there is no harm
<f00b4r0>
neggles: the argument about discrepancy between pre-cal and BDF is also a strong one in favor of a "bug" behaviour.
<neggles>
yeah
<neggles>
you could argue for looking for the APIv2 file first, then APIv1 if not found, since v1 is 'deprecated'
<f00b4r0>
if pre-cal behaved as BDF, nothing would work.
<robimarko>
neggles: Yep, APIv2 aka board-2.bin is looked for first
<robimarko>
And if that fails it moves on to just look for APIv1 aka board.bin
<neggles>
yep just looked again
<neggles>
...still failing to see the issue...
rua has quit [Ping timeout: 480 seconds]
<robimarko>
I can open an issue on bugzilla, mabye that gets some traction
<robimarko>
Cause Kalle just asked if somebody can review it
<robimarko>
And that was it
<neggles>
I tell a lie, the APX530 *does* have different board IDs per radio, i was looking at the wrong log
<neggles>
so I guess you *could* technically build an APIv2 file 'on the fly', but it's still a waste of flash
<robimarko>
Well, the only tool to generate them is in Python
<robimarko>
So thats gotta be moved into C or shell
<jow>
I always thought the userspace firmware helper can simply cat the firmware contents to a sysfs file
<robimarko>
And I dont like adding another tool
<neggles>
chunkeey dropped a `sh` script using some printfs in there
<f00b4r0>
jow: they can, and that's exactly what I implemented
<f00b4r0>
sadly, it's only used for mikrotik devices, for $reason.
<jow>
the current flow (regardless of the discussed PR) seems to be generate file, store somewhwere, fail (in the sense of not uploading firmware contents)
<neggles>
then retry and succeed this time
<neggles>
?
<jow>
then invoke another tool which actually uplaods
<jow>
or that, yeah
<f00b4r0>
no. They generate the file, and then fail + retry
<neggles>
ath wifi drivers are such a mess
<nbd>
wouldn't it make sense to just generate the files at boot before the module loads?
<jow>
nbd: apart from the totally uneeded waste of flash it would be possibility, yes
<nbd>
could be symlinks to /tmp
<f00b4r0>
jow: my argument for caldata_sysfsload_from_file() was exactly to "correctly" use the hotplug kernel API
<f00b4r0>
I think it's the only code path in OpenWRT that actually does
rua has joined #openwrt-devel
<nbd>
then again, that would waste some RAM as well
<neggles>
the "this is a bug" argument seems pretty solid
<f00b4r0>
nbd: it would and provides no benefits over direct load to sysfs
<neggles>
given that the whole problem is "driver asks for the same file for different cards"
<f00b4r0>
neggles: I agree
<nbd>
f00b4r0: i guess the only benefit would be being a bit more robust
<neggles>
this wouldn't be a problem on (for example) a board with an ath9k and an ath10k, or an ath10k and an ath11k, or even two different ath10k chips
<neggles>
but when they're both the same chip
<jow>
nbd: while you're here
<f00b4r0>
nbd: why? loading to sysfs is the documented kernel API for firmwares.
<nbd>
if i recall correctly (from years ago), the kernel sysfs upload api was somewhat picky about how things would be written
<f00b4r0>
+loads.
<f00b4r0>
nbd: it's completely streamlined nowadays and extremely easy to use
<nbd>
i think there were some write size specific quirks + bad interactions with busybox cat at some point
<nbd>
but if it's all fixed, then i'm fine with just using it
<f00b4r0>
nbd: that's different, the cat issue was _reading_ from special files (truncation at page size). That's understood and worked around.
<jow>
nbd: I'd like to extend netifd's ubus network.device status output to include flow offload capability (ethtool's named "hw-tc-offload" flag)
<jow>
nbd: and use it from fw4 to filter out flowtable devices which are not offload capable
<jow>
since we're already reporting advertised and used link speeds (also acquired from ethtool) I suppose it's fine
<jow>
of course I could also do it elsewhere but since we're processing that ubus status anyway I figured it makes sense to include the info right there
<jow>
might also come in handy later for other capabilities
<nbd>
fine with me
<jow>
just add a new toplevel key "offloading: true/false" or move into a "capabilities": { ... } object?
danitool has joined #openwrt-devel
<nbd>
i think capabilities makes sense
<jow>
ok
<nbd>
unless it's not static and can be disabled
<nbd>
via ethtool
<jow>
depending on the device it is fixed or changeable
cmonroe has joined #openwrt-devel
<jow>
for bridges it is fixed off, for otheres (eth0 on mine) it can be toggled
<nbd>
then we should leave it in the top-level object
<jow>
okay
joao has joined #openwrt-devel
joao has quit []
robimarko has quit [Quit: Page closed]
robimarko_ has joined #openwrt-devel
cmonroe_ has quit [Ping timeout: 480 seconds]
cmonroe has quit [Ping timeout: 480 seconds]
cmonroe has joined #openwrt-devel
norris_ has joined #openwrt-devel
norris has quit [Ping timeout: 480 seconds]
norris_ is now known as norris
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<aparcar>
stintel: pardon I'm confused, what is the course with octeontx? bump to 5.10 and then disable it?
<robimarko_>
I think that stintel was trying to avoid that
<stintel>
aparcar: octeon != octeontx
<robimarko_>
Ahh yeah
<stintel>
I don't have any octeontx boards so I have no opinion about that
<stintel>
for octeon non tx I would like a few more days for testing some things
<Habbie>
stintel, still want me to test anything?
<ynezz>
stintel: so you've already found that issue?
<Grommish>
but it did grow and eventually kill the box
<rsalvaterra>
Grommish: I had actually never done a build without printk support… I did one now, and the difference in the size of the compressed kernel image is around 100 kB. Rather significant, I'd say…!
<neggles>
btw, how are you exporting that data? luci-app-statistics' RRD graphs leave something to be desire
<stintel>
this is with both running 5.10.96, one with 49d28ebdf1e30d806410eefc7de0a7a1ca5d747c reverted, one not
<stintel>
prometheus-node-exporter-lua
<neggles>
cool :)
<Grommish>
rsalvaterra: >_<
<neggles>
dropping printk seems like a bad idea :P
<jow>
there's a lot of useless info reported by printk
<jow>
and for a production build; why not
<jow>
you can't do anything meaningful with the output anyway
<rsalvaterra>
jow: +1
<robimarko_>
How much space does it save?
<neggles>
why not just raise the minimum level to NOTICE or ERROR rather than INFO?
<neggles>
that alone will probably get you 80% of the savings
<jow>
yeah, probavbly a good idea
<Grommish>
In three days, rsalvaterra will have patched in config checks to leave htem out hehe
<neggles>
actually don't we default to DEBUG
<rsalvaterra>
The thing is, if you're desperate for some space and you need to shed weight, printk is a good candidate.
<neggles>
dropping all the pr_debug() calls cuts the overwhelming majority of it out
<jow>
problem with leaving /some/ printk stuff in is that you'll also need to keep the entire support machinery
<jow>
format strings, oom formatting etc.
<rsalvaterra>
neggles: Dropping printk gets rid of the whole (quite complex) infrastructure it requires.
<rsalvaterra>
If you still need to printk some strings, the infrastructure will still be required.
<jow>
iirc DD-Wrt did disabled prink builds for ages for their micro builds
<neggles>
AFAIK the majority of the space savings comes from losing all the actual messages out of .text, but I've not compared "printk with NOTICE" and "no printk", only printk with DEBUG and printk with INFO / NOTICE
<rsalvaterra>
jow: We should definitely start considering it for SMALL_FLASH.
<neggles>
but yeah if your options are "no printk" or "no kernel" then
<neggles>
I found an MT7621 inside another thing today, casa systems pebble (one of the femtocells sprint deployed) - with an MT7615 attached in DBDC mode, even
<rsalvaterra>
jow: But the total savings of doing monolithic kernel builds are even greater. If possible, I believe this should be the first thing to tackle…
<neggles>
then i murdered it with a logic analyzer somehow. oops.
<neggles>
that chip shows up in the darndest places
<aparcar>
rsalvaterra: monolithic kernels aka no kmods?
<rsalvaterra>
The only issue I see is on systems with fixed size kernel partitions. A monolithic kernel will be bigger.
<neggles>
in some cases you could make up for that by moving initrd out of the kernel, but I imagine that's already been done on targets where this matters
<stintel>
goes from <100M to >400M in ~48h
<rsalvaterra>
neggles: We don't use initrd in most targets, I think.
<stintel>
so the same timespan as the previous image
<rsalvaterra>
aparcar: For the same kconfig, a monolithic kernel much smaller than the sum of its base + modules. Because interprocedural optimisations. :)
<rsalvaterra>
*is much
<aparcar>
but... how do we chose what's needed
<rsalvaterra>
aparcar: Right… that's an issue.
* rsalvaterra
sometimes forgets not everyone does their own builds… >_<
<rsalvaterra>
*sigh*
<aparcar>
cmon rsalvaterra ;)
<neggles>
rsalvaterra: perhaps, default image, and include ASU?
<aparcar>
ASU can't build kernels
<neggles>
touche
<Grommish>
Eh, for the targets who might need it, they should build their own, or don't complain :D plus, with space that limited, it isn't like they have a great deal of choice, do they?
<aparcar>
do we have a switch in the build system to make things static?
rua has quit [Quit: Leaving.]
<rsalvaterra>
aparcar: Sorry about the brainfart, I'm just too deep inside the territory. :)
rua has joined #openwrt-devel
<rsalvaterra>
To do this, we'd need the image builder to build the kernel just-in-time, which would be impractical.
<aparcar>
aka the sdk
<rsalvaterra>
Yeah…
<rsalvaterra>
So, I'll just put down the crack pipe now.
rua has quit [Remote host closed the connection]
<stintel>
pass it to me!
<Grommish>
rsalvaterra: Tsk, don't do that.. just refocus.. Go get an Octeon device
<stintel>
sharing is caring ... ;p
rua has joined #openwrt-devel
<aparcar>
rsalvaterra: maybe openwrt should have a sharing is caring device excahnge thing
<aparcar>
so vendors and companies can give stuff to people, hoping support improves
<stintel>
I already shared my retired ERLs ;)
* Habbie
o/
<stintel>
and hurricos shared a bunch of SNIC10e with me, I in turn shared with svanheule and a friend of his
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<rsalvaterra>
aparcar: That's not a bad idea… I thought we already accepted hardware donations, though.
<Pepes>
rsalvaterra: Me too, because what I know a few devices from Turris were sent to SFC to support the development
<rsalvaterra>
Grommish: I'm poor, I can't be spending money on hardware all the time… :P
minimal has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
eduardo010174 has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Tapper has joined #openwrt-devel
danitool has joined #openwrt-devel
mattytap has quit [Quit: Leaving]
eduardo010174 has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<aparcar>
tl;dr rename firewall package to firewall3 to avoid confusion now that there is firewall4
<stintel>
I don't have a strong opinion
rua has left #openwrt-devel [#openwrt-devel]
<stintel>
can anyone confirm major performance regression in mt76 since today's bump?
<rsalvaterra>
stintel: Haven't noticed. Will iperf3 tomorrow, maybe.
<rsalvaterra>
What are you seeing?
<stintel>
I noticed it earlier when I tried git master, didn't find the time to bisect it
<stintel>
drop from 600+Mbps to 200-
<stintel>
when I say major I mean major :P
<rsalvaterra>
Hm. MT7915, right?
<stintel>
yes
<Slimey>
:o
<Slimey>
hello hello
Gaspare has joined #openwrt-devel
<Slimey>
bought a pcs-cap324 for $14 :P
<ynezz>
BTW is this rule still needed https://git.openwrt.org/?p=project/firewall4.git;a=blob;f=root/etc/config/firewall;h=f4a3322a7d056b5dd3763e93ba1da5de822571ad;hb=HEAD#l33 ?
<ynezz>
running nmap UDP scan revealed that open port and I was like wtf, I've always thought, that everything from wan is forbidden
<f00b4r0>
ynezz: last time I checked (in 19.07) it was
<ynezz>
actually testing that on 19.07, have disabled that rule and everything is fine
<rsalvaterra>
stintel: I only have MT7615… :/
<ynezz>
f00b4r0: it probably doesn't work in some rare corner cases?
<f00b4r0>
ynezz: I'm not exactly sure what was the issue tbh. DHCP has always been black magic to me :)
<Slimey>
f00b4r0 i am a dhcp expert ;)
<f00b4r0>
ha! I'll be subscribing to your lessons then :-)
<stintel>
rsalvaterra: 2015 called, they want their radios back :D
<f00b4r0>
lol
<Slimey>
i've been the network guy at various colleges for like 20ish years now
<f00b4r0>
ynezz: the linked ticket hints that the rule was still needed 3 years ago
<Slimey>
we used to have this problem with dorm kids hooking soho routers to the lan network backwards
<stintel>
:P
<Slimey>
so i have a nice collection over the years :0
<stintel>
dhcp snooping ftw
<Slimey>
yes that has fixed that problem
<ynezz>
I'm not that much happy to have dnsmasq open to internet
<Slimey>
my latest is a archer ax1800 1.26 but i think its broadcom so maybe ill give it back at the end of the term
<f00b4r0>
ynezz: it's not
<stintel>
ynezz: dnsmasq shouldn't listen on 68
<f00b4r0>
ynezz: if you look at open ports (netstat -ltu) you'll see that 68 is not listening
<stintel>
68 is the client port
<f00b4r0>
^
<Slimey>
in wireshark you can use just the dhcp string for filtering
<ynezz>
stintel: ok, then it's udhcpc, but still software, which has bugs
<rsalvaterra>
Speaking of which, why is the firewall even open by default on port 68? DHCP works just fine with it closed. It's "special", I guess.
<ynezz>
PORT STATE SERVICE
<ynezz>
68/udp closed dhcpc
<stintel>
read the linked bug report
<ynezz>
that bug report is very special use case isn't it? why to have it by default in 2022?
<stintel>
people tend to complain hard when their uplink breaks
<f00b4r0>
that they do
<rsalvaterra>
stintel: Link to the bug report?
<stintel>
04|17:59:45 < ynezz> BTW is this rule still needed https://git.openwrt.org/?p=project/firewall4.git;a=blob;f=root/etc/config/firewall;h=f4a3322a7d056b5dd3763e93ba1da5de822571ad;hb=HEAD#l33 ?
<ynezz>
click on '[x] I've weird DHCP server topology and I don't care who is talking to me' in your LuCI
<f00b4r0>
that requires knowledge of your upstream topology, which most people don't have
<f00b4r0>
s/people/users/
<stintel>
indeed, usually the ISP maintains that
<rsalvaterra>
"DHCP request (renewal) is sent to 134.58.127.4 but the DHCP reply comes from a different IP address (134.58.127.1). That's why it's not related and you need to explicitly allow incoming UDP 68."
<stintel>
and often ISPs are clueless :P
<rsalvaterra>
What. The. Actual. F.
<rsalvaterra>
Is this even legal?
<f00b4r0>
btw, I see similar rule for DHCPv6
<stintel>
probably some weird HA setup
<ynezz>
dhpcv6 doesn't work here, so that's next
<rsalvaterra>
ynezz: If it works for you, kill that rule. :)
<rsalvaterra>
I don't have it.
<f00b4r0>
now if I had to question some defaults rules, Allow-IPSec-ESP and Allow-ISAKMP would be scrutinized much before udp port 68; in my very humble opinion
<stintel>
I would at least proactively try to contact users that had these problems in the past, before just removing these rules
<f00b4r0>
i could test again, but I can't do that right now. Will have to wait until next week
<stintel>
breaking someone's uplink would be a bad regression, even if the fix is questionable
<rsalvaterra>
stintel: No argument there.
<f00b4r0>
besides my ISP is currently in shambles. IPv6 has been taken down a few weeks ago so I'm not inclined to aggravate the situation just now :)
<stintel>
pfff I dunno what is worse, having had IPv6 and it being taken down, or your ISP not even caring about it at all
<stintel>
does starlink offer IPv6 ?
* rsalvaterra
cries in IPv4…
<stintel>
> Starlink Premium is not yet available in your area. Please check back for future availability in your area.
<stintel>
boooh
<f00b4r0>
starlink visual pollution in the night sky is very much available in my area though ;P
<stintel>
> Order now to reserve your Starlink. Starlink expects to expand service in your area in 2023. Availability is subject to regulatory approval
<stintel>
pffft
<stintel>
can't even enter company / vat if I want to make a deposit
<rsalvaterra>
How about a compromise…?
<rsalvaterra>
How feasible would it be to create a rule to consider traffic from the same subnet related for udp port 68?
valku has joined #openwrt-devel
<rsalvaterra>
That should solve the problem without exposing the port to the world, no?
dangole has joined #openwrt-devel
floof58 has quit [Ping timeout: 480 seconds]
<stintel>
rsalvaterra: how would that work if there's no IP assigned yet :)
floof58 has joined #openwrt-devel
goliath has joined #openwrt-devel
<ynezz>
rsalvaterra: in their case that response come from routable pulic IP, so if we would like to support receiving UDP packets from internet, we can't even limit that to private IP ranges
<ynezz>
s/come/came/
<ynezz>
but it could be probably possible to adjust that rule once udhcpc receives the response for the first time
<ynezz>
there is some script called IIRC
<ynezz>
(or could be)
<ynezz>
f00b4r0: yep, removed those also, thanks for the hint
<Slimey>
anyone heard from danielg4 lately?
<Slimey>
DonkeyHotei
<stintel>
got left behind on freenode?
philipp64 has quit [Quit: philipp64]
<stintel>
so apparently my phone doesn't even connect to the 5GHz network of my EAP615-Wall anymore since the mt76 bump
<stintel>
it *is* there, and my laptop does connect to it
Tapper has quit [Ping timeout: 480 seconds]
<minimal>
ynezz: is it possible to write a rule that corollates the "server-id" field of the DHCP response with a previous request?
<stintel>
o_O I just spotted this on one of my EAP615-Wall: [ 428.361518] sched: RT throttling activated
<stintel>
it's the first time ever this appears in my entire log archive...
<stintel>
whichs spans like 8 years
<stintel>
ok so the difference between the AP that has been upgraded with new mt76 and the old is ... encryption psk2 vs psk3-mixed
<stintel>
the phone no longer appears to connect to the one with psk2
<stintel>
wtf
<stintel>
switched it to psk3-mixed and phone still doesn't connect
<stintel>
maybe the samsung doesn't like channel 140
<hexa->
inb4: it's 11w
<hauke>
aparcar: from my point of view you can merge the octeontx kernel 5.10 change
<hauke>
aparcar: stintel: We said in the meeting that we want to make octeon source only becasue of the memory leak
<hauke>
if the memory leak is gone and it is working for you we should not make it source only, but just set the default kernel to 5.10
<hauke>
stintel: I send the patch with source only to push people to fix the real problem ;-)
<hauke>
I would prefer if the real problem is fixed and my patch gets rejected
philipp64 has joined #openwrt-devel
<stintel>
hauke: I'll try to conclude my "investigation" this weekend
<stintel>
and in fact, now that I have a way to auto oct-remote-boot the SNIC10e with persistent config ... if the leak is fixed, they could actually replace my M300 "cluster" :P
<hauke>
stintel: thanks
<stintel>
oh dear, what am I getting myself into again
<stintel>
dnsmasq seems to register the hostname of the host is runs on as A records for all local IP addresses ... is there a way to disable this behavior?
rua has joined #openwrt-devel
danitool has joined #openwrt-devel
<stintel>
yeah that's probably a vague question
<stintel>
I also have no clue what search terms to use
<Habbie>
all local IP addresses, or all DHCP interfaces?
<stintel>
this causes issues because I often have overlap with a local test subnet when working on some device
<stintel>
and the 192.168.x.0/23 is a hard requirement because that's what client's VPN excludes, anything else will not be accessible from my corp laptop when its connected to VPN
<stintel>
so my work test devices are in some /26's in that /23
<Habbie>
hmm
<Habbie>
'openwrt.lan' only returns the A address of the interface I ask it of, here
<Habbie>
stintel, what does /etc/hosts on the dnsmasq box say?
<stintel>
you might be right that it only adds A records for IPs of interfaces where dnsmasq does dhcp
<stintel>
127.0.0.1 localhost and 3 manually added records not pointing to the dnsmasq box
<stintel>
add_local_hostname
<stintel>
add_local_fqdn
<stintel>
but default for add_local_fqdn says 1: Hostname on Primary Address.
<stintel>
right
<stintel>
it shows me all these IPs because the query comes from a subnet where DHCP is not enabled
<Habbie>
yes!
<stintel>
I should try and get my 2nd OC200 back up and running so that my kea and dnsdist setup is redundant again, and then completely nuke dnsmasq from my network
<Habbie>
# dig a openwrt.lan @89.188.0.50 +short
<Habbie>
192.168.50.1
<Habbie>
192.168.141.1
<Habbie>
192.168.142.1
<Habbie>
confirmed here
<stintel>
but for dynamic dns with kea I'm going to require an auth ns too
<stintel>
not sure if the OC200 memory will allow for all of that :/
<Habbie>
make dnsdist inspect the kea database so you don't need an auth ns