<stintel>
you're gonna hit some annoyances like missing symbols, some kmod packages might miss files, but usually 5-10 iterations to hack those in/out should do
Ansuel has quit [Read error: Connection reset by peer]
Ansuel has joined #openwrt-devel
<aparcar[m]>
Ansuel: what should we do about erofs? I'd love to compare actual sizes within openwrt
<aparcar[m]>
I backported whatever erofs stuff I could find but there is likely a better way. Since you did a bunch of backporting, maybe you can easy do it
<Ansuel>
the pr is up to date?
<Ansuel>
for compare we should test for sure low space target (ath79 should be a good candidate)
<Ansuel>
also the idea is to have it optional for now and still use squashfs correct?
<Ansuel>
yep i remember but i assume we now have support for better compression
<f00b4r0>
squashfs priotizes size, erofs speed. Not sure that's what we need/want.
<Ansuel>
we may consider a bigger project with a flag for system that have no space constraints (would match with the idea of installing openssl by default)
<Ansuel>
but this idea is a nightmare for maintainers
<f00b4r0>
i really fail to see the rationale here
<f00b4r0>
exactly
<f00b4r0>
we're not targetting smartphones
<Ansuel>
sure but if the speed is double and the size increase is just 1mb then it would make sense for device that have no space problem
<f00b4r0>
Why?
<f00b4r0>
we're talking about a read-only fs. Any read-intensive data will be cached anyway.
cbeznea has joined #openwrt-devel
<Ansuel>
another reason was that since squashfs was dead (was the case before me switching to the new project) erofs was a replacement since it is actually maintained
<robimarko>
Squashfs has been maintained for years again
<f00b4r0>
^
<f00b4r0>
it's also proven reliable.
<robimarko>
I am failing to see what would erofs bring to us
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<Ansuel>
at times there was an idea to replace squashfs... now i think just better boot time?
<f00b4r0>
imho faster boot times only matter to devs. We're talking about devices that 1) barely take forever to boot and 2) aren't rebooted multiple times a day.
<robimarko>
If you are using NOR to boot then squashfs overhead is the least of your worries
<dwfreed>
the longest part of my device's boot is the 60 seconds spent on DFS scanning
<f00b4r0>
that and that ;)
<Ansuel>
also ath10k booting
<Ansuel>
also 10 times sleep
<dwfreed>
reading squashfs is probably not even noticeable without squashfs
<Ansuel>
also honestly i would move those upstream patch in generic instead of bloating the target
<Ansuel>
Two ethernet ports (on extra switch) and fiber port not working
<Ansuel>
from reading this i think the fiber port is connected to the port5 of the qca8k switch
<Ansuel>
but i think not currently supported in qca8k currently
<hauke>
Ansuel: the commit says the fiber port is not working
max_ has joined #openwrt-devel
<Ansuel>
reading some message from the pr... really interesting soc with how things are connected
<hauke>
yes this is a special design
<Ansuel>
trying to find why sfp port doesn't work
<Ansuel>
only info i found is this The QCA8K switch is connected to port1 (lan3) and the fiber port is phy 6.
max__ has quit [Ping timeout: 480 seconds]
<Ansuel>
hauke btw chance you have permission to create a new repo on git repo? Or hint on how should i ask for it?
<robimarko>
Ansuel: What modes are supported on port 5
<Ansuel>
port 5 can run as a separate rgmiii port
<robimarko>
That is useless for SFP
<hauke>
Ansuel: No I do not have that permissions, but jow has
<robimarko>
I assume there is PHY in between
<Ansuel>
robimarko any idea of an use of running port 5 in that mode? the original swconfig driver had all sort of configuration
<Ansuel>
but no device ever had that
<hauke>
Ansuel: I would also merge it when the fiber port is not working
<robimarko>
You can connect a PHY or second switch via RGMII
<Ansuel>
hauke yep also ok for me just would be good to have more context... like proprietary driver, missing source...
cbeznea1 has quit [Quit: Leaving.]
<hauke>
A AT 8033 is used to conenct the AON fiber
<hauke>
on the AVM 5490
<hauke>
the 5491 is for PON
<robimarko>
That makes sense
<Ansuel>
robimarko the only config a bit different was the mikrotik rb3011 that had 2 qca8337 and i think they were interconnected with port6... but they were 10 port so port5 was used as a normal port... mhe who knows who actually used it
danitool has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
<hauke>
Ansuel: looks fine to me
<hauke>
but I am not an expert on ofhcpd
<hauke>
odhcpd
<stintel>
why are we sending packets on a down interface? I think this patch will just hide a misconfiguration, so I'd be inclined to ank
<stintel>
nak*
<Ansuel>
stintel actually i always had them and the ipv6 device wasn't down
<Ansuel>
they are always logged if you have ipv6 assign active but no ipv6 connectivity
<Ansuel>
(no wan ipv6 connectivity but the interface there)
<dwfreed>
that's a lan message though
<dwfreed>
it does not give 1 iota about whether there's lan v6
<dwfreed>
s/lan v6$/wan v6/
<stintel>
I still think we should come up with an explanation before silencing the error
<Ansuel>
sure worth to investigate but for me it never was a misconfiguration, in my secnario i have a not-so-stable ipv6 connection and lan having a /64... when the ipv6 connection was dropped i always had those messages
<dwfreed>
you should not have a LAN send failure for lack of WAN connectivity
<dwfreed>
if you do, then something is really wrong outside of odhcpd
<stintel>
then we should fix that something really wrong instead of hiding this error no ?
<dwfreed>
yes
<Ansuel>
well we don't have this for ipv4... also you would notice something is broken, to me doesn't look useful that message that say that it failed to send stuff to a ipv6 local ip
<dwfreed>
it's one thing to have the 'no default route' messages mentioned in the forum post stintel just linked, but the patch referenced does not affect that
<Ansuel>
let me check if i manage to repro quickly
<dwfreed>
the issue mentioned in the patch doesn't even make sense, br-lan should always be up, even if its constituent interfaces have nothing plugged in
<dwfreed>
even on DSA
<stintel>
I don't even use odhcpd but silencing an error message without properly understanding what is going on is always wrong
<Ansuel>
From around the web
<Ansuel>
this trace is often triggered when there's no valid link local address in use or when no layer3 connectity is supported on the device eg due to the device being a bridge member
<Ansuel>
daemon.err odhcpd[2210]: Failed to send to ff02::1%lan@br-lan (Address not available)
<Ansuel>
done repro
<stintel>
how?
danitool has joined #openwrt-devel
<Ansuel>
LAN no ipv6 assign | DHCP Server set to server mode for RA and DHCPv6 | Default route set to Forced
<Ansuel>
force is to force it but i think on connection lost the same problem arise (due to an old entry?)
danitool has quit []
<dwfreed>
I mean, if you don't have *any* IPv6 addresses on your LAN interface, then the error 100% makes sense
<dwfreed>
but that is not the default configuration, for 1, and 2 that should complain anyway
<dwfreed>
if you do not have IPv6 configured on your LAN interface, you should not be running a DHCPv6 server at all
<dwfreed>
but you've intentionally created that configuration
<Ansuel>
it's there also with a 64
bluew has quit [Remote host closed the connection]
<Ansuel>
i wonder if the problem is if there was a route and then connection is lost entirely
<Mangix>
stintel: exotic configurations seem to be untested
<Mangix>
busybox and ccache fail as an example
<stintel>
Mangix: what exotic configuration? I don't use ccache
bluew has joined #openwrt-devel
<stintel>
and I did rm -rf build_dir/ staging_dir/ bin/ tmp/
<stintel>
to make sure nothing old is causing weirdness
<Mangix>
well, elfutils fails for you. busybox fails for me on fedora 37. it tries to run qemu for some reason
<Mangix>
ccacche does not work on ubuntu 18.04
<Mangix>
which is supposed to be a supported distro
<stintel>
elfutils built fine after that rm
<Mangix>
ok
<stintel>
I guess we should more aggressively cleanup stuff from build_dir and staging_dir on version bumps because this keeps causing issues
<Ansuel>
but on version bump the package should be compiled on his own directory and also clean is called before (i think?)
<Ansuel>
btw i really think the Failed message are fixed with the recent improvement to odhcpd
<stintel>
Ansuel: this was tools/elfutils, I guess there it's more complicated
<stintel>
ugh wth happened with author in my 2 odhcpd commits
<Mangix>
anyway, to fix ccache, gcc version must be bumped to 7
<Mangix>
as 7 introduces std::filesystem
<Mangix>
sorry, 8
<Ansuel>
stintel notice big rip
<Ansuel>
anyway i think i will revert the commit and rework where odhcpd_send is used... drop the generic error there and add the error in each user of that function
<Ansuel>
or keep the commit and add error in any user of odhcpd_send
<Mangix>
oh wait a minute. I think I can make it work.
<stintel>
probably this shitty dmarc wrapping and git pw patch apply
<Mangix>
oh no I can't. it uses C++17
<Mangix>
that needs 7
<Ansuel>
What do you think? any hint? to me the 'Failed to send' error is way too generic and hard to bisect if still present after the odhcpd changes
<stintel>
we can just drop Ubuntu 18.04 support. there's 2 new LTS releases after that and 18.04 is EOL soon
<Habbie>
two more weeks
<Habbie>
kill it :)
<stintel>
> As 18.04 reaches the End of Standard Support in May of 2023
<stintel>
so I think we should do it before branching 23.whatever
<Ansuel>
maybe something to discuss on the next meeting
<Ansuel>
we have also python cleanup to check
<stintel>
is there a pad already?
<Ansuel>
nope
<stintel>
as for odhcpd ... I really think we should get to the bottom of this instead of changing that message to debug
<stintel>
I'm thinking how I can setup odhcpd without having to change my main router configs to repro/debug this
<Ansuel>
wonder if it's just enough to have a bridge + ra set to server + force
<Ansuel>
(but for sure i would add better describing error... the current failed is a PITA to track)
<stintel>
this lan@br-lan ... do you have an interface that is actually named lan on this device where you repro'd ?
<stintel>
interface as in ip l, not in /etc/config/network
<Ansuel>
it's the default lan interface
<Ansuel>
let me check
<Ansuel>
from ip link
<Ansuel>
it's br-lan
<stintel>
what device ?
<Ansuel>
btw can confirm if it's just enough to have a bridge + ra set to server + force
<Ansuel>
Failed to send to ff02::1%test@lan3 (Network unreachable)
<stintel>
yeah but force as dwfreed explained is non-standard and if you don't have IPv6 on the interface it's supposed to error
<stintel>
and this is ENETUNREACH so different
<Mangix>
18.04 is EOL in 2028
<Ansuel>
Failed to send to ff02::1%test@testbr (Address not available)
<Ansuel>
i created another bridge, assigned a port, crated an interface added the bridge, ipv6 64, ra server, default route automatic
<Ansuel>
so everything is standard
<stintel>
ok, so we should start by changing the message format
<stintel>
test@testbr is super confusing
<stintel>
because ip l can show interface like slave@master
<stintel>
but in this case we should interface_name_from_etc_config_network@ifname
<Mangix>
anyway
<Ansuel>
interface is test
<Ansuel>
bridge name is testbr
<stintel>
so if you see lan@br-lan the first thing I think of is that it's trying to send on slave interface name lan of a bridge named br-lan but that is completely not the case
<Mangix>
jow's the loudest voice on keeping old OS compatibility AFAIK
<Ansuel>
Mangix well then we can disable or reject ccache on 18.xx
<Mangix>
even better
<Mangix>
18.04 has gcc 7 and 8 with apt by default
<Mangix>
but prereq-build.mk needs changing
<Mangix>
maybe install a gcc symlink in staging_dir
<Ansuel>
we can change prereq to require gcc-8 min
<Mangix>
speaking of updating deps, I also suggest python 3.8, which 18.04 also has