SlimeyX has quit [Read error: Connection reset by peer]
hanetzer2 has joined #openwrt-devel
hanetzer1 has quit [Ping timeout: 480 seconds]
SlimeyX has joined #openwrt-devel
danitool has joined #openwrt-devel
robimarko has joined #openwrt-devel
<oliv3r[m]>
I thought SGMII was a 1Gbit interface, and that QSGMII thus would be 4GBit, but I also see SGMII marked as 1.25Gbit (what's the point of that?) and obviously then QSMII being 5GBit. This then makes me wonder, what is XSGMII which I thought was 10Gbit. Or did someone mess up gbit and Ghz?
<robimarko>
SGMII is 1.25G
<oliv3r[m]>
G what, Gigaherz, Gigabaud, Gigabit :)
<robimarko>
AFAIK, thats overhead
<oliv3r[m]>
So 1.25Gigabaud -> 1Gbit?
<robimarko>
SGMII is 1.25Gbps RAW
<robimarko>
That will get you your 1Gbps of data
<robimarko>
AFAIK, its due to 8B/10B encoding
<robimarko>
Same scales for 2.5Gbps which is 3.125Gbps, etc
<oliv3r[m]>
Ok, fair nuff
<oliv3r[m]>
All I want for christmas, is a proper RTL9302b datasheet, with all registers in it :( but even just the datasheet would be nice :(
<oliv3r[m]>
heck, i'd be bappy with just the pinout tables atm :)
<robimarko>
Hehe, my wish is similar, just for QCA products
<oliv3r[m]>
:p one can dream :)
<oliv3r[m]>
should become a law imo; datasheets must be public and complete :p
<oliv3r[m]>
it's in their own friggin' benefit :(
<robimarko>
Tell that to management
<robimarko>
Their whole world is NDA-s
<oliv3r[m]>
anyway, RXAUI+ what is that? As in, the rtl9301 states '2x RXAUI+ links, giving 4 8G pairs. So is be definition an RXAUI+ link a dual pair?
<robimarko>
I know of the version without +
<robimarko>
That one is 10G version of RGMII
philipp64 has joined #openwrt-devel
<oliv3r[m]>
The name doesn't help; wouldn't be supprised that + is then dual that for 20G Though they call the serdes for a single RXAUI+ lane '8G' (32G probably in total for that dual RXAUI+ link)
<[Pokey]>
Has something just happpened to the OpenWRT packages repo?
<\x>
repo has 5.10.138-1-218bf6e00a546ab5c6ea465b29f9c777
<[Pokey]>
\x: hm. Yea its a self built. Why would it work yesterday but not today? I haven't updated my repo
<\x>
it probably worked for normal userspace stuff
<\x>
for anything that needs a kmod nope
<\x>
thats because thekernel youre running doesnt have the same hashsum as the one on the repo
<jow>
not even the same version
<robimarko>
You aint gonna be able to use prebuilt kmods if you self-built
* [Pokey]
confused look
<[Pokey]>
Puzzling because that was just an opkg update which has been working perfectly fine for the last few days and I have been using nothing but self builds
<\x>
try it now and itll work
<\x>
opkg update; opkg install coremark
<\x>
itll work, because it doesnt have any kmnod dependency
<\x>
but for example you do 'opkg install luci-proto-gre' it wont.
<[Pokey]>
nuppers
<[Pokey]>
It refuses to update the package listing
<\x>
nslookup downloads.openwrt.org
<\x>
what do you get [Pokey]
<\x>
168.119.138.211 and 2a01:4f8:251:321::2 ?
<[Pokey]>
168.119.138.211
<[Pokey]>
YEa but I can't do IPv6 here so
<\x>
ipv4 should work
<\x>
mtr 168.119.138.211
<[Pokey]>
It requests URLs and then reports a signature issue, if I go to the URL I get 404
<[Pokey]>
Understandably because of the kernel ver
<\x>
just build what you need for now, youre on snapshots anyway right
<[Pokey]>
I haven't got mtr just normal traceroute
<[Pokey]>
\x: If by snapshots you're talking straight from GIT, yes
<[Pokey]>
Its just so frustrating because the kernel version shouldn't have changed, I haven't pulled for days
<\x>
you can always port your changes to 22.03.0 on your local copy, kernel should be reproducible
<jow>
[Pokey]: did you build the release branch yourself?
<\x>
as long as you dont do any custom stuff on kernel_menuconfig, most of times youll end up with the same hash as the repo
<[Pokey]>
bin/targets/ramips/mt7621/packages on my local build has a load of ipk files, that should be everything?
<[Pokey]>
jow: I'm building not the release branch but the very latest beleding edge (as of a couple days ago) from GIT
<jow>
then it is puzzling that your opkg has 22.03 repos configured
<\x>
either that or he changed opkg config ahaha
<g___>
maybe a sysupgrade without -n
<[Pokey]>
wait a sec... Is it possible that me doing a SYSUPGRADE via the Web UI instead of directly flashing via recovery did this?
<jow>
possible, altough opkg config is usually not kept, only if it deviates from the system default or if you explicitly marked it for preservation
<\x>
if you kept settings maybe, im not sure if distfeeds is saved
<[Pokey]>
Maybe I'll just reflash this from recovery and if that works I'll just roll with it
<[Pokey]>
Just when I feel like I am learning this process something new pops up haha
<\x>
I was gonna say that you can just edit distfeeds
<\x>
turns out your hash isnt the same as the repo
<[Pokey]>
\x: Yea I'm guessing thats because I am not running the latest copy out the repo, i'll be a few commits out of date I would imagine
<[Pokey]>
Regardless, flashing it directly has resolved it now. User error :) thanks all
<[Pokey]>
Oh - I spoke too soon, one succeeded and the others still failed
<[Pokey]>
I'm not doing too well here am I
<\x>
just compile what you need really, you have a 3900X right? put it to use.
* [Pokey]
mumbling effort sounds at \x
<[Pokey]>
Is there a good way to set up a local repo for that stuff? Because I don't wanna find and upload each package's dependencies every time I need to install a package
<Mangix>
\x: 3950X is really nice when doing rm -rf build_dir staging_dir tmp;make -j 31
<[Pokey]>
Mangix: Do ya leave 1 thread of room for your system to brethe? :P
<Mangix>
I don't have a good reason for it honestly.
<Mangix>
I don't think OpenWrt's make is able to fully saturate all threads
<[Pokey]>
Fair! I let mine suffer pinned at 100 everywhere
<Mangix>
then again, I use ccache
<[Pokey]>
I hope after all this my initial device support PR gets accepted >.>
<robimarko>
Mangix: Oh, it will use all of the threads you give it
<[Pokey]>
Of course with my different kernel version that means nothing, but still good to learn
<[Pokey]>
I still don't know why my kernel version is suddenly different which is frustrating but meh, not much I can do
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
Tapper has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
srslypascal is now known as Guest1730
srslypascal has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
Guest1730 has quit [Ping timeout: 480 seconds]
<[Pokey]>
I think I might have messed something up here and I am really not sure what. I just redownloaded the buildinfo file and ran a built, and rather than the build being labelled snapshot it is labelled snapshot-r20757+1-f1b3958d02 What did I mess up?
<robimarko>
oliv3r[m]: Whats the state of SMP on those dual core RTL-s?
dangole has quit [Ping timeout: 480 seconds]
<neggles>
hmmmm
<neggles>
have and of y'all messed around with Terragraph hardware
<neggles>
er, s/and/any
<robimarko>
Whats the HW?
cbeznea has joined #openwrt-devel
cbeznea has quit []
domon has quit [Write error: connection closed]
fpsusername[m] has quit [Remote host closed the connection]
bluse-blue[m] has quit [Remote host closed the connection]
lipnitsk has quit [Remote host closed the connection]
Jonny[m] has quit [Remote host closed the connection]
fieryeagle954[m] has quit [Remote host closed the connection]
pavlix has quit [Write error: connection closed]
MatrixTravelerbot[m]1 has quit [Write error: connection closed]
hexagonwin[m] has quit [Write error: connection closed]
decke[m] has quit [Write error: connection closed]
schmars[m] has quit [Write error: connection closed]
Kiste has quit [Write error: connection closed]
MatMaul[m] has quit [Write error: connection closed]
dfceaef[m] has quit [Write error: connection closed]
evils[m]1 has quit [Write error: connection closed]
znullptr[m] has quit [Write error: connection closed]
Movedtomkg20001mkg20001io[m] has quit [Write error: connection closed]
mkg20001 has quit [Write error: connection closed]
tohojo has quit [Write error: connection closed]
whatevs111[m] has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
oliv3r[m] has quit [Write error: connection closed]
JuniorJPDJ has quit [Write error: connection closed]
Q__ has quit [Write error: connection closed]
ctdvqgg445[m] has quit [Write error: connection closed]
t4h4[m] has quit [Write error: connection closed]
will[m] has quit [Write error: connection closed]
barhom has quit [Write error: connection closed]
aparcar[m] has quit [Write error: connection closed]
John[m]123456 has quit [Write error: connection closed]
olmari has quit [Write error: connection closed]
nick[m]1234 has quit [Write error: connection closed]
GNUmoon has quit [Quit: Leaving]
GNUmoon has joined #openwrt-devel
aparcar[m] has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
cbeznea has joined #openwrt-devel
<ynezz>
jow: do I understand it correctly, that having /usr/lib/libwolfssl.so.5.4.0.ee39414e means, that we're now not able to update(break) users with simple `opkg install /tmp/libwolfssl5.5.1.ee39414e_5.5.1-stable-0_aarch64_cortex-a53.ipk` anymore?
<ynezz>
jow: so additional manual fiddling like `ln -sf /usr/lib/libwolfssl.so.5.5.1.ee39414e /usr/lib/libwolfssl.so.5.4.0.ee39414e` is now needed or do I miss something?
cbeznea has quit []
<jow>
ynezz: yes
<jow>
ynezz: executables will link against and expect /usr/lib/libwolfssl.so.5.4.0.ee39414e
<jow>
ynezz: they wan't load or look for /usr/lib/libwolfssl.so.5.5.1.ee39414e
<jow>
unless they're updated to a version that does link /usr/lib/libwolfssl.so.5.5.1.ee39414e
<jow>
which they will, but without a version change
<jow>
only "fix" for this is manually bumping the version (pkg revision) of all libwolfssl users
cbeznea has joined #openwrt-devel
<jow>
but nothing will break on installed systems
<jow>
and if users happen to install/upgrade a package linking against the newer libwolfssl, they'll end up with two wolfssl versions installed in parallel
<jow>
if all users of the old version are uninstalle/upgraded, opkg should automatically remove the old libwolfssl as orphaned package
<ynezz>
or still end up with vulnerable system by only updating the libwolfssl
<jow>
correct
<jow>
this is why libwolfssl appears to be a very bad choice from a lifecycle mgmt pov
<jow>
no chance to apply critical security fixes within a stable abi version
<ynezz>
well, this can happen to any part of the system
<jow>
Yes, and it can only be solved with strict packaging hygiene
<Habbie>
i missed some context - why can't you apply critical security fixes?
<jow>
Habbie: you can, but you needto manually reinstall/bump all users of the fixed library
<jow>
because the library has no stable abi you can't simply replace the .so with a fixed version
<Habbie>
because applying a patch changes the .so filename?
<jow>
the fix comes along with a bunch of unrelated updates rendering the .so abi incompatible
<Habbie>
right, but most patches won't touch the abi, right?
<Habbie>
ah
<jow>
so all packages have to rebuilt/relinked against the new abi
<jow>
wolfssl just has a shitty abi/version mgmt
<jow>
not like, say openssl, where you can simply ship 1.0.0y instead of 1.0.0x
<ynezz>
ok, so this special handling is only related to wolfssl?
<jow>
because both will share the same abi
<jow>
ynezz: related to any library where upstream does not provide some kind of abi-stable lts release
<ynezz>
so this is decided and enabled manually on case basis?
bluew_ has joined #openwrt-devel
dangole has joined #openwrt-devel
<ynezz>
ok, looks so f378d81da6
<neggles>
oh robimarko left
<neggles>
that's what I get for dropping the ball on replying
<neggles>
jow: isn't that because wolfssl is primarily intended for microcontrollers and other systems with monolithic images where everything is built at once
<neggles>
it's still unhelpful but
<neggles>
vaguely justifiable
<ynezz>
jow: BTW seeing PKG_RELEASE:=$(AUTORELEASE) in hostapd, is that enough to trigger the update of new libwolfssl?
<ynezz>
IIRC it would only work when something within that package changes, right?
bluew has quit [Ping timeout: 480 seconds]
<ynezz>
px5g-wolfssl has PKG_RELEASE:=$(COMMITCOUNT), it's getting interesting :]
<ynezz>
so with packages feeds we've 17 packages which build against wolfssl and would need to be handled
Tapper has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
Ansuel has joined #openwrt-devel
<[Pokey]>
Is there a developers guide somewhere which goes into making a HTTP opkg feed with all packages compiled matching your build's kernel and vermagic. I don't see one and searching is showing singular packages but not the whole suite. Preferrably I would use the official one but I am just at a loss as to how to fix my setup to do that now
Ansuel_ has joined #openwrt-devel
<jow>
ynezz: sorry, phone call. I had a longish chat with Hauke quite a while back about how to handle reverse deps after library/abi bumps
<jow>
ynezz: and all options are bad. If you look at large distros like debian or redhat derivates, the issue seems to be handled in an organizational, not technical manner
<jow>
means strict packaging policies for libraries etc.
<jow>
a potential technical solution for reverse deps would be to form some kind hash over the abi versions of all linked libararies
<jow>
problem is that a hash is not monotonically increasing, so it only helps to ensure that the version *differs* but not necessary to signal an update
<Ansuel_>
(well if the version differ you are running on an undefined state so you should refresh/update just to make sure)
<jow>
the only clean way is bumping the pkg-release (or some other suitable part of the version identifier) in a monotonically increasing manner
<ynezz>
indeed, could we please leave that discussion once we get that RCE fix for 22.03 out of the door? :)
<jow>
so that means bumping the PKG_REVISION:= of all 17 wolfssl users whenever we bump libwolfssl to an incompatible abi
<jow>
the only sane way for *that* is backport imho
<jow>
or disabling session ticket uspport if we cannot reasonably fix it
<ynezz>
IIUC we now need to do that always
<jow>
doing an uncoordinated bump of a central library forcing upgrades to large chunks of the userland is throwing ou the baby with the bathwater imho
<ynezz>
I simply did `ln -sf /usr/lib/libwolfssl.so.5.5.1.ee39414e /usr/lib/libwolfssl.so.5.4.0.ee39414e` and was still able to connect over wpa3 and use https
<ynezz>
so it seems like ABI compatible jump, right?
<karlp>
abi compatible for the bits that you used...
<jow>
if it is then there is no reason to change the soversion
<ynezz>
I understand, that I'm not able to test all codepaths, right
<ynezz>
but what is worse, unpatched RCE or possible ABI breakage? I know, those are pretty nasty and hard to track down
<jow>
possible abi breakage can lead to futher RCE...
<ynezz>
yes, good point
<Ansuel_>
so it's backport or disable ?
<ynezz>
so in order to stay on safe side, simply bump PKG_REVISION+=1 right?
<jow>
commit f378d81da6d1976ba3d304932cda4ff0cdd5f182 is plain wrong btw imho
<hauke>
jow: didn't you had a website which showns ABI differences?
<jow>
it needlessly pegs the abi version of the shared object to the source version
<jow>
the offical abi version still seems to be 34
<ynezz>
Ansuel_: nobody is able to reproduce it, even wolfssl folks...
<ynezz>
Ansuel_: so we rely on confirmation by some random dudes on internet :)
<Ansuel_>
bad....
<ynezz>
there is no reproducer, no further technical analysis can be done
<Ansuel_>
wonder if we checked if the user have some kind of special chrome flags enabled?
bluew_ has quit [Read error: Connection reset by peer]
bluew_ has joined #openwrt-devel
<ynezz>
I've tried to fiddle with those knobs related to TLS
<ynezz>
no dice
<hauke>
I also think wolfssl did not handle this bug very well
<ynezz>
even sending those tls hello packets didn't lead to crashes, so it must be related to some proper sequence/memory/process state
<ynezz>
hauke: they apparently had CVE already, dunno why it wasn't mentioned in those release notes
<hauke>
wolfssl is probably also used by some of their paying customers on systems without stack cookies
<Ansuel_>
ynezz fun thing the first guy that reported it disappeared...
<Ansuel_>
so we are not even sure if it was the same bug
<ynezz>
so the question is, whats the preference of fixing it in 22.03? 1. Change all 17 (?) libwolfssl users with PKG_REVISION+=1 change or 2. Don't bump PKG_ABI_VERSION (this would be very strange)
<ynezz>
I'm inclined more towards 1. with security advisory and related forum post
<ynezz>
explain there clearly what needs to be done etc.
<hauke>
ynezz: I am also for option 1
valku has joined #openwrt-devel
<jow>
ynezz: my preference would be disabling session tickets and ship the same version with bumped pkg release
<ynezz>
jow: are you sure that it's related?
<Ansuel_>
ynezz wonder if we can ask that guy to test it
<jow>
actually, I'd vote for dropping wolfssl with 22.03.1
<jow>
it cleary is unmaintainable
<Ansuel_>
jow and use what as an alternative?
<jow>
you can't leap forward to a way newer version everytime there's a securty issue
<jow>
Ansuel_: openssl and no ssl support for low spec devices
<Ansuel_>
ynezz doesn't seem that bad to backport... and that should not change abi version
<ynezz>
it's the same like doing your own crypto, don't do that
<ynezz>
you can simply introduce other issues, that code is ifdef mess
<karlp>
I'm with jow, support wolfssl's internal abi changes was a nightmare in the past.
<karlp>
just toss it.
<karlp>
we only brought it in because they were first to offer a path to wpa3 right?
<ynezz>
well, fine with me, I wasn't considering that option, since the .0 was released
<neggles>
how much of a difference does it make to image size anyway?
<Ansuel_>
neggles openssl is BIG
<karlp>
like manyhundreds of kB.
<neggles>
do we have to build/include *everything* ?
<ynezz>
yes, otherwise good luck with longterm support
<ynezz>
bbl, family duties
<neggles>
no i mean, surely there are things that can be disabled for lower-spec devices that might save some space? (I don't really know anything about how configuable/shrinkable openssl is)
<neggles>
(suspect not very)
<robimarko>
those things are already disabled AFAIK
<Ansuel_>
neggles with low space device it's a miracle the system run... more than a miracle that have ssl support... installing openssl imho it's a no go but also disabling ssl for these target it's not that good in 2022
<jow>
cd ../; abi-compliance-checker -l libwolfssl -old ABI-old.dump -new ABI-new.dump
oliv3r[m] has joined #openwrt-devel
<oliv3r[m]>
<robimarko> "oliv3r: Whats the state of SMP..." <- On my RTL9302B, I got dual VPE's with the new timer working :) We also guestimate that on those RTL931x's we'd have dual CPU's with dual VPE's but without hardware, hard to say.
<neggles>
is TLS1.2 not good enough for what in the overwhelming majority of cases is being used for a non-external-facing admin web ui and not much else?
<Ansuel_>
imho we should ask that guy to test if the problem is still there with tls1.3 disabled but I understand we won't be sure if it will be THE real solution?
<robimarko>
oliv3r[m]: thanks, I knew it was bit of an mess
<oliv3r[m]>
robimarko: yeah but slowly things are comming together; it's a bit of 2 steps forward, one step back :p
<robimarko>
It wouldnt be interesting otherwise
<oliv3r[m]>
for me, the most important bit is the SFP+ DAC tuning, so I can use my 3m DAC :p
Ansuel_ has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
<oliv3r[m]>
Yeah, In 3 years we'll have a laugh at this, like we did for other platforms :p
<robimarko>
3 years would be great timeline
<robimarko>
Took me 2 years to make ipq807x usable, and networking is still meh
<neggles>
oh robimarko the terragraph stuff - QCA6436/wil6210 radios and an LS1048, 1x Mgmt. 1G + 4x1G + 1xSFP+
<oliv3r[m]>
What excites me about these rtl93xx SoC's, is that (hopefully) they'll be around for a decade or so. I've had really old 1gbit switches for ... 10+ years now; HP1810 stuff; so replacing that with RTL93xx stuff and 'up-to' 10GE will hopefully last me a long time
<hauke>
but there are some patches adding hostapd support for mbdtls
<robimarko>
hauke: hostapd is problem
<Ansuel>
hauke there is a pr open
<Ansuel>
it's experiemntal tho
<robimarko>
guy that is doing it opensly said that he wont complete it without somebody funding that
<robimarko>
SAE is broken
<hurricos>
not surprising
<hauke>
ok, SAE would be the interesting stuff
<hauke>
if EAP TLS is not working I do not care much
<hauke>
EAP users can use openssl
<Ansuel>
hauke anyway so we decided on bump wolfssl and add all the info in forum post?
<hauke>
should we complain in privte to wolfssl?
<Ansuel>
hauke i agree also EAP doesn't make sense on low space device
<hauke>
to give them a change to improve
<hauke>
Their marketing is probably unhappy if we drop wolfssl and provide the reasons
<Ansuel>
hauke we should try so we can skip all this mess with abi and bump...
<neggles>
suspect their attitude is "what, you're not just compiling the whole system at once?"
<Ansuel>
...
<neggles>
"PaCkAgE uPgRaDeS oN eMBeDdEd DeViCeS?!?" (maybe i'm being a bit mean)
<jow>
whatever library we settle on, it should have LTS releases
<hauke>
The 5.5.1 is already released, I do not expect improvments there
<hauke>
but on the next one
<hauke>
5.6.0 ??
<jow>
wolfssl just seems to randomly change exposed api details without any regard for long term maintenance or backport-ability of fixes
<hurricos>
neggles: ohhh
<jow>
and they likely do not support older versions (free of charge)
<robimarko>
they gotta make money somewhere
<neggles>
(because they're expecting you to you compile it as part of a single unified system image, not do package upgrades, because that's what their commercial customers do)
<hurricos>
I'm just interested in the firmware. I'm interested in this pattern of using ARC CPUs to handle MAC
<hauke>
better the 2.28 branch
<Ansuel>
jow well nice... i would replace wolfssl with mbedtls on low space device and use openssl on bigger one... we can assume normal device to also support wpa3 and all the related feature... low space device probably doesn't have enough power to work with wpa3
<neggles>
oh i can bundle up /lib/firmware for you
<hurricos>
I can dig through that thanks
<hurricos>
poor-vendor's facsimile of the awfulness behind broadcom / ath>10k
<jow>
Ansuel: is there an internal crypto implementation for sae in hostapd?
<robimarko>
jow: nope
<hauke>
jow: no
<jow>
or does it require external lib support in all cases?
<jow>
odd
<hauke>
yes
<hauke>
SAE needs ECC which is not part of hostapd
<jow>
hm, and what if we would statically link openssl in hostapd to get a standalone sae-enabled build for low spec devices?
<robimarko>
I understand from hostapds view
<Ansuel>
jow we should check pkg size
<jow>
(and ship the system otherwise without ssl on low end devices)
<robimarko>
Thats gonna cause backlash
<jow>
then get a bigger device
<jow>
it's the standard response for bloat increase elsewhere as well, why should it be different here
<Ansuel>
are we really sure low space device can handle sae / wpa3 stuff ? can't we just ship it with no support for it as a limitation of the device?
<hurricos>
neggles: I saw, I was diging for the tarball offset :p
<robimarko>
jow: not a problem for me
<neggles>
then `dd if=Edgecore_MLTG-360_1.3.3-2646-72c8e391.rom of=Edgecore_MLTG-360_1.3.3-2646-72c8e391.ext4fs.zst iflag=skip_bytes skip=32768`
<hurricos>
Oh I could read the shell source to find out lol
<neggles>
it's 32kb
<robimarko>
Ansuel: why not?
<hurricos>
yeah $((0x8000))
<hurricos>
:p
<hurricos>
thakns
<hauke>
Ansuel: only the handshake is different between WPA2 and WPA3
<neggles>
also 31744 is the offset of the metadata json
<robimarko>
Only issue is usually 802.11w thats broken
<hauke>
and the protected Management frames
<neggles>
which is thoroughly uninteresting for anything other than repackaging the shellball so you can flash a version with your own keys in /etc/ssh/authorized_keys
<jow>
I wonder what pieces of libopenssl/libwolfssl are actually needed for SAE
<jow>
I assume just digests
<jow>
too lazy to dig into it right now
<Ansuel>
well we have time to sort it out
<hauke>
jow: and ECC for a ECDH handshake
<Ansuel>
now priority is wolfssl topic and how to fix
<jow>
Ansuel: I though tjhis is decied. Bump wolfssl to a new incompatible version
<jow>
and bump all users
<neggles>
oh hurricos fwiw, the firmware sources that are public in meta-terragraph are for the M80 release and edge-core is still on M60 which is... a bit old now
<neggles>
supposedly they're releasing M80 any day now
<neggles>
other compatible devices include: ubiquti AF60-HD, Cambium V1000/V2000 (which I didn't tell you about)/V3000/V5000, various Siklu things
<\x>
neggles: thats not good enough of a shitpost "PaCkAgE uPgRaDeS oN eMBeDdEd DeViCeS?!?"
<\x>
this one is better
<\x>
WPA doesn't hide the fact that i'm using WPA so that's why i don't use encryption because everyone is trying to crack encryption so i just don't use encryption because no one is looking at unencrypted data because everyone wants encrypted data to crack
<neggles>
\x: stupid like a fox >:D
<neggles>
ooh ubiquiti's image has newer firmware
Tapper has joined #openwrt-devel
<neggles>
interesting that these are all using DPDK/VPP for packet forwarding
<neggles>
guess that's the easiest way to get 3+Gbps out of a quad cortex-A53
<neggles>
robimarko: also on the ipq807x front, I picked up an XE5-8 because of Reasons. thing's *huge*
<\x>
so a client scanning on 6GHz will take time to find the AP
Gaspare has joined #openwrt-devel
<\x>
this needs to be advertised I guess
<\x>
11k
hanetzer2 is now known as hanetzer
<neggles>
i've not noticed much in the way of slowness
<\x>
I wonder how it is being done yeah
<neggles>
and it's not really all that much wider than 5150-5825
<\x>
isnt it 1200MHz full
<neggles>
depends on where you are
<\x>
meanwhile on 5Ghz its like 480MHz
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<neggles>
in any case it doesn't take very long to scan
<neggles>
few seconds
<neggles>
and once you're connected, yeah, 802.11k
<karlp>
\x: as well as the surveillance, you can also use bluetooth on APs to be bridges for bluetooth sensors, but yeah, location "services" is going to be the main use I'd imagine :)
<neggles>
heh. do I need to pull up the juniper/MiST AP bluetooth antenna array photo
<neggles>
three or four of these in an office and you can spatially locate any bluetooth device to within a roughly 30cm bubble
<karlp>
and that's _before_ bt aoa/aod features :)
<neggles>
yup
<neggles>
this works whether your device cooperates or not, and that's why they charge *eight hundred dollars a year* for licensing
<neggles>
so management can tell who's been slacking off T_T
<neggles>
it's also used for stuff like inventory and vehicle tracking in warehouses - beacons in pallets and on forklifts
<\x>
neggles: does it offer FT/SAE now?
<neggles>
the cambium?
<\x>
yeah
<neggles>
sure does
<\x>
based
<neggles>
full 802.11k/r/v
<neggles>
and all the other fun things
<neggles>
it is incredibly based but at AU$3500 sticker you'd hope it was
<\x>
maan this 11r +WPA3 thing puzzles so many people on the forums
<\x>
people dont know that SAE isnt FT/SAE
<neggles>
a sane and reasonable person would settle for "just" an XE3-4
<\x>
though I cant blame them, android and apple doesnt support it yet
<neggles>
which is 2x2 2.4 + 2x2 5 + 4x4 5/6
<neggles>
the thing that pisses me off the most is all of intel's 6ghz capable cards may as well not be
<\x>
why so? no IR on 6GHz?
<neggles>
even on the absolute latest firmware, the moment they see a single AP beaconing a non-US country code, they hard disable wifi until you reset
<neggles>
er
<neggles>
hard disable 6ghz
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<neggles>
and despite asiarf now showing their MT7916 cards as in stock, my preorder from june *still* hasn't shipped out, so all I've got is an mt7921U and MT7921K for 6ghz capable client
<\x>
mt7921u is fun
<neggles>
windows drivers don't work worth a damn though
<\x>
havent tried it on windows yet, I bought for monitor/injection, hella good for it.
<neggles>
it can see my 6ghz-only SSID
<neggles>
but when you try to connect, the firmware crashes and it does a usb disconnect/reconnect
<\x>
i think it has issues with intel pcs even on linux
<neggles>
works great on linux though
<\x>
AP mode atleast
<neggles>
...as long as you're running mainline
<neggles>
if you're using a usb wifi dongle in AP mode and expecting good performance, that's on you
<neggles>
so your neighbor who bought a xiaomi AX3000 kills it
<\x>
this is AX210
<\x>
its just no IR for him
<neggles>
lets see here
<\x>
do an iw scan
<\x>
then iw reg get, then iw phy whatever to see which is open which is not
<[Pokey]>
I decided to distclean and pull to try and fix my boatload of issues. Now on make download I get ERROR: package/network/config/qosify failed to build. Should I let the build continue anyway or will I end up with something broken?
<\x>
just continue
<\x>
qosify needs something to be built iirc
<\x>
as long as you dont include it, it wont matter
<[Pokey]>
I'm using the config.buildinfo for ramips so I assume it won't be included by default
<oliv3r[m]>
What phy-mode are we supposed to put in the devicetree for SFP+ cages? They can do both 10Gbase-r and 1000base-x; it depends on what you put in them. I just put the phy-mode to 10Gbase-r, and got some nasty crashes and polling (obviously a driver issue, but), however when putting the phy-mode in the dts to 1000base-X things actually work. I would expect that in the dts, we describe the hardware, since phy-mode isn't fixed, what should
<oliv3r[m]>
be there?
<neggles>
an sfp object
<oliv3r[m]>
(some polling of .read_status)
<oliv3r[m]>
neggles: what phy-mode should be set as part of the sfp-object :p let me link you
<Ansuel>
if you are using fixed-link you should not use fixed link in theory
<neggles>
oliv3r[m]: is there a second chip between your switch and the SFP+?
<oliv3r[m]>
nope
robimarko has quit [Remote host closed the connection]
<neggles>
please refer to line 110
<neggles>
and 89
<neggles>
you have a line 89, not a line 110
robimarko has joined #openwrt-devel
<oliv3r[m]>
ahh! ok, makes more sense now
<neggles>
some nics/switches have a "phy" sitting between the SFP+ and the ASIC
<oliv3r[m]>
e.g. rtl8214fc afaik would be one of those 'inbetween' chips; then you setup the link as 10Gbase-KR, while that chip will 'downgrade' the connection to whatever SFP you insert
<neggles>
correct
<neggles>
also a number of microsemi chips
<oliv3r[m]>
so the switch things its talking 10Gbase-KR
<neggles>
most of them have incredibly cursed functionality such as internal loopbacks and mirrors, not just speed-shift
<neggles>
you do have a (logical) phy between interface and port
<Ansuel>
12x U.FL connectors O_O
<neggles>
sfp object goes under phy27
<neggles>
IOW you do have a line 110 :P
Gaspare has joined #openwrt-devel
<Ansuel>
robimarko they provide documentation with the development board? :DDDD
<neggles>
i think? not sure how that works with one shared phy
<Ansuel>
buy sample --> login YES
<slh>
that's also what's putting me off the idea of the BPi/r3, after adding all the pigtails and antennas to the tally, it costs at least twice as much
<neggles>
pffffffft just whack a bunch of the $2 pcb pigtail antennas on it'll be fiiiiiiiiiine
<Ansuel>
the soc even support 2 sim slot wow...
<neggles>
the miniPCIe/M.2 card slots do
<neggles>
nothing to do with the SoC :P
<slh>
neggles: my priority is using devices, not just testing them - so the resulting range/ throughput should be reasonable. and for 5 GHz and 6 GHz, antennas and pigtails aren't that easily source - especially in quantities for a single device (iow, not being able to scout the market first and buy samples from n+1 sellers)
srslypascal has quit [Remote host closed the connection]
<neggles>
slh: I see I should've added the </s> :P
srslypascal has joined #openwrt-devel
<robimarko>
Ansuel: Yeah, thats the point of dev boards
<robimarko>
To have a "known" good working platform and not have to guess everything
<neggles>
i spent *way* too much money on this thing
<neggles>
to risk hurting it
<neggles>
they're not easy to come by
<Ansuel>
TestNET
<Ansuel>
ahahha
<neggles>
001001
<robimarko>
If they are hard to get for you, when are we poor peasants gonna be able to get one
<neggles>
I mean it's also in a spectrum licensed band
<neggles>
it's just 28ghz so the range is so damn low that it doesn't matter
<neggles>
that's with a single 100mhz NR carrier and one 10mhz LTE carrier, the samsung doesn't want to do 10+10 LTE and 100+100+100 even though it's capable of it
<neggles>
something misconfigured somewhere
<neggles>
in theory that base station is capable of 4.8Gbps downlink and 1.6Gbps uplink to four clients simultaneously
<robimarko>
Whats the effective range?
<Ansuel>
let me search an image to understand how vodoo internally that thing is /for 4f for example)
<neggles>
FCC internal photos are confidential
<neggles>
robimarko: to a phone, about 200-300m
<neggles>
to a fixed CPE, about 1km
<Ansuel>
need to find the damn video
<neggles>
insanely tight pencil beams and almost 400W EIRP
<robimarko>
So, just short enough for you to newer get caugth?
<neggles>
correct :)
<neggles>
it's also only good for 125 degrees azimuth and about 30 degrees elevation
<[Pokey]>
What does Error 2 on build (V=sc) without any further explanation provided mean?
<robimarko>
I have an neighbour that works for HAKOM, the regulatory agency and drives their mobile measurment truck
<neggles>
this particular one was installed on the roof of a bar in Chicago
<neggles>
silly verizon, you have to factory reset the unit *after* you deconfigure it in your ZTP system
Gaspare has quit [Quit: Gaspare]
<neggles>
robimarko: it's also incapable of being a P-cell, so it doesn't really transmit until the primary gets a connection from a device that's capable of talking to it
<neggles>
whereupon it starts sweeping all four beams across every possible beam angle until it finds a path to the UE
<robimarko>
Now you are talking nuclear physics with me
<neggles>
cellular carrier aggregation, the first cell you connect to is the P-cell (primary cell) and all control channel traffic goes across that one
<neggles>
then extra channels on the same or other bands are S(econdary)-cells
<neggles>
in the simplest configuration this unit has to be slaved to an LTE cell, which handles coordination with UEs (User Equipment, phones and fixed wireless CPE) and the like
<neggles>
if the P-cell has no mmWave capable clients connected, the mmWave PS-cell (yeah. the first of the 8 100MHz channels it has is called the primary secondary cell. because this wasn't confusing enough...) and S-cells don't transmit
<Ansuel>
you are in us right?
<neggles>
nah
<neggles>
the unit is right now, at a friend's place
<neggles>
it will be getting shipped here soon enough
<Ansuel>
i mean in europe no mmwave phone so that's why i'm asking
<neggles>
europe has mmwave phones, just not iphones
<neggles>
i'm in australia
<Ansuel>
samsung phone are still sold with no antenna
<neggles>
as usual there's two SKUs and sometimes you can get both
<Ansuel>
i read that italy is the only one using mmwave tech and the only carrier is fastweb for fixed wirless broadband
<neggles>
mmwave is kind of a wank for anything other than fixed wireless or "80,000 people in a sports stadium" anyways
<neggles>
(AU also don't get mmwave iphones, and our local mmwave deployments are on 26ghz not 28ghz, which is a challenge for finding a UE, but details)
<neggles>
but ya boi neggles has enough cell tower equipment to cover a small town, because it's fun and it's interesting to learn how it all works
<Ansuel>
read that even a finger stops signal of mmwave
<Ansuel>
the you are holding it wrong meme back again
<neggles>
eh, that's mostly a solved problem, they use four antennas and shift between them
<neggles>
spoiler: how mobile phone networks work, is ludicrously complicated
<neggles>
also the operating system that runs on the radio unit itself is the bastard lovechild of OpenWrt and Wind River Linux so that's fun.
<neggles>
it's a Xilinx XCZU9EG Zynq UltraScale+ MPSoC and a couple of custom Ericsson RFICs
<Ansuel>
install mainline openwrt on a cellular cell and use it as an AP LOL
<neggles>
you could *probably* do that on one of the LAA/LTE-U capable units
<neggles>
but the secure boot stuff is pretty airtight and good luck getting GPL tarballs for *any* of it
<Ansuel>
new device: add support for Xilinx XCZU9EG Zynq UltraScale+
<neggles>
zero point for AIR 1281
<Ansuel>
Installation instruction: Steal one from a tower cell
<neggles>
custom ericsson silicon driving the radio
<neggles>
1. buy one off ebay
<neggles>
2. ask neggles for firmware and licenses
<Ansuel>
3. get rejected
<neggles>
nah i'm happy to share
<Ansuel>
also GPL source?
<neggles>
hah
<neggles>
no
<Ansuel>
HAH
<neggles>
ericsson will not give you it unless you're a paying customer
<neggles>
and i am not that. ericsson don't like me much.
<neggles>
I keep telling people their secrets.
<Ansuel>
guess all this stuff is really confidential cosidering they are somewhat mission critical
<neggles>
i mean ericsson keep it secret from their customers even
<neggles>
and the baseband units run on Intel Axxia SoC-FPGAs
<neggles>
an entire product line that publicly, doesn't exist
<neggles>
(yes, i have two of those, yes, they work, if you buy a pack of SIMs from sysmocom and have a NUC to run Open5GS on i'll tell you how)
<neggles>
n.b. requires special GPS receiver or stratum-1 NTP server to function
<neggles>
NTP polling rate is 3Hz
<Ansuel>
o.O
<neggles>
they frequency and phase synchronize
<neggles>
so you can have a dozen of them all on the same channel, which is the same channel as a nearby macrocell
<neggles>
without any interference issues
<Ansuel>
ingeniuos idea to sync all the cells
<Ansuel>
wonder what happen if you mess with that tho
<neggles>
it shuts down
<neggles>
in frequency and phase sync mode, after 24 hours without GPS, it stops transmitting
<neggles>
you get a week in frequency-sync-only mode
<neggles>
the timing tolerances here are ludicrously tight, you need to be below 200 nanoseconds for frequency sync and below 20 for freq+phase
<neggles>
sorry, 200 microseconds and 200 nanoseconds, i always mess that up
<Ansuel>
well you are emetting freq like a macrocell, out of phase and you emit 0/they conflict each other
<neggles>
yup
<neggles>
freq sync only mode still allows channel sharing, but more careful coordination and you can't have neighboring picos that can hear each other on the same channel
<neggles>
whole thing's utterly nuts
<Ansuel>
this thing is complex as fk
<neggles>
heh
<Ansuel>
fun that all coordinate with time
<neggles>
yup
<[Pokey]>
neggles: Sorry to pitch in but do you have a channel dedicated to this stuff I can watch? I find mobile infrastructure incredibly interesting
<neggles>
as well as Osmocom's website, and their various talks/videos
<[Pokey]>
Neat, thanks!
<[Pokey]>
I had looked at BTSes on eBay but expensive much
<neggles>
pico 6402 up there is pretty cheap
<neggles>
sadly i've not gotten the 2nd radio in there to work yet, it's LAA (uses 5ghz wifi band for extra downlink with some careful coordination to avoid screwing up wifi too much)
<neggles>
but it'll do 300x50mbps with just the other one
<[Pokey]>
I'm more noob at mobile networking than I am at OpenWRT :P What does that thing support?
<neggles>
it is a 2x2 MIMO 20MHz bandwidth LTE picocell
<[Pokey]>
LTE, nice
<neggles>
~250-300mW TX power on Band 2, Band 4, or Band 7
<neggles>
it's not directly radio related but IMO it's something anyone who owns a phone and understands tech should watch
<neggles>
SIM cards are *terrifying*
<[Pokey]>
I hear there are some grossly insecure parts around the whole thing
<neggles>
kinda.
<neggles>
modern ISIMs have ludicrous quantities of computing power, run an entire java based operating system, and have a backchannel to your carrier that cannot be monitored or blocked or controlled
<Ansuel>
java....
<[Pokey]>
We talking more than "javacard" here?
<neggles>
they're javacard based
<neggles>
and *so much more*
<[Pokey]>
eek
<neggles>
fun fact: VoLTE *requires* IPSec
<[Pokey]>
Glad I don't use an ISIM then
<neggles>
if you have VoLTE, or a SIM card manufactured in the last 5-7 years
<neggles>
you have an ISIM
<[Pokey]>
Oh
<neggles>
and USIMs aren't much better.
<[Pokey]>
I thought you meant Integrated SIM
<neggles>
nope
<[Pokey]>
jeez
<neggles>
ISIM is just the successor to USIM
<neggles>
enables VoLTE amongst other things
<[Pokey]>
Do we know what kinda data traverses that backchannel?
<[Pokey]>
one of my feet is in said rabit hole and I am deciding if I wanna go down it
<neggles>
nah just spending all your money
<neggles>
if you're not careful you'll get in trouble with the regulatory authorities
<neggles>
just run low transmit power and don't use channels that are in use nearby
<neggles>
and, y'know, turn it off when you're not using it
<Ansuel>
setup all of it in an airport
<neggles>
but, one day you're trying to set up a tiny 2G cell so you can make a phone call on a Motorola RAZR V3 in 2020 (successful btw, it's about the size of a paperback and uses LTE for backhaul :P range of about 15 meters)
<neggles>
the next thing you know you've got an entire macrocell setup, four commercial picocells, twelve commercial femtocells in various states of hacked, and you just bought a mmWave base station
<neggles>
I CAN QUIT ANYTIME I WANT
<Ansuel>
suuure
<[Pokey]>
neggles: So, how did you start all this? What happened?
<neggles>
> one day you're trying to set up a tiny 2G cell so you can make a phone call on a Motorola RAZR V3 in 2020
<[Pokey]>
haha fair
<Ansuel>
the other you have a priavte isp like that guy in us
<neggles>
i bought a LimeNET micro and turned it into a GSM femtocell that i can carry around in a backpack
<neggles>
works great
<neggles>
then i bought a couple of AT&T 3G femtos to break into because they were $15
<neggles>
and nobody had done it yet
<neggles>
took me a month but i got there
<Ansuel>
only 15 ?
<neggles>
they're old and slow
<neggles>
a whopping 5mbps
<Ansuel>
still it's a lot of tech
<neggles>
it's an ip.access nano3G with some cisco garbage glued to it
<neggles>
and they don't work anymore
<neggles>
at&t shut down the backend for them years and years ago
<neggles>
so to most people they're bricks
<neggles>
funny thing is, the prov server's still up, but all it does is send a command to trigger the tamper detection and shut down
<neggles>
then i got the pico 6402 after seeing that the osmocom guys had made them work
<neggles>
and it just kinda escalated from there
<neggles>
anyway i better sleep and also quit being fairly off-topic :P
<Ansuel>
right all of this stuff have a self destruct thing
<neggles>
yeah but none of them work.
<neggles>
only the femtos with broadcom chipsets actually wipe their own firmwarer
<Ansuel>
(btw on another topic it's incredible the amount of open vdsl cabinet in italy... like half of them are open...)
<neggles>
but they also basically netboot in the first place, so it's whatever. classic broadcom.
<Ansuel>
ok so your intention is to have your private carrier instead of using voip and simple wifi bridge ahahhaha
<Ansuel>
overkill
<neggles>
it's still voip!
<Ansuel>
but really fun
<neggles>
it's just fun and educational.
<neggles>
makes you appreciate your phone and the network that powers it much more.
<neggles>
g'night :)
<Ansuel>
right australia
<Ansuel>
you are upsidedown gn :D
<ynezz>
jow: how is that PKG_REVISION:=1 supposed to work? I can't find anything referencing that with `git grep PKG_REVISION`
<Ansuel>
also how that works with the autorelease macro ?
<Mangix>
Ansuel: cmake PR was reported as working.
<Ansuel>
Mangix hoping the cleanup continue for the other lib :D
<oliv3r[m]>
<neggles> "you do have a (logical) phy..." <- According to the DTS? probably; I'll look why the proper phy-mode doesn't work later; or figure out what the proper phy-mode is supposed to be; but all of that is 'interal' to the SoC though
danitool has joined #openwrt-devel
<Mangix>
Ansuel: I'm tempted to fix by removing tools/zstd
<Ansuel>
o.o
<Mangix>
And adding dependencies with prereq-build
<Ansuel>
so use the host zstd ?
<Mangix>
Yeah. That's also what toolchain/gcc currently does
<oliv3r[m]>
neggles: Btw, I do see in phylink_validate; that it is reported as 10gbase-r; even those phy-mode is set to 1000base-x in the dts; maybe on older kernel you set it to the lowest and it upgrades itself? idk :(
<robimarko>
Is in band management enabled?
<oliv3r[m]>
yep
<robimarko>
Then it really should set the PHY to whatever mode Phylink requests after parsing what module supports
<oliv3r[m]>
my question was initially 'what should phy-mode' be set to in the dts; first we said its hould be gone, which doesn't work; then 10Gbase-r; which causes a crash; so back to 1000base-x which works, and gets 'upgraded'
<robimarko>
Well, thats the thing, with SFP only port that shouldnt really matter at all
<robimarko>
As Phylink is gonna override it as soon as module is plugged
<oliv3r[m]>
exactly; maybe 5.10?
<oliv3r[m]>
very poor driver :p
<robimarko>
It could be shitty driver
<oliv3r[m]>
something to look into later :p
<oliv3r[m]>
anyway, my bigger issue; when I plug in an SFP port; SFP detection stuff runs; fine; then from switch_ops; phylink_validate gets triggered, that does something; then gets triggered again 9with the proper phymode, sot hat's probably the reason?) great. the phy gets re-configured, and phylink_mac_config gets called. (currently) Phylink is supposed to train/calibrate the serdes, but for that to be done properly, I need to know what port we
<oliv3r[m]>
have (copper DA, fiber etc) and the SFP eeprom data (cable length) which are all part of the sfp object. I can get it, from phy_device afaik; however, phy_device isn't supplied via phylink_mac_config, only dsa_switch is (which doesn't contain anything). After mac config, stuff gets enabled; so it would be 'too late' to calibrate my link then
<oliv3r[m]>
so how can I get those parameters from phylink_mac_config (or where should I go calibrate thel ink otherwise?
<robimarko>
Hm, I think I had similar issue with QCA8075
<robimarko>
As there is no way to get the phy_device
<robimarko>
And that is intentionally
<oliv3r[m]>
well I need the SFP object technically :D
<robimarko>
Whats that struct name?
<robimarko>
Its been a while
<oliv3r[m]>
for the sfp? good question. I know struct sfp_bus *sfp_bus; is needed to query some stuff
<robimarko>
Yeah, that
<oliv3r[m]>
but I could be chasing the wrong rabbit; not sure so far
<robimarko>
What stuff does phylink_mac_config provide, so I dont have to search?
<robimarko>
Well, you have struct phylink
<robimarko>
Nope
<oliv3r[m]>
So `PORT_DA` (crappy name) is what I want, and is generated by sfp_parse_port (hopefully internally by the SFP stuff) and is commonly stored in `pl->link_port = pl->sfp_port;` not sure yet what :p (link port or sfp port)
<robimarko>
Not the generic phylink_validate, but rather its DSA OP
<robimarko>
They introduced get_caps to replace it
<oliv3r[m]>
ah right; yeah was reading through get_caps
<oliv3r[m]>
calibrating during 'port_enable' sounds way to late however, right?
<oliv3r[m]>
because during port_enable we do get this data that we so desperatly need :p
<robimarko>
I suppose it could work even there
<robimarko>
Is interface mode available?
<oliv3r[m]>
phy_interface_t phy_mode I have yes
<oliv3r[m]>
but that just tells me `PHY_INTERFACE_MODE_10GBASER`
<robimarko>
Then it should be possible even that late
<oliv3r[m]>
hmm, port_enable however, doesn't seem to run after plugging in an SFP module; so it's a different kind of enable :(
<oliv3r[m]>
and no i don't, i have `struct dsa_switch *ds, int port, struct phy_device *phydev` as args, which should contain it though
<robimarko>
That should be what gets called once netdev is called up
<oliv3r[m]>
i see it in my bootlog; just not on sfp insert/removal
<oliv3r[m]>
could that be related to the driver at all? or is this all handled at upper layers?
<oliv3r[m]>
heh, I think our hacky driver is already keeping a copy of everything intside its private structure :)
Piraty_ has joined #openwrt-devel
<robimarko>
Then half of hack already done
Piraty has quit [Ping timeout: 480 seconds]
<Borromini>
oliv3r[m]: looking into the SFP+ ports? :)
<oliv3r[m]>
lol yes, what a mess :(
<oliv3r[m]>
i found the 1250-12 issue though; and it's very dumb :p
<Borromini>
ok :P
MaxSoniX has quit [Quit: Konversation terminated!]
<[Pokey]>
Is there any documentation explaining the names of the output bin files for firmware? My file is called openwrt-snapshot-r20784+1-ec8fb542ec-ramips-mt7621-zbtlink_zbt-wg1602-v04-32m-initramfs-kernel.bin all of a sudden when it used to be called openwrt-snapshot-ramips-mt7621-zbtlink_zbt-wg1602-v04-32m-initramfs-kernel.bin and I am trying to understand exactly what causes that
<Ansuel>
+ means you have special commit in your buildroot
<[Pokey]>
Special commit?
<Ansuel>
not upstream one
<[Pokey]>
Well yes that is definitely true. I have one of my own commits
<Ansuel>
see
<[Pokey]>
But I have had that for days and it has never said "snapshot-r20784+1-ec8fb542ec" just "snapshot"
<Borromini>
you're poking around in git, you should be able to deduce most of that working with the tree
shibboleth has joined #openwrt-devel
<oliv3r[m]>
Borromini: So in the DTS, we have to set the `phy-mode` to `1000Base-X`, right now, it's set to `10GBase-R`. Better yet, ideally, we remove the node completly, because we are detecting the mode, and overwriting it, which we even see when setting 1000Base-X; but stuff just crashes or breaks or doesn't do the right thing when we don't set phy-mode incorrectly to 1000Base-X :(
<[Pokey]>
Borromini: I got pretty much the lot of it bar the whole snapshot-r20784+1-ec8fb542ec thing. I understand that +1 means +1 ahead of upstream. Cool. ec8fb542ec is the last commit I had pulled before I applied my +1. Cool. Not sure how r20784 is produced - where it comes from, where it is stored? And I am also curious how it realises there's a +1. Does it just look ast "master" in comparison to current branch and say ah, +1?
<Borromini>
[Pokey]: run ./scripts/getver.sh in your tree
<Borromini>
you can read through that script to see how it gets its values
<Borromini>
oliv3r[m]: cool. so multiple clues to where it's going wrong, if i understand correctly?
<oliv3r[m]>
yeah, our drivers are just pretty poor in a lot of places, and being on 5.10 is not helping either :(
<Borromini>
i understood 5.15 has some showstoppers of its own on realtek no?
<[Pokey]>
Borromini: Perfect, thats super useful thank you. I assume that I will then understand why it was just "snapshot" before, too.
<Borromini>
[Pokey]: master builds have historically been named 'snapshots' afaik.
<Borromini>
when i look at my own master or builds though i don't see the revision number or git hash in it, nor 'snapshot'
<Borromini>
[Pokey]: always useful to check ./scripts/diffconfig output if you accidentally flipped some switch somewhere
<Borromini>
that will show differences between your config and what's default for your target.
<[Pokey]>
Forgive me, Borromini, by master build I cannot assume you mean straight from the master branch nor can I assume you mean downloaded from the OpenWRT downloads page, so I am not sure quite what that means. I also just ran the diffconfig and it spewed a lot of stuff out. Either thats normal because my .config is a copy of config.buildinfo for ramips so its not the absolute default, or something has gone very wrong and I don't know quite
<[Pokey]>
what
<Borromini>
there's not need to grab the config.buildinfo normally. The buildroot has its defaults baked in for each target
<Borromini>
the one you grab is for the buildbot, which builds for all targets (all hardware supported) and all packages by default AFAIK.
<Borromini>
a build can be both compiled by you or an official OpenWrt image, although people will explicitly refer to the latter as 'official' or 'vanilla', or another term to make set them apart
<[Pokey]>
I am using it for exactly that purpose. So that my produced image contains exactly what comes as default when downloading OpenWRT. The only change I have made via menuconfig is to target my specific device, which is why I have a +1. I have a commit which adds support for my device in my tree
Borromini has quit [Quit: Lost terminal]
<[Pokey]>
I really appreciate your advice, I will read the getver script soon to get a good understanding of why it has suddenly changed name. I'm trying to learn how to use the build system from scratch here and one of the other issues I am persuing is why I can no longer use the official opkg repo because my kernel has suddenly changed
<[Pokey]>
It's the little bits like this I find are undocumented and only really known by asking here for advice
<Ansuel>
[Pokey] would be really good to document your finding
<Ansuel>
example i was aware of this as i had some changed in luci and the same logic was used for luci versioning
<Ansuel>
also if you want to know
<Ansuel>
the system know you are +1 +2 +324097
<Ansuel>
based on the origin/master commit
<Ansuel>
he just checks the amount of commits diverge and that's all
<[Pokey]>
Ansuel: I would like to document, but I don't feel confident just going forward and editing these very important and heavily public facing and used wiki pages
<Ansuel>
it's all really local to your repo
<[Pokey]>
Thats good to know, thank you
<Ansuel>
[Pokey] if you understand the logic and you have good example it's just added info... there is no harm in adding info to it... at wors add a secion with a disclaimer or even ask if it's good on irc :D
<Ansuel>
we don't bite
Borromini has joined #openwrt-devel
<oliv3r[m]>
Borromini: not sure, I think some of those are getting resolved
<[Pokey]>
Ansuel: It's a me problem definitely haha. I'm used to more modern chat platforms in general. People here just have names and no profile pictures (ignoring things like IRCCloud, Gravatar) and for some reason I find it hard sometimes to follow conversations and also guess how a person means something. Basically, I don't wish to be a pain in the ass to anyone, I want to learn but sometimes I have to ask really basic questions because I
<[Pokey]>
land myself in the middle of something managing to skip prerequisite information people just expect me to know
<Borromini>
oliv3r[m]: the L2 learning thing seemed the biggest issue last time i checked? (Way over my head though)
<oliv3r[m]>
Ansuel: why is daniele golle not following the patch guidelines? :p
<Ansuel>
mh?
<oliv3r[m]>
I was just gonna comment 'yeah sure lets merge it' and I check, and 6 new patches :p
<Borromini>
oliv3r[m]: you can ping him he's in the channel :P
* Ansuel
grabs popcorn
<oliv3r[m]>
:p
<Borromini>
Ansuel: :D
shibboleth has quit [Quit: shibboleth]
<oliv3r[m]>
If i'm all doing it for nothing; that'll be good to know too :p
<Borromini>
hehe
<Ansuel>
oliv3r you had done the big work of sorting all the submitted by and to clean them so honestly it's not for nothing. If other wrong patch comes later as some push patch by mistake/hurry it will be much more easier to fix
<Ansuel>
before fixing the problem of rebuildling tool
<Ansuel>
wanted to wait for aparcar for the container topic but i think he is very buys so i wonder if i should just merge and fix this problem
<Ansuel>
(currently the kernel workflow is very fragile and we test only 35 target out of 75)
<Ansuel>
increase if from 2h 38minutes to 3h 40 minutes
<Ansuel>
MHHHH difficult to take decision
<oliv3r[m]>
Ansuel: just pushed the latest patches :p
<Ansuel>
just notice thanks a lot !
<Ansuel>
have to take a shower and i will merge!
<Borromini>
best to do merges clean!
<Borromini>
is there a way to manipulate the IPv6 prefix OpenWrt hands out on the LAN?
<Borromini>
I just noticed OpenWrt decided to renumber after I introduced a guest network...
<Borromini>
now the guest network gets the nice prefix (:1500:) and the lan the ugly one (:1510:) :'(
<Borromini>
i'd very much like to keep this static so I do not need to keep fixing my static clients...
<Borromini>
looks like option 'ip6hint' might do what I need.
<Ansuel>
yep
<Ansuel>
ip6hint should do the trick
<Ansuel>
i used it to assign from my /48 he tunnel ::1 to lan and ::2 to guest
soxrok2212 has quit [Quit: Who ate my gummy worms?]
soxrok2212 has joined #openwrt-devel
<jow>
ynezz: sorrs, I meant PKG_RELEASE
srslypascal is now known as Guest1799
srslypascal has joined #openwrt-devel
Guest1799 has quit [Ping timeout: 480 seconds]
<[Pokey]>
Would someone be so kind as to go into OpenWRT history mode for me and explain to me why ee53a240ac902dc83209008a2671e7fdcf55957a or "LEDE Reboot" is the important stage in OpenWRT's life when the revision numbers started?
<jow>
the project was forked and lede reboot was the initial revision of the fork
<jow>
eventually the project remerged and the fork become canon
<jow>
*became
<[Pokey]>
Neato. OpenWRT trivia question I guess haha
<[Pokey]>
Thank you
<[Pokey]>
Another question if someone doesn't mind answering it too. What are the revision numbers used for? I can see they're just a counter of commits since that Reboot commit
<dwfreed>
easy to numerically differentiate between revisions
<dwfreed>
most useful when using various snapshot builds
<jow>
right, a monotonically increasing counter, that's all
<dwfreed>
can't exactly sort git hashes
<Ansuel>
git hashes are just hashes
<Ansuel>
unique identifier
<[Pokey]>
Thanks. For context I am writing a small explanation as to the output image files naming syntax
<Ansuel>
ok i should really resurrect my work for the hw driven leds
<Ansuel>
we have now what 4 user that would benefits for it and 0 review from led team...
<Ansuel>
only review i got was a marvell guy that just wanted to implement his own version at all cost even with a netdev reviwers approving mine and saying it was a better approach
<Ansuel>
wth
<Ansuel>
ok enough reason to respin
<Ansuel>
or at least merge a stable version on openwrt as a pending patch so more people can use it
soxrok2212 has quit [Ping timeout: 480 seconds]
robimarko has quit [Quit: Leaving]
<Mangix>
Ansuel: hmm?
soxrok2212 has joined #openwrt-devel
dangole_ has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole_ has quit [Remote host closed the connection]
dangole_ has joined #openwrt-devel
<Borromini>
Ansuel: yes, did the same here. Thanks for confirming :) Gonne come in handy.