<Mangix>
cmake's brokenness never ceases to amaze me.
csrf1 has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
robimarko has joined #openwrt-devel
SlimeyX has joined #openwrt-devel
csrf1 has joined #openwrt-devel
<oliv3r[m]>
Why is openwrt using kernel patches, rather then just have an openwrt 'sanctioned' tree?
<robimarko>
That one tree with patches for all of the targets would be a mess
<robimarko>
Though, I usually really preffer trees and not patches, way easier to work with
<robimarko>
But I dont think it would work here
<oliv3r[m]>
because of the different architecture teams/maintainers? I mean in the end, it's all just patches ontop of the linux tree, they should be able to co-exist
<robimarko>
No, but just because of the amount and their scope
<robimarko>
There are some patches that are hacks, workarounds etc and which depend on applying on a single target
<robimarko>
As they would break other, etc
<jow>
oliv3r[m]: also to enforce strict separation and "hygiene"
<oliv3r[m]>
true, but some ifdef magic could help there; I know the current state is broken to do so; but it could be possible to fix that :) starting point could be target/linux/generic :p
<oliv3r[m]>
well hygiene is far to be found atm :p
<jow>
having a forked tree lowers the barrier to sneak in unclean changes
<oliv3r[m]>
it depends on how rigourous your review process is on your commits that go into your tree
<jow>
also reduces the incentive to upstream changes
<oliv3r[m]>
it's all just a bit hacky nad messy :)
<oliv3r[m]>
that last part is true; but I've seen patches that are 10? years old, not even relevant anymore; yet still sit there :(
<jow>
also makes it painful to quickly glance at deltas compared to upstream
<oliv3r[m]>
git log? but yeah I see that as an advantage, you have a quick glance of the stuff that still needs to be fixed up/cleaned up; it makes it more tangiable
<oliv3r[m]>
as in the end, at some point, there should be 'no' patches for stable stuff
<jow>
and it violate the design principle of openwrt as source distribution
<jow>
it's vanilla sources + patches
<jow>
not forked sources
<oliv3r[m]>
that's not really true though; a) you have tree's for your packages; and b) it's still just vanilla sources + patches; just how you store and organize them
<oliv3r[m]>
and the design principle SHOULD be, vanilla sources + no patches :p
<jow>
it is perfectly find to have a private "vendor" kernel tree where you regularily export patch series from
<jow>
afaik multiple developers do that
SlimeyX has quit [Remote host closed the connection]
<jow>
but we do not want to host/maintain/promote a forked kernel tree
<oliv3r[m]>
I'm just looking at 'ease to work with, overhead, uneeded complexity' pov; working with kernels on openwrt is harder then it should be, especially keeping things in sync, but that's from a developer pov of course, which ideally, shouldn't be that much happening, as ideally, all should be upstream
<jow>
s/find/fine/
<jow>
to some extend it *should* be painful
<jow>
openwrt is not the place to introduce platform support
<jow>
in an ideal world I mean
<jow>
kernel.org is
<jow>
and patches should either be an interim to bridge time until upstream sources ahve cought up or to add local hacks that are not upstreamable (e.g. because they would conflict with other targets)
<oliv3r[m]>
Yep I agree completly with that; though the sad truth is, right now it's a 'staging/experimental' area where new things get 'discovered' while giving access to users :(
<oliv3r[m]>
no argument there :p
<jow>
yeah and making it more convenient would turn the staging area aspect into a canonical upstream
<robimarko>
I agree
<robimarko>
Its hard enough to encourage people that OpenWrt is not a place to drop hacks and forget about them
<oliv3r[m]>
but, there's a big backlog of cleaning things up though; so it's kinda working against you atm
<oliv3r[m]>
Sadly, that's exactly what is happening though :(
<jow>
I don't disagree
<jow>
but making it easy to work with own kernel trees would further encourage the "drop local hacks" aspect
<oliv3r[m]>
yep
<jow>
drop as in introduce, not remove
<robimarko>
Plus there is an issue with some generic hacks that have been carried over for years and years
<robimarko>
They lack description etc, pretty much its hard to see why they even exist
<jow>
robimarko: remove tham and see what breaks :)
<nbd>
i think a reasonable compromise would be if we could reach the point where have 2-way conversion between openwrt kernel patches and git commits on top of an upstream kernel tree. we shouldn't publish such a git tree, and the openwrt patch stack should remain the master.
<nbd>
but things would be easier to maintain if you could use git instead of quilt
<robimarko>
jow: thing is that nothing would break for most targets
<oliv3r[m]>
I thought of doing a script; that you can run to go to a tree
<jow>
what I learned is that a typical run-off-the-mill developer is already overtaxed with the concept of a git rebase
<jow>
he'll complain that quilt is hard to deal with and that git would be easier
<robimarko>
that is true, git is way easier for rebase
<jow>
in reality he means git would make it easier to both random changes into the tree
<jow>
not necessarily tro make clean, isolated and upstreamable changes
<robimarko>
My gripe with quilt is that it sometimes will apply already existing patch just fine
<oliv3r[m]>
i find quilt also to be stupidly painful :p annoying and 'whats the purpose' even
<robimarko>
Even though it was upstreamed and break stuff
<jow>
joe r. random working at bcm or qca will master neither
<jow>
they'll just shit onto a random linux clone of the day, beat it until it boots and leave it as-is
<oliv3r[m]>
anyway, dropping the need for quilt would already help some :p
<oliv3r[m]>
so true jow, so true :(
<robimarko>
Marvell has a way around that, they have their tree against a certain version and then just export 1500+ patches using git format-patch
<robimarko>
Problem solved
<jow>
exatly, that would be a sane workflow
<robimarko>
But why?
<robimarko>
That doesnt make things any better
<oliv3r[m]>
yeah; I've been playing enough with GPL drops, that it's so painful even to find out what their 'starting point' was
<oliv3r[m]>
'not my problem' attitude, if it works, ship it, attitude
<oliv3r[m]>
anyway, preaching choir and allt hat :)
<jow>
because dealing with a gitam'able patch stack is easier than cloning an entire kernel tree and figure out what changes there ight be on top
<robimarko>
That is where we dont agree
<jow>
fair enough
<robimarko>
For me its way easier to just lookup the history and clearly see what is the upstream commit
<robimarko>
Than trying to do forensics with patches
<jow>
you cna reconstruct the tree by using a vailla kernel.org clone and apply the patch stack
<jow>
most people just won't need that though
<oliv3r[m]>
but you can generate that can't you? just git am; git log
<jow>
side effect is that it forces the vendor to properly rebase his modifications on top of the start commit
<robimarko>
We both know that nothing proper is gonna happen
<jow>
no non-linear history, changes scattered around, injected in between releases as the tree was synced with upstream while changes were developed
<robimarko>
But I get why we are using patches in OpenWrt
<robimarko>
But we really should get around to at least adding titles and descriptions so that you can use git am to apply everything
<jow>
yes, absolutely
<Mangix>
probably not relevant, but quilt is enforced in the packages feed
<jow>
we could also think about extending the build system to offer a "git mode" for managing patches
<robimarko>
oliv3r[m] is the guy that has the PR that adds missing description etc to patches
<oliv3r[m]>
well I did that, cause I couldn't do `git am` :p
<jow>
oliv3r[m]: becasue they open random kernel files in visual studio, press ctrl-s
<jow>
then, because not knowing how to work with git, simply commit all changes files though the ide (because it compiles, so it must be right)
<oliv3r[m]>
but then everything would change, and that is not the case, also, some changes are just hella sloppy
<jow>
then rpduce some "diff file" (what is that even?) for those unix weirdos
<robimarko>
Consider yourself lucky that they did not change line endings as well
<oliv3r[m]>
and yes, ctrl-s; git add -a; git commit
<oliv3r[m]>
on SOME lines they did :p
<robimarko>
Thats nice of them
<robimarko>
I have a customer that send me config files, etc they want packaged in the FW
<robimarko>
And they always, like always send me stuff with Windows/CR line endings
<robimarko>
These things are "runtime" tested, tested my ass
<robimarko>
So, I will eventually just make a script that converts all of them to UNIX by default
<Mangix>
robimarko: strange. I would expect with W10 Microsoft tools no longer do that
<Mangix>
the tool is dos2unix
<jow>
Mangix: I would not expect those guys to use w10 yet
<jow>
:P
<Mangix>
that would explain it
<robimarko>
Mangix: It wont if you edit existing files, but as soon as you create a new one
<robimarko>
Then it will default to Windows endings, and I have tried explaining that they need to switch the config, but nope
<oliv3r[m]>
robimarko: dos2unix not good enough?
<robimarko>
And lets pray then just arent using regular Notepad(They most certainly are)
<oliv3r[m]>
heck even .gitattributes cand o that for you :p
<jow>
robimarko: what out for BOMs too
<jow>
*watch
<robimarko>
oliv3r[m]: It works
* Mangix
looks for openwrt's gitattributes
<robimarko>
jow: Oh yeah
<dwfreed>
good ol utf-16
<jow>
yeah, you can never have enough null bytes
<Mangix>
* -text <-- I have no idea what this is
<dwfreed>
though I've heard stories of windows doing utf-8 BOMs too
<dwfreed>
(which are technically invalid, but most utf-8 decoders allow them)
csrf1 has quit [Ping timeout: 480 seconds]
<robimarko>
As you know, standards are here so we can not enforce them
<robimarko>
BTW, whoever the idiot at Gitlab that decided to not show the history button on the default branch anymore is, has he not bothered to ask if anybody wants that?
<robimarko>
Now its just 3 clicks more for the same thing
<Mangix>
huh
<Mangix>
so should core.autocrlf be set to true for openwrt?
<jow>
no
<jow>
automatic conversions are always problematic
<jow>
maybe you eventually *want* a file with \r
<Mangix>
I know in packages that's the case with softethervpn. That's about it.
<jow>
I can also think of a bunch of testcase files that would be affected
<jow>
e.g. liblucihttp. Would not be a problem in this specific case because it is in its own repo, but still
<Mangix>
oh funny, there's also a core.safecrlf option
<PaulFertser>
Official git for windows installer used to default to enable some automatic conversion :/
Borromini has joined #openwrt-devel
bluew_ has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
<nbd>
zx2c4: ping
<zx2c4>
nbd: hey!! I saw your awesome mesher thing the other week on my phone and was meaning to look into it. Im still on my phone now
<zx2c4>
Lemme grab a laptop
<zx2c4>
What's up?
<nbd>
glad you like it. i have a dev question related to that actually
<nbd>
so i want to improve doing STUN on the wireguard port
<nbd>
right now i'm basically switching wg to a different port while doing STUN
<nbd>
but ideally i would like to do it while wg is running
<nbd>
and figuring out the outgoing device and attaching a bpf program to it has too much overhead for my taste
<nbd>
so i was wondering if it would be acceptable to add a way for wireguard to relay any rx packets it considers 'dropped' (malformed, invalid, etc.) to user space somehow
<zx2c4>
for the purposes of STUN, this trick here works quite well
<f00b4r0>
jow: catching up a bit late on the git/quilt thing, I have to confess that I didn't bother bringing e.g. the variable erase mtd patch that we have in our tree to the same point where I have the patch submitted upstream because of the pain of dealing with quilt. Then again, where it's going to bite me back is seeing how upstream seems uninterested in merging said patch :P
<nbd>
last time i checked (may have been a long time ago), doing a raw socket, even with BPF came with significant overhead for received packets
<nbd>
and i wanted to avoid that if possible
<robimarko>
f00b4r0: So no reply?
<f00b4r0>
robimarko: none. I've lost interest at this point.
<f00b4r0>
as in, they don't care, why should I ;P
<zx2c4>
nbd: bpf supposedly eliminates overhead. but either way, this is something you setup briefly, do stun, tear down
<nbd>
so right now STUN is only needed when peer discovery happens on a separate port
<nbd>
e.g. via 'mainline DHT'
<f00b4r0>
robimarko: there was some exchange on irc (thanks to rmilecki) but that went nowhere. Seemed that whoever was commenting didn't understand mtd's susbsys own code. That was it for me :P
<robimarko>
f00b4r0: You just arent used to no reply for a long time
<rmilecki>
well, i wouldn't call it nowhere
<zx2c4>
nbd: and you want to run the DHT over the wg port or something?
<rmilecki>
we know what is needed
<nbd>
zx2c4: yes, that way I wouldn't need STUN anymore
<rmilecki>
we need to use existing info about erasing
<rmilecki>
(instead of adding another property in mtd struct)
<f00b4r0>
rmilecki: maybe you do, I don't.
<zx2c4>
nbd: seems like you could expand the bpf filter to match on specifically dht-type messages, right? and then userspace would only get those
<f00b4r0>
rmilecki: I'm sorry, that's not the case. You need the extra info to compute the least common denominator.
<f00b4r0>
for the purpose of mtdpart.
<nbd>
not sure how well i can match those with BPF. the existing code does a lot of strstr() for finding matching patterns
<rmilecki>
well, I don't agree
<f00b4r0>
ok then :)
<nbd>
and for that protocol, i would need the filter attached basically all the time
<nbd>
which would increase the processing overhead
<f00b4r0>
rmilecki: i guess I'm not smart enough to know how to do this differently. So that's that :)
<rmilecki>
f00b4r0: i'm not sure what for you to better to hear
<f00b4r0>
rmilecki: regardless, I don't consider an irc chat to be an actual patch answer/review
<rmilecki>
f00b4r0: that you are not smart enough or you don't want ot look for other ways of implementing that ;)
<rmilecki>
f00b4r0: i think you're smart enough for that
<zx2c4>
nbd: afaik, a sufficiently specific bpf program should reduce that overhead considerably. it's better than having unknown packets queue up in userspace under DoS
<f00b4r0>
rmilecki: i honestly did not understand what was "asked" (if anything was)
<zx2c4>
nbd: do dht packets not have a unified header?
<rmilecki>
f00b4r0: good point, i'll reply to that patch
<rmilecki>
maybe that will help
<nbd>
zx2c4: i guess i need to do more research on that. so far i simply reused the implementation from transmission
<f00b4r0>
rmilecki: it bears repeating the patch does not deal with erases. It only deals with 1) making sure mtdpart does not mark a part RO when it's doesn't have to be and 2) that the actual code that deals with erases uses all EB sizes.
<nbd>
and it's quite lax in what kinds of packets it accepts
<rmilecki>
f00b4r0: so there is a problem that very common for OpenWrt devs ;)
<rmilecki>
f00b4r0: we do things that work
<rmilecki>
we don't care much if they fit existing designs well ;)
<rmilecki>
f00b4r0: yes, your patch does what you expect from it
<f00b4r0>
well I did. And it seemed like the least invasive way to implement this
<rmilecki>
f00b4r0: no, it doesn't fit well mtd subsystem
<f00b4r0>
well that's the part I don't understand.
<rmilecki>
f00b4r0: we don't want "the least invasive way"
<rmilecki>
refactoring may be needed
<rmilecki>
it is I bet
<zx2c4>
32 struct pex_hdr {
<zx2c4>
33 uint8_t version;
<zx2c4>
34 uint8_t opcode;
<zx2c4>
35 uint16_t len;
<zx2c4>
37 };
<zx2c4>
36 uint8_t id[PEX_ID_LEN];
<zx2c4>
nbd: stick a magic u32 as the first field
<nbd>
that's not the DHT protocol
<rmilecki>
f00b4r0: i'll comment on that patch directly during this weekend
<zx2c4>
oh
<f00b4r0>
rmilecki: least invasive also means easier to review, easier to "prove" and less likely to break anything.
<zx2c4>
whoops
<zx2c4>
udht.[ch]?
<nbd>
yes
<rmilecki>
f00b4r0: which doesn't make it good :P
<nbd>
and dht.[ch] (which is copied from transmission)
<f00b4r0>
rmilecki: ok. I'll be off this weekend so take your time :)
<rmilecki>
f00b4r0: refactoring is always needed
<rmilecki>
yes, it may break things
<rmilecki>
still we take risk
<nbd>
or rather, the separate git repo that transmission pulls it from
<rmilecki>
to get a nice implementation in the end picture
<nbd>
(written by Juliusz Chroboczek)
<f00b4r0>
rmilecki: the problem is I have a very limited understanding of the mtd subsys. I managed just enough to know what I was doing. Anything beyond that is well above my head.
<rmilecki>
f00b4r0: i also admit this IS complex
<rmilecki>
f00b4r0: UBI + ubifs makes it really ugly
<rmilecki>
(they don't work well with small erase sizes)
<f00b4r0>
i haven't touched that and have no interest in doing so ;P
<rmilecki>
f00b4r0: true, you need to investigate more in that subsystem to get it right
<rmilecki>
i admit it takes time
<rmilecki>
it's not rocket science
<rmilecki>
but it takes time to look into mtd, spi-nor, UBI
<f00b4r0>
it may not be to you :)
<f00b4r0>
and this work doesn't pay my bills; so I can't devote endless time either :)
<rmilecki>
f00b4r0: ah, i know that way too well
<rmilecki>
f00b4r0: too many things on my list that I can't get anyone to pay for it
<zx2c4>
nbd: dht.c is pretty gnarly
<zx2c4>
glad you didnt write it :-P
<nbd>
:)
<f00b4r0>
rmilecki: on a related topic, I have a client who might be interested in participating in funding a CoovaChilli replacement. I tried reaching out to blogic about that but didn't hear back so I'm making this info public here :)
<nbd>
i mainly used it, because it's small, easy to integrate and i assume that it has been hammered at a lot due to it being used in transmission and other bittorrent clients
<rmilecki>
f00b4r0: oh my, it was 5+ years since I've heard about CoovaChilli
<nbd>
i also kept it separate from the main unetd binary for a reason :)
<f00b4r0>
rmilecki: consider yourself lucky. It's a cesspool. I'm not touching that code with a 10ft pole :)
<robimarko>
That thing just refuses to die, despite being broken
<nbd>
zx2c4: yes. with a simple protocol where nodes basically send their public key (along with some form of proof that they also have the private key) from the wg port to a public service
<zx2c4>
oh, shit, i forgot to shift
<nbd>
so that other nodes can query it
<nbd>
that filter is specific to little endian hosts though, right?
<zx2c4>
nbd: yea i dunno about endian. you might need a `cpu_to_be32()` or whatever in there to flip things around
<zx2c4>
i just figured it was easier to read a full 4byte word and mask than it was to read 3 bytes branching each time
<nbd>
actually, isn't 0x64313a00 the big endian representation?
<neggles>
[Pokey]: the extra bit in your name comes from flipping on a kconfig option
<nbd>
regarding discovery: yes, it would be similar to the example. the client would also have to transmit its private ip address. that way if the server detects that the queried node and the querier have the same source ip, it'll transmit the private ip/port instead of the public one
<[Pokey]>
neggles: I enjoyed that video by the way! Interesting, That would be part of the .config wouldn't it? Do you know which option it is specifically by chance?
<nbd>
even with DHT + STUN, i was able to get a direct connection between two unetd nodes firewalled behind NAT in different networks
<nbd>
but DHT is slow, and discovery can take a minute or even more until the connection works
<neggles>
[Pokey]: little bit terrifying, isn't it? yes, i do, just pulling up a menuconfig
<nbd>
since it's not enough for one node to find the other one
<nbd>
they have to both ping each other before the firewall will open up the port
<nbd>
a centralized node would make discovery much faster
<nbd>
and then people can choose which option they prefer
<[Pokey]>
neggles: definitely scary but not as bad as I anticipated to be fair. The only thing I super wasn't happy with is the ability for the SIM to request the device notifies it if things you're doing like opening a browser
<neggles>
CONFIG_VERSION_FILENAMES and CONFIG_VERSION_CODE_FILENAMES, both under image configuration -> version configuration options. CONFIG_VERSION_FILENAMES will put whatever you set CONFIG_VERSION_NUMBER to into the filename, and CONFIG_VERSION_CODE_FILENAMES puts whatever CONFIG_VERSION_CODE is set to into filenames
<neggles>
however, if CONFIG_VERSION_CODE isn't set, then CONFIG_VERSION_CODE_FILENAMES puts the last N characters of the last git commit hash and uhhh
<neggles>
so in your case, snapshot-r20784 is probably what CONFIG_VERSION_NUMBER is set to by `config.buildinfo`
<[Pokey]>
Interesting! I do wonder why I suddenly started getting those set then because I was using the same config.buildinfo the whole time. The only thing I did was redownload it. So I can only guess it got changed somehow the first time
<neggles>
and `+1-ec8fb542ec` is '+1 extra commit, last commit hash ends with ec8fb542ec' I *think*
<[Pokey]>
The revision number comes from getver.sh, that's something I have worked out
<[Pokey]>
I'm just using my user page as a workspace for now. There's some things I need to double check there
<neggles>
that's right
<neggles>
`snapshot` is what the buildbots set CONFIG_VERSION_NUMBER to for, well, snapshot builds
<neggles>
so that'll be in config.buildinfo
<[Pokey]>
Now I know what those config options are I can describe them too
<zx2c4>
nbd: https://א.cc/Z7oPSUQq/c this works
<zx2c4>
looks like cBPF does things in big endian
<[Pokey]>
Aha! Thanks for that one. That was the next thing I needed to work out tonight
<nbd>
zx2c4: ah, that makes things a lot easier. thanks
<zx2c4>
you might also want to add checking on the src port?
<zx2c4>
or maybe dst port is better? dst port is better
<zx2c4>
or perhaps you want to keep it flexible so you dont have to sync ports
<neggles>
[Pokey]: looks like snapshot builds don't have a version set, but I vaguely recall something about "if unset, default to snapshot" being in the makefiles - I would also *highly* recommend *not* importing config.buildinfo unless your goal is to produce something that's kernel-module-compatible with a stable release, it defaults to building
<neggles>
*everything* and takes *forever*
<[Pokey]>
That makes sense
<[Pokey]>
Yes indeed, that is the goal I had
<neggles>
even then
<[Pokey]>
I wanted it to be compatible with the official opkg
<[Pokey]>
And match an official release
<neggles>
if you just want userland compatibility that's easy
<[Pokey]>
Naw, this was and still is definitely a full staging test as I added support for a new device (credit goes to \x really)
<neggles>
but if you want to be able to download the 'official' release's kmod packages and have those work, if you've made any changes to the kernel sources, you can't.
<neggles>
if your changes are restricted to things outside of the kernel patches, you're fine
<[Pokey]>
Indeed, I have learned about vermagic
<[Pokey]>
Clever stuff
<neggles>
i mean vermagic is just enforcing a fundamental restriction in the linux kernel
<[Pokey]>
Yea, saving your ass from kernel incompatibilities and panics and bugs
<neggles>
it's intended to largely be monolithically built, and in general (there are ways around it for some things, yes, but shh) if you change the sources, all your modules won't work :P
<neggles>
hence why dkms exists
<[Pokey]>
Puzzlingly though, the config.buildinfo I downloaded is now producing a build with a newer kernel to the one from the official opkg repo so I can't use it anyway
<[Pokey]>
I can only assume some commit changed the kernel version
<neggles>
where'd you get it from
<nbd>
zx2c4: unetd in general is heavily inspired by tailscale, but i wanted something that does not depend on a centralized service in any way, and i also didn't want to run wireguard in userspace :)
<neggles>
if you're building against master, which you should be for a new device
<[Pokey]>
Uhh I'm on mobile so I can't get you the link but from downloads.openwrt.org under ramips mt7621 I think it was
<zx2c4>
decentralized, non-corporate, actually does things the linux way
<[Pokey]>
Yes I'm using master from git
<neggles>
yeah okay
<neggles>
you have absolutely no chance of building an image that's compatible with the main opkg repo
<neggles>
for more than about 20 hours
<[Pokey]>
I did it for at least 24! Did I set a record?
<nbd>
zx2c4: if you ever have time to look at it more closely, i'd love to have a second opinion about the security of the protocol
<zx2c4>
ill take a look
<nbd>
i tried to be careful, but there might be a few things that i missed
<neggles>
the whole point of 'snapshot' is that it's rebuilt from master roughly once a day :P
<robimarko>
Yeah, roughly
<robimarko>
But not really as buildbots are quite busy
<neggles>
if you download a snapshot image, you better flash it and install any kmods you want immediately
<[Pokey]>
To combat this I would like to be able to build all packages and host my own opkg repo containing supported packages for my exact build but I find no documentation on this
<neggles>
heh.
<neggles>
i've done some stuff here and there on that. ansuel has some useful repos
<robimarko>
neggles: Actually, kmods for a bunch of snapshot releases are preserved
<neggles>
robimarko: oh? i've never been able to download a kmod more than a day or so after installing an image
<[Pokey]>
neggles: robimarko: Yes I see you're right robimarko, my issue is because I'm using a newer kernel suddenly for which they have not officially been built
<neggles>
check again tomorrow
<neggles>
:P
<neggles>
and it looks like that's the last commit/hash before each version bump?
<[Pokey]>
neggles: I'd rather cause myself pain and suffering running my own opkg repo
<neggles>
well the good news there is that part's easy as heck
<robimarko>
[Pokey] You are gonna be putting more effort into trying to hack everything to try and use kmods from buildbots instead of doing it yourself
<neggles>
things you need to host an opkg repo: the build system and nginx/apache/lighttpd2/caddy/whatever
dangole_ is now known as dangole
<robimarko>
neggles: Even pythons HTTP server would work
<neggles>
hence "whatever" :P
<neggles>
do i still have mine set up? (haven't done much openwrt for a while, been working on QuartzPro64 and some other things)...
<[Pokey]>
robimarko: I'm not trying to do that luckily. What I mean by running my own opkg repo is actually building every single package from source and exposing it as a webserver
<neggles>
how powerful's your build machine
<robimarko>
[Pokey] well that is the thing, you just need kmods
<robimarko>
Userspace will work
<neggles>
but yep ^ that
<[Pokey]>
I suppose so actually yea
<[Pokey]>
neggles: Ryen 3900X
<[Pokey]>
s/Ryen/Ryzen
<neggles>
an ALL_KMODS build shouldn't be too bad
<neggles>
but a "BUILD ALL THE THINGS!" config is not going to be fun
<[Pokey]>
The problem is how to do that isn't documented and I'm a supernoob
<[Pokey]>
Can I just say by the way neggles thanks for reading back the IRC history and replying to my question too. that's a rarity haha
<neggles>
I scrolled up to where i logged off last night :P
<[Pokey]>
I got lucky then :P
<neggles>
what target is your device under / what device is it
<[Pokey]>
:P it's not a bank breaker and I'm a cheapskate
<neggles>
robimarko: I knew we were doomed when ubiquiti and tp-link both put them in wifi 6 APs
<karlp>
I've "regularly" python -m http.server my bin directory to do opkg updates from my laptop, "works good"
<robimarko>
They quit quickly
<neggles>
"surely wifi 6 will be too much and it will be time to move on"
<neggles>
[Pokey]: yeah so karlp has just given the game away
<neggles>
just serve your <buildsystem>/bin directory
<[Pokey]>
Huh okay
<neggles>
I got a little bit fancier than that, since I have multiple trees floating around for different things, so I uh
<[Pokey]>
Didn't think it would be that easy because when I looked at the opkg feed config it looked like the URLs it was requesting did not match the feed URLs. Looks like it appended kernel version and vermagic some places
<neggles>
it does! the downloads.openwrt.org webui *LIES TO YOU*
<neggles>
it says the filename is nice and short and clean but it is lying and it knows it
<karlp>
you can ... edit the opkg.conf on your target to put in extra thigns too :)
<neggles>
yeah :P
<karlp>
even via luci!
<neggles>
what i ended up doing was, i told nginx it was okay to follow symlinks and pointed it at a pair of folders full of symlinks
<neggles>
then i uh
<neggles>
installed a copy of the stuff that runs downloads.openwrt.org
<karlp>
there's a make package/index or something target to make sure you've run, that generates the packages.gz stuff,
<karlp>
it's normally done automatically ifyou're just doing "make" but if you're doing "special" steps like quilt rebuilding things by hand, you sometimes need to kick it a bit to reindex.
<neggles>
that's what opkg pulls down when you do an opkg update
<neggles>
and it's got all the info and URLs to the packages
<neggles>
well filenames, relative to where Packages is
<[Pokey]>
Right. So I literally do just need to point a websercer at the packages bin output
<neggles>
yeup
<[Pokey]>
Dam
<neggles>
and make sure you have the right host in feeds.conf
<[Pokey]>
I feel a fool!
<[Pokey]>
There's no page for this though, is there?
<neggles>
(the .conf in the target image, not in the buildsystem)
<neggles>
there kinda is
<neggles>
I don't remember where I got the webui stuff from but I am 90% sure it was one of Ansuel's repos
<[Pokey]>
I mean a developer's guide page
<neggles>
OpenWrt's developer documentation is... let's go with "better than a lot of projects i've dealt with, on account of it exists, and is mostly accurate"
<neggles>
m o s t l y
<[Pokey]>
There's a guide to compiling singular packages but I might make a page to describe doing a full package build, a kmod package build, why you'd want one or the other and how to set up a webserver for it, if there's no objections to such a page existing
<neggles>
literally nobody in this channel will ever, EVER object to someone making documentation
<[Pokey]>
Hehe
<neggles>
as long as it's not "how to do these things that are HORRIBLE IDEAS and you should NEVER DO"
<neggles>
(however a page explaining why they're horrible ideas would be welcome)
<[Pokey]>
Haha yea
<[Pokey]>
Sensible
<neggles>
you end up spending a lot of time reading and re-reading makefiles and commit messages, and asking people questions in here, once you start digging into bits and pieces of how the build system works
floof58 has quit [Ping timeout: 480 seconds]
<neggles>
target makefile variables controlling how images are put together are a maze of twisty make function(?) definitions, all alike
<neggles>
and if you ever work out how to set up your own buildbot instance that works, let me know :P
floof58 has joined #openwrt-devel
<[Pokey]>
neggles: when I said supernoob before, I meant it. I'm a C# developer so although I am technically inclined, I am not familiar or comfortable with make or shellscripts at all and I'm learning as I go
<neggles>
Makefiles are cursed
<neggles>
and the OpenWrt build system is both a work of art and utterly terrifying
<neggles>
and you should see some of the absolute magic jow (and others) can pull off with busybox sh
<neggles>
if you're invoking awk or sed in a shellscript, I'd say probably 9 times out of 10 you didn't need to
<neggles>
but anyway. it's all pretty straightforward, there's just a lot of it.
<hauke>
ynezz: thanks for the link
<hauke>
lets see what wolfssl will answer
<[Pokey]>
neggles: I see your suggestion of assembling a buildbot and whilst the challenge is tempting I don't have a server powerful enough to host it on :P
<[Pokey]>
I would imagine the official server used to do those builds packs a mean punch
<neggles>
it's a fleet of containers hosted on... I don't even know what
<[Pokey]>
Insert name of large compute vendor here
<neggles>
wiki says something about some Hetzner servers, but I've no clue how up to date that is
<[Pokey]>
Don't ya just love hope FCC levels the playing field somewhat for most companies
<neggles>
it probably has secure boot locked way down and good luck ever getting sources out of apple
<[Pokey]>
Not always but ofteb
<[Pokey]>
Yea bleh
<neggles>
It is nice to be able to work out whether the random cheap router thing on eBay is Broadcom or something potentially supportable or not :)
<[Pokey]>
It's probably running some tight built Darwin derivative like everything of theirs
<neggles>
i can practically guarantee it is running an OpenWrt derivative.
<neggles>
the Expresses do.
<[Pokey]>
neggles: got your eye on one in particular?
<[Pokey]>
Woah okay fair enough
<neggles>
buddy I own too many goddamn routers/APs
<[Pokey]>
Didn't think apple would stoop so low
<neggles>
it was 2011
<neggles>
if they built a router today it would have an A13 in it
<[Pokey]>
True
<neggles>
and it would be insane
<[Pokey]>
10G or something stupid I guess
aiyion_ has joined #openwrt-devel
<[Pokey]>
"Hey we put an M1 in your router"
<neggles>
but I don't see apple getting back into network gear anytime soon.
<[Pokey]>
I do wonder why they left
<robimarko>
To put it mildly its quite price sensitive market with consumer stuff
<neggles>
^
<robimarko>
Aint nobody gonna dump 1k or a router for home
<[Pokey]>
True
<neggles>
once the major NAS product lines worked out how to do Time Machine
<neggles>
the reason they had to keep doing it went away
<robimarko>
And I dont see what could Apple offer that nobody else does anyway
<neggles>
yup
aiyion has quit [Ping timeout: 480 seconds]
<[Pokey]>
One thing I always liked about the apple gear is they did over the network and over the air SSID roaming pretty well. I'm not sure if OpenWRT matches it's capabilities? I need to look into it
<neggles>
pretty much everything that's not bottom tier consumer garbage does these days
<neggles>
the smarts are largely client side
<robimarko>
802.11r is the magic
<neggles>
until you get to that ^
<robimarko>
Current issue is broken clients
<neggles>
always is
<[Pokey]>
Hm. You suggest that they did it without .11r?
<neggles>
they did
<neggles>
11r didn't exist
<[Pokey]>
How did they pull that one off
<robimarko>
How did that work with non-Apple clients?
<[Pokey]>
robimarko: well in my experience
<neggles>
bullshit is how
<robimarko>
There is no way they could have done it with non Apple clients
<neggles>
an actual implementation of over-the-DS Active Roaming and forged BSSIDs
<karlp>
"what do you mean non-apple clients? what are those?" was the thinking...
<neggles>
active roaming existed before .11r
<neggles>
it just wasn't, actually properly defined
<robimarko>
karlp: Any client device that isnt Apple product
<robimarko>
neggles: than thats not fast roaming
<neggles>
it was 2011!
<karlp>
robimarko: yes...
<[Pokey]>
It's mediocre speed roaming!
<neggles>
but it also didn't work super great with non-apple things. Worked as well as anything else
<neggles>
just not zero packet loss
<robimarko>
neggles: Exactly, that is my point
<robimarko>
It couldnt have worked well with non-apple clients connected
<[Pokey]>
Wait .11r is 0 pkt loss? Huh
<neggles>
yes
<robimarko>
In theory
<neggles>
...when your client isn't misbehavingn
<neggles>
and your AP implements the whole thing
<neggles>
and it's set up right
<[Pokey]>
Well I guess I didn't expect it to be because I was used to losing packets when switching access point in the apple network
<[Pokey]>
But that's neat
<neggles>
and Saturn isn't in retrograde, and the price of ocean trout in Singapore is below $Y
<neggles>
to be fair with these cambiums swapping between radios both within and cross-AP has been seamless every time
<[Pokey]>
From what I read there's no real good way to coordinate OpenWRT access points for this though? They have to be configured with the same SSID and password and the mobility thingy and it then black magic works but if any of those don't match you're gonna end up with a broken AP
<neggles>
that's pretty much the whole deal really
<neggles>
like that's how all wifi roaming has always worked outside of ubiquiti's old meta-AP disaster
<[Pokey]>
I'd love to see a ubiquity style system available at some point where you can coordinate the whole fleet together
<[Pokey]>
Ha
<[Pokey]>
Beat me to the punch
<neggles>
ubiquiti APs run OpenWrt*
<neggles>
*QSDK
<robimarko>
Its some weird combo
<[Pokey]>
I've heard about this QSDK floating around... What is it?
<robimarko>
Qualcomm-s SDK
<robimarko>
OpenWrt based SDK
<neggles>
Qualcomm forks OpenWrt every now and then and slaps a whole assload of proprietary in there
<neggles>
and ships it to their customers to build off
<[Pokey]>
Ew
<[Pokey]>
That sounds grim
<neggles>
that's how/why OpenWrt runs the majority of the world's routers
<neggles>
it's public
<neggles>
mostly
<neggles>
full of blob ofc
<[Pokey]>
Presumably not liked though
<neggles>
and the kernel. oh god, the kernel.
<neggles>
bastard love child of ChromeOS, Android, and Linux
<[Pokey]>
Is it not possible to build pure OpenWRT for these?
<neggles>
what do you think all the images for UBNT's QCA APs are
<[Pokey]>
Idk I haven't looked :P
<[Pokey]>
I'm stuck in ramips land
<neggles>
In short, yes
<[Pokey]>
Neat
<neggles>
ath79, ipq40xx, ipq806x
<neggles>
don't ask robimarko about ipq807x
<neggles>
or ath11k
<[Pokey]>
Would it be a good assumption that Ubiquity are just using standard OpenWRT .11r support and slapping their own remote management Daemon on top?
<neggles>
kinda
<neggles>
they do some extra magicks, same as Cambium do
<neggles>
their own over-the-DS stuff
<neggles>
and on the IPQ APs, they're using the NSS engines
<neggles>
NSS is how Qualcomm get away with a quad cortex-A53 in an access point that can do 8Gbps
<robimarko>
BTW, anybody interested in writing their own NSS FW?
<robimarko>
They do at least have a public toolchain
* [Pokey]
backs away slowly
<[Pokey]>
Pass
<neggles>
and some semi public documentation
<neggles>
it's not as bad as HEXAGON
<[Pokey]>
I'm curious now whether there's an add-on for OpenWRT centralised remote management
tlj_ has quit [Remote host closed the connection]
<robimarko>
OpenWISP is about as close as you are gonna get
<mrnuke>
robimarko: only of NSS stands for No-Schitt-Sherlock
<neggles>
An Attempt Was Made rather than *crickets*
<robimarko>
Just one from the finally picked series
<neggles>
god can you even imagine how much better the quality of their patches would be and how much goodwill they'd get from just
<robimarko>
Original driver was upstreamed in 20 f*cking 20
<neggles>
hiring half a dozen developers dedicated solely to upstreaming things
<[Pokey]>
That's one of their patches?
<robimarko>
[Pokey] Nope, that is my fix of their broken shit
<[Pokey]>
neggles: and that's probably cost them nothing in the grand scheme of things
<neggles>
drop in the bucket
<[Pokey]>
robimarko: aha
<robimarko>
neggles: Fun fact its that they have devs, but they are pretty much upstreaming mobile SoC-s
<robimarko>
And I would guess mostly because of Google not wanting to use them otherwise
<neggles>
robimarko: well yeah but i mean specifically for router side
<neggles>
and yep
<neggles>
google gets the credit for that
<robimarko>
Router side is at best, they push pins and clocks
<robimarko>
And usually half-broken
<\x>
ahemm, QCA complaining time?
<robimarko>
Yeah, its rant time
Ansuel has joined #openwrt-devel
<\x>
just like everyday
<neggles>
and it's only happening because of google realizing that maintaining android as an aggressive fork from mainline was a bad move
<Ansuel>
o/
<Ansuel>
what is the topic today?
<neggles>
qualcomm
<neggles>
just like every other day
<\x>
Ansuel: QCA ranting
* Ansuel
hides
<robimarko>
Our love for QCA
<neggles>
the thing that's so frustrating about qualcomm is
<Ansuel>
did they nack some patch or something?
<neggles>
they come *so close*
<neggles>
*SO CLOSE*
<neggles>
to being "yeah, alright"
<neggles>
and it would cost them almost nothing to get over that line
<neggles>
but they just, don't
<neggles>
like ffs guys, whole-ass or no-ass, don't half-ass
<robimarko>
The best part is that then eventually they move to a newer kernel that they broke
<robimarko>
And have to fix it downstream
<robimarko>
By "fix" I mean hack it even more
<\x>
port to a newer kernel that will just get EOL'd soon?
<\x>
its their MO
<neggles>
what's the latest QSDK on
<neggles>
5.10?
<robimarko>
5.4
<neggles>
classic
<robimarko>
And 12.0 is the first version using it
<robimarko>
Only took them 2 or so years
<neggles>
most products are on 11 or 10 or older still
<robimarko>
To them it really doesnt matter if its LTS or not
<neggles>
XE5-8 is on uhhh
<robimarko>
Cause they never update it
<robimarko>
And yeah, vendors never update QSDK
<neggles>
yeah they don't even apply stable tree patches
<neggles>
idk how they haven't learned from google's mistake
<neggles>
chromeos/android will be mainline-adjacent one day. one day.
<robimarko>
Now you want them to move away from the good old vendor SDK style
<\x>
I should have the MR7350 tomorrow or monday/tuesday
<\x>
just cleared customs
<robimarko>
\x: Havent even removed the plastic from mine
<\x>
whats kinda assblasting though is amazon
<neggles>
robimarko: would it be so hard for them to ship it as a set of patches or a tree that's intermittently rebased like rockchip SDKs
<\x>
when i bought it, they didnt offer free shipping
<\x>
just yesterday, they started offering it
<\x>
wtf
<neggles>
\x: complain
<neggles>
they will refund you
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<neggles>
every single time
<\x>
ill try that and see yeah
<robimarko>
neggles: now you are asking much
<neggles>
if rockchip can do it
<robimarko>
Ansuel: I got an idea for a "fun" project
<neggles>
\x: amazon's physical goods business does not make money, and it basically never has
<robimarko>
Using NSS core 1 for crypto but without the fun QCA drivers
<Borromini>
QCA probably wants to keep their healthy margins (I do suppose they are healthy)
<robimarko>
Lets just say that I am not afraid that they are losing money
<neggles>
IMO they just don't want people finding out how many GPL violations they've done.
<neggles>
and they *definitely* don't want people looking too closely at SDX and HEXAGON.
<robimarko>
Mediatek started being worse than QCA
<robimarko>
But recently they have really turned around
<neggles>
hexagon definitely does not run linux, those blobs are not a heavily hacked up linux kernel, that's crazy talk, don't know what you're on about, no sir. and it 100% doesn't have access to the full physical memory map of every SoC it's in, without any oversight or monitoring. no sir. no way no how.
<Ansuel>
robimarko from 1 to 10 how "fun" it is :D
<robimarko>
Probably 11, on the "fun" scale
<Ansuel>
robimarko also the crypto core require the eip firmware
<neggles>
there's a toolchain
<neggles>
time to write your own >:D
<Ansuel>
pls don't tell me you want to find a way to use the marvell free one
<robimarko>
Ansuel: Well, good thing they kindly ship it as part of stock FW
<robimarko>
So, we cannot ship it, but nothing prevents us from telling users how to get it
<Ansuel>
oh ok so you want to prepare everything and leave the user extract the eip firm
<robimarko>
Yeah, kind of like VDSL FW for vectoring is done
<neggles>
perhaps include a little shellscript in the initramfs image to extract it from the stock fw
<robimarko>
No need, you can just unpack the squashfs and copy/paste
<neggles>
lmfao
<robimarko>
binwalk -e will sort that out
<Ansuel>
robimarko well ok idea my concern is you know.... the crypto package
<Ansuel>
also you need nss-drv to load the firm
<Ansuel>
unless you want to create a simple package about it
<robimarko>
My idea is to do everything ourselves
<robimarko>
Loading the FW is the easiest part
<Ansuel>
and there goes your 11 to 110
<robimarko>
Its quite literaly ioremap and couple of write
<robimarko>
Well, there are 2 kmods for crypto
<Ansuel>
fell free to ask for help I WANT TO PARTECIPATE TO THIS MADDNESS AHAHAHA
<robimarko>
But the one that actually exposes it to the kernel needs to be rewritten as that whole framework was dropped
<neggles>
I swear i found some sources for some nss things somewhere.
<Ansuel>
you mean the cfi thing
<robimarko>
neggles: Its all there
<robimarko>
git.codelinaro.org
<Ansuel>
neggles nss stuff is all opensource
<robimarko>
And just look for nss-
<Ansuel>
i even hacked a way to use mismatched firm
<robimarko>
Ansuel: BTW, they updated the public NSS FW
<robimarko>
With the 12.0 one
<neggles>
I mean I thought i'd found some firmware sources, but it was probably more of a "nvidia dkms driver" type situation now that i think about it.
<Ansuel>
neggles you mean the nss blob source o.O
<neggles>
yeah. where'd i put that damn tarball
<robimarko>
neggles: now that would be a goldmine
<Ansuel>
lol....
<neggles>
ah dangit i meant to harass our cambium guy about GPL tarballs this week too
<Ansuel>
robimarko i know you are thinking the same...
<Ansuel>
edma offload...
<robimarko>
How could you guess
<[Pokey]>
Was on a phone call. Did I miss anything exciting?
<robimarko>
Well, for start RX checksum offloading would be great
<robimarko>
Cause, I know that EDMA has all of the fancy HW offloads for TSO, GSO, etc
<Ansuel>
like we are at the point that we don't care at all about the firmware but we just want some clue on how to setup the switch ahahahha
<Ansuel>
anyway my experience with the wax202.... it seems hw offload makes the connection crash as soon as it goes idle
<Ansuel>
testing by disabling it an 15h uptime
<\x>
<robimarko> \x: Havent even removed the plastic from mine
<\x>
I guess its QSDK time for meee for some time
<robimarko>
Its gonna be QSDK time for a while
<\x>
I need to also know how that linksys dual firmware thing works, its my first time having one
<Ansuel>
(btw robi with a driver for ourself we can even consider wifi offload but that's another project...)
<Borromini>
Ansuel: have you been testing 5.15 on your WAX202 or still 5.10?
<[Pokey]>
Has anyone ever screamed at Qualcomm to be more helpful?
<Ansuel>
5.15
<neggles>
[Pokey]: if you'd like to bash your head against a brick wall, be our guest
<\x>
yooo Borromini, you might be interested on that cheap MR7350 on amazon, just a heads up
<[Pokey]>
There's gotta be someone there that sympathises with you even if they can't do anything
<Ansuel>
main problem is that i control it remotely since it's at my parents house soooo when it crash i have to call my parents and make it reboot
<neggles>
i am sure at least some of their devs wish they could do better, yes
<neggles>
Ansuel: sounds like it's time for a $5 esp8266+relay module >:D
<Borromini>
neggles: that was [Pokey] i was asking about the 20 chains :)
<neggles>
oh right
<[Pokey]>
oh right
<[Pokey]>
Minimum Advertised Price
<neggles>
lmao
<neggles>
*facepalm*
<[Pokey]>
I wasn't that off
<karlp>
Ansuel: isn't that just that we re-upload tarballs to that webuild? so ours are consistent even if it's not the same as what you can re-pull yourself?
<\x>
[Pokey]: so is that usb switcher thing good now?
<neggles>
and the two 4x4 5GHz can be turned into an 8x8
<Borromini>
o_O
<[Pokey]>
\x: Uhhhhhhhhh I kinda went off on a tangent, assisted by neggles. Tonight I am deploying my own kernel packages opkg feed to a websetver and writing some documentation for it on the wiki. Then once I've got that little tangent sorted I'm going to finish working that out then I have to talk with jow again
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<Ansuel>
robimarko i just want to know if we actively use that mirror on openwrt... i'm busy with some ci changes so I can't check right now but hacked and cdn/mirror looks scary when put togheder
<[Pokey]>
Not neggles' fault though, I just asked questions:P
<robimarko>
Ansuel: Isnt that the Chinese one that has recently been added to the list*
<mrnuke>
robimarko: Did you try it on your MR7350? No dice here. Still no serial, and reboots
<robimarko>
mrnuke: Nope
<robimarko>
Wait, you dont get any output?
<mrnuke>
always possible I messed something up
<mrnuke>
no output whatsoever
<robimarko>
Ok, thats a deeper issue then
<robimarko>
I am gonna see over the weekend if it works with Buildroot and Linux-next
<robimarko>
As that is what I am using for deving, trying to use OpenWrt is just pain
<mrnuke>
You haven't used Yocto, have you?
<robimarko>
Nope, trying my best to avoid it
<mrnuke>
(that was sarcastic. I find openwrt to be an absolute pleasure when compared to yocto)
<robimarko>
I meant, its a pain for deving
<robimarko>
Once its working in Buildroot then its time to backport to OpenWrt
xback has quit [Ping timeout: 480 seconds]
<mrnuke>
Do you think you'll have to use JTAG to figure out the issue?
<robimarko>
Doubt it
<robimarko>
Since its working on CP01 and EAP101
<mrnuke>
It would be hillarius if it just works for you
<robimarko>
I am starting to prefer buying stuff with RJ45 serial ports
<robimarko>
Edgecore usually puts them, and EAP101 has them
<Borromini>
and ubiquiti :P
<Borromini>
gotta say it is pretty neat to have
<robimarko>
Yeah, really good if you have a bunch of gear
<robimarko>
Cause, half of time time I will be lacking screws to reasemble
<mrnuke>
robimarko: where did they fit an RJ-45 serial on EAP101?
<robimarko>
Ok, that was stupid from me, posting a local link
<mrnuke>
:)
<\x>
give the ssh credentials, we can access it, thanks.
<robimarko>
root/openwifi
<robimarko>
Since its "OpenWiFi"/TIP
<Borromini>
what's inside the EAP101? QCA as well I assume?
<robimarko>
Yeah, IPQ6018
<robimarko>
EAP102 is IPQ8074
<mrnuke>
robimarko: BTW, after rebaseing on the latest ipq8074-5.15-pr, I noticed a kernel crash on reboot from wcss (mind you, this is IPQ6018). I'll file a more detailed report after I've investigated this a bit
MaxSoniX has quit [Quit: Konversation terminated!]
soxrok2212 has quit [Read error: Connection reset by peer]
<Ansuel>
Thank you. This jq is just an example. After applying aria2, there may be more and more inconsistencies between the openwrt cdn and the source package hash in the future. But aria2 does improve download efficiency, bad cdn caching makes this look bad
<Ansuel>
With a little effort, I am wondering if it is possible to use multiple hashes to satisfy any one, which means that the verification is performed in this way.
<Ansuel>
should i warn these guy download integrity doesn't work that way and cdn doesn't modify the final package?
<Ansuel>
even more sus by these response.... i smell something bad here but i can be wrong
<robimarko>
Ansuel: Looks like its time to learn mandarin
Slimey has quit [Ping timeout: 480 seconds]
<robimarko>
hauke: Any plans on updating the backports?
<hauke>
robimarko: it is on my todo list
<hauke>
but I haven't found the time yet
<robimarko>
hauke: Thanks, I tried couple of times before but is beyond my abilities
<robimarko>
hauke: What is the minimal kernel version that backports are supposed to support?
philipp64 has quit [Ping timeout: 480 seconds]
<Ansuel>
robimarko can't wait till the package maintainer will open a pr saying the hash is wrong with the same release number... sure why it was wrong sir?
<hauke>
robimarko: currently kerenl 4.4, but we can increase it if it causes too many problems
<hauke>
I only really care about OpenWrt
<hauke>
for backports
<hauke>
and there we have kernel 5.10 minimum
<robimarko>
hauke: ok, let me mess around over the weekend
Slimey has joined #openwrt-devel
<Ansuel>
macos workflow are SOOOO slow my god
Piraty_ has quit []
Piraty has joined #openwrt-devel
<[Pokey]>
Ansuel: what are you using your workflow for that's so complex that makes its speed an issue?
<hurricos>
neggles: < secure boot > BCGA1408 can't be booting securely, it's a Kirkwood (88F6281) with a directly wired spi-nor
<hurricos>
that said it's 2011 lol
<hurricos>
also, have fun initializing the PCIe switch on the back of that thing
<hurricos>
let alone the broadcoms
<hurricos>
which do not support either b43 nor brcmfmac :(
<Ansuel>
[Pokey] the fact that if we want kernel bump in a good way we will have to test all the 75 target and that will stop any other check for 4 hours :D
<[Pokey]>
Ouch
<[Pokey]>
What is that a macos workflow for tho and not a shell script like everything else
<Ansuel>
nha it's just macos slow to build
<Ansuel>
the same process on ubuntu-latest is just 17 minutes
<Ansuel>
on macos it's 1h:30
<[Pokey]>
Eq
<[Pokey]>
Ew*
tlj_ has quit [Remote host closed the connection]
tlj_ has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
danitool has joined #openwrt-devel
minimal has joined #openwrt-devel
<[Pokey]>
neggles: Looks like CONFIG_ALL_KMODS is set by default and CONFIG_ALL is not so I assume I already have all possible kmods ready to serve just not userspace packages which i can grab from the official repo anyway
srslypascal has joined #openwrt-devel
Gaspare has joined #openwrt-devel
philipp64 has joined #openwrt-devel
sorinello has quit [Quit: Leaving]
<philipp64>
anyone have a pointer for how to set up a port on my firewall as a VLAN trunk? with 1:PVID 2:TAGGED 4:TAGGED
<nbd>
jow: ping
Gaspare has quit [Quit: Gaspare]
sorinello has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
philipp64 is now known as Guest1882
philipp64 has joined #openwrt-devel
Guest1882 has quit [Ping timeout: 480 seconds]
csrf1 has joined #openwrt-devel
philipp64 is now known as Guest1885
philipp64 has joined #openwrt-devel
srslypascal has quit [Ping timeout: 480 seconds]
Guest1885 has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
<[Pokey]>
At a little bit of a loss with opkg at the moment.It keeps saying "Signature check failed. Remove wrong Signature file." on my custom build, but I only have it pointing to the official userspace repos, as well as a privately run kmod repo. TMy locally run repo throws no signature error. Why might this be?
danitool has quit [Remote host closed the connection]
danitool has joined #openwrt-devel
Borromini has joined #openwrt-devel
danitool has quit [Remote host closed the connection]
<dwfreed>
would be cool if usign could produce the public key of a given private key
<dwfreed>
(to be fair, signify presently doesn't have an option to do this either)
<jow>
nbd^pong
danitool has joined #openwrt-devel
<dwfreed>
just realized at some point I changed my usign private key, and wasn't sure I'd saved the public key anywhere; luckily I had, at least
csrf1 has quit [Ping timeout: 480 seconds]
<dwfreed>
aha, the last 32 bytes (after decoding) are the actual ed25519 pubkey, and the rest of the usign pubkey can be assembled from that
<dwfreed>
so that makes a usign privkey -> pubkey operation super simple, at least
<[Pokey]>
dwfreed: Sorry for the ignorance, is that related to the signature on the opkg? :P
<[Pokey]>
I feel like I'm missing a trick with what you're saying if it is
<dwfreed>
no, no idea why yours is failing
<dwfreed>
just noticed my own repo was failing for unrelated reasons
<dwfreed>
and it was because the pubkey I had on the system I was using was no longer the right pubkey
<nbd>
jow: made progress with the wiphy rename thing. so i decided against renaming it in the hotplug handler, because that would be way too racy. i'm doing it early in the netifd mac80211 setup script instead
<nbd>
i have one concern though
<nbd>
if we keep radio* as section names, we can easily end up with a config where wlX is configured as radioY and X != Y
<nbd>
which would be rather confusing
<nbd>
so i wonder, how important is it to you to preserve the radio* section names?
<[Pokey]>
dwfreed: no worries, soz!
<jow>
nbd: not sure I follow. What is wlX ? A phy name or a wifi netdev name?
<nbd>
renamed phy
<nbd>
as per previous discussions
Borromini has quit [Quit: leaving]
<[Pokey]>
Disabled signature checks on opkg for now and its working again. Puzzled still but I will ignore for now and invesitgate later
<[Pokey]>
Added my local opkg kmod feed to my device, updated and went to install a package, and got pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.138-1-218bf6e00a546ab5c6ea465b29f9c777) for kmod-nls-base
<[Pokey]>
My kernel is .144, why would it be looking for .138 when I see that it explicitly pulled kmod-nls-base from my own opkg repo which was built under 144?
<robimarko>
What is the feed order?
<[Pokey]>
my feed first
<robimarko>
That is really weird
<Ansuel>
Mangix nice idea to create a draft pr
* [Pokey]
throws his ipks everywhere
<[Pokey]>
is this thing such a pain to get rightr
<[Pokey]>
it shouldn't be
<[Pokey]>
Userspace packages which rely on kmods should not be concerned as to what version of a kmod they get, right?
tlj has joined #openwrt-devel
tlj_ has quit [Ping timeout: 480 seconds]
<[Pokey]>
Which would allow me to provide newer kmods which work with my newer kernel to the packages on the official opkg repo
<[Pokey]>
Userspace packages on the official repo, to be precise
<Ansuel>
i'm not following you kmod needs to be synced with kernel magic to prevent any kind of crash/missing symbol
<Mangix>
Ansuel: I mean I have the commits. Might as well
<Ansuel>
anyway time to wait gozillion action queue for this... sad...
<Ansuel>
worst time to push since other user decided to push tons of pr ahahah
<[Pokey]>
Ansuel: Indeed.So, when I build my firmware image, I have CONFIG_ALL_KMODS set. This will build every single possible kmod to be compatible with my newer .144 kernel. I have a webserver running which provides these compiled .144 compatible kmods as an opkg feed. I have added this feed as my first feed in my feeds list. I have disabled the official openwrt_kmods feed. I then would expect the official userspace package feeds to just work
<[Pokey]>
without relying on me recompiling the, because when they request a kmod, they'll get a .144 compatible version of that kmod downloaded from my feed
<Mangix>
Ansuel: not sure I understand BUILD_ALL_HOST_TOOLS . Is the idea to have something in between a regular environment and an SDK?
<[Pokey]>
I believe this information is correct but it is proving to not be the case so far
<jow>
nbd: I'm not really married to the radioX designation, I just think that changing it will break a lot of existing downstream tooling
<nbd>
do you have any preference on how to move forward with this?
Borromini has joined #openwrt-devel
<Ansuel>
Mangix: yes currently it's not set but yes the idea is to force compile all tools for both testing purpose and also to generate a tar with everything compiled in
<Ansuel>
Ideally the option will be enabeld and the tar will be part of the container that will be used here
<mrnuke>
Does it limit your wifi speeds if you don't pay a monthly subscription?
<mrnuke>
JK. Thank you, robimarko, for figuring out this madness. It should would have given me a lot of grief!
<Mangix>
Ansuel: I'll note prereq-build does not do any checks for curl, wget, or aria2c
<Mangix>
well, it checks for wget even though it might not use it.
<robimarko>
mrnuke: We are gonna get there
<robimarko>
It requires a f*cking mobile app to setup first
<mrnuke>
Umh, I got to the config toggles via web GUI. It was a really SSH.it ghui, but a web gui nonetheless
<robimarko>
But at least: secure boot fuse is not enabled
bluew has joined #openwrt-devel
<[Pokey]>
I seriously give up tonight. Still getting pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.138-1-218bf6e00a546ab5c6ea465b29f9c777) for kmod-nls-base even after rebuilding everything from the latest master after a distclean and flashing the image, removing the openwrt_kmods feed and adding my kmods feed from my build output before ever updating the package list. I have no idea what its problem is now. The only packages it
<[Pokey]>
should get from the official repo are userland ones and they should be able to use my kmods if I am not mistaken
<jow>
the core feed contains kmods as well and opkg fails to select the proper provider
diederik has left #openwrt-devel [Going to see what happens IRL, see ya!]
<dwfreed>
probably just version mismatch, and opkg always selects "best"
<dwfreed>
vs trying to do a proper resolve
Borromini has quit [Quit: Lost terminal]
<jow>
yeah
<[Pokey]>
The "best" should be my kmods. Because they're the ones built for my kernel version. I'm in 144 and the official repo is 138. So why the hell it wants 138 I don't know
<jow>
our opkg fork is quite botched
<robimarko>
mrnuke: flashed CRM-TZ.WNS.5.1-00152 from QSDK12 and boom mainline kernel boots
<jow>
[Pokey]: it probabley stops looking at the first provider for the abstract package, and that would be the kmod from the core feed
<dwfreed>
[Pokey]: except it's probably selecting the best kmod-nls-base from an updated master in openwrt/core repo, rather than your private kmod repo
<jow>
the kmods feed once was meant as an overlay to supplement builds with compatible kmod feeds
<[Pokey]>
So it literally is a bug because it's disregarding the feed order?
<jow>
yes, it is a bug in opkg
<jow>
in openwrt's fork of opkg
<jow>
you could try moving your kmod feed before the core one
<jow>
wonder if that would help
<[Pokey]>
I guess I'm the only crazy weirdo trying to cheat by hosting my own kmods and use them alongside the official userland packages
<jow>
no you're not
<[Pokey]>
My feed is the first in the list
<robimarko>
Anyway, off to bed. Have a good night guys
<jow>
but most people end up hosting all packages thermselves
<jow>
not just the kmod feed
<[Pokey]>
Good night robimarko
robimarko has quit [Quit: Leaving]
<[Pokey]>
jow: yea I'm wondering if I should just build all of the possible packages too. Not sure how to do that right now though
<[Pokey]>
Would prefer this just worked
<[Pokey]>
At least it's opkg and not me. I thought I was screwing something silly up
<[Pokey]>
I've also given up trying to understand the signature errors and just turn off the signature checks now too
<jow>
did you build with package signing enabled?
<jow>
otherwise your own local feed will be completely unsigned while opkg demands signatures
<[Pokey]>
Presumably yes because it outputs a signature file and I'm using the original config.buildinfo which I would expect has that on. But it also fails when it tries to access official feeds too
<neggles>
[pokey]: you gotta disable signature checks cause by default, while it'll sign your packages, those keys don't end up in the image
<neggles>
afaik
<neggles>
Ansuel: ◕w◕ I would drop the capitals in the tool option names, personally
<neggles>
why would you not want to use aria2 tho...
<Ansuel>
if you missed the drama just scroll up :D
<neggles>
oh god I scrolled past that somehow
<Ansuel>
neggles ok i'm dropping the capital
<Ansuel>
neggles your hand protected you from it
<neggles>
Ansuel: ugh. personally I don't think we should be pandering to idiots who drink the YouTube sponsor segment kool-aid and think absolutely everything should be run through some stupid VPN service
<neggles>
people who run encrypted BitTorrent over VPNs make me sad.
<Ansuel>
the feature was already on my todo sooo.... just didin't like how toxic he was but whatever
<neggles>
but letting the tool be configurable is still a good idea, just not for that reason.
<neggles>
yeah
<Ansuel>
anyway perl is so evil
<neggles>
<shibboleth> better have you buildboxes connected straight to inet, like 1337 h4x0r5 < no like someone who actually understands how the internet works and the impracticality of your ISP spying on you in any meaningful way...
<neggles>
Perl ought to be a war crime
<Ansuel>
ahahahah yes looks ""simple"" at first and then
<neggles>
and the "what about the 76 other packages the default meta package depends on"? buddy. pal. friend. you can `apt-mark manual` all of those, then `apt-mark auto` the metapackage, and remove it and aria2c.
<neggles>
yes I'm assuming they use apt, but I'm 99% sure that's an Ubuntu user.
<neggles>
Or ubuntu derivative. Or Manjaro maybe. details.
<Ansuel>
best thing was the solution... after suggesting him that he could just comment the line in the script he said
<Ansuel>
i can rename aria2c to something else... SURE
<neggles>
what
<neggles>
the heck
<neggles>
but yes Perl is definitely a crime
<Ansuel>
LOL
<Ansuel>
the best thing i discovered is that env variable keep the "
<Ansuel>
so
<Ansuel>
my $preferred_tool = $ENV{DOWNLOAD_TOOL_PREFER};
<neggles>
it looks simple and cool and good and then the next thing you know you're ^ yep doing cursed things with regexes
<minimalist>
he wasn't as bad as the other guy in the netfilter channel at the start of the week who had a mess of scripts for openwrt to set up ban rules and was complianing about slow rule import times and who then for some reason decided to go onto the alpine channel (rather than openwrt channel) to continue the same "discussion" (i.e. rant) and hassled and insulted people there