<mangix>
just noticed multiCPU DSA never got merged. hrm.
<neggles>
IIRC there are a bunch of wifi features you lose if you run an open network... would anyone happen to have a list
<neggles>
i can't find details cause all google's giving me is page upon page of "make sure u protect ur wifi!!!" and "isn't wifi 6 great" and "LOOK WPA3"
<Namidairo>
if it's open-open then you lose protected management frames/802.11w
<Namidairo>
but then again that's what OWE is for
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<enyc>
Therefore, wondering if this should be notified or github-bug or what, if 22.03.0 should have that default package set change, for example.
goliath has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
castiel652 has quit [Quit: Leaving]
GNUmoon2 has quit [Ping timeout: 480 seconds]
<PaulFertser>
enyc: yes, open a ticket on OpenWrt github please.
ekathva has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
robimarko has joined #openwrt-devel
<robimarko>
PaulFertser, or anybody else familiar: Is there a way to have DFS working with mwlwifi + mwifiex
<robimarko>
Because, I have to support Espressobin Ultra-s that use the crappy 88W8997 USB radios as well
<robimarko>
And those are only supported by mwifiex which does not support DFS at all
<robimarko>
So I cant just use mwifiex for both PCIe 88W8997 and the USB one
<robimarko>
And with the combo DFS is not working
<PaulFertser>
robimarko: oh, I have no idea :(
<hauke>
enyc: what is the 3. wifi provided by kmod-mwifiex-sdio used on the WRT3200ACM ?
<robimarko>
hauke: I think it should be 88W8887
goliath has quit [Quit: SIGSEGV]
dedeckeh has joined #openwrt-devel
goliath has joined #openwrt-devel
<enyc>
hauke: I don't have the device, compsci. friend does. I understand it has a 2.4ghz radio, a 5ghz radio, and a 3rd dual-band radio with lower-power-antennae intended for DFS-scanning / channel-monitoring and the like, though it can, in-fact, be repurposed signal-limitations-repurposed.
<enyc>
PaulFertser: OK May be ~8hrs until they do but will ask for it to happen. Thankyou for answer.
<enyc>
I wonder how much TCP_ECN benefits OpenWrt SQM and so-on.
goliath has quit [Quit: SIGSEGV]
<SwedeMike>
enyc: are you wondering how ECN works, or what is the question?
valku has joined #openwrt-devel
goliath has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
<enyc>
SwedeMike: i'm wondering if it benefits Openwrt-SQM, that is ... does SQM in OPenWRT actually do ECN-marking, and so-on ?
zatwai_ has quit [Read error: Connection reset by peer]
goliath has quit [Quit: SIGSEGV]
danitool has joined #openwrt-devel
<hurricos1>
mrnuke: I have substantially more ports.
<hurricos1>
mrnuke: I'm fairly sure there's some port mapping going on.
minimal has joined #openwrt-devel
goliath has joined #openwrt-devel
<hurricos1>
How does the OpenWrt buildbot cache its toolchain?
schwicht has joined #openwrt-devel
<mrnuke>
hurricos1: my experience has been that port mapping doesn't matter in power delivery. It only changes which output is changed when the command says "port=0"
<mrnuke>
For exampe, I can map port 0 to pse 3 and say "do x with port 0". If I don't map the ports, I have to say "do x with port 3"
<hurricos1>
It's just odd that sending a request for port 0x0a fails, and sending a request for 0x0d responds with info on 0x0a
<hurricos1>
I have a tough time believing that's unrelated to the non-functioning of realtek-poe
<hurricos1>
on this 24-port switch.
<hurricos1>
working today on migrating some services, including my build system, off a big power-hungry server
<mrnuke>
You can enable or disable it via an ioctl
<hurricos1>
poem
<hurricos1>
Oh, shit
<hurricos1>
this is your port to poemgr
<hurricos1>
mm, OK.
<mrnuke>
Yup, that's right. I'm getting PoE support one war or another
<hurricos1>
Well, this needs to be included in the base realtek-poe
<mrnuke>
s/war/way/
<hurricos1>
since in the base realtek-poe, frame 10 always falis
<hurricos1>
and indeed every 256th frame after it fails
<hurricos1>
I saw the \r and \n in 0x0a and 0x0d, fwiw, I just didn't know how the heck it'd have anything to do with anything
<mrnuke>
Lucy us we're using 8-bit bytes. Imagine if we used 7-bit and every 128th frame failed!
<hurricos1>
but ugh
<hurricos1>
lol
<mrnuke>
I only realized what the 0x0a forkup was after watching the serial bus with a separate adapter. Wait a second! I wasn't sending _that_ character
<hurricos1>
I don't believe I have easy access to the serial bus, is the other problem
Borromini has joined #openwrt-devel
<hurricos1>
I say "not easy" to talk about the way the stacked boards connect with each other
<hurricos1>
but I have one hear I can tear down to look ... once I can finish this migration
<mrnuke>
let me brew up a new beer
<mrnuke>
I mean patch for realtek-poe for that dinosaur termios stuff
hanetzer1 has quit [Quit: WeeChat 3.5]
hanetzer has joined #openwrt-devel
castiel652 has joined #openwrt-devel
<castiel652>
rsalvaterra I think I found the commit that causes problem
<mrnuke>
Who the folcklore would have thought that not setting termios.c_cc[VMIN] to 1 could have caused so much painassery. This terminal stuff is really irritating
<hurricos1>
mrnuke: new git repo is set up, new build server is ... running, ish.
<hurricos1>
and pushed your patch. Hopefully it compiles.
<hurricos1>
Ditto, I think, for the other one requiring re-bracketing? Actually, yeah, hold on a minute.
<hurricos1>
I should really be rebasing mine on yours, since you're developing another board at the same time
<mrnuke>
hurricos1: wow. For a second there I thought you were going to say "you should stop drinking" :)
<svanheule>
hurricos1: mrnuke: keep going guygs, I love what you're doing for Realtek PoE :D (curl-ing my reverse engineered documentation; neat!)
<mrnuke>
svanheule: That documentation is forking amazing!
<svanheule>
mrnuke: long nights during a covid lockdown; gotta make good use of your time
<svanheule>
mrnuke: after a while I started reverse engineering the BCM59121 firmware embedded in the MCU firmware
<svanheule>
quite quickly decided that was probably taking it too far, but it also disassembled as ARM Cortex M0 code IIRC
<mrnuke>
Wait, there's MCU firmware, and then there's also ... BCM firmware?
rua has quit [Ping timeout: 480 seconds]
<svanheule>
the firmware embedding goes three levels deep: device firmware > kernel driver with MCU firmware blob embedded > MCU firmware with BCM firmware embedded
<svanheule>
it's Broadcom hardware, _of course_ it needs firmware
rua has joined #openwrt-devel
<svanheule>
AFAIR, the MCU protocol that is documented on the wiki resembled the BCM protocol rather closely
<mrnuke>
Then I wonder what reason they possibly could have had to interject a MCU in-between the CPU and PSE
<svanheule>
*in theory* one could write custom MCU firmware with the BCM firmware as a payload, if the latter would be understood well enough
<svanheule>
real-time requirements? the MCU can do continous monitoring of the PoE power consumption, and cut off ports on different PSE chips as required
<mrnuke>
and the BCM firmware can't do that?
<svanheule>
for the outputs on one PSE chip, I assume it can (as a matter of self-protection)
<mrnuke>
I miss the good old days when you had competent hardware designers -- No need for 42+ software patches to fix a product -- was good from the factory
<svanheule>
but I don't think the PSE chips can communicate among themselves
<svanheule>
the PD69-series has the same set-up: PSE chips and a management MCU
<svanheule>
but those actually have publicly available documentation
<svanheule>
and a serial protocol that doesn't look like it was developed by a 16-yo doing Arduino programming
<svanheule>
(hope I didn't offend too many people with that last statement)
<mrnuke>
I like fixed-length packets on a stream. Allows me to get really lazy with programming the protocol
<svanheule>
they're only fixed length for most frame IDs
<svanheule>
ah, but the request and reply contain the same PSE index, so you can overload the echo field with that data, and not modify any other code! /bigbrain
rua has quit [Ping timeout: 480 seconds]
<mrnuke>
If I were the intern with employee ID:10T, I would have done away with the checksum byte instead!
<mrnuke>
Maybe I've read data off a different PSE. How would you know if I didn;t tell you in the packet? :p
* svanheule
imagines a bogo-poll mode, where you need to poll until the MCU randomly returns the status of PSE you needed
rua has joined #openwrt-devel
<mrnuke>
monte-carlo polling?
<svanheule>
exactly :P
<mrnuke>
I wonder how hard it would have been to implement a PSE with existing MCU, a few external mosfets, and no BCM chips
<mrnuke>
That is true. AFAIK, PoE detection relies on the end-device presenting a specific resistance
<svanheule>
you may not be able to cram all that (high power) hardware into a device like a GS1900-8HP though
<mrnuke>
I think you can. Hold on a sec
<svanheule>
there are switches that have PoE daughter boards, to inject power into the ports
<svanheule>
if you feel like you have too much time, you can try making your own daughter board :P
<stintel>
greetings from the Aegean Sea :)
<svanheule>
stintel: o/
<stintel>
svanheule: \o
<mrnuke>
I had some old, but well-lit, pictures of the engenius variant (8-port PoE). If you take out the BCM chips, there's plenty of room for an analog mux and som sot-23 MOSFETs
<mrnuke>
I saw the pictures earlier this week, but have no idea which folder they were in. Can't find them now
dedeckeh has quit [Remote host closed the connection]
valku has quit [Remote host closed the connection]
<mrnuke>
blocktrron: I'm almost ready to submit the realtek port for poemgr (https://github.com/mrnuke/poemgr/commits/unreal-tek-poe). It depends on the werror-cleanup branch. May have gone a little too crazy on the refactoring...
valku has joined #openwrt-devel
<nick[m]1234>
Any idea why it is not possible to buy a belkin rt3200 in gerrnany anymore?
<eloy_>
hello! I compiled OpenWrt (legacy x86), but in the /bin/targets/x86/legacy I'm not getting a generic-ext4-combined.img.gz file. Am I forgetting some configuration? I do get a kernel and rootfs.
<blocktrron>
nick[m]1234: belkin does not sell routers to germany, only the linksys is distributed here
<dwfreed>
eloy_: is CONFIG_GRUB_IMAGES set in your .config ?
<blocktrron>
that being said: The WAX206 is 90€ in DE and comes with a 2.5GE WAN port, overall being the better deal apart from nobody having taken a shot at it
<eloy_>
dwfreed: nope, and that was indeed the solution! thanks a lot :)
<Lechu>
Folks, is anyone using phy*assoc LED trigger? Just noticed, on my freshly ported ZF7372, that this trigger does nothing in conjunction with ath9k. When connecting new station the LED doesn't even blink. What is the expected behaviour for it?
<Lechu>
Haven't yet checked on older releases, though.
<Lechu>
I observe the same on 19.07. What I'd like to achieve is to have one colour of the LED lit with station(s) connected, other colour blinking on throughput, like with phy*tpt.