<stintel>
/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-11.2.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/11.2.0/../../../../x86_64-openwrt-linux-musl/bin/ld: /usr/lib/libgmp.so: error adding symbols: file in wrong format
<stintel>
next host leak
<stintel>
ffs
<Tusker>
btw, did you get the LCD panel working on the M300 ?
<aparcar[m]>
stintel: if you want me to test some stuff with buildbot like settings give me the config options and I run it through my github ci
<mangix>
stintel: still have that special setup Isee.
<Tusker>
ok, looks like no LCD on the m300 :| ignore the question
<stintel>
mangix: there is nothing special about having libgmp installed in a host system ¯\_(ツ)_/¯
<enyc>
I was hoping somebody would give me a $clue on the Interface Config changes between 19.07(.8) and 21.02(.1) -> specifically, in LuCI Network->Interfaces LAN->Edit ... in General Settings when in (default) mode "Static Address" -- all the boxes to set IPv6 address etc. are missing now, only appear if creating a 'new' interface. Not at all clear if this is a deliberate development change.
<enyc>
... may be possible to play games with assignment-hints and so-on but this (appears) to be a regression in 21.02.x unless there is some article explaining loss of explicit address-setting etc.
strobo_ has joined #openwrt-devel
strobo has quit [Ping timeout: 480 seconds]
isinyaaa has quit [Quit: WeeChat 3.3]
musashino has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
Tusker has quit [Quit: Hey! Where'd my controlling terminal go?]
victhor has quit [Ping timeout: 480 seconds]
fda has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
philipp64 has joined #openwrt-devel
<philipp64>
Anyone know what's required on x86 hardware to get an external (SFP) PHY recognized? I have an SFP plugged in by the system isn't seeing it...
<enyc>
philipp64: I suspect the nic-type matters.... but can't comment further on the topic myself.
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<dwfreed>
is a driver loaded for the card?
<dwfreed>
lspci -k
<dwfreed>
does dmesg/logread (if openwrt) complain about missing firmware for the card?
valku has quit [Quit: valku]
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
rmilecki has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tusker has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<rmilecki>
thank you ynezz, pushed
<dwfreed>
rmilecki: since you're around, could you update the topics to mention the 21.02.1 release?
<dwfreed>
here and the main channel
<rmilecki>
oh, weird, I was asked by Hauke but then someone wrote he handled that
<rmilecki>
or so i thought
<dwfreed>
I said I could do it as well, but nobody asked me to
<dwfreed>
Generally staff only use their privileges in time of need
<mrkiko>
rmilecki: ehehe, I remember days where we patched the bootloader directly in ar7 if it matched some checksums ... we are wild, you know! :) :)
<mrkiko>
rmilecki: rmilecki: was talking about Asus RT-AC88U mail thread :D
<rmilecki>
mrkiko: ;)
danitool has joined #openwrt-devel
digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
<mrkiko>
rmilecki: sorry, I promised I was going to test bcm47xx but didn't do it yet, sorry
digitalcircuit has joined #openwrt-devel
<rsalvaterra>
PaulFertser: ldir, probably?
<PaulFertser>
rsalvaterra: thank you, I'll try talking to him when he's around.
musashino has quit [Ping timeout: 480 seconds]
<stintel>
mangix: strace ?
user3586 has joined #openwrt-devel
<mangix>
yeah. so the gnutls package installs bad stuff to staging_dir/host and messes up compilation of other packages including strace
user3586 has quit [Remote host closed the connection]
Tusker has quit [Quit: Time wasted on IRC: 3 hours 53 minutes 47 seconds]
<stintel>
haven't seen that
<mrkiko>
rmilecki: so bcm switching to u-boot, should I expect better or worse BCM support?
<rmilecki>
mrkiko: in long time better I hope
<rmilecki>
mrkiko: at least u-boot is something that can be modified
<rmilecki>
mrkiko: of course u-boot source with Broadcom modfication will be a huge mess i'm sure
<rmilecki>
i'm still waiting for vendors to release GPL packages with Linux & U-Boot sources
<mrkiko>
rmilecki: if one day we'll meet in person in front of something hot to drink or whatever, I would like very much you to explain me how the jffs2 stuff worked. that fact the files are named incrementally and so on, cferam.001, 002... never got it
<rmilecki>
but I'm sure Broadocm put half of their sdk in U-Boot and then put tons of hacks to integrate it ;)
<rmilecki>
mrkiko: sure :)
<rmilecki>
we really need a summit
nitroshift has quit [Read error: Connection reset by peer]
<mrkiko>
rmilecki: it would be beautiful. I'll try my best to be there. I'mnot such a huge cntributor but I really apreciate openwrt
<mrkiko>
actually, the only board where CFE was friendlier to me is a bcm47xx with RS232
<rmilecki>
mrkiko: doesn't matter if you contribute when meeting & having a beer ;)
<mrkiko>
rmilecki: :D :D
<enyc>
bah, trying to ask about ?bug?/difference with LuCI Network->Interfaces LAN->Edit in 21.02.1 compared to 19.07.8 in #openwrt, I'd like a -dev clue about this apparent difference (ipv6 static settings gone awol entirely unless you create a 'new' interface)
<enyc>
\x in #openwrt just confirmed seeing exactly same thing on 21.02.1 etc
<enyc>
please =) Some dev's give us a $clue =)
nitroshift has joined #openwrt-devel
victhor has joined #openwrt-devel
Tapper has joined #openwrt-devel
<stintel>
enyc: I'd expect the combination of people that use luci and static IPv6 addresses are very limited. I myself know close to nothing about luci, the only reason I have it is for the fancy realtime graphs so can't help you
<stintel>
enyc: if you're sure it's a bug and not some browser (cache) issue, maybe just report it on the luci gh
<enyc>
stintel: I am not *yet* *sure* its' a bug because I'd like to know from dev's in the know -- if there is a deliberate design-decision here to hide that section by default for LAN interface, or some new decision about how IPv6 delegation and address setting supposed to work.
<enyc>
stintel: I'm not *sure* how to go about finding out if there is some deliberate/intended change there.
<rsalvaterra>
stintel: You need LuCI for that? Isn't there a way (some kind of RPC API) to retrive the required data from the router and generate fancy charts locally?
pmelange has joined #openwrt-devel
<enyc>
maybe jow and so-on may come on and enlighten us sooner or later =)
<stintel>
enyc: I guess that's your best bet. please practice some patience, something with life and kids ;)
<Tapper>
Hi how to fix my wifi on my r7800. Flashed latest master and am getting this in my logs.
<Tapper>
Thu Nov 4 09:27:29 2021 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) --> new PHY
<Tapper>
Thu Nov 4 09:27:29 2021 daemon.err hostapd: Line 63: unknown configuration item 'qos_map_set'
<Tapper>
Thu Nov 4 09:27:29 2021 daemon.err hostapd: Failed to set up interface with /var/run/hostapd-phy0.conf
<Tapper>
Thu Nov 4 09:27:29 2021 daemon.err hostapd: 1 errors found in configuration file '/var/run/hostapd-phy0.conf'
<stintel>
nbd: seems like you introduced a default for that in a5e3def1822 - can you have a look ^ ?
<stintel>
probably not supported in some of the variants
<enyc>
stintel: yes, luckily I'm not in a hurry to configure the new router swap-over etc
<stintel>
Tapper: for now, comment out this line in /lib/netifd/hostapd.sh: set_default iw_qos_map_set 0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
<nbd>
stintel: i'll make a patch to move it out of #ifdef CONFIG_INTERWORKING
<nbd>
because the feature makes sense without interworking
<enyc>
stintel: I've been asking on-and-off over a day, sounds like I'm asking a very sensible/relevant -dev change question too. I like your point that static IPv6 + LuCI limited userbase.
<Tapper>
OK thanks
<stintel>
nbd: sounds good, thanks
<Tapper>
stintel Thanks for your help. I went to bed after flashing a new build. My pc is wired and I did not check wifi lol.
<stintel>
hehe my apartment would start misbehaving badly without wifi
<stintel>
Tapper: welcome
<Tapper>
The wife and kids got up and then came and got me out of bed with no wifi lol
<stintel>
rise and shine :D
<Tapper>
Yeah same here lots of smart things. That are not so smart.
<rmilecki>
what is the first choice after closing WikiDevi now?
<mrkiko>
digitalcircuit: digitalcircuit: am I wrong or it was you working on some issues of the nbg6617 ? The device build is being disabled in the ipq40xx switch to 5.10. Maybe you can help out?
robimarko has joined #openwrt-devel
<robimarko>
Its disabled due to kernel size limit
<mrkiko>
robimarko: sure, just wanted to inform him since I seen he was working on it
<mrkiko>
robimarko: very nice to meet you here, I'm following th github thread
shibboleth has quit [Quit: shibboleth]
<mrkiko>
robimarko: well, do you think there can be a workaround??
<mrkiko>
robimarko: apart from intermediate bootloader?
<mrkiko>
robimarko: I guess the answer is no from what I know
<robimarko>
mrkiko: zImage is an option if the bootloader supports it
<robimarko>
Then you can XZ compress the kernel, it doesnt get much better than that
<mrkiko>
robimarko: I was thinking about a more future-proof solution, with something intermediate loading the kernel on it's own later. sure, no trivial task...
<robimarko>
mrkiko: Well, that would require porting/rewriting the LZMA loader for IPQ40xx
<mrkiko>
robimarko: maybe I am saying a very stupid thing here, but ... is the approach used for the 7530 and 4040 a viable solution here? Or, in other words, may we reuse something of that before going the LZMA loader road? Using a second-stage u-boot?
<robimarko>
mrkiko: That could work, but to me it doesnt look like a proper solution
<mrkiko>
robimarko: due to the fact it will need more work in the long term to port the u-boot to enough different hardware? the proper one would be the LZMA loader ? How hard do you estimate it to be?
<robimarko>
Yeah, some kind of intermediary loader like LZMA loader could be the solution, no idea how much work it would take
<nbd>
stintel, Tapper: hostapd fix pushed
<stintel>
nbd: thanks for heads-up!
Tapper has quit [Ping timeout: 480 seconds]
<rsalvaterra>
Has anyone around here done any mklibs builds recently? :/
<stintel>
rsalvaterra: I was actually using netdata at some point, but that was causing issues (refused to shut down, causing delays during reboot) so I ditched that
<stintel>
also don't like the cloud requirement for some features
robimarko has quit [Quit: Page closed]
<rsalvaterra>
What do you use now, rrdtool?
<stintel>
well for realtime, luci ;)
<stintel>
but for history, observium
<rsalvaterra>
Observium?
* rsalvaterra
googles it…
<rsalvaterra>
Oh…!
<stintel>
tried to migrate to librenms but that's... telling me to chown -R librenms /opt/librenms and then tells me to configure PHP to run as librenms
<stintel>
which is, ehm, yeah, don't do that
<rsalvaterra>
LOL
<rsalvaterra>
I have… opinions… on PHP.
<stintel>
don't we all :)
<rsalvaterra>
xD
<stintel>
but yeah librenms is forked from observium because people don't like the observium lead dev I believe :P
<stintel>
but at least observium doesn't require me to use php composer or tell me to do stupid things
<stintel>
I also have icinga2 with carbon (iirc) backend
* rsalvaterra
is trying to understand why mklibs isn't doing jack…
<rsalvaterra>
I'll probably have to nag dangole about it, since he seems to use it (ported it to Python 3, at least)…
<rsalvaterra>
When it worked, it reduced my build sizes by a non-trivial amount.
dangole has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
valku has joined #openwrt-devel
Andi_ has quit [Remote host closed the connection]
Andi_ has joined #openwrt-devel
ashkan has joined #openwrt-devel
mirko has joined #openwrt-devel
musashino has joined #openwrt-devel
minimal has joined #openwrt-devel
fda- has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
nitroshift has quit [Quit: Gone that way --->]
notlistening has joined #openwrt-devel
<notlistening>
Hi all, just moved to 21.02.1 on my linksys WRT 32x and I am finding that on every reboot that all the settings / ssh keys etc are not persisting. Doesn't look like the overlay is saving to disk. Any ideas / solutions to this? I have searched on this this problem and also asked next door in the main channel..
<stintel>
notlistening: small flash device ?
<stintel>
probably not enough space left to create the jffs2 overlay and tmpfs is used instead
<rsalvaterra>
Another one who downgraded from master to 21.x… :P
<rsalvaterra>
Sun Oct 24 09:01:44 2021 kern.err kernel: [ 8.050219] UBIFS error (ubi0:1 pid 975): 0xc0341584: 'compressor "zstd" is not compiled in
<rsalvaterra>
notlistening: Sorry about that, but now you have to do a complete wipe (first_boot). After that, the overlay should mount fine.
<stintel>
well that was fast :)
<rsalvaterra>
stintel: Yeah, someone in the forum complained about it a while ago… this issue had the same smell.
<stintel>
should we backport that to 21.02 ?
<notlistening>
Ah yeah that would be me :) I took the change the the latest snapshot would be stable, i knew there was a risk :)
<notlistening>
*chance
<rsalvaterra>
stintel: People running master builds should know what they're doing. Risking instability in 21.02 to cater to a minority shouldn't be the way to go…
<rsalvaterra>
notlistening: Yeah, we try to keep things stable in master, of course, but sometimes there are unexpected interactions, especially when downgrading. ;)
<notlistening>
Don't pander to the few ;) I should know better
<rsalvaterra>
The issue you've hit was "caused" by me.
<rsalvaterra>
I set the ubifs overlay compression to zstd, by default, since it was always available and has the best overall performance.
<rsalvaterra>
However, that wasn't true in 21.02.
<rsalvaterra>
When downgrading do 21.02, ubifs complained, and rightly so, for not being able to find the zstd compressor.
<rsalvaterra>
(Needed to mount the overlay created by the master build.)
<enyc>
... OK now I have another confirm in #openwrt thath the IPv6 settings in Network->Interfaces->LAN->General Settings with Static adderss are messing, but appear if create a new interface.
<enyc>
I wonder which devs may have a $clue if this is some intentional or accidental change in code
<mrkiko>
I would like to revive the work on the GL-B2200 and I downloaded the patch from github.
<mrkiko>
How do I understand at what commit the patch should be applied?
<mrkiko>
possibly from command-line
Ansuel_ has joined #openwrt-devel
<Ansuel_>
Hi
<mrkiko>
Ansuel_: hi!! you can help me I know :D :D
<Ansuel_>
o.o
<Ansuel_>
let me read the backlog
<mrkiko>
Ansuel_:
Ansuel has quit [Ping timeout: 480 seconds]
<mrkiko>
Ansuel_: no backlog in irc
<Ansuel_>
what do you mean with at what commit ?
<mrkiko>
Ansuel_: all the backlog is in github; I should just address the inline comments - which are that 1) leds should have names like "color:function" in their labels, like "blue:power" and not "power:blue"
<mrkiko>
and 2) compatible string. I addressed both of them in the .diff directly, need to apply to github and rebase it or something
<Ansuel_>
anyway i started crazy idea of testing ipq806x on 5.15 does anyone started the port?
<Ansuel_>
mrkiko ok ? so tell me where do you need help
<mrkiko>
s/apply to github/apply to my local git tree/
<svanheule>
mrkiko: you could add the original author's github repo to your remotes, and then clone their branch to start from there
<mrkiko>
Ansuel_: I have the .diff and a copy of the master tree. But the diff won't apply anymore. I was trying to understand at what commit I should move to have the .diff applicable by "git am"
<mrkiko>
and then starting to rebase it
<Ansuel_>
mhhh you can consider using gi am --reject with the patch
<Ansuel_>
and check what part is rejected
<Ansuel_>
then follow instruction from console and add the related files so you can fix what am rejects
<mrkiko>
svanheule: thanks! It's a good idea.
<Ansuel_>
or clone and rebase
<mrkiko>
Ansuel_: ok, clone and rebase doesn't seem an option since in the page of the original author I can't find the repo
<mrkiko>
oh, found
<mrkiko>
ok
<mrkiko>
I'll try this out
Andi_ has quit [Ping timeout: 480 seconds]
Andi_ has joined #openwrt-devel
<jow>
enyc: what ipv6 settings?
<enyc>
jow: ability to explicitly set IPv6 address... uerr 1mo will show pictures somebody in #openwrt took
<jow>
assumption is that static ipv6 addressing interferes with prefix delegation
<enyc>
jow: ooooo this is different to 19.07.8 and nonobvious
<jow>
if it is indeed a valid and *working* configuration then it is trivial to change
<jow>
I can't test though
<enyc>
this is network with static assignments incl upstream
<Ansuel_>
funny with 5.15 backport dir is reduced to only 3 patch
<Ansuel_>
or 4 as I still need to check the kbuild one... but i think it can be dropped
<jow>
enyc: so setting a static ipv6 address *and* having something like option ip6assign 60 works fine? interface gets static address and ula prefix chunk and upstream prefix chunk assigned?
<enyc>
jow: well mine was all static routing without relying upon dhcpv6....
notlistening has quit [Quit: Leaving]
<enyc>
dating back to 10.03.1 days etc
<jow>
then disable / remove option ip6assign 60 and you should get the expected behaviour
<enyc>
jow: I could imagine situation where you would want explicit IPv6 address/pricfix an this interface AND want dhcpv6 prefix subdelegation to co-exist
<enyc>
e.g. have multiple static addrsesse or whatever
<jow>
displaying those static ipv6 options despite ip6assign will be confusing as well unfortuantely
<jow>
they're very prominently placed and blank
<jow>
which means many users will assume they have to be filled out
philipp64 has joined #openwrt-devel
<jow>
then you need to explain that they don't need to get filled out
<jow>
then they complain that this is unintuitive
<enyc>
jow: can they not be 'hidden by default' or something, ar an explanitoin given that to set ipv6 address satitcially you normally don't want the xyz
<stintel>
hide them behind "advanced" or "expert" checkbox ?
<jow>
I'd rather cater for the 80%
<enyc>
jow: what about "static adderss" or "static address with IPv6 static" or some other way
<jow>
if you're in the 20% group needing static addresses but no ip6assign, then disable ip6assign
<jow>
well, as you notice, we're already complicating it even further for all users
<enyc>
jow: there could at least be a "ipv6 not shown because of ip6assign" sort of message
<enyc>
link to reference doc or whatever
<jow>
I understand the use-case
<jow>
but that's a bit like having a DHCPv4 interface and wanting a static IPv4 IP as well
philipp64 has quit [Quit: philipp64]
<jow>
for IPv4 one would simply create an alais interface targetting the same l3 device
philipp64 has joined #openwrt-devel
<jow>
set proto to static and add whatever IPs are needed
<enyc>
oh, I was thinking the ip6assign was about downstream assignment
<enyc>
like, being able to prefix-delegate to downstream clients
<jow>
it also effectively controls which IPv6 addresses the interface gets
<enyc>
jow: it should be possible to set static address *on* this interface *and* have it dhcpv6-PD to downstream from here
<jow>
yeah, but why should it be possible for IPv6 and not for IPv4 ?
<enyc>
jow: maybe you are saying that isn't an issue wit ip6assign turned off
<enyc>
jow: IPv4 is different, doesn't do Prefix delegation
<enyc>
you tend to daisy-chain-NAT or other routing protocol instead
<jow>
well as you might have noticed, I have neither motivation nor time to spend effort changing this
<jow>
I will review PRs providing specific suggestions on how to improve it
<enyc>
to be clear (which may be where we are getting confused) I'm thinking dhcpv6-SERVER not -client which is where i think we might be talking cross-wires
<jow>
there are other ways to achieve the same, e.g. making an alias interface (like lan6) with proto static and no ip6assign
<jow>
I understand that some people need this
<philipp64>
jow: what's a global way of detecting if IPv6 is absent (uncompiled or unconfigured) on a box? I need to detect if `named` needs to be run with `-4` or not to avoid filling the log files with a lot of noise about not being able to resolve AAAA requests, etc.
<jow>
but so far I am not convinced that those that need it are the vast majority
<philipp64>
since we're on the subject...
<enyc>
philipp64: even if box is fully IPv4 connectivity, it can still resollve AAAA records, jsut getting the inforamtion via IPv4-transit
madwoota has quit [Read error: Connection reset by peer]
<jow>
philipp64: bind to an ipv6 address and check errno == EAFNOSUPPORT
<enyc>
philipp64: also boxes with IPv6 uncompiled will be rather rare, lots of daemons rely on it being there and using the ipv4-compatibilty iof the socket api etc. aiui
<jow>
philipp64: however I also do think that catering for "no ipv6" use cases in 2021 is anachronistic
<jow>
any sane environment should at least provide a proper ipv6 loopback setup
<philipp64>
many ISPs in the US and Canada are anachronistic...
<jow>
and v4 mapped socket handling
<philipp64>
but it's still a huge number of users.
<jow>
I am not talking about IPv6 global connectivity
<jow>
but about "systems lacking IPv6 support"
<enyc>
philipp64: the end user box will still be ipv6-supporting, just not the ipv6 access ....
<philipp64>
so there's IPv6 link scope addresses, but they're useless for name resolution, etc.
<jow>
why?
<jow>
what is the actual problem you're trying to solve?
<philipp64>
I haven't dug into it, but it looks like Bind might be trying to use IPv6 to resolve IPv6 addresses...
<jow>
what is the effect of `-4` in named?
<philipp64>
trying to not get the logs to fill up with a bunch of useless warnings.
<jow>
shouldn't named be changed to stop these useless warnings?
<enyc>
philipp64: I think that assumption is wrong, both A and AAAA pointers are happily priveded (often simultanteusyl in response to ANY query) over whatever transit
<jow>
maybe I misunderstand the problem
<philipp64>
I'll see if I can dig out some warnings and paste them in.
<jow>
ok
<philipp64>
probably not today, however.
<enyc>
jow: thankyou for initial answer/consideration, i'll need to check my facts / test / ettc =)
<philipp64>
first I need to figure out the SFP issue.
<enyc>
jow: what I may also want to have is a box/consumer-router / other-openwrt that can 'recieve' a dhcpv6-pd to pair with this
<enyc>
then I can sort this out properly, etc etc =)
<jow>
I think a system which simply happens to have ipv6 support (as in having IPv6 LL on its interfaces but no GUAs) but no IPv6 connectivity (as in default route or any global unicast route) with a standard setup of named should just work without having to use stuff like `-4`
<jow>
but maybe named is confused by the ULA addresses
<jow>
picks those up and tries to do stuff with them
<enyc>
jow philipp64 +1 I have seen OSes (e.g. might have bene a windows vista laptop or something) frustrated by ULA addresses and just removing them entirely on router sorted it, that could easily cause problems... I would question if it also is picking up a *default IPv6 route* along with the ULA or just a route to the ULA-ranges .......
<enyc>
jow philipp64 : furthermore +1(a lot) definitely completely normal to have IPv6 LinkLocal and just no IPv6 connectivity/addresses , that is no surprise at all etc.
hitech95 has quit [Remote host closed the connection]
<slh>
mrkiko: digitalcircuit is working on the nbg6817, ipq8065 - not nbg6617/ ipq4018; as a quick workaround, I'm pretty sure that you could change the kernel size in ubootenv for the nbg6617 (and then bump the kernel limit accordingly) - that should be easy and work, but it's a tad difficult for new users <-- they would have to install an old OpenWrt version first, use fw_setenv to change the bootloader
<slh>
kernel size and then upgrade
<Ansuel_>
any help with kernel depns in kernel modules?
<Ansuel_>
having a hard time understanding the logic
Borromini has joined #openwrt-devel
goliath has joined #openwrt-devel
<Ansuel_>
any idea how to handle ko provided by 2 different kernel config?
<Ansuel_>
(they unified netfilter log ko)
Ansuel has joined #openwrt-devel
<Ansuel>
aaand serial doesn't work...
Ansuel_ has quit [Ping timeout: 480 seconds]
<mrkiko>
Ansuel: mhm, withous serial is hard
<Ansuel>
ethernet works
<Ansuel>
they probably change serial output again in 5.15
Tapper has joined #openwrt-devel
<Ansuel>
Linux version 5.15 (ansuel@Ansuel-xps) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 11.2.0 r17393-57807f50de) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 SMP Tue Sep 7 11:23:16 2021
<Ansuel>
problem is that cpufreq is broken (rpm problem?) and no serial output but the log seems more or less clear
<Ansuel>
ok cpufreq fixed but still no idea how the no serial output
<Ansuel>
i invoke
<Ansuel>
robimarko
<Ansuel>
while i think of a solution i will publish all the work
<hauke>
Ansuel: when do you plan to rebase the ipq806x: add dsa support pull request?
<Ansuel>
there are conflicts?
<hauke>
yes
<Ansuel>
let me check
<hauke>
I would like to get this into master soon
ashkan has quit [Remote host closed the connection]
<Ansuel>
oh ok hauke i just rebased but i think we still need to understand what to do about that hack of the eth swap
<Ansuel>
or the drop of asrock g10 that set the mac in preinit
<hauke>
ok
<Ansuel>
i also dropped the 2 swconfig flag from the config file
minimal has quit []
<Ansuel>
if you can give it a quick check
dedeckeh has quit [Quit: Page closed]
Ansuel_ has joined #openwrt-devel
<slh>
Ansuel: the question about that g10 hack has been resolved, it's not needed - the intention was to ensure setting the right MAC addresses even in the failsafe environment, so no real need
<slh>
there's no need for it to do anything else than any other ipq806x device
Andi_ has quit [Ping timeout: 480 seconds]
madwoota has quit [Read error: Connection reset by peer]
<hauke>
Ansuel_: you can also remove ETHERNET_PACKET_MANGLE again
<Ansuel_>
done
<hauke>
what is still open?
<stintel>
hauke: did you see my gdb issue after 11.1 bump?
<stintel>
hauke: it's trying to use my host's libgmp
<hauke>
stintel: no
<stintel>
I have to revert to be able to build
madwoota has quit [Read error: Connection reset by peer]
<stintel>
did some digging already, added some configure options but was unable to fix it
<slh>
the single CPU port variant (PR4036) works, it has also been tested on most devices (at least one of each class) and bridge-vlan filtering and everything around DSA is working, but multi CPU port support will be needed 'soon', to get back to full speed
<hauke>
stintel: can you jzst revert it, then I can have a look at it in the next days
<stintel>
hauke: yeah I'll keep it reverted locally
<stintel>
hauke: are you developing on macOS ?
<hauke>
no
<hauke>
linux
<hauke>
only
<stintel>
ok
<stintel>
same
<stintel>
maybe it's a gentoo thing
<stintel>
because I'd expect most hosts to have libgmp installed
<stintel>
as it's a dependency of gcc afaik
<hauke>
probably I do not have the development files for libgmp installed
<stintel>
right
<stintel>
gentoo has no -devel packages
<stintel>
it's all or nothing usuaully
<mangix>
I tried compiling zstd as a static library, broke GCC
<hauke>
I will look at it tomorrow
<Ansuel_>
slh: don't know if i should give priority to leds generic patch or multicpu
<Ansuel_>
currently i'm messing with 5.15 support cause i'm stupid...
Slimey has quit [Remote host closed the connection]
<hauke>
mangix: will have a look at it the next days
<stintel>
I would want to ask to don't spend too much time on 5.15 before there are any outstanding issues with 5.10, but I understand that's a lot to ask :)
rmilecki has quit [Ping timeout: 480 seconds]
<stintel>
now why the heck does dnsmasq give its own v6 IP as DNS to clients
<stintel>
when I explicitly configured it to use a different one
<mangix>
stintel: I assume next release will see a bunch of DSA conversions. Easier with 5.15. Less stuff to backport.
<stintel>
kind of breaks my DNS hijacking setup
<stintel>
mangix: next release will use kernel 5.10
<mangix>
right
<Ansuel_>
slh: kernel port is almost done in my hacky way... just serial doesn't work LOL... currently i'm working of adding some missing patch
<slh>
I don't have a serial console connected anyways (it's all there, but if I don't have to open it, all the better - I just need it to work as router9
<stintel>
so dnsmasq init script hardcodes [::] as ipv6 dns server if there is no specific one set for the network, completely breaking the possibility to set a global one
<stintel>
awesome
Ansuel has joined #openwrt-devel
Ansuel_ has quit [Ping timeout: 480 seconds]
dangole has quit [Ping timeout: 480 seconds]
Tusker has joined #openwrt-devel
<aparcar[m]>
nbd: is the llvm-bpf stuff already packaged? Or do you plan to add that?
Ansuel_ has joined #openwrt-devel
<Tusker>
Hi Ansuel_, for nvmem with ASCII mac address with :, do you know if there is a patch that works ?
<Ansuel_>
i think for ascii the only way is use a script and extract the value... doesn't work the effort to create something in c
<Tusker>
Ansuel_: I don't mind writing the C, but I'm not sure how nvmem hangs together
<Ansuel_>
it doesn't and afaik nvmem doesn't have support for ascii stuff
<Tusker>
ok, so just don't worry about it, and just use the 02_network etc ?
<Ansuel_>
(again if you are referring to the ascii function we use in opernwrt)
<Ansuel_>
yes we have to continue using the legacy way of ascii function with the mtd name
<Tusker>
well, I know the shell script version of the ascii functio, but is it worth creating a provider for nvmem that can handle ascii ?
<Ansuel_>
mhhh i tried in my free time but honeslty it doesn't worth it
Ansuel has quit [Ping timeout: 480 seconds]
<Tusker>
OK, and I suppose quite a bit of resistance upstream ?
madwoota has quit [Remote host closed the connection]
<Ansuel_>
the mac increase patch won't ever accepted upstream they are good but they are a big hack.... dts should only describe feature not how oem handles them
<Ansuel_>
having something that increment mac would go against this logic
<Ansuel_>
meanwhile we are fked...
<Ansuel_>
warning: left shift count >= width of type
<Ansuel_>
we reached the end of the type of netdevice.h
<Ansuel_>
packet mangle patch use it
madwoota has joined #openwrt-devel
<Tusker>
:|
<Ansuel_>
think major rework is needed... aka move the flag to another place