<slh>
aside from the heat and power requirements, given that ppc (iirc p1020) can't really keep up with mt7915 anymore, I'd doubt QCA9558 would be the best idea to try
Tapper has quit [Quit: Tapper]
isak has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
minimal has quit [Quit: Leaving]
<\x>
Mangix: AX210 ahaha
<Namidairo>
I think it already struggles with the card it came with, let alone another one
<\x>
<schmars[m]> can't give you a upper number on routing
<\x>
itll route gigabit with tweaks, move irqs around and a bit of an overclock
<Namidairo>
just iperf outwards from a wireless client to a server on wan
<\x>
700~ codel, 200~ cake
<Namidairo>
meanwhile the c7 will collapse in on itself and tap out at like <300
<\x>
I think even with sfe they wont even do 500 wired routing
<Namidairo>
any QoS and it's basically done
<Namidairo>
I wouldn't even trust it on 100mbit because it's probably close enough to start destroying ping if it spikes or has to do pppoe or wlan encap/decap
<\x>
somebody should put a set-interrupt-affinity script for these things heh
<\x>
i tested it out, for real balance like spread, 1tx and 1rx per core, there are situations where both are used, so a single core handles both tx and rx, and it drops perf, not huge but it drops
<\x>
so what I did is to move all tx to a core, and all rx to another core, now two cores always work when routing
xback has quit [Remote host closed the connection]
<alexey>
Changing uImage header breaks rootfs mount
danitool has joined #openwrt-devel
indy has quit []
indy has joined #openwrt-devel
borek has joined #openwrt-devel
<PaulFertser>
alexey: I do not see the boot log attempting to boot uImage with the right (kernel only) size in the header. I also do not see DTS file you're using.
<PaulFertser>
alexey: and why is Factory partition so big that it includes "firmware" partition?
<alexey>
PaulFertser includs kernel + squashfs
robimarko has joined #openwrt-devel
<PaulFertser>
alexey: OpenWrt convention is to use "firmware" for uimage+squashfs. And DTS should define compatible "denx,uimage" for it, then it's auto-splitted properly.
<PaulFertser>
alexey: and none of the partitions defined in the DT should be intersecting.
<alexey>
PaulFertser Updated thread. But I have non-standard uImage. What to do in this case?
<PaulFertser>
alexey: why do you have a non-standard uImage?
<PaulFertser>
alexey: "OpenWRT boot log with the right (kernel only) size in the header" log looks like it works nicely though?
<alexey>
PaulFertser yes, it works nicely with standard uImage. But to use the native uploader I need write File size in the field at 0x0C address.
* ldir
can't quite believe that he's written sed -nre 's#^.*[^0-9]([46])$|.*[-_]([46])[-_].*$|^([46])[^0-9].*$#\1\2\3#p'
<PaulFertser>
alexey: by native uploader you mean vendor's web interface?
<alexey>
PaulFertser yes
<alexey>
It breaks everything
<ldir>
the regexp competent will now no doubt be falling off their chairs laughing
<PaulFertser>
alexey: I can imagine two-stage installation then: you use native uploader to flash an initramfs image, and then regular sysupgrade to flash a proper sysupgrade image.
<alexey>
PaulFertser interesting. Does that mean there is no other way? I already wanted to pick OpenWRT scripts)
<PaulFertser>
alexey: if that vendor firmware is sick like that, I see no other sane way. And flashing from vendor is just one-time job anyway, so making it slightly more complicated isn't a deal breaker.
<alexey>
PaulFertser then with the method of loading decided. Take care of other questions. Thanks a lot
<PaulFertser>
alexey: thank you for working on upstreaming support for this device properly :)
<[Pokey]>
I have been thinking about broadcom hardware... Why do we have so much trouble with it? Sure, theres no open source drivers, but the fact the hardware even exists means theres drivers for it, just closed source ones. Whats to stop us extracting those drivers and using them? Obviously they cannot easily be distributes, but they could surely be grabbed and used?
<\x>
one is getting stucked to an old kernel
<\x>
abi compatibility shiz
<olmari>
binary blobs supporting mostly always ancient kernels, being highly specific to whatever custom shit they put in, IP and NDA also
<[Pokey]>
:/
<Namidairo>
broadcom would kick down your doors then audit your vmware licenses as well
<Namidairo>
the only actual broadcom development I've seen in the last while is support for the fullmac card that comes with the M1/M2 macbooks
<PaulFertser>
There were also some firmware enhancement projects to allow monitor/injection on some smartphones.
alexey has quit [Remote host closed the connection]
<Namidairo>
those were patched firmware images weren't they
<\x>
QSDK's 5.4 but in here the memory is way lower again?
<robimarko>
[Pokey] Well, I cannot find in-tree driver supporting that ID
<\x>
I think he'll come here in a while later he want to join that matrix group you guys made
<[Pokey]>
robimarko: Most likely going to be something I need to instruct the driver to recognise
<[Pokey]>
If the appropriate driver supports that function, like another RT driver I have used before does
<robimarko>
[Pokey] Actually, you want the RTL8712 staging driver
<robimarko>
It lists that ID, but expect it to be half-broken
<[Pokey]>
Do I? I thought I would be best off using a non staging driver
<[Pokey]>
non fullmac
<robimarko>
[Pokey] But which one?
<robimarko>
None list the ID
<robimarko>
\x: What do you mean memory is lower again?
<\x>
i think he used the wrong memory profile or something?
cbeznea has quit [Quit: Leaving.]
<robimarko>
\x: I am gonna be honest and say that I dont care
<[Pokey]>
robimarko: :/ Yea right, I just realised the last adapter I messed with was Atheros. RTL probably works completely differently I guess, can't force the driver to load on an unknown ID
<robimarko>
[Pokey]: RTL has so many completely incompatible chipsets that just adding an ID wont work
<[Pokey]>
I think this task might be above my grade
<[Pokey]>
Its one thing taking a complete driver and compiling it for a target but its another entirely to try and get a staging driver to play ball
<robimarko>
Well, you can just package it in mac80211
<robimarko>
And try it out, maybe it works fine enough
<[Pokey]>
robimarko: mhm, I have a lot of prerequisite learning to do before I can even begin to comprehend fully what you just said to do unfortunately
<ynezz>
f00b4r0: lets continue here, it's proper place for such discussion anyway, is it a know issue already fixed?
<f00b4r0>
ynezz: I think it's a non-issue
<f00b4r0>
basically customer uses a custom-built coova-chilli (they need SSL enabled, the "official" build does not enable SSL by default iirc). Custom-built package was built against 5.2.0, and for some reason loads, but of course does not work properly with 5.5.1
<f00b4r0>
at least that's my current understanding of the otherwise unexplainable breakage symptoms
<f00b4r0>
ssl is needed for radius operation AIUI, which seems like a common-enough use case for chilli, maybe we should have a -ssl variant built along the current default
<f00b4r0>
(until we can kill chilli with fire, that is :)
<ynezz>
f00b4r0: anyway, IMO it's a bug you've hit and should be recorder in form of bug report so it could be referenced
<ynezz>
ideally if you could track it down/bisect it to a specific commit in wolfssl :P
<f00b4r0>
well is it really a bug? I understand you're not supposed to execute a binary linked against an ABI-incompatible version, are you?
<f00b4r0>
it boils down to wolfSSL poor ABI management, but that's nothing new
<ynezz>
the more detailed evidence of such breakages, the better for our eventual final decission
<ynezz>
"We do have API's marked with WOLFSSL_ABI and those are binary compatible. Meaning you can update wolfSSL and not have to rebuild your application if those API's are used." is such a bold claim.
<f00b4r0>
Tracking this down requires diving into chilli's code. I'm afraid that's not something I'm willing to do. I'm happy to say that "chilli linked against 5.2.0 running on 5.5.1 breaks", but I'm not sure that will be very helpful
<ynezz>
I didn't looked into coova, since as you've already stated we don't ship it ssl enabled, but I assume, it would be public ABI/API only as well
<f00b4r0>
I'll see what a quick grep shows
<f00b4r0>
i'll first want to confirm that rebuilding the package "fixes" the issue, because so far it's mere speculation on my end
<f00b4r0>
but the coincidence is striking.
<ynezz>
well, it's very likely, that someone is going to bump into this as well, so having answer indexed by search engines is going to save them some time :P
<f00b4r0>
i get that. It's just that whether I post on chilli's tracker or on wolfssl one, the answer will very likely be "you're not supposed to do that". Unless I can prove chilli only uses WOLFSSL_ABI calls, which I'll try to check quickly for :)
<f00b4r0>
i just don't want to get into that code base, it gives me nightmares ;P
<f00b4r0>
ynezz: yes seems you're right, afaict chilli knows nothing about wolfssl and only uses openssl calls
<f00b4r0>
i guess the next question is: are *all* of these calls implemented in wolfssl with "WOLFSSL_ABI" (I would expect they are but who knows)
<ynezz>
so you could claim, that you're API compatible, but break ABI? :)
<nbd>
i think we should probably switch back to mbedtls as soon as its hostapd support is properly tested
<nbd>
wolfssl is just way too fragile for my taste
<pepes>
openssl is the way! :-D
<nbd>
haha
<ynezz>
nbd: want to join a round table discussion with wolfssl folks instead? :P
<jow>
nbd: or statically link hostapd against those openssl bits needed
<ynezz>
I still believe, that wolfSSL is going to improve if they understand the issues we're facing
<jow>
have't yet tried but can't imagine that it will be that much larger
<f00b4r0>
jow: that would pose other problems tho
<nbd>
jow: i'd expect there to be a lot of internal cross dependencies that would pull in lots of bloat
<jow>
nbd: only one way to find out :)
<jow>
f00b4r0: such as? need to rebuild for every fix? we do need that with abi-unstable wolfssl too
<f00b4r0>
yes, so not an improvement. And how do you deal with other packages that depend on ssl?
<jow>
they get their dynamic openssl or whatever
<jow>
idea is that we cna ship wpa3 by default without imposing the overhead of all of openssl
<nbd>
from what i read and based on superficial looks at the code, mbedtls just seems to have significantly better code quality compared to wolfssl
<nbd>
probably less chance of remote code execution bugs :)
<f00b4r0>
so anything that needs ssl would then require openssl, except for hostapd? That's not exactly a win imho
* Borromini
is wholly in favour of mbedTLS
<jow>
f00b4r0: if it were for me I'd drop ssl by default
<jow>
so far it only degraded user experience, introduced a potential rce and increased the image size
<jow>
the only reason we otherwise need to bother with it is to pull the required bits for wpa3
<f00b4r0>
jow: i'd be inclined to agree, but for the use cases that do require ssl (such as radius auth), having a lightweight implementation is certainly a plus
<jow>
and people who do want tls should simply deply hardware that can handle openssl
<jow>
*deploy
<f00b4r0>
i'm no crypto expert by any means but I share nbd's opinion of mbedtls code, for the little I was able to look at
<jow>
it is the industry standard and long proven to be able to properly deal with longterm release management
<f00b4r0>
true
<jow>
we've spent so much effort on dealing with random crappy unicorn libraries
<f00b4r0>
also true
MaxSoniX has quit [Remote host closed the connection]
<f00b4r0>
mbedtls is used in a ton of iot applications tho, so I would presume it gets a lot of attention
<jow>
yeah, not opposed to it if it works
MaxSoniX has joined #openwrt-devel
<ynezz>
well, you'll never know until you try it :)
<jow>
but switching to unfinished, potential unstable and not throroughly tested mbedtls for hostapd support might also just lead us into the next desaster
<f00b4r0>
i can't deny that ;P
<robimarko>
Its gonna be an issue if we switch to mbedtls and then the hostapd support never makes it upstream
<ynezz>
AFAIK it wasn't even submitted upstream yet
<f00b4r0>
ynezz: so i read ssl.c and main-radsec.c and I can't find obvious cases where WOLFSSL_API (P, not B) calls are used in an ABI-incompatible manner (I don't see manual dereferencing of pointers, etc); so I'm inclined to think that wolfSSL did crap over itself
<jow>
from what I gathered, the author now wants funding to complete the work
<robimarko>
Yes, its still pretty much experimental and yeah author stated that he wont complete it unless there is some funding
<ynezz>
BTW I'm not seeing anything wrong with that
<robimarko>
Me neither, he wants to get paid, we all do
<f00b4r0>
*nod*
<robimarko>
My point is that I dont see it wise to switch until there is upstream support for mbedtls in hostapd
<robimarko>
Otherwise we might get stuck with maintaining that
<ynezz>
+1
indy has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
<f00b4r0>
jow: if I read you well, basically by linking hostapd statically, we would then allow the users to select whichever ssl implementation they want (openssl/wolfssl/mbedtls) without having to carry whatever hostapd is using + their choice, right?
<jow>
f00b4r0: that's the very rough idea, yea
<f00b4r0>
i see. That would be an improvement for sure
<jow>
maybe we can also statically link wolfssl if openssl pulls in too much internal bloat
<jow>
and we can still offer a dynamically linked flavor, probably the -full one
<jow>
*instead of
<f00b4r0>
i see. Though that latter option may increase maintenance overhead
<jow>
likely not much more compared to the current situation
<f00b4r0>
touché
<jow>
we already do maintain a large number of different build flavors for hostapd
<f00b4r0>
*nod*
<f00b4r0>
bbiab, lunch
<jow>
same
goliath has quit [Quit: SIGSEGV]
minimal has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
cbeznea has joined #openwrt-devel
<Habbie>
i put some PKG_BUILD_DEPENDS in a package; I see them in feeds/packages.index; but building my package (make package/X/compile) does not cause the entries in PKG_BUILD_DEPENDS to be built
<Habbie>
(sorry i cannot be more vague)
<Habbie>
any hints on where to look?
<f00b4r0>
ynezz: PEBKAC. Newer upstream chilli package overrides local older ipk. Really wish we had a pinning mechanism in IB
<mrkiko>
ynezz: ping
<rmilecki>
does anyone know how TP-Link bootloaders know where to look for "partition-table" blob on flash?
<rmilecki>
they need to find it in order to read kernel offset and boot it
<mrkiko>
rmilecki: maybe look in the bootlog of some of these devices
<mrkiko>
if you look for the bootlog of the C60 I might be able to help out somehow
<mrkiko>
rmilecki: and can provide flash dumps of a V2 and V3
<rmilecki>
mrkiko: i checked 2-3 devices and found "Reading Partition Table from NVRAM ... OK"
<rmilecki>
mrkiko: on C59 V1 I can't see anything in NVRAM
<rmilecki>
mrkiko: can you show me output of "fw_printenv" from C60?
<mrkiko>
So, I don't have the device live, but if I am not mistaken uboot-envtools wasn't configured for that device
<rmilecki>
mrkiko: "cat /dev/mtdblock1" will be fine too
<rmilecki>
mrkiko: if you happen to run that device later
<mrkiko>
rmilecki: no. did you gather any useful hint from the gpl dump ?
<rmilecki>
mrkiko: i just extracted it
<mrkiko>
for the C60 ? V2 or V3?
<rmilecki>
i'm looking in C59 V1 GPL
<mrkiko>
rmilecki: curious about what you find out. I am under the impression this may be hard-coded...
<[Pokey]>
Bleh, package luci-app-rp-pppoe-server does not provide the service it is meant to. Either I am using it wrong or its broken
<[Pokey]>
Nothing appears under services
<Habbie>
and if you restart luci?
<[Pokey]>
restarted the whole device
cbeznea has quit [Quit: Leaving.]
<rmilecki>
mrkiko: it seems so
<rmilecki>
#define NM_PTN_TABLE_BASE 0xe50000
<rmilecki>
#define NM_PTN_TABLE_SIZE 0x002000
cbeznea has joined #openwrt-devel
<mrkiko>
rmilecki: and note that in some cases (commit 646d95c374072598fab9e949ef4425177c5c7960), seems the firmware can have a different partition table on its own
<rmilecki>
mrkiko: lovely
<mrkiko>
ehehe, nice times. Remember once I by mistake overwritten all the flash partition from kernel onwards, and so the device wouldn't accept any firmware because, I guess, I corrupted the data the device used to identity itself. :D
<mrkiko>
had to use u-boot UART to recover
<[Pokey]>
Habbie: Can confirm not appearing on a second device running 22.03.0 too
isak has joined #openwrt-devel
<[Pokey]>
Habbie: Figured it out
<[Pokey]>
UCI config section was commented out
<Habbie>
hah
<f00b4r0>
jow: opkg doesn't support installing specific package version (e.g. opkg install package:1.0), correct?
<[Pokey]>
woop woop PPPoE server works
<mrkiko>
[Pokey]: out of curiosity, why do you need a pppoe server?
<[Pokey]>
mrkiko: epand knowledge
dangole has joined #openwrt-devel
<mrkiko>
[Pokey]: authentication?
<[Pokey]>
expand*
<mrkiko>
[Pokey]: nice!!
<[Pokey]>
I am likely to face PPPoE in the future with the slow rate of tech upgrade in the UK
<mrkiko>
[Pokey]: does the server process all the frames in user-space or does it leverage kernel code somehow?
<[Pokey]>
mrkiko: I have no idea. I am highly underqualified to answer that
<mrkiko>
[Pokey]: well, even here inItaly pppoe is pretty diffuse still
<[Pokey]>
I'm using the rp-pppoe-server package
<mrkiko>
rp = roaring penguin :D :D
<[Pokey]>
yus
<[Pokey]>
angry penguin indeed
<mrkiko>
:D
<mrkiko>
[Pokey]: do you have FTTC or FTTH?
<[Pokey]>
I read a forum post where someone wanted to run an ethernet line through a "hostile environment" to connect their lan from one place to another and they wanted encrypted authenticated PPPoE running through that line
<mrkiko>
[Pokey]: why not 802.1x over ethernet?
<[Pokey]>
mrkiko: Maybeeee FTTC but I would not be surprised if it wasn't FTTN (fibre to the nowhere)
<mrkiko>
untilI find a CLI package for discourse... no thanks :D
<[Pokey]>
mrkiko: Hardcore :P
<mrkiko>
[Pokey]: partly hardcore, partly being blind and using a braille display, so I find myself confortable in where I have just the informations I need, like over APIs.
<jow>
f00b4r0:afair no
<[Pokey]>
mrkiko: Respectable!
<jow>
mrkiko: afair the ppp daemon is just handling session setup pado/pads etc. and offloading the actual ppp frame processing to the kernel ppp modules
<mrkiko>
jow: thanks! So this is true for the pppd client and for the rp-pppoe-server packages as well?
<f00b4r0>
jow: ok thanks. I'm looking at how variants packages are being done; it feels this wouldn't play well with a package that offers multiple options in its menuconfig, would it?
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<stintel>
mrkiko: iiuc 802.1x only does authentication, no encryption
<stintel>
mrkiko: macsec might be an option
<[Pokey]>
mrkiko: I think his point of using PPPoE instead of 802.11x was because it doesn't need additional infra like RADIUS
<[Pokey]>
though og course if what stintel said is true, that too
<[Pokey]>
s/802.11x/802.1x
<mrkiko>
stintel: thanks! I misunderstood - tough "encrypted" authentication" was needed, not data encryption. Didn't read the forumpost infact...
<mrkiko>
stintel: out of curiosity, did something change regarding odhcpd and the problem we encountered when a big number of routes was available?
<stintel>
mrkiko: not that I'm aware
<stintel>
but you can just use the workaround I implemented
<stintel>
or convince someone to clean it up
goliath has joined #openwrt-devel
<stintel>
I don't have a reason to figure it out, I'm too bad of a programmer to be able to do that quickly, the workaround works for me, and I'm in the process of completely ditching dnsmasq and odhcpd for dhcp
<stintel>
s/for dhcp//
goliath has quit [Quit: SIGSEGV]
<jow>
f00b4r0: compile time options and binary packages are simply conflicting concepts imho
<jow>
f00b4r0: if you look at e.g. debian then you don't have compile time options
<f00b4r0>
jow: agreed.
<jow>
you get the binary package as-is. If you want tunables, you'd use Gentoo and fiddle with USE flags
<f00b4r0>
ack.
<f00b4r0>
I dunno if a patch that moves coova-chilli away from compile-time options would be accepted though. Then again, that thing is abandonware
<jow>
unfortunately OpenWrt hasn't really decided yet what it wants to be
<jow>
fromt what I heard, coova is a heap of aptches anyway and each vendor/integrator adds his own crappy hacks on top
<f00b4r0>
it's ugly as f
<stintel>
forget about coova, use uspot and spotfilter
<soxrok2212>
robimarko: have you performed any NAT tests on ipq807x devices? my 301w seems stuck at ~400mbit
<f00b4r0>
stintel: is there some documentation that I can read somewhere?
<stintel>
f00b4r0: no
<f00b4r0>
brilliant. Then how am I supposed to use it?
<stintel>
argh, gh is not responding again
srslypascal is now known as Guest2749
srslypascal has joined #openwrt-devel
<robimarko>
soxrok2212: Well yeah, you can also find NAT+PPoE test results
dvm has quit [Ping timeout: 480 seconds]
<stintel>
f00b4r0: I know ... the easiests way is probably to check the examples in ucentral-schema/files/etc/ucentral/examples/captive-* and check https://github.com/Telecominfraproject/wlan-ucentral-schema how these are rendered to UCI
<stintel>
f00b4r0: I don't have a use for captive portal, but from what I heard about all the other solutions, it's probably worth figuring out uspot/spotfilter
<stintel>
it's ebpf based like qosify
<stintel>
no messy custom kernel modules
<f00b4r0>
why is it that nearly all the tools that are developed for openwrt are invariably completely undocumented? :P
* f00b4r0
sighs
<robimarko>
Because devs hate writing docs
<f00b4r0>
robimarko: not all of them do. I write doc before I write code
<robimarko>
Then I congratulate you
<robimarko>
That is how its supposed to go
<f00b4r0>
i've been told it's called "code by contract" or somesuch, though I don't care, it suits me well :)
<jow>
can anyone "see" a "zero day" in the (wrongly linked) screenshot?
<jow>
or is this yet another user running nmap for the first time and being overwhelmed by the information?
* jow
is starting to question his sanity
<stintel>
jow: being in IT for as long as we are that's probably the sane thing to do :P
<f00b4r0>
jow: I can't see anything in that screenshot
<f00b4r0>
as in, what's the relevant part
<jow>
that was my impression as well
<robimarko>
jow: That screenshot makes no sens
<f00b4r0>
^
<robimarko>
There isnt even nmap output
<f00b4r0>
i think it's safe to assume that anyone running nmap through a GUI on a windows machine is unlikely to find and/or report anything useful :P
<f00b4r0>
especially when they submit an entire screen capture as "proof"
<Namidairo>
screenshot of a screenshot in paint
<f00b4r0>
also that
<robimarko>
Dont forget saved as bmp and then uploaded
<f00b4r0>
lol
<jow>
even tried to google that vulnerability Id but that did yield no results
<jow>
nbd: I would like to add posix itimer support to uloop in order to gain support for stable interval timers (self re-arming one-shot timeouts tend to skew over time) - do you know if the relevant APIs are available on OS X too
<jow>
and do you have any other remarks?
<Habbie>
what do people use uloop for on osx? just development?
<jow>
the API is signal driven, so the support will likely look a lot like the existing process tracking support... itimer signal will interrupt epoll, we walk the list of staged timer contextes and fire any callback that belongs to the interval timer that fired
<jow>
... then resume epoll
<nbd>
jow: i don't think it's available on macos
<nbd>
oh, wait
<nbd>
i think i looked at the wrong api
<nbd>
you mean getitimer/setitimer?
<jow>
no, timer_create()
<nbd>
that one is not available on macos
<jow>
hmm, too bad. tought it might, due to it being posix standard
<f00b4r0>
if anyone is in touch with blogic, could they ask him if he got my email and if he could reply. I think I might be able to get some sponsoring for uspot
rua has quit [Quit: Leaving.]
<nbd>
jow: well, you could easily implement a rearming timer as a wrapper around uloop_timeout in libubox
<nbd>
just store the interval
<jow>
yeah, that's probably what I'll do
<nbd>
because the uloop_timeout struct has absolute time values (based on CLOCK_MONOTONIC)
<nbd>
so if you add the interval to those, there should be no drift
<f00b4r0>
(email was sent a month ago, I'll ping him again now)
<soxrok2212>
robimarko: should 8072a be able to NAT 1gbit?
<robimarko>
soxrok2212: At least close to it
<robimarko>
Just ask on the forum in the AX3600 thread
goliath has joined #openwrt-devel
rua has joined #openwrt-devel
lmore377 has quit [Read error: Connection reset by peer]
lmore377 has joined #openwrt-devel
dvm has joined #openwrt-devel
dvm has quit [Ping timeout: 480 seconds]
<cc0>
hi! i've rolled up my version of a small script that advertises its wifi SSID & channel to umdns/bonjour and aggregates any SSID & channel from other routers on mdns/bonjour to build a 802.11v neighbor list. would it make sense to package the script as an openwrt package and publish it to the openwrt community packages repo/feed?
<cc0>
i meant 802.11k. not 802.11v.
<stintel>
have you looked into usteer or dawn ?
Tapper has quit [Ping timeout: 480 seconds]
<cc0>
dawn is a bit too clever for my use case, it tries to actively steer clients around with 802.11v by asking the different routers how well they can see the client, and then running heuristics. in theory it could be beneficial but i'm not sure it'd really help on my home network. i just want to use 802.11k to let client know on which channels to probe for APs
<cc0>
i think it'd work better to let my device know which APs are there and then let it make its decisions about which AP to connect to.
<stintel>
haven't been using dawn for a while, but in usteer I believe you can disable the steering but still have 802.11k
<stintel>
anyway to answer your question, you could create a PR to add it to the packages feed, but I'm not sure how the maintainers there will respond to it
<stintel>
but imo it probably makes more sense to add support for what you want / need to one of the existing solutions
<cc0>
OK makes sense. something like a global switch to disable steering entirely in usteer and keeping only neighbor reports could make sense instead of a new package with a set of shell scripts
madwoota has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<cc0>
blocktrron: is there a way to do 802.11k neighbor reports only and no steering or 802.11v at all in usteer?
<nick[m]1>
There is also some bash script just exchanging the 802.11v neighbor strings. However never found its way go upstream linhx
<stintel>
cc0: just out of curiosity, is your script available somewhere?
rua has quit [Remote host closed the connection]
<blocktrron>
cc0: yes
rua has joined #openwrt-devel
<nick[m]1>
cc0: you can just disable the steering part by settimg some parameters to 0
<cc0>
i think thats what nick[m]1 is referring to as well
<stintel>
got it, thanks
madwoota has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
dvm has joined #openwrt-devel
zatwai has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
zatwai has joined #openwrt-devel
<Tapper>
Hi any one know how to get a log of a failed sysupgrade? Using putty this is for my r6260
<schmars[m]>
blocktrron: yo, thanks for that poemgr release the other week! o/
<Tapper>
mrkiko BTW mate discord will work with NVDA but it is not a nice user interface.
<mrkiko>
Tapper: thanks for the hint! I am not a discord user at the moment, but you never know :D
<Tapper>
There is a lot of short cut keys for it.
zatwai has quit []
<Tapper>
So not to bad. Not as good as using irc with a screen reader tho.
zatwai has joined #openwrt-devel
<mrkiko>
Tapper: :D nice to know! BTW, have you ever used a VNC client?
<Tapper>
mrkiko no mate. Do you want me to ask about using one with a screen reader for you. I have some techy friends who use a11y tech
<ynezz>
f00b4r0: I fail to see, how would it solve your problem, where you're (re)using same package name coova-chilli for your variant package with different feature set coova-chilli-customer
<mrkiko>
Tapper: thanks a lot! It would be great, really. I have currently no clue on how to proceed.
<f00b4r0>
ynezz: I'm not sure I understand
<Tapper>
mrkiko I have a r6260 that will not sysupgrade. Do you know how to get more info out of it. Can you get a log output as you flash?
<mrkiko>
Tapper: as for your sysupgrade question - mhm, I guess it won't be easy to get infos out of the device without UART. For "failed" sysupgrade, you mean - the device reboots in the same version it was before?
<f00b4r0>
ynezz: customer only needs ssl support for radius; any chili-ssl variant would work for them
<Tapper>
mrkiko yes mate stuck on the build from a wile agao
<ynezz>
f00b4r0: AFAIK there is no such variant
<f00b4r0>
ynezz: incidentally since we don't build ssl support in the "official" package, the version bump was probably unneeded
<mrkiko>
Tapper: so, it actually reboots and performs the sysupgrade, but then stops
<f00b4r0>
ynezz: that's my point, adding such variant. But since chilii is build-options based, that's not going to happen
<Tapper>
mrkiko yeah reboots in to old build
<mrkiko>
Tapper: strange. R6260 is ramips, right?
<Tapper>
mrkiko yeah. Should I try flashing a 22.03.x build and try flashing back to master?
<mrkiko>
Tapper: have you tred both normal sysupgrade and a sysupgrade with -n flag to not preserve config ?
<Tapper>
mrkiko no as I need to keep configs. It's a dumb AP in a hard to rech place.
<mrkiko>
Tapper: hmhm... and you're sure you are passing the *squashfs-sysupgrade.bin file, right? I ask because sometimes it' easy to get confused, for me at least :D
<Tapper>
mrkiko yes mate I even renamed the file to jon.bin
<Tapper>
lol
<Tapper>
Shorter to type
<mrkiko>
:D
<ynezz>
f00b4r0: so you've tried it already? I can't find any such rejected PRs :P
<f00b4r0>
ynezz: read scrollback :P
<ynezz>
f00b4r0: tl;dr
<mrkiko>
Tapper: custom build or downloaded from downloads.openwrt.org?
<f00b4r0>
ynezz: ¯\_(ツ)_/¯ ;P
<Tapper>
mrkiko custem build
<mrkiko>
Tapper: so if you use the "file" command on jon.bin, it's a posix tar archive, right??
<Tapper>
yeah
<ynezz>
f00b4r0: I fail to see how introduction of coova-chilli-*ssl is going to break anything
<Tapper>
OK mrkiko it's my build because it's flashed back to 22.03.0
<mrkiko>
Tapper: strange. I don't have the exact hardware still, so ... unable to hep you more.
<Tapper>
22.03.0 OK mate thanks for trying.
<mrkiko>
Tapper: :D
xback has quit [Remote host closed the connection]
<f00b4r0>
ynezz: it doesn't work with compile options. Consider menuconfig; how do you have multiple binary packages of the same package when said package has a dropdown menu with build options; and the binary variants would be some combination of these options.
xback has joined #openwrt-devel
<ynezz>
f00b4r0: coova-chilli-wolfssl would be default coova-chilli config + CONFIG_COOVACHILLI_WOLFSSL enabled on top, no other changes
<f00b4r0>
ynezz: but it needs a Kconfig entry, does it not?
<ynezz>
on contrary, you would need to remove that Kconfig entries
<ynezz>
in other words you would always build coova-chilli-wolfssl with --with-cyassl configure option
<Tapper>
mrkiko I fixt it.
<Tapper>
mrkiko you are going to laf at me. I was flashing the rong file. you were rite.
<Tapper>
haha
<f00b4r0>
ynezz: I'm afraid I'm confused.
<mrkiko>
Tapper: :D how was it wrong, you told me it was posix tar
<Tapper>
It was the old build file I was flashing and not the new one.
rua has quit [Ping timeout: 480 seconds]
<mrkiko>
ah ok!!
<Tapper>
mrkiko do you want to use a vnc on windows.
<ynezz>
f00b4r0: just take a look at ustream-ssl
<f00b4r0>
ynezz: regardless, I've been enlightened to uspot, I think it will be a more productive use of my time (and my client's money :)
<Tapper>
[Pokey] I know rite. lol feel like a rite knob!
<[Pokey]>
We've all done something similar
* Tapper
nods
<f00b4r0>
ynezz: see https://github.com/openwrt/packages/blob/master/net/coova-chilli/Config.in. Any -ssl variant would still need to be able to be built with any of these options. So either you don't remove the ssl choice from the main package, and you can confusingly build an ssl variant through the config option or through the package variant; or you do and you can't build-in the other options with the ssl variant.
<f00b4r0>
either way, it doesn't work. Jow hilighted that before.
rua has joined #openwrt-devel
<f00b4r0>
anyway, chilli is a boring cesspool; let's not dwell on it :)
Borromini has joined #openwrt-devel
<mrkiko>
Tapper: thanks man! I am on Linux, and my remote is Linux as well.... so I can't use NVDA
<mrkiko>
Tapper: but nvdaremote is great I think :D
<ynezz>
f00b4r0: of course, that you would need to remove that config knob
<f00b4r0>
ynezz: which config knob?
<ynezz>
SSL
<Tapper>
mrkiko So you would like a linux tool? You want to vnc from linux to linux?
<f00b4r0>
then how do you build ssl chili with JSON support??
<ynezz>
f00b4r0: coova-chilli-full-wolfssl ?
<f00b4r0>
what if you don't want all the options, but only ssl and json?
<f00b4r0>
then what if you want kmod xt-coova support in chilli?
<ynezz>
then you need your own package
<f00b4r0>
etc
<f00b4r0>
it doesn't work
<jow>
do those tunable even make practical sense?
<f00b4r0>
again, it's a waste of time anyway. This is abandonware.
<jow>
or should we simply enable all by default and ship that
<f00b4r0>
jow: I wouldn't honestly know. I know what my client uses, that's the extent of my knowledge
<jow>
fair enough
<f00b4r0>
enable all probably means a much bigger package with a lot more deps
<jow>
I suppose it isn't modular?
<Mangix>
Turns out luci doesn’t have an ico file
<mrkiko>
Tapper: if this can help - in the case of ramips, you can decompress the sysupgrade via tar, and then look at the two files you get - rootfs and kernel. Maybe you can look at the versions here, or at the file dates for that matter
<f00b4r0>
miniportal brings in haserl; json uses libjson-c; then the various ssl options bring in openssl or wolfssl
<Mangix>
That’s a bit annoying
<jow>
Mangix: due to the stray 404's or why?
<Mangix>
jow: on iOS, adding it to springboard does not result in an icon
<mrkiko>
Tapper: so you might get something looking like - kernel: u-boot legacy uImage, MIPS OpenWrt Linux-5.10.147, Linux/MIPS, OS Kernel Image (Not compressed), 2860773 bytes, Sun Oct 9 20:52:48 2022, Load Address: 0X80001000, Entry Point: 0X80001000, Header CRC: 0XB9A4EB91, Data CRC: 0X29A22435
<jow>
ah, but for that a bunch apple meta tag gibberish is needed afair
* Mangix
looks
<f00b4r0>
jow: modular? It's all #ifdefs in the source. It's beyond vomit-inducing ;P
<jow>
f00b4r0: ah okay. didn't know if it uses dlopen'd plugins or something
<jow>
or a bunch of helper exeutables
<f00b4r0>
if only :P
<f00b4r0>
that code is a 101 of worst practices
<Mangix>
jow: so I see <link rel="apple-touch-icon" href="favicon_180x180.png"> . But I also see <link rel="icon" href="favicon.svg" sizes="any" type="image/svg+xml">