<Grommish>
Cortex-a9 should never be attempting to compile rust as the HOST, so I'd hope it would error..
<Grommish>
Pepe: but yes, look at x86.. Fails because it runs out of disk space
<Grommish>
Unless yu can reasonably expect to compile OpenWrt on it, the package will fail more than likely. It's the fact that x86_64 and powerpc work (and other platforms used to actually build OpenWrt) that I'm concerned with
<Grommish>
No one would be compiling Rust on their router :D
<Grommish>
/would/should/s
<Grommish>
I'd be crazy enough to try.. and in fact I do have rustc/cargo for mips64 so I COULD
ivanich has quit [Quit: Konversation terminated!]
<Grommish>
The only artifact would be the compied toolchain, which for myh x86_64 to mips64 is 530MB in a tar.xz file
<Grommish>
Pepe: Unless OpenWrt wanted to host the "safely" compiled toolchain installation stuff, the user would have to generate their own at least once and then it'll use that resulting installation blob to deal with rust in the future (stashed in dl/*)..
<Grommish>
and then again each time the toolchain updates
Tost has quit [Ping timeout: 265 seconds]
indy has joined #openwrt-devel
Tapper has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
Tapper1 has joined #openwrt-devel
Tapper has quit [Ping timeout: 272 seconds]
Tapper1 is now known as Tapper
MichaelOF has quit [Quit: Konversation terminated!]
qdel has quit [Ping timeout: 260 seconds]
Risk64 has quit [Quit: Risk64]
qdel has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
linzst has joined #openwrt-devel
victhor has joined #openwrt-devel
linzst has quit [Quit: Leaving]
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
DonkeyHotei has quit [Ping timeout: 265 seconds]
<mangix>
Grommish: I've compiled OpenWrt on an mvebu host. AMA.
<Grommish>
mangix :D Nah, Pepe was saying the packages were failing on the CI.. and they are, but the ones I actually care about fail due to out of space
<Grommish>
mangix: Would you want/need a rust toolchain that was cortex_a9 or whatever as the host?
<Grommish>
or failing because rust doesn't support tier 3 for standard install, just cross compile. which is why I don't mind those
aptanet has quit [Ping timeout: 264 seconds]
Monkeh has quit [Ping timeout: 256 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
home-alone has quit [Read error: Connection reset by peer]
home-alone has joined #openwrt-devel
<aparcar[m]>
mangix: I think you mdns patch is merged tomorrow
dorf has joined #openwrt-devel
hurricos has quit [Ping timeout: 264 seconds]
hurricos has joined #openwrt-devel
Strykar has quit [Quit: /quit]
Strykar has joined #openwrt-devel
goliath has joined #openwrt-devel
weijie has quit [Quit: Ping timeout (120 seconds)]
weijie has joined #openwrt-devel
rmilecki has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
Huntereb has quit [Read error: Connection reset by peer]
black_ant has quit [Ping timeout: 240 seconds]
<mangix>
aparcar[m]: ok
mmlb7 has joined #openwrt-devel
mattsm has quit [Killed (barjavel.freenode.net (Nickname regained by services))]
mattsm has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
mmlb has quit [Ping timeout: 264 seconds]
mmlb7 is now known as mmlb
Night-Shade has joined #openwrt-devel
feriman has joined #openwrt-devel
valku has quit [Quit: valku]
dedeckeh has quit [Quit: Ping timeout (120 seconds)]
Tost has joined #openwrt-devel
home-alone has quit [Ping timeout: 272 seconds]
home-alone has joined #openwrt-devel
jas4711 has quit [Remote host closed the connection]
danitool has joined #openwrt-devel
reiffert has quit [Ping timeout: 256 seconds]
<aparcar[m]>
nbd: ping
reiffert has joined #openwrt-devel
Ycarus_ has joined #openwrt-devel
Ycarus has quit [Ping timeout: 264 seconds]
Ycarus_ has quit [Client Quit]
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
<nbd>
aparcar[m]: pong
home-alone has quit [Ping timeout: 260 seconds]
Ycarus has joined #openwrt-devel
<aparcar[m]>
nbd: mwarning1 and me trying to add initramfs files to the profiles.json file. The current state is here: https://github.com/mwarning/openwrt/commit/053a726660deb38c5d6da57bf75607fc3cf70c6d I don't understand how the device variables are somewhat delayed exported. Would it be possible to make variables like DEFAULT_PACKAGES etc directly accessible?
<aparcar[m]>
isn't this line used to export the variables?
dedeckeh has joined #openwrt-devel
Grommish has quit [Ping timeout: 246 seconds]
grift has quit [Quit: Bye]
grift has joined #openwrt-devel
home-alone has quit [Ping timeout: 246 seconds]
home-alone has joined #openwrt-devel
Huntereb has joined #openwrt-devel
<aparcar[m]>
nbd: I'm off for today, please ping me if you have an idea how to make these variables available. the other option would be to do quite some python changes to stuff things together with seem like a terrible workaround
<aparcar[m]>
mangix: which messenger are you using now? thinking about replacing the matrix client...
<olmari>
aparcar: plenty alternative matrix-clients out there ;)
dedeckeh has quit [Quit: Connection closed]
victhor has joined #openwrt-devel
hexa- has quit [Ping timeout: 265 seconds]
<mangix>
aparcar[m]: IRC? I use a quassel docker container on my VM.
home-alone has quit [Read error: Connection reset by peer]
home-alone has joined #openwrt-devel
finsternis has quit [Remote host closed the connection]
<barhom>
Are there any good way to remove a firewall rule by name? I feel like removing a firewall rule by id (i.e. uci delete firewall.@rule[X]) is prone to racing conditions errors
dedeckeh has joined #openwrt-devel
<hurricos>
barhom: you can name your rules. I don't know if uci takes them up, but ...
<barhom>
Yeh, I can name them. But I can't delete a rule by name
valku has quit [Remote host closed the connection]
dedeckeh has quit [Quit: Ping timeout (120 seconds)]
valku has joined #openwrt-devel
<reiffert>
Hi. My openwrt stable keeps dying. According to someone here these issues are solved with trunk. How can I compile trunk and include luci, nmap and tcpdump as packages? Last time I tried I couldn't install packages after compiling.
<grift>
in make menuconfig also tick "[*] Build the OpenWrt Image Builder"
<grift>
when its done compiling, extract the image builder .xx and use that to create an fireware image:
<reiffert>
Device mikrotik,rb750gr3 not supported by this image
<reiffert>
Supported devices: mikrotik,routerboard-750gr3 mikrotik,rb750gr3 - Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA
<reiffert>
mhm any suggestions? install trunk from snapshots and then install this here?
heffer has quit [Ping timeout: 240 seconds]
Tapper has joined #openwrt-devel
<stintel>
reiffert: sysupgrade -n (this will cause you to lose all configuration though)
<grift>
not sure , but i would probably revert to stock and then do a factory install
<reiffert>
stintel: can I push the config backup later on?
<stintel>
reiffert: the other option is rm /etc/config/network; sysupgrade -f - you will then only lose network config, which should be relatively easy to reconstruct
<stintel>
reiffert: the problem is /etc/config/network - your backup will not be compatible due to the move to DSA
<reiffert>
I have a couple of vlans .. guess I need to figure a way to create them with CLI / uci?
Tapper has quit [Client Quit]
<reiffert>
stintel: after deleting etc/config/network .. will the remaining config survive?
<stintel>
reiffert: it should
<stintel>
did it like that on my DIR-860L not so long ago
home-alone has quit [Ping timeout: 272 seconds]
home-alone has joined #openwrt-devel
heffer has joined #openwrt-devel
<reiffert>
I'll try tomorrow, dont have a laptop with me for rescue
<reiffert>
do we know which packets make the switch or ip-stack die?
<Borromini>
svanheule[m]: sorry for the clusterfuck :P doesn't help our main tester atm is posting a single message a day. i ordered my isolated uart adapter off tindie. will test once i have it.
Darkmatter66 has joined #openwrt-devel
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #openwrt-devel
<Borromini>
guys can i unpack a sysupgrade image? any instructions for that somewhere?
<Borromini>
i wanna make sure packages do end up inside and make V=s in the buildroot doesn't seem to show that
<Borromini>
is that responsibile disclosure, 13 days?
<ldir->
Mac OS 11 Big Sur is 1.8.31 - My latest firmware Qnap boxen are 1.8.16 - I mean fucking hell!
<Borromini>
debian testing is 1.9.5p1
<aparcar[m]>
ynezz: oh so I have root hen on the openrwt servers ;)
<Borromini>
finally ;)
<svanheule[m]>
Borromini: no worries, let me know if you find anything that doesn't work after you get serial on your device :-)
<svanheule[m]>
Borromini: the people porting the Archer A6/C6U are working hard on nailing down the switch initialisation of the SoC, so that problem might get solved by itself :D
<Borromini>
svanheule[m]: cool, haven't kept an eye on it
<Borromini>
but good to know :)
<Borromini>
can someone tell me (and from what point on) i should extract the squashfs part from the image? binwalk gives this: https://paste.debian.net/1182855/
<Borromini>
i reckon i only need the squashfs part to see the actual upgrade image contents, but i don't know how to read the numbers that binwalk prints
<rsalvaterra>
ldir-: OMG, that's a nasty one.
<svanheule[m]>
Borromini: binwalk -e will just try to extract everything it finds, so no need to extract the squashfs first
<Borromini>
svanheule[m]: oh! thanks let me try that.
<Borromini>
sweet, obviously didn't know about that
<rsalvaterra>
ldir-: How wonderful, both Debian Sid and Ubuntu 20.04 are still vulnerable.
<rsalvaterra>
*20.10
<Borromini>
rsalvaterra: yeah nothing newer than 1.9.5p1. hence my question about how responsible that qualys disclosure is. I have no idea about 'lead time' on such far-reaching exploits
<Hauke>
rsalvaterra: my debian stable just got a new sudo version
<ldir->
Surely this is much worse than the dnsmasq vuln
<Hauke>
ldir-: yes, we were informed in Octiber about the dnsmasq problem
<ldir->
but having said that, I'd rather it be known and closed as a low hanging fruit vector for a state actor.
<Hauke>
this sudo problem was much shorter
<Borromini>
Hauke: i'm on testing and mine is 1.9.5p1-1
<Hauke>
ldir-: you still need normal user access to the system
<rsalvaterra>
It's a local root exploit. It could only be worse if it were remote.
<Borromini>
oh local. move along :P
<Borromini>
i haven't told my wife about sudo yet so nothing to worry about ;)
<rsalvaterra>
Borromini: Any incidents reported? :P
<ldir->
^^^ that's what happens to Borromini when wife discovers sudo! :-D
<rsalvaterra>
Haha!
<Borromini>
:D
<grift>
debian has selinux, if that was enabled and the policy was leveraged properly then normal users would not be able to exploit this because it requires access to cap setuid, users that would have access would be able to gain root but would be stuck in there selinux domain probably and so damage would be contained (disclaimer i havent tried it so i might be wrong)
<ldir->
Hauke: combine that with a command injection vuln... and inject a sudo
<grift>
in openwrt this is exploitable even with selinux
<grift>
but openwrt is not really a multi -user system
<ldir->
grift: indeed, I log in as root to it all the time!
<Borromini>
i get why people are confused when you tell them 'do not compile as root!'
<Borromini>
after all you have to log in as root on what you compile :P
* Borromini
hides in the silly jokes closet
* ldir-
locks the door
<Borromini>
:(
<Borromini>
at least make sure there's some air coming in :P
<ldir->
brb
* ldir-
cuts round hole - tries to fit square lithium hydroxide canister through it - dammit!
<Borromini>
you're dangerous!
<ldir->
possibly - I think mostly just silly
<Borromini>
:P
ivanich_ has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
<ldir->
Borromini: but you get the Apollo 13 reference right?
adrianschmutzler has quit [Read error: Connection reset by peer]
<Hauke>
pkgadd: yes same casing
<Hauke>
I almost had done the same changes already
<pkgadd>
yep, it's a rather trivial addition, based on its siblings just a different hwid and lua-rs232 is not needed (which is used as part for the userspace PoE support)
<Hauke>
it looks like there is a problem with RX
<Hauke>
I do not receive any packets
<pkgadd>
the marking on the PCB is wrong, rx <--> tx are mixed up