<hurricos>
fwiw, realtek-poe does not function for >8 PoE-port devices, or at least not in my experience -- the larger devices seem to require a port mapping to be injected to the STM
<hurricos>
It obviously doesn't function because MAX_PORTS is set to 8, but with that patched out ...
<mrnuke>
I had luck with realtek-poe on the EWS2910P I'm trying to convert from the dark side. Always shows "status": "unknown" for ports with a PoE-capable sink attached
<mrnuke>
s/luck/no luck/
<hurricos>
mrnuke: How many ports on the device?
<hurricos>
ah, 8
<hurricos>
yeah, others have reported a port-mapping issue.
<hurricos>
Try this:
<hurricos>
-- assuming you're compiling yourself?
<hurricos>
basically, what I've found (and I'm curious if you have this issue) is that the MCU is expecting to be told something about how the physical ports map to *its* pinout
<hurricos>
either that or it remembers (incorrectly) a port mapping.
<hurricos>
For example, manipulating port 0x0a on my switch fails, but manipulating 0x0d reports back as having manipulated 0x0a
<hurricos>
I haven't tried to sniff the serial traffic -- I probably should try that.
<hurricos>
(on the OEM firwmare)
goliath has quit [Quit: SIGSEGV]
<mrnuke>
hurricos: oh boy! Debugging the MCU protocol. That will be fun!
<mrnuke>
actually... I should measure the midpoint voltage on the transformers. Maybe it just bumps on the wrong port
<mrnuke>
BTW, for this realtek device (EWS2910P) It seems that the SCL line of the SFP ports is shared between port 9 and port 10, although each port has a different SDA line. DOes this make any sense? Am I missing something?
<hurricos>
what is not documented is how this looks in implementation. We have a few people whose realtek-poe's do not work or show a state of 'unknown' when plugged in.
<zorun>
the wifi chip is a BCM43430/1 (brcmfmac) so I don't have very high hopes for openwrt (and that's not the main goal atm)
<Habbie>
right, and other boards might make other choices
<karlp>
hrm, 43430 is on a few linux-sunxi boards, it probably "just works" actually :)
<stintel>
f00b4r0: thanks, glad it's useful!
<f00b4r0>
certainly is!
<stintel>
any ideas to improve?
<stintel>
I was thinking maybe it's better to add comments in the code and have something generate docs from that but I've no experience with that really
<f00b4r0>
i typically use doxygen, but frankly any kind of doc is better than "just read the code and try to figure it out by yourself"
<stintel>
/home/stijn/Development/OpenWrt/openwrt/build_dir/target-x86_64_musl/root-x86/etc/init.d/lxc-auto: line 3: /lib/functions.sh: No such file or directory
<stintel>
sigh
* stintel
grabs the yak shaver
<f00b4r0>
:)
<zorun>
karlp: ah, good to know! I had this idea that broadcom = pain in the ass
<stintel>
where were the build logs again to check if lxc fails to build on CI also?
<stintel>
if it fails there I'm just going to push a revert
<stintel>
yep sunshine-01 is going to fail all new builds it's going to try
<stintel>
weren't the buildbots migrated to build in containers and supposed to have identical base?
<stintel>
hmmm, sunshine-01 did build that failing commit for x86/geode
<neggles>
stintel: sorry for the delay but, Tested-By: Andrew Powers-Holmes <aholmes@omnom.net> (works fine / as intended)
<stintel>
neggles: for the EAP-615 ?
<stintel>
mind replying that to the mail?
<neggles>
can do
<stintel>
tha
<neggles>
ah, don't think i was CC'd
<stintel>
you're not sub'd to the mL?
<neggles>
...good point
<neggles>
I don't think I am actually
<neggles>
i should fix that
<stintel>
I'll try to remember to add your tested-by when I grab the commit from patchwork :P
<neggles>
i can pull some In-Reply-To trickery i think
<neggles>
but not rn since it's half 11 and I owe my wife some TV time
<stintel>
np :)
<stintel>
want to give other people time to react
<stintel>
ideally someone who understands nvmem-cells mac-address and mt76 properly comes up with a better solution ;)
<neggles>
there's been a lot of recent linux-wireless/lkml discussion around how to handle weird storage formats for nvmem macaddrs
<jow>
stintel: lxc-auto (any init script for that matter) must not include target-specific paths (such as /lib/functions.sh) outside of its start(), stop() etc. procedures
<jow>
stintel: since the init script is sourced during the build process
<neggles>
conclusion seems to have been 'a generic property the driver can match on and do whatever it wants with'
<neggles>
I have made some progress with these checkpoints i've ended up with (half a dozen 730/1430 and one 750/1450, Alpine AL21200/21400) but now comes the fun 'wring GPL sources out of checkpoint' part, while i make progress using some of netgear's and the R9000 repo of someone's
<neggles>
the alpine SDK drivers are actually quite well put together, but they use the device tree in a totally asinine way so some refactoring needed... sigh...
<neggles>
fortinet are going to be a fun one, too. they make their own SoCs (actually - custom accelerator IP... so probably pointless / impossible to support open-source, but) and their OS has some interesting design choices.
<neggles>
such as a 70MB /bin/init binary.
<neggles>
they might've shot themselves in the foot with that one. i think it links to some stuff that's GPLv2, not LGPLv2.1... anyway.
<stintel>
I was looking in the code for pointers but that's seriously hard to read :(
<blocktrron>
Found it
<blocktrron>
return n_assoc_new <= n_assoc_cur;
<blocktrron>
your local one is 2.4 and the remote one is 5GHz
<blocktrron>
and thus it selects the 5GHz one
<stintel>
but should that even be considered if I do not have load_balancing_threshold set
Slimey has quit [Ping timeout: 480 seconds]
Slimey_ is now known as Slimey
<blocktrron>
Yes, because load_balancing only takes action for the load-kick sm
<stintel>
I see, so at assoc time is not configurable ?
srslypascal has quit []
<stintel>
either way, forcing 5GHz over 2.4 does not make sense if on 5G the signal is that bad ?
Guest821 has quit [Ping timeout: 480 seconds]
Slimey_ has joined #openwrt-devel
<blocktrron>
Correct
<blocktrron>
i never touched that part
<blocktrron>
but i think we should reweork this
srslypascal has joined #openwrt-devel
Slimey has quit [Ping timeout: 480 seconds]
Slimey_ is now known as Slimey
Slimey_ has joined #openwrt-devel
Slimey has quit [Ping timeout: 480 seconds]
Slimey_ is now known as Slimey
Slimey has quit [Remote host closed the connection]
Slimey has joined #openwrt-devel
noltari_ has joined #openwrt-devel
noltari has quit [Ping timeout: 480 seconds]
noltari has joined #openwrt-devel
noltari_ has quit [Ping timeout: 480 seconds]
noltari has quit [Read error: Connection reset by peer]
noltari has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<stintel>
hurricos: ping
<hurricos>
stintel: opng
<hurricos>
(printing and attaching label to a package and prepping an email while I wait for the reping)
<stintel>
ah I wanted to ask if I can take your 141-octeon_snic10e_support.patch and send it upstream but I already did :P
<stintel>
it wasn't exactly rocket science to get from the octeon SDK
<hurricos>
You have my blessing. I'm assuming, of course, that you haven't found a better .dts than the one in that patch.
<stintel>
oh I'm not sending DTS yet
<hurricos>
Oh, I thought --
<hurricos>
Oh.
<hurricos>
I used a search engine for that string and found the patch on my Gitea, and assumed after a small scroll that it was mostly the .dts
<hurricos>
No, I just can't read.
<hurricos>
I hestitate for a moment, actually
<stintel>
I sent 2 patches to linux-mips before, they're already accepted, but I skipped the 3rd one because it was early in the morning after bisecting the mips64 leak
<hurricos>
Well, not quite. Every vendor tree I've seen uses 50 for the cvmx_board_types_enum
<hurricos>
for their custom board
<stintel>
interesting
<hurricos>
My memory is a little foggy at this point
<stintel>
oh well we'll see
<stintel>
if this goes well I might have an attempt at upstreaming that vsc
<hurricos>
Yes, for sure. It'll be nice to have maintainers accept it, and then the out-of-tree folks buzz up like a hive of bees
<hurricos>
I was just thinking about your fixups to the port for the VSC8488! You absolutely should. It's not an uncommon piece of hardware.
<hurricos>
Though I think VSC8490 is a little more common, I think the driver is basically copy-pasted over
<hurricos>
Both are XAUI to XFI / SFI PHYs
<hurricos>
Edgerouter Infinity uses VSC8490, I think
<hurricos>
anyways, upstream away. It will be better than what (Microchip?) is currently distributing
<hurricos>
seeing as it'll be in-kernel ..
<stintel>
and I guess I should consider upstreaming the firebox m300 dts also :)
<hurricos>
I don't remember the other quirks of the hardware. I think the PHY doesn't know how to talk I2C to get info from the SFP+ modules that get connected to it, or something?
<hurricos>
I really appreciate to see you sending the patches pustream for the VSC :^) a glorious day indeed
<hurricos>
It's a little ironic. A real come-back story for MIPS Octeon and the platforms it's paired with precipiated from global supply chain disruption
<hurricos>
(referring to the actual effort being put into mainline u-boot on the platforms)
valku has quit [Quit: valku]
<stintel>
going to work on adding support for 802.11v to esphome now
<Habbie>
ooh
<stintel>
I've 10+ esp32-c3 and they tend to be rather sticky :P
pony has joined #openwrt-devel
pony_ has quit [Ping timeout: 480 seconds]
<stintel>
imx/cortexa9 is broken for a month already?
<hurricos>
blocktrron: Mind if I send https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=commitdiff;h=258240c11b7c099fbf0fc3a9f8b006cf4ca148f1 upstream?
<hurricos>
err.
<hurricos>
I mean to openwrt master. I'd like to start testing this on our APs
pony has joined #openwrt-devel
valku has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
ekathva has quit [Remote host closed the connection]
<grift>
having issues building toolchain with git head
<grift>
make[3] -C toolchain/gcc/initial compile
<grift>
ERROR: toolchain/gdb failed to build.
<grift>
make -r world: build failed. Please re-run make with -j1 V=s or V=sc for a higher verbosity level to see what's going on
<stintel>
please pastebin the complete log, the above info is useless
<grift>
what was the command to log it to a file again?
<blocktrron>
hurricos: feel free to do what you like with it
<stintel>
grift: BUILD_LOG=1
<stintel>
then you should fine logs per package in logs/
<stintel>
or enable it in the .config
<blocktrron>
stintel: regarding the pre-assoc machines usteer has - I'm uncertain how to handle this in it's current state
<grift>
stintel: strip: error while loading shared libraries: libdw.so.1: cannot open shared object file: No such file or directory
<blocktrron>
also, I'm questioning whether it is actually beneficial trying to hide APs by omitting probe responses at all
<grift>
i guess it grew a new dependency
<blocktrron>
hostapd e.g. performs pre-auth for all APs seen when using 802.1x
<blocktrron>
so we might achieve the oposite we want in this situation
<grift>
installing libdw-dev....
<blocktrron>
we also have support across the board for 802.11v bss-transition management nowadays to actually communicate with clients instead of trying to trick them
<blocktrron>
what i think would be reasonable is to add a config option, how much of a signal downgrade is acceptable when attempting to load-balance / steer clients
<blocktrron>
stintel: thoughts about that?
<stintel>
welp, github comments on commits, issues, multiple people talking to me here, and in private, and on dating apps
Tapper has joined #openwrt-devel
<stintel>
blocktrron: can we discuss this tomorrow?
<blocktrron>
if you msg me at the right time - sure
<stintel>
grift: probably related to my bpf changes, someone reports the same
<stintel>
but the buildbots are fine so I'm not sure what's going on
<blocktrron>
hopefully all meetings tomorrow are boring nonsense where im busy counting the tiles on my ceiling (again)
<stintel>
well I'm looking into steering because of work so prefer to do that during work hours ;)
<stintel>
oh and meanwhile I also broke my rpi zero 2's camera
<stintel>
I think I'm just going to call it a day and look at things tomorrow with a fresh head
<grift>
i guess the buildbots have libdw-dev installed because installing it fixed ir (so far)
<stintel>
no, libdw should be part of one of the tools packages
<stintel>
grift: can you make tools/elfutils/compile and retry ?
<grift>
o actually it complained about that as well
<grift>
WARNING: Makefile 'package/feeds/packages/frr/Makefile' has a build dependency on 'elfutils/host', which does not exist
<stintel>
that can be ignored, there's a PR for that
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
Borromini has joined #openwrt-devel
<grift>
i will try that if i can get it to build at all
<grift>
now in the middle of debian pcre issues ...
rua has quit [Ping timeout: 480 seconds]
<stintel>
yeah it's going to have to wait until tomorrow I'm afraid, reverting would be ugly as there are many commits that would need to be reverted, and the buildbots are fine so most likely a local issue, maybe distro related
<Borromini>
grift: Debian testing?
<stintel>
hmm, buildbots don't build toolchain, they use the precompiled toolchains?
<grift>
Borromini: sid yes
<grift>
its complaining about pcre2.h but it might not be on the host
<stintel>
I'm trying a build on ubuntu 20.04 after make dirclean to see if I can repro the gdb build problem
rua has joined #openwrt-devel
<Borromini>
grift: ok. can't help then, on stable
<grift>
i guess we need prce2 in openwrt
<grift>
can only find "pcre" which i think is deprecated
<stintel>
this doesn't make a lot of sense to me though, toolchain/gdb is now failing due to missing libdw.so.1 but before my changes this was in elfutils/host, which can only get built after toolchain is completed?
* stintel
needs moar and faster cores
<Borromini>
5950X? =)
<stintel>
only 16? I have 40 now :P
<Borromini>
on that Power thing of yours? :P
<stintel>
no, main workstation
<Borromini>
some Xeon?
<stintel>
I was thinking of an upgrade to dual AMD EPYC 74F3
<Borromini>
:)
<stintel>
yeah currently dual Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz
<stintel>
but 2.3GHz and ancient architecture is slow af
Slimey_ has joined #openwrt-devel
Slimey has quit [Read error: Connection reset by peer]
Slimey_ is now known as Slimey
<Borromini>
what arch is that? Haswell?
<grift>
better than me
<stintel>
dual 74F3 is like 5k EUR for the CPUs alone or so :(
<stintel>
Broadwell iirc
<Borromini>
:P :P
<Borromini>
well gotta spend money to make money amirite
Slimey_ has joined #openwrt-devel
<Borromini>
and threadripper is too old i suppose?
<Borromini>
besides being a seemingly dead platform
<stintel>
try finding a threadripper motherboard with 256GB ECC RAM in the compat list
<grift>
building on a Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz dual socket
* Borromini
is happy with his 5800X but it should last a while
ptudor has quit [Ping timeout: 480 seconds]
<Borromini>
stintel: sorry, not that familiar with your wishlist and the limitations of each platform :)
<grift>
anyway's i ran into complications, i guess we need to move prce back to the packages feed and get prce2 into core....
<stintel>
Borromini: ECC is non-negotiable ;)
<Borromini>
understandable
Slimey has quit [Ping timeout: 480 seconds]
Slimey_ is now known as Slimey
<Borromini>
i'm out, goodnight
Borromini has quit [Quit: Lost terminal]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<stintel>
grift: toolchain/gdb builds fine on ubuntu 20.04 after make dirclean
<stintel>
maybe a make toolchain/gdb/clean can help
<grift>
it builds now after i installed libwd-dev
<grift>
ran into other issues not related to that
<stintel>
but you don't need libdw-dev
<grift>
ok, but this error message seems pretty clear to me though:
<grift>
i guess that should be directed to stintel ?
<mangix>
whoever is having issues
<grift>
i was having issues but that looks like it might be a packaging issue then
rua has quit [Ping timeout: 480 seconds]
<stintel>
lol trying to repro on debian 10 and it fails at tools/tar
<stintel>
configure: error: you should not run configure as root (set FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check)
<stintel>
yeah great
<stintel>
no debian machine at hand so doing it in a container but containers suck
<stintel>
I would like to run in podman with userns=keep-id but then I'd need to prepare a container with all the dependencies for building openwrt already included because running with userns=keep-id you're not root in container and can't install anything
<mangix>
stintel: qemu :B
<stintel>
would have to install debian 10 first
<grift>
systemd-nspawn allows you to open a shell in a container with your userid from the host and then you get your hosts homedir in the container as well
<stintel>
so it's equally enough effort
<mangix>
stintel: gnome boxes installs it automatically
<stintel>
I don't use gnome-boxes
rua has joined #openwrt-devel
<stintel>
vague stuff really
<stintel>
strip is apparently part of elfutils
<stintel>
or binutils?
<dwfreed>
binutils provides /usr/bin/strip
ptudor has joined #openwrt-devel
<stintel>
dwfreed: I'm more interested in what provides it in openwrt, so far it seems inconclusive
<dwfreed>
usually it's binutils
<stintel>
in the build system that is, ./staging_dir/host/bin/strip
<dwfreed>
because you need binutils for the linker, so you might as well use its strip too
<mangix>
my router was working fine. then I rebooted. Now it's garbo.
<mangix>
time for a new build i guess
<stintel>
-rwxr-xr-x 1 1066535 1066535 396520 mei 19 00:42 ./build_dir/host/elfutils-0.186/src/strip
<stintel>
-rwxr-xr-x 1 1066535 1066535 396520 mei 19 00:42 ./staging_dir/host/bin/strip
<stintel>
sha512sum also same
<dwfreed>
guessing elfutils replaces it
<stintel>
but why does it work fine on buildbots and for me and for others that tested things
<stintel>
sigh
<dwfreed>
oh, wait
<dwfreed>
in a full build, you're going to build host stuff first, right? and then toolchain gets built
<dwfreed>
what's the path order? toolchain:host, or host:toolchain ?
<stintel>
tools, toolchain
<stintel>
and elfutils is in tools
<stintel>
build order that is
<dwfreed>
so elfutils will have priority over toolchain (ie, binutils)
<dwfreed>
oh
<dwfreed>
what's the PATH order afterwards
<dwfreed>
is staging_dir/host before or after the toolchain dir
<stintel>
good question
<stintel>
you might be on to something
<dwfreed>
if staging_dir/host is first, then it'll be elfutils strip; if toolchain is first, then after toolchain is built you'll have binutils strip, and before elfutils-strip
<dwfreed>
debian prefixes the elfutils utils in order to prevent collisions
<stintel>
so rather than pointing elfutils strip to staging_dir/host/lib
rua has quit [Ping timeout: 480 seconds]
<stintel>
just don't install elfutils strip
<dwfreed>
or change the binary name like debian does
bluew has joined #openwrt-devel
<mangix>
dwfreed: host comes before toolchain
rua has joined #openwrt-devel
<stintel>
does anyone have a clone around and didn't build in the past 24h ?
philipp64 has quit [Quit: philipp64]
<stintel>
I'd like to see if staging_dir/host/bin contains strip
<stintel>
nvm I'll just build pre ad79b92719498afa93567cccdfbffeb49a57388d
bluew has quit [Quit: Leaving]
<dwfreed>
probably doesn't, so it would fall back to buildhost strip
<stintel>
but then where did elfutils/host install strip ..
<stintel>
or did that somehow automagically linked to the correct libdw then as opposed to how tools/elfutils does it now
<stintel>
still, that could cause undefined behaviour as in different situations different strip binary could be used
bluew has joined #openwrt-devel
<stintel>
hmmm, there was only 1 dependency on elfutils/host - does the host variant build automatically when the normal package builds?
<mangix>
stintel: no
<mangix>
elfutils/host was only built for frr
<stintel>
amazing corner case
<stintel>
can't immediately find how debian prefixes it
<stintel>
also can't be disabled without hacking the source
<stintel>
hmm
<stintel>
so frr needs only libelf, not sure what dwarves needs
<stintel>
I could maybe HOST_MAKE_VARS += SUBDIRS=libelf