ivanich has quit [Quit: Konversation terminated!]
sbrown__ has quit [Quit: Leaving]
dangole has quit [Ping timeout: 272 seconds]
koniu has quit [Ping timeout: 268 seconds]
<swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
koniu has joined #openwrt-devel
<owrt-2102-builds> build #17 of bcm53xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/bcm53xx%2Fgeneric/builds/17
koniu has quit [Ping timeout: 268 seconds]
<owrt-snap-builds> build #787 of mediatek/mt7622 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/787
hbug has joined #openwrt-devel
victhor has quit [Ping timeout: 260 seconds]
hbug___ has quit [Ping timeout: 268 seconds]
koniu has joined #openwrt-devel
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
jlsalvador has quit [Quit: jlsalvador]
goliath has quit [Quit: SIGSEGV]
Tapper1 has joined #openwrt-devel
Tapper has quit [Ping timeout: 245 seconds]
Tapper1 is now known as Tapper
<owrt-2102-builds> build #13 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mediatek%2Fmt7623/builds/13
Tapper has quit [Ping timeout: 245 seconds]
<russell--> guidosarducci: i had an iproute2 build failure on oxnas/pogoplug-v3, a weird message complaining that libbpf was version 0.3.0 but it needed at least 0.1.0
<guidosarducci> russell--: that does sound weird. Is the log online somewhere?
<russell--> not yet, i worked around it by hacking the configure script to always pass
<russell--> building the full version
<guidosarducci> russell--: could something be broken in the environment? Or causing problems with shell arithmetic or test utilities? I'll have a look at the sources, but know it built fine on mips, arm, x86...
<owrt-2102-builds> build #14 of mediatek/mt7622 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mediatek%2Fmt7622/builds/14
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #openwrt-devel
<owrt-2102-builds> build #13 of bcm63xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/bcm63xx%2Fgeneric/builds/13
<russell--> CONFIG_TARGET_oxnas=y
<russell--> CONFIG_TARGET_oxnas_ox820=y
<russell--> CONFIG_TARGET_oxnas_ox820_DEVICE_cloudengines_pogoplug-series-3=y
<russell--> CONFIG_PACKAGE_ip-full=y
<guidosarducci> russell--: right-o, let's see...
<guidosarducci> russell--: not much there I'm afraid. From the configure, it's failing a test compile against libbpf. Do know libbpf built OK?
<guidosarducci> russell--: maybe also edit the compile invocation in "configure" to save its output instead of to /dev/null.
danitool has quit [Ping timeout: 245 seconds]
<russell--> yeah, bpftools built fine
<guidosarducci> russell--: weird box BTW, naked PS inside with exposed mains power.
<russell--> i replaced the power supply in mine
<guidosarducci> russell--: could you try saving the failing compiler output as above? (I tried a build but still making toolchain)
<russell--> my build box is doing something else at the moment
<Grommish> damex: ping
<damex> Grommish: pong
<Grommish> damex: So I finally pulled a dts file for the device. cn7020
<guidosarducci> russell--: mine's still making gcc. After your workaround/hack did ip-full build OK?
<russell--> yes
<Grommish> damex: https://gist.github.com/Grommish/07fcbb5f95599d657792de0bf055469a I think I want to incorp it, does it look like it should work?
<russell--> i probably am not exercising anything related to libbpf at runtime though
<damex> Grommish: looks a bit unformatted and seem to have redundant definitions but overall looks like it should work.
<Grommish> damex: I pulled it from the running system, so it wouldn't surprise me
<damex> ah, okay
<guidosarducci> russell--: the fact it linked is OK for now. I have test script I can share if you want some exercise. :)
<guidosarducci> russell--: gcc build done.. now kernel.
<damex> if pulled from running system then yes, it should work. it might be broken though. due to how kernel patches up device tree on the fly
<damex> but that one seem to be ok
<russell--> it seems to fail first time, make package/iproute2/compile again and it seems to succeed
<philipp64> guidosarducci: I'd consider it... though my fu for generating the new configs probably needs work...
<owrt-2102-builds> build #13 of mvebu/cortexa53 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mvebu%2Fcortexa53/builds/13
<russell--> /usr/lib/libgcc_s.so.1: file not recognized: file format not recognized
<russell--> collect2: error: ld returned 1 exit status
<russell--> that's the output of the configure line
<russell--> $CC -o $TMPDIR/libbpf_test $TMPDIR/libbpf_test.c $LIBBPF_CFLAGS $LIBBPF_LDLIBS >/tmp/libbpf.log 2>&1
<guidosarducci> philipp64: I missed something I think, you're referring to my earlier ping re: x86_64?
<guidosarducci> russell--: ld complaining about libgcc doesn't sound good, how would things even get that far?
<owrt-2102-builds> build #13 of mpc85xx/p1010 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mpc85xx%2Fp1010/builds/13
<philipp64> guidosarducci: yes regarding x86_64
<guidosarducci> philipp64: great, thanks. a couple of folks are working on a 5.10 update for x86_64 and running into build problem related to libelf
<philipp64> Is there a thread about it?
<guidosarducci> philipp64: tools/libelf is actually an ancient lib unneeded on Linux, and can break builds looking for the modern elfutils. TL;DR it's fixed by the first 3 commits of my PR https://github.com/openwrt/openwrt/pull/3855, which has links to the x86_64 PRs.
<guidosarducci> philipp64: was hoping you, ldir- or someone caring for x86 might take a look
<guidosarducci> russell--: my build. finished. successfully. I see ip-full, libbpf packages all there.
<guidosarducci> guidosarducci: could you have a dirty build environment, considering I just built mine new?
<guidosarducci> ^^ I meant russell--
<russell--> this is the command line that failed: arm-openwrt-linux-muslgnueabi-gcc -o config.Ow9olb/libbpf_test config.Ow9olb/libbpf_test.c -I/home/openwrt/src/lede/staging_dir/target-arm_mpcore_musl_eabi/usr/include -L/usr/lib -lbpf
<russell--> i'll try a dirclean for giggles
<guidosarducci> russell--: OK, I'll rebuild the package just to see...
<owrt-2102-builds> build #13 of ipq40xx/mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ipq40xx%2Fmikrotik/builds/13
<russell--> i could get it to fail reliably with make package/iproute2/{clean,compile} with the four line .config stub above
<guidosarducci> russell--: my rebuild was also successful. One difference is my config builds all the iproute2 packages, but I don't see that making a difference. ip-tiny, ip-full, tc are different variants getting built in different dirs.
<guidosarducci> russell--: I'll turn off all but ip-full from iproute2...
<guidosarducci> russell--: that also worked.
<guidosarducci> russell--: earlier you said it would succeed compiling after failing the first time. How does that mesh with reliably failing now? Did something change?
rmilecki has joined #openwrt-devel
<guidosarducci> russell--: This still bothers me: /usr/lib/libgcc_s.so.1: file not recognized: file format not recognized
<guidosarducci> russell--: to be clear, did you edit the path, or is it trying to use the system libgcc rather than cross-compiled one in staging_dir?
guidosarducci_ has joined #openwrt-devel
<russell--> guidosarducci: that is what came out of the configure compile command
guidosarducci has quit [Ping timeout: 268 seconds]
guidosarducci_ is now known as guidosarducci
<russell--> same error after a make dirclean world
<russell--> the build machine is an up-to-date archlinux box
koniu has quit [Ping timeout: 268 seconds]
<russell--> IPT_LIB_DIR=/usr/lib/iptables XT_LIB_DIR=/usr/lib/iptables ... not clear what those are used for, but they are the build host's
<owrt-2102-builds> build #12 of gemini/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/gemini%2Fgeneric/builds/12
<russell--> that looks normal
<russell--> guidosarducci: the only thing i edited was that configure line
<guidosarducci> russell--: yeah, understood. the other difference is I'm using a bigger .config normally used for iproute2/bpftool/kmod testing. Why that should make difference I'm not sure. Maybe I should try your 4-line .config?
koniu has joined #openwrt-devel
nitroshift has joined #openwrt-devel
<russell--> yes, please for sanity sake
<guidosarducci> russell--: Can you try editing something? I have an idea...
<guidosarducci> russell--: vi staging_dir/target-arm_mpcore_musl_eabi/usr/lib/pkgconfig/libbpf.pc
bob23 has joined #openwrt-devel
<guidosarducci> russell--: change the line to be: libdir=${exec_prefix}/lib
<guidosarducci> russell--: from libdir=/usr/lib
<guidosarducci> russell--: pkg-config for iptables also doesn't seem right, save later
<guidosarducci> russell--: try rebuild after edit, and also capture that configure output?
bob23 has quit [Quit: Connection closed]
bob11 has joined #openwrt-devel
<bob11> Hey everyone! Just built a firmware image from the latest main source for WRT32X Venom and was curious if it's useful to anyone that it worked great! I've been searching around due to the kernel size/partition size changes to see where to provide feedback that it's working for venom as of latest main source. I used a sysupgrade.bin with 'force
<bob11> upgrade' & wipe settings coming from an OpenWRT image [19.07.6 r11278-8055e38794]
bob11 has quit [Ping timeout: 240 seconds]
<owrt-2102-builds> build #12 of mxs/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/mxs%2Fgeneric/builds/12
<guidosarducci> russell--: Any news? I'll need to go soon, but definitely spotted problems in 2 pkg-config files.
bob82 has joined #openwrt-devel
<Grommish> bob82: Also, I'm also from Cincy :)
bob76 has joined #openwrt-devel
bob82 has quit [Ping timeout: 240 seconds]
<bob76> Grommish awesome, will do!  Haha, cool! Just moved to Ohio actually!  Sorry, it keeps kicking me out over and over
<Grommish> bob76: Ignore the weather and you'll be fine :D Anyway, welcome here as well
bob76 has quit [Client Quit]
bob24 has joined #openwrt-devel
<russell--> guidosarducci: sorry, back at keyboard
goliath has joined #openwrt-devel
<russell--> initial try worked
<russell--> command line becomes: arm-openwrt-linux-muslgnueabi-gcc -o config.Btp06J/libbpf_test config.Btp06J/libbpf_test.c -I/home/openwrt/src/lede/staging_dir/target-arm_mpcore_musl_eabi/usr/include -L/home/openwrt/src/lede/staging_dir/target-arm_mpcore_musl_eabi/usr/lib -lbpf
<russell--> and the compile is silent, no error
<russell--> (in the configure script in have_libbpf_basic)
<guidosarducci> russell--: glad to hear it. Still don't understand why it worked on my build.
<russell--> so, why does libdir have /usr/lib?
bob24 has quit [Ping timeout: 240 seconds]
<guidosarducci> russell--: considering I don't have a host libbpf installed. And why did your second compile sometimes work? I give up -- too late. Will send a fix tomorrow and cc you.
<guidosarducci> russell--: /usr/lib is usually the host default, but most config files use a $prefix variable that can be overridden e.g. for cross builds.
<Grommish> CONFIGURE_ARGS usually do this automatically
<Grommish> Check ./include/host-build.mk and package-defaults.mk
<Grommish> If you aren't using it, or overriding it, it can cause issues (i've had both happen)
<russell--> i do have some /usr/lib/libbpf*'s on my build host
<owrt-2102-builds> build #12 of at91/sama5 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/at91%2Fsama5/builds/12
<guidosarducci> russell--: I think this slipped by because nothing used libbpf's pkgconfig before. You happy now that the electrocution router works? :-)
<Grommish> I need a networking diety to help me figure out why dnsmasq doesn't work unless the WAN port is UP and connected via DHCP ;p Any volunteer?
<russell--> the advantage of living on the bleeding edge is you find bugs when they are fresh in the perpetrators mind
<Grommish> russell-- haha
<guidosarducci> russell--: at least I discovered a new, truly dangerous router. :) clocking out now, take care
<Grommish> guidosarducci: g'night1
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
decke has joined #openwrt-devel
<owrt-2102-builds> build #12 of octeon/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/octeon%2Fgeneric/builds/12
danitool has joined #openwrt-devel
Borromini has joined #openwrt-devel
glyph has quit [Quit: End of line.]
glyph has joined #openwrt-devel
Tost has joined #openwrt-devel
<Grommish> Anyone know if I should be concerned my ethernet ports don't have a ring buffer? I'm seeing packet drops, and the common fix is up the buffer, but I don't seem to have one..
<Grommish> *shrug* Cannot get device ring settings: Not supported
heffer has quit [Quit: heffer]
heffer has joined #openwrt-devel
<plntyk> Grommish, isnt increasing buffers what lead to "problems" like bufferbloat ? in case of dropped eth frames shouldnt other stuff like the (buggy) pause frames be used
<Grommish> No idea. The CPU doesn't spike and the device doesn't chug, but I get dropped packets
<Grommish> I'm not sure if I just have a dodgy device build (like missing something), or if it's not supposed to be there, etc. I do know that the common "fix" for the dropped packets seems to be to increase said ring buffer
<plntyk> dunno what hardware you are using - but investigating sth like https://forum.openwrt.org/t/mt7621-mt7530-programming-disabling-flow-control-on-all-ports/76006
Borromini has quit [Ping timeout: 260 seconds]
<plntyk> maybe its sth similar
<Grommish> I can't tell you how many times I built an image without the ethernet driver :D
<Grommish> plntyk: Thanks :) That doesn't seem to apply, but I appreciate you looking!
koniu has quit [Ping timeout: 268 seconds]
koniu has joined #openwrt-devel
ivanich has joined #openwrt-devel
<plntyk> dropped packets might also be hardware defect or some other issue
<Grommish> its spread across the 3 eth ports.. eth0 is wan, eth1 and eth2 are bridged
<Grommish> getting half from 1 and half from 2 to equal the eth0 dropped number
<plntyk> creating a ticket with affected eth-hardware and maybe ask in forum if someone with same unit or same eth hardware on other devices might replicate
<plntyk> doing iperf might be enough to trigger
<plntyk> nice more build breakage hihihi
Darkmatter66 has quit [Ping timeout: 260 seconds]
Darkmatter66 has joined #openwrt-devel
zatwai_ has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
zatwai has joined #openwrt-devel
<rmilecki> plntyk: driver should have rings big enough & support BQL, to let kernel deal with queues (and bufferbloat)
<rmilecki> plntyk: see if driver has netdev_sent_queue() and netdev_completed_queue() calls - that it what's needed for BQL
<rmilecki> with that, kernel knows exactly how many bytes and queued and handles packets wisely
Borromini has joined #openwrt-devel
<mangix> seems this autoconf-lean thing broke a bunch of packages
fredrikh1 has quit [Quit: leaving]
<mangix> Now if only everyone can move to meson/cmake
fredrikhl has joined #openwrt-devel
victhor has joined #openwrt-devel
<Grommish> rmilecki: I think that is directed at me :) The original question was should my ethX ports have ring buffers, because ethtool tells me to go away
<rmilecki> Grommish: every Eth driver has ring buffers
<rmilecki> Grommish: my guess is your driver doesn't allow configuring them dynamically
<Grommish> Cannot get device ring settings: Not supported
<Grommish> I
<rmilecki> right, I think most drivers have hardcoded ring sizes
<Grommish> err I'm seeing dropped packets, and the common advice was to increase it
<Grommish> Bah
<rmilecki> Grommish: you need modify driver and recompile it (and whole image)
<Grommish> Oh, that isn't an issue if I can find it
<Grommish> but boo
<Grommish> Anyway to find out why I'm getting the dropped packets?
<rmilecki> do you see dropped packets in interface statistics on a router?
<Grommish> eth0 is WAN, eth1/eth2 are bridge in br-lan
<Grommish> there isn't a Switch chip on the device
<Grommish> at least that I could ever find
Darkmatter66_ has joined #openwrt-devel
<Grommish> I removed teh IP's from the WAN, it's connected
PaulFertser has quit [Ping timeout: 272 seconds]
PaulFertser has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 260 seconds]
<rmilecki> Grommish: do I see correctly you have 0,0186779593459% dropped packets on br-lan?
<Grommish> Probably, the issue is that it comes in batches, whcih freezes the eth1 and eth2 traffic
<Grommish> So I get notiable hitches in things like video
<rmilecki> you should add some debugging to the ethernet driver
<rmilecki> sure, you can increase rings sizes, but I'm not sure it's going to help
<rmilecki> Grommish: maybe start observing IRQs, see if RX IRQs stop appearing at some intervals or sth
<Grommish> Yeah, i'd like to find out why it's happening, it's being a pain
<Grommish> and it itsn't consistent
<rmilecki> i'l add dev_info_ratelimited to the irq handler
<rmilecki> and let it run
<rmilecki> once you see a hiccup, see if IRQs stopped appearing during that timeframe
<rmilecki> Grommish: also try to trigger a stall using iperf
<rmilecki> Grommish: put a machine running "iperf -s" on the WAN port
<rmilecki> Grommish: then run "iperf -c" on LAN connected machine
<Grommish> I get 920/240 to the ISP. Like I said, it just isn't consistent :(
<Grommish> I will have to see about the driver though
Tapper has joined #openwrt-devel
<Borromini> Grommish: octeon still?
<Grommish> yeah
<Grommish> I'm getting dropped packets and I'm not sure why, even though it's very small in ratio :p
<rmilecki> Grommish: i guess that on high traffic, when you e.g. run out low on free RX buffers, sth "Bad" happens
<Grommish> That's my guess, which led me to the ring buffers hehe
<Grommish> Mines a cavium driver, so I'm not enthused about mucking about in there
<Borromini> :P
<Borromini> Grommish: did that Ubiquiti Octeon guy already talk to you?
<Borromini> the one in the forum looking for a paid port
<Grommish> Oh, no.. The ER6 guy?
<Borromini> yeah
<Grommish> Nah, I told him to send me one and I'd work on it, but I doubt he'll want to do that
<Grommish> He was confused about what he even wants to do
<Grommish> but, if he wants to mail me one, I'd work on it and return the device when done
<Grommish> Or, if someone wants to help me with my dnsmasq issue, that would certainly speed up my deve time hehe
<Grommish> not being able to work on the device here is a PITA
hrw has joined #openwrt-devel
<hrw> morning
<hrw> can openwrt be built on non-x86 architecture? (target irrevelant)
<karlp> sure.
<hrw> thanks
<decke> Grommish: I can send you an ER10X if you want to work on something ... (mt7621)
<Grommish> My only experience, such as it is, is with the octeon SoC. But I'm persistent at things. in reality,there are better folks to send gear to for results.
<Grommish> Don't get me wrong, I'd be all for it, just giving you the standard disclaimer
<decke> Grommish: the ER10X is actually an EdgeRouter X but with a 5 Port Switch RTL8367RB for ports 5-9 (via rgmii)
<Grommish> Does RealTek release the drivers?
<decke> Grommish: yeah integrated in the opensource download from Ubiquiti
<Grommish> So whats the bottleneck? What issues are you having building it?
<decke> Grommish: I've started working on it about a year ago - kernel 4.14
<Borromini> decke: what issues are you running into?
<decke> Borromini: the main issue back then was to get an initramfs image for testing which was too big at that time
<Grommish> Do you have the image/Makefile target?
<Grommish> I can build it in about an hour or so if you do
<decke> that issue got solved some months ago - also documented in the edgerouter wiki pages
<Borromini> decke: that sounds a bit weird, the initramfs being too big?
<Borromini> ok so what is the main issue now?
<decke> Borromini: that all the stuff that I have is out of date, old and for a different kernel
<Borromini> you got a dts?
<decke> and that it's my first device to hack on it myself
<Borromini> ok :)
<decke> yeah for 4.14
<Borromini> was that all needed to get the board to work on 4.14?
<Grommish> decke: did you actually start building the target?
<Grommish> I found it
<rsalvaterra> guidosarducci: You're bloating my builds, now I need libbpf in addition to libelf… :P
<rsalvaterra> … and all because of sqm-scripts and tc… I wonder if would be possible to have a "light" variant of tc…
<rsalvaterra> Hauke: ping
<hrw> heh. why openwrt does not produce logs per built component...
<hrw> 'oops, failed. rerun with -j1 V=s and hope for best'
<Grommish> because it runs at $(nproc) by default
<Grommish> and that means the error won't be at the end
<hrw> so does several other build systems
<ynezz> hrw: it does, you need to ask for it
<plntyk> hrw, BUILD_LOG=y config
<ynezz> BUILD_LOG=1
<hrw> tx
<hrw> ok, once it fail, will add it
<ynezz> make foo BUILD_LOG=1 works as well
<decke> Grommish: yes, about 12 months ago https://github.com/decke/openwrt-er10x/actions
caravel has joined #openwrt-devel
<rsalvaterra> ynezz: I can haz "mvebu/omnia: fix the device tree" for 21.02? :)
<decke> Grommish: with some minimal changes (flash layout, console) it is compatible with the regular edgerouter, igoring the 5 upper LAN ports
<ynezz> rsalvaterra: git cherry-pick -x foo; git send-email foo :p
<rsalvaterra> Oh… I had sent it with a note to apply to 21.02 too… :/
<rsalvaterra> I can resend, though.
<Grommish> decke: I've added the target, let's see if it builds, then we can plug in the extra stuff
<Grommish> I copied the ERX target for now
<ynezz> rsalvaterra: I can do it if you give me the commit hash
<rsalvaterra> Sure, let me see…
<rsalvaterra> ynezz: 6fe6b631ef91a8a44d7324329ad6aaec6f08ada6
<Grommish> rsalvaterra: I made a SysBench package for testing and quantifying changes :P
<rsalvaterra> Grommish: SysBench?
<Grommish> It compiles, I jiust need to figure out the install
<Grommish> yar, sytem benchmarks
<Grommish> There has been debate about code and its detriment to my device.. I want to see if its true :)
<rsalvaterra> Well, you can't optimise what you can't measure, that's for sure… :)
<Grommish> Indeed.. I wonder how resource heavy it is..
<Grommish> I jumped to package before I ran it
<Grommish> I want to build the target, then I can add the dts and whatnot
<hrw> ok - package/boot/arm-trusted-firmware-mvebu fetches cross compiler instead of using existing one. so it fails on non-x86
<Grommish> decke: it should build since it's a direct copy of the ER-X.. then we can break it
<Grommish> decke: but I don't have that toolchain built, so I'm going to go do that first
<ynezz> hrw: congratulations, you've just earned corner case badge :P https://github.com/openwrt/openwrt/pull/2521#discussion_r341187914
<hrw> ;D
<hrw> ynezz: just selected same target as I recently did on x86-64 ;D
<hrw> ynezz: espressobin v5 runs nice with 5.10.18 kernel. replaced my ath79 wndr4300
csrf has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
csrf has joined #openwrt-devel
<ynezz> hrw: what do you use as your build host?
<ynezz> clearfog?
Darkmatter66_ has quit [Ping timeout: 240 seconds]
dedeckeh has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
<hrw> ynezz: honeycomb
<ynezz> how long does it take to build the image?
<decke> Grommish: all the dirty secrets how ubiquiti integrated the 5 port Realtek chip can be seen in the GPL download
<hrw> ynezz: need to choose different target ;D
<ynezz> ah, yes
<ynezz> hrw: anyway it would be nice to report that breakage as people still live in their Linux x86/64 only bubbles https://lists.openwrt.org/pipermail/openwrt-devel/2020-October/031694.html
<Borromini> Grommish: please share, so i can run on the erlite too :)
<hrw> ynezz: ath79/wndr4300 then
<ynezz> hrw: don't know how much space/time you've, but can you try it with https://downloads.openwrt.org/snapshots/targets/ath79/generic/config.buildinfo ?
<ynezz> curl https://downloads.openwrt.org/snapshots/targets/ath79/generic/config.buildinfo > .config; make defconfig; make -j$(nproc)
<hrw> ok
<hrw> ynezz: it is more to check how/does openwrt work on non-x86 then for use.
<hrw> ynezz: espressobin works so I do not plan to build updates for it (can fetch from repos) and wndr4300 waits for being reconfigured to be just AP
<hrw> btw - can someone change gcc check to check for <= 4.8 rather than > 4.8?
<hrw> Fedora 34 uses gcc 11
<ynezz> it should be 6+ soon
<hrw> whatever. check 'is it too old' rahter than 'is it new enough'
<ynezz> it's just bunch of regexps defined in include/prereq-build.mk
<hrw> which need changes on each new gcc version
<ynezz> yes
<hrw> which is wrong way
<ynezz> patches are welcome :)
<hrw> ;P
Night-Shade has quit [Read error: Connection reset by peer]
<hrw> ynezz: https://bugs.openwrt.org/index.php?do=details&task_id=3654 - feel free to tell what I wrote/marked wrong
<ynezz> hrw: thanks
<decke> Grommish: and that code uses the rtl8367c driver to integrate the 5 port switch .... which seems to work fine on kernel 5.10 \o/ https://github.com/openwrt/openwrt/tree/master/target/linux/mediatek/files-5.10/drivers/net/phy/rtk/rtl8367c
<Grommish> decke: Ok.. I'm thru the toolchain and building the target, no issues so far, but i don't expect any at this point
<Grommish> If it's in the 5.10 kernel, I'll see what ramips is building for
<plntyk> hrw, regarding gcc change - upstream gcc explicitly mentions versions when bootstrapping - so a "feature detection" does not seem that viable
<decke> Grommish: i'm just looking at the special stuff and that looks promising so far
<Borromini> decke: 5.4 doesn't?
<Grommish> If you can find the patch set for it, I can backport it to 5,4 for testing
<decke> Borromini: don't know, ubiquiti stock fw is still using 4.14
<Grommish> Got all the way to the end and borked :D Lets see why
<decke> so 5.4 might be fine as well
<Grommish> Ok
<Grommish> O
<Grommish> I'll have to see how to call that in the defines
<Borromini> Grommish: the archer c2 v1 uses an external realtek switch as well, if that could help
<decke> Grommish: and there is some code that we don't seem to have in the tree yet which is called rtl8367s
<hrw> plntyk: depends how much time you want to waste on every gcc update? as I did not say 'openwrt needs to change gcc version' but 'gcc version check'
<Borromini> it bypasses the internal 100 Mbps one altogether i think.
<decke> Borromini: correct, that is the same
<hrw> ynezz: did first one locally by hand
<hrw> when it said that my gcc/g++ are not working ok
<plntyk> alternative to version checks are probably doing feature/toolchain checks like buildroot.net does
<hrw> while they compiled hello.c properly
<ynezz> we've now some time until gcc-20
<Grommish> decke: On the dts file, does the 10x have all the partitions the x does?
<Grommish> Except for the 740000 partition?
<Grommish> the ubi partition is larger it loos like
<decke> Grommish: yes, correct - that partition is just bigger because the flash is 512m
<hrw> ah rootfs size
<decke> Grommish: i've digged it out of their GPL code
<Grommish> Gotcha
<hrw> from wrt54gs with 8MB flash and 32MB ram I went (with some other routers on a way) to wndr4300 with 128/128. Now Espressobin has 1GB of ram and 16GB rootfs (as it was smallest microsd card I have)
<ynezz> rsalvaterra: done
<decke> Grommish: for reference you can download the GPL code easily https://www.ui.com/download/edgemax/edgerouter-10x/er-10x
Darkmatter66 has quit [Ping timeout: 245 seconds]
<Grommish> decke: So..
<Grommish> -rw-r--r-- 1 grommish grommish 4237026 Mar 1 07:49 openwrt-ramips-mt7621-ubnt_edgerouter-10x-initramfs-kernel.bin
<Grommish> -rw-r--r-- 1 grommish grommish 4322441 Mar 1 07:49 openwrt-ramips-mt7621-ubnt_edgerouter-10x-squashfs-sysupgrade.bin
<Grommish> With the dts for the er10x
<Grommish> I dunno if it works, but.. eh
<decke> Grommish: did you also take the other changes from my er10x dts?
<decke> Grommish: awesome
<Grommish> on 5.4
<decke> Grommish: so that is about the same state when I left it
<Grommish> Except its 5.4 instead of 4.19 yes
<decke> because it actually did only build the squashfs file and not the initramfs - but I was not brave enough to just flash and break it
<Grommish> You shouldn't
<Grommish> Hold on
<decke> the good thing is the uboot can handle initramfs from TFTP to RAM
<Grommish> Does the ER10x have the vfat partition that it loads the kernel from?
<decke> Grommish: http://sector5d.org/openwrt-on-the-ubiquiti-edgerouter-x.html a bit down to uboot ...
<decke> Grommish: "1: Load system code to SDRAM via TFTP."
<decke> Grommish: that is what we want right?
<Grommish> openwrt-ramips-mt7621-ubnt_edgerouter-10x-initramfs-kernel.bin is the initramfs file
<Grommish> That is what you flash, yes
<Grommish> but
<Grommish> Unless you now how to revive from a brick with that device, I wouldn't
<Grommish> I have no idea if this is going to work or not and i don't want to lose the 7 minutes of sleep feeling bad about it
<decke> Grommish: the device has a proper console port on the front
<Borromini> Grommish: initramfs wouldn't kill it would it?
<Grommish> Good do you have a rj45 rollover:
<Borromini> a lot of ubiquitis have a nice rj45 to serial port
<decke> Grommish: i have a cable for it yes and tested it with the stock firmware
<Grommish> I've got the RJ45 and I'm making breakout headers to attach it to serial pins
<Grommish> You get two adapters per single unit
<decke> Grommish: loading the initramfs should be safe even if it doesn't work properly right?
<Grommish> Borromini: I hesitate to flash any device that isn't mine. THe recovery for mine (and the ER4) is ludiciously easy I forget others don't have it as good
<Grommish> decke: As long as you can return it to stock in case the worse happens, yes it's safe.. uboot would still be there
<Grommish> and that image is just the ER-X rebadged with your dts file included
<decke> Grommish: yeah I assume it would boot and don't detect the upper 5 ports
<Grommish> Well, if the switch driver was introduced in 5.4
mrkiko has joined #openwrt-devel
<Grommish> If it isn't automatic, we can add the kmod call if needed
<mrkiko> Hello all!!
<decke> Grommish: but as I said in the beginning, I'd be happy to send you an ER10X straight away
<Grommish> but given you've already found the .c driver file in the upstream
<Borromini> Grommish: yeah but initrams is meant to be loaded from the bootloader 9 times out of 10 no
<Grommish> Borromini: right, it won't effect uboot regardless
<Grommish> Unless it flashes over the uboot partition, but the only change in the partitions was the ubi size
<Grommish> So that shouldn't be an issue either
<Grommish> decke: I'm always down for the challenge, as I told the guy with the er6
<Grommish> decke: But you've got the knowledge to flash, it shouldn't be any different than testing the ER-X
<mrkiko> Hello all! As you may guess from my ML message I was looking around in the AVM QCA routers. Was wondering what difficulties where being met in booting directly from EVA, and so hat led to the creation of the second-stage u-boot bootloader.
<Grommish> If you brick it, then you can mail it to me
<Grommish> Since you would be without it anyway
<Grommish> mrkiki: I'm not familar with that device :( Sorry!
<decke> Grommish: for longer term - especially getting the upper 5 ports working it would probably be wise if you have one around
<decke> Grommish: "longer term" as in in two days
<Grommish> decke: Eh, maybe, but you should test to see if they work first ;p
<Grommish> I mean, I don't mind hardware.. I'd just setup a new segment
<mrkiko> Grommish: thanks! oh well, this was a generalquestion
<Grommish> mrkiko: You might want to try the Forum (https://forum.openwrt.org/c/hardware-questions-and-recommendations/13)
<Grommish> That's the HW Question section
<mrkiko> Grommish: thanks a lot. Well, you're right. I'm using IRC most of the times since it's more confortable for me to use but I acknowledge it might help to get to the Forum, r maybe posing this same question in ML.
<mrkiko> blocktrron: I guess you tried without u-boot as well ?
<blocktrron> mrkiko: what is your goal?
<mrkiko> blocktrron: oh, currently no specific goal, wanted to learn a little bit how things worked; the device works really great
<blocktrron> yes you can boot them without the U-Boot by appending the DTB to the kernel and enabling legacy booting
csrf has quit [Remote host closed the connection]
<blocktrron> For the NAND models two problems arise: The KErnel is limited to 4M, you have to deal with the dualboot mechanism and the kernel is not stored in UBI, therefor you don't have any wear leveling for the flash at hand
csrf has joined #openwrt-devel
<mrkiko> blocktrron: so using u-boot made things more elegant and clean. Thanks.
<blocktrron> Having the second-stage U-Boot allows us not to deal with AVMs ecosystem
<blocktrron> The non-IPQ devices (lantiq as well as QCA) don't use a second-stage loader.
<mrkiko> blocktrron: Very nice! Thanks. BTW, now VLANs works fine as well.
<blocktrron> good to hear :)
<rmilecki> how can I refresh kernel patches of every kernel?
<rmilecki> *every target
<Grommish> I'm so ready for bed. Night/Afternoon all :) It's 0830 here.. Oy.. Blasted sunlight
<ynezz> rmilecki: probably the easiest way is to use update_kernel.sh from maintainer-tools repo
<rmilecki> ynezz: thanks!
<hrw> ynezz: built.
<hrw> real 71m58,602s
<hrw> user 570m8,730s
<hrw> sys 78m54,594s
<ynezz> hrw: ah, nice, thanks
<hrw> ynezz: note that some sources were already fetched, probably similar for some host tools
<ynezz> still would expect faster time
<hrw> aha
<ynezz> Hetzner CPX41 VPS (8vCPU AMD EPYC 2nd gen) can do that same config in 37mins.
<ynezz> this monster is 16x a72 cores right?
<hrw> yes
<hrw> but monster? it is just mini-itx ;D
<ynezz> well, does it matter?
<ynezz> 16x a72 is 16x a72 :)
<hrw> and it's cooler looks like toy compared to junk cooling my ryzen 5 ;D
<hrw> ynezz: for me it is 'just 16x'
<hrw> ynezz: I am used to higher core count on aarch64
<ynezz> probably should look around for some aarch64 VPS
<hrw> AWS?
samantaz_ has joined #openwrt-devel
samantaz has quit [Ping timeout: 240 seconds]
caravel has quit [Ping timeout: 256 seconds]
<ynezz> I'm avoiding that one, terrible UX :)
<ynezz> but maybe I should try it again with something like terraform
<grift> interesting... only thing that comes to mind is some difference in environment , but not sure how that would be related and how --xattr-include fits in there
<grift> wrong chan
caravel has joined #openwrt-devel
<jow> ynezz: terraform++
guidosarducci_ has joined #openwrt-devel
guidosarducci has quit [Ping timeout: 268 seconds]
guidosarducci_ is now known as guidosarducci
nitroshift has quit [Quit: Gone that way --->]
<rmilecki> oh my, it seems to take ages to refresh all targets
samantaz_ has quit [Remote host closed the connection]
samantaz_ has joined #openwrt-devel
eduardas has joined #openwrt-devel
<ldir-> rmilecki: yes, it's VERY single threaded AND it refreshes the generic patches each time as well.
<ldir-> a big improvement would be to refresh generic once and then refresh each target on top of that.
<Borromini> :)
xback has joined #openwrt-devel
dedeckeh has quit [Quit: Connection closed]
v0n is now known as vdl
shibboleth has joined #openwrt-devel
fracticated has joined #openwrt-devel
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
decke has quit [Quit: Leaving.]
fracticated has quit [Remote host closed the connection]
caravel has quit [Ping timeout: 272 seconds]
caravel has joined #openwrt-devel
<owrt-snap-builds> build #580 of bcm63xx/smp is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fsmp/builds/580 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Sebastian Kemper <sebastian_ml@gmx.net>, Daniel Golle <daniel@makrotopia.org>
<owrt-snap-builds> build #884 of pistachio/generic is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/884 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Sebastian Kemper <sebastian_ml@gmx.net>, Daniel Golle <daniel@makrotopia.org>
dangole has joined #openwrt-devel
<owrt-snap-builds> build #825 of tegra/generic is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/tegra%2Fgeneric/builds/825 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, Sebastian Kemper <sebastian_ml@gmx.net>, Daniel Golle <daniel@makrotopia.org>
<rsalvaterra> ynezz: Thanks!
blogic_ is now known as blogic
<owrt-snap-builds> build #821 of ath79/nand is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/821 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Daniel Golle <daniel@makrotopia.org>
kubrickdave has quit [Read error: Connection reset by peer]
<owrt-snap-builds> build #626 of bcm27xx/bcm2711 is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2711/builds/626 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Daniel Golle <daniel@makrotopia.org>
kubrickdave has joined #openwrt-devel
<owrt-snap-builds> build #611 of bcm27xx/bcm2710 is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2710/builds/611 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Daniel Golle <daniel@makrotopia.org>
<owrt-snap-builds> build #807 of lantiq/xway_legacy is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway_legacy/builds/807 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Daniel Golle <daniel@makrotopia.org>
jmv09 has joined #openwrt-devel
<rmilecki> can we make buildboots execute make -j N V=s || make V=s
<rmilecki> what I mean is doing -j 1 as fallback
<jmv09> xxd can not be downloaded -> openwrt can not be built.
<jmv09> xxd-1.10.tar.gz
<rmilecki> ynezz: jow: ^^ ? -j 1 thing
<Borromini> nbd_: i'm seeing the timeouts and dead radio on MT7613 again (seems to take multiple days now though. 21.02 HEAD. https://0paste.com/218742
<Borromini> this time i'm also seeing hostapd saying 'out of memory' - but free shows plenty available
hrw has left #openwrt-devel [#openwrt-devel]
<Borromini> that's what hostapd says when i'm restarting wifi, that is.
<hurricos> Grommish: You're getting dropped packets because Octeon ethernet drivers are *bad*
<hurricos> Octeon has hardware workqueues and everything, but very few vendors actually use them well and I've only seen then functional on very patched versions of Linux
<hurricos> in fact, in practice octeon mips devices boot linux on one core and have that one core initialize the hardware and spawn Simple Executives on the other cores
shibboleth has quit [Quit: shibboleth]
Darkmatter66 has joined #openwrt-devel
<rmilecki> i've pushed mtd change that last time broke MTD partitioning
<rmilecki> let's hope this time things go clean
<rsalvaterra> guidosarducci: Actually, tc is failing to build here. I don't know what's causing it. Will dig.
Borromini has quit [Ping timeout: 260 seconds]
<lipnitsk> zx2c4: that's some remote debugging you are doing - good luck. Hope we don't have to revert all the work we did...
Borromini has joined #openwrt-devel
<Borromini> Grommish: are you still seeing stack traces with 5.10 on octeon?
<Borromini> from what i can see Adrian's PR is still the same compared to when it first got posted so i'm going to add my stack trace there
<damex> hurricos: i think ubiquiti use that hardware queues on their edgeOS :)
<damex> it is ofcourse heavily patched vendor kernel :)
dannyAAM has quit [Remote host closed the connection]
mwalle has joined #openwrt-devel
koniu has quit [Ping timeout: 268 seconds]
zkrx has quit [Ping timeout: 245 seconds]
dedeckeh has joined #openwrt-devel
<hurricos> damex: sure. Doesn't mean it's practiceable.
<hurricos> or feasible. It was just a little while ago that GKH threw Octeon ethernet out of staging and tried to drown it
<hurricos> and since then? The closest I've seen to honest mainstreaming efforts has been re-hiring Aaron Williamson for their u-boot port. Activity on their ethernet has been *dead*
<damex> hurricos: yeah, it is not. i have had to patch things in to that kernel driver. actually octeon support is horribly split across many places it is not just a simple driver from staging that makes driver work.
<hurricos> right, that's why it was thrown out
<hurricos> but throwing it out of staging is exactly how giants smack patch-based beehives
<damex> and it is <incomplete> with lots of stubs
<hurricos> and OpenWrt cannot afford to maintain a patchstack like what would be needed.
heffer_ has joined #openwrt-devel
heffer has quit [Ping timeout: 245 seconds]
zkrx has joined #openwrt-devel
eduardas has quit [Quit: Konversation terminated!]
mwalle has quit [Ping timeout: 260 seconds]
<guidosarducci> rsalvaterra: there was a pkgconfig issue that doesn't always manifest, try this: https://github.com/openwrt/openwrt/pull/3956
<rsalvaterra> guidosarducci: Later. Seeing if I can put tc through a rigorous diet. :)
<rsalvaterra> Thanks for the heads-up!
<guidosarducci> rsalvaterra: russell-- hit it with ip-full building for oxnas, but my oxnas builds were working.
plntyk has quit [Quit: Leaving]
heffer_ is now known as heffer
[florian] has quit [Quit: Lost terminal]
[florian] has joined #openwrt-devel
<guidosarducci> rsalvaterra: let me know about the diet. I've also looked into any low-hanging fruit, DCE, static linking, but it needs some time investigating.
<rsalvaterra> guidosarducci: libbpf is over 200 kiB on 74Kc -O2. It's just unbearable for my personal config. :/
<Hauke> rsalvaterra: pong
koniu has joined #openwrt-devel
<guidosarducci> rsalvaterra: that's on -O2. It's 80KB normally... "-O2" usually means "size? who cares!" :^)
<rsalvaterra> Hauke: Hi! It was about backporting the Omnia device tree fixes for 21.02, ynezz already merged the commit, thanks. :)
<Hauke> ok
<guidosarducci> rsalvaterra: at one point I tested a 'tc-tiny' build but it didn't save much, but now maybe useful.
<rsalvaterra> guidosarducci: I know, but it's about striking a balance… -Os slaughters the performance on architectures with heavy penalties for misaligned memory accesses.
<Borromini> rsalvaterra: what are such architectures?
<rsalvaterra> guidosarducci: And I could almost get rid of libelf too… if it weren't for ipset. :P
<guidosarducci> rsalvaterra: for your custom build why don't you just manually disable libelf and libbpf?
<rsalvaterra> Borromini: Well, MIPS, for example. :P
<guidosarducci> rsalvaterra: for the last 30 years most MIPS tools have been very careful about alignment...
<rsalvaterra> guidosarducci: That's what I'm doing, but having a tc-minimal/tiny/basic/whatever would probably be useful for other people too, not just me. :)
<rsalvaterra> guidosarducci: I don't know… dangole has some horror stories about the general state of the MIPS toolchain… :/
<Borromini> rsalvaterra: ok :P
* Borromini is the heretic that has optimised openssl for size on mt7621
<rsalvaterra> Borromini: Yeah, about optimising OpenSSL for size… you might want to have a look at my tree. :P
jmv09 has quit [Quit: Connection closed]
<rsalvaterra> I haven't sent the series for fear of persecution by the Portuguese Inquisition. :P
<owrt-snap-builds> build #666 of layerscape/armv7 is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/666 blamelist: Rafa? Mi?ecki <rafal@milecki.pl>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sebastian Kemper <sebastian_ml@gmx.net>, Daniel Golle <daniel@makrotopia.org>
<guidosarducci> rsalvaterra: I hear they're not as bad as the Spanish...
<Borromini> rsalvaterra: thanks, will check that out
<rsalvaterra> guidosarducci: Sure, but I'm Portuguese. :P
<guidosarducci> rsalvaterra: Todo bom!
<rsalvaterra> Tudo óptimo! ;)
<guidosarducci> rsalvaterra: I'll dig up my old tc-tiny stuff... (and I forgot most Portugese, and it was Brazilian)
<rsalvaterra> guidosarducci: Alright, it'll probably be useful, thanks.
Lipton_lan has joined #openwrt-devel
<Lipton_lan> Hey! How can I invite a friend to our project? He has no access through the github.
<grift> hi Lipton_lan: thank him in advance and tell him to send his git patch contributions (see https://git-send-email.io/) , ensure they are signed off by: (see https://www.kernel.org/doc/html/v4.10/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin) to the openwrt-devel mailing list (see https://lists.openwrt.org/mailman/listinfo/openwrt-devel)
<grift> in other words there are no invitations, invite yourself. contribute to gain influence
shibboleth has joined #openwrt-devel
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
<grift> regardless of what some thing free software communities arent social clubs, free software is about scratching an issues, the communities are just people that share the itch to scratch, and so its a meritocracy to more you do the more credits you get to spend (do steering)
<grift> s/issues/itch/
<grift> as a matter of fact most here are probably pretty anti-social :-P
plntyk has joined #openwrt-devel
kubrickdave has quit [Ping timeout: 245 seconds]
kubrickdave has joined #openwrt-devel
<Lipton_lan> Why deprive the community of the opportunity to contribute? Why have you removed the registration option?
<grift> they havent
<grift> github is and always was nothing more than a glorified mirror , as for the wiki: registrations require an administrator due to spam issues
caravel has quit [Quit: Konversation terminated!]
junland has quit [Quit: %ZNC Disconnected%]
<grift> you see some people live(d) in the past thinking that everything is/was still as it used to be in the early day's. these day's you cannot do self-registration anymore because it is abused like everything else on the internet
<grift> you open up registration and your site gets spammed into oblivion these days theres no mercy
junland has joined #openwrt-devel
<grift> so you just need to contact an administrator to add yourself to the wiki
<ynezz> Lipton_lan: just /msg me his desired username and email, I'll create the account
<Lipton_lan> thank! He was offered the same on #openwrt
hsp has quit [Read error: Connection reset by peer]
hsp has joined #openwrt-devel
<grift> and that is also why we need MAC, things changed and if we dont change with it then "failure is inevitable". think about that prospect
<grift> this isnt just "personal failure" this is failure of the industry and even the technology as a whole
<grift> and since we rely on it so much: failure of societies
<grift> etc
<grift> today it might be spamming a wiki, tomorrow it might be contributing flawed and malicious code that can harm the whole project and everyone using it
<grift> a good example is the supply chain debable with solar winds
<grift> anyway ignorance is bliss
Lipton_lan has quit [Quit: Connection closed]
<grift> *crickets* we need to talk about it because affects us all. stop looking away. youre relying on technolgies dating back to the 60's. some of us probably werent even born yet but the signs are all around us. ip4 is way outdated and even the nat patch is not enough anymore, you think thats the only aspect of the stack that is way out of date?
<grift> just saying this isnt a darpa project anymore, this is everywhere now
<Grommish> Borromini: I haven't checked yet :(
luke-jr has quit [Ping timeout: 276 seconds]
luke-jr has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Borromini has quit [Ping timeout: 264 seconds]
Borromini has joined #openwrt-devel
black_ant has quit [Ping timeout: 264 seconds]
fracticated has joined #openwrt-devel
<fracticated> Does the openwrt build do something different with netlink permissions w/ IPv6? I'm trying to do an "openvpn --show-gateway" and get a permission denied message for IPv6 that I don't get on a standard build. See: https://pastebin.com/GabAbkGP
<grift> not my field but since no one else replies for now, i would argue that the -EACCES is probably misleading, its probably instead either just something missing (no supported in the built) or the link is not up or whatever
<fracticated> grift: thx, I figured something missing but I've tried most IPv6 options I can find. I'm going to try on an x86 build to see if it is something arch related
dedeckeh has quit [Quit: Connection closed]
<Borromini> fracticated: i don't know what user openvpn is using but openwrt has been moving to a more privilege based approach instead of the old single user/everything root stuff
<grift> Borromini: not sure what you referring to but the seccomp, user stuff done by dangole seems not related to this
<grift> not to mention that its opt-in (as selinux is) so unlikely related
<grift> its not uncommon to see inaccurate error codes
<grift> for example i see permission denied issues all the time with unbound, while the link it down. its not that unbound doesnt has access, its just that the link is down
<Borromini> grift: i was just referring to limited privileges because a lot of services run as their own user instead of root. anything else than that basic privilege separation is above my paygrade :)
ivanich_ has joined #openwrt-devel
<grift> from what i can tell openvpn runs as root AFAICT
ivanich has quit [Ping timeout: 245 seconds]
<fracticated> grift: yes, that's right. it seems to be something with IPv6 - it can read the IPv4 routing table just fine
<fracticated> I figure I'm missing a package or something like that
<grift> or a kernel feature /module
<grift> or even it might just be misconfig, but i dont doubt your ability to configure it properly
<grift> just saying that the -EACCES might not be accurate thats all
<Borromini> a configure switch for ipv6 support maybe?
<mangix> target/linux fails to compile
<mangix> lovely
<rsalvaterra> mangix: How? Where?
fracticated has quit [Remote host closed the connection]
<mangix> some patch was not refreshed
<rsalvaterra> Oh, that's a easy one, fortunately. :)
<mangix> fatal error: sys/cdefs.h: No such file or directory
<mangix> ffs
<mangix> this autoconf-lean change is causing all sorts of failures
rmilecki has quit [Ping timeout: 276 seconds]
<rsalvaterra> guidosarducci: I've got a working tc-tiny here.
<rsalvaterra> (Not linked against libbpf, basically.)
<mangix> this autoconf-lean thing is very libc specific
<mangix> the current config is not applicable to glibc for example
koniu has quit [Ping timeout: 268 seconds]
<guidosarducci> rsalvaterra: yes, it's possible, I dusted my old stuff off too. There's some trickiness too, don't be fooled by too easy! :^)
<guidosarducci> rsalvaterra: have to be carefull with shared lib support, reorganizing the variants, and there's a hotplug script we wanted to move out since a long time ago.
<rsalvaterra> guidosarducci: Devil's always in the details… ;)
<guidosarducci> rsalvaterra: that's what I worry about after sort of adopting the package... As a test you should try installing both tc-tiny and tc-full together, which should be possible/supported.
koniu has joined #openwrt-devel
<rsalvaterra> guidosarducci: Nope. I made them conflict and declared tc (didn't rename it for compatibility reasons) provide tc-tiny.
<guidosarducci> rsalvaterra: fine for you, not so much everyone else :-)
<rsalvaterra> guidosarducci: Hm… why is that so? :P
graphine has joined #openwrt-devel
<mangix> Hmm json-glib breaks with BUILD_NLS. Guess I need to fix gettext-full...
<rsalvaterra> guidosarducci: Just looked at the script… is anyone actually using sch_teql…? o_O
<graphine> there is a problem building with glibc, due to new autoconf-lean not finding xnet, I had to set ac_cv_lib_xnet_main=${ac_cv_lib_xnet_main=no}
<rsalvaterra> guidosarducci: Hmm… https://dev.archive.openwrt.org/ticket/11192
<mangix> bfstools failed to compile again...
<mangix> oh that's new
<mangix> unresolvable R_PPC_REL24 relocation against symbol `ftell'
Borromini has quit [Quit: leaving]
<mangix> oh I see. I don;'t want to deal with this.
<guidosarducci> rsalvaterra: see discussion in https://github.com/openwrt/openwrt/pull/1627#issuecomment-447923636. General consensus is to move teql hotplug to kmods. I didn't do it at the time since tc wasn't split.
<guidosarducci> rsalvaterra: but have to revisit it now... Would really like to see this iproute2 in 21.02 for the improvements, but wary about the "tc-tiny" can of worms.
<rsalvaterra> guidosarducci: Well… that problem is solved if you don't allow both variants to coexist. Featurewise, tc is a superset of tc-tiny. :)
<rsalvaterra> Let me push this out, I'll show you…
shibboleth has quit [Quit: shibboleth]
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
Tost has quit [Ping timeout: 260 seconds]
graphine has quit [Quit: Leaving]
<mangix> can't figure out the issue with bash
<mangix> oh well
m4t has quit [Quit: m4t]
m4t has joined #openwrt-devel