<Ansuel>
coincidentally this table was wrong in old datasheet revision... well they fixed that it seems
<Ansuel>
they must really hate that table to did it 2 times wrong...
danitool has quit [Ping timeout: 480 seconds]
<mangix>
is that for switch?
<Ansuel>
yes i wasting some time improving the code... dropping random shift define and stuff... porting all to FIELD_PREP and starting to love this macro
<digitalcircuit>
slh: As suggested, I've tried "make distclean" and redoing the NBG6817's "make menuconfig" from a 21.02 build config + extra packages, and the kernel still stops on "[ 2.877832] Waiting for root device /dev/mmcblk0p5..." Just now I see there's 5.10 changes after https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fa13dd658f59df41b9184d4dc15a5b29530e7c2c , unsure if that fixes it.
<digitalcircuit>
(I'm probably doing something obvious wrong, though this worked just fine with snapshots built for Linux kernel 5.4)
<digitalcircuit>
So before the 5.10 switchover, just after the DTS OPP voltage fix was merged.
<digitalcircuit>
...I don't know if I ever actually tried 5.10 when it was in testing.
<slh>
Linux nbg6817 5.10.66 #0 SMP Thu Sep 16 05:59:50 2021 armv7l GNU/Linux so v5.10 shouldn't be it
<digitalcircuit>
Hmm. I'll try not persisting my configuration settings and see if that fixes it. I don't have the DSA PR, and I don't see how that'd break mounting the MMC, but maybe. It's also possible my build config (e.g. enabling the UAS USB storage module) might impact things.
<digitalcircuit>
(Unrelated, I've noticed that using the uboot serial console to "run boot_mmc_1" does not change the dualboot flag, it's just a one-time thing. I'll sort that out at some point too; it might play into figuring out if the NBG6817 has a non-serial-console way to force toggling which boot partition is active.)
<digitalcircuit>
Nope, same issue even if I don't persist configuration. My next guess would be to jump to the latest snapshot code since there's been some kernel updates.
<digitalcircuit>
Wait-a-minute...
<digitalcircuit>
Sorry, I think I see the issue - to use the "diffconfig" script, I ran "make kernel_menuconfig", and saved after that, then ran diffconfig. I think that changed the 5.10 kernel build settings to disable various things.
<digitalcircuit>
I'll try rebuilding on the latest snapshot code, and make sure the git tree is clean, too.
guerby_ has quit [Read error: Connection reset by peer]
<slh>
always expand via make defconfig oldconfig, after overwriting the config with your minified diffconfig
<slh>
(before menuconfig/ kernel_menuconfig)
guerby_ has joined #openwrt-devel
<digitalcircuit>
In this case, I wasn't expanding the minified diffconfig, I was building on top of the 21.02 config. Noted though! It hasn't caused issues before, but I might've just been lucky (e.g. I otherwise hadn't touched kernel_menuconfig).
<digitalcircuit>
slh: Thanks! I'll give this another shot. And pardon the noise; I'll launch a build and hopefully it was user error.
* digitalcircuit
puts "make defconfig oldconfig" into his "packages and build" documentation
<philipp64>
slh: any idea how to create a symlink from /var/log => /mnt/thumb/log early on during boot (before syslogd gets started)? or conversely remount /mnt/thumb/log as /var/log ?
<slh>
no, but I assume you'd have to hook into (just before-) the overlay mounting
<slh>
but hasn't master recently gotten a config option to separate out /var/?
victhor has quit [Ping timeout: 480 seconds]
<philipp64>
does it? I was unaware of that...
<philipp64>
I thought it's always a link to /tmp
<digitalcircuit>
slh: snapshot build of r17647-fca5ad55d2 is also broken on "mmc0: error -110 whilst initialising MMC card \n Waiting for root device /dev/mmcblk0p5..." thing despite seemingly having fixed up my build config. I'll have to try the OpenWRT official snapshot next; if that works, then maybe it's the kernel modules or such.
<slh>
I wanted to build a new snapshot for my devices tonight, but it's getting late and I haven't even started the PR branch juggling yet...
<slh>
hopefully sometime this weekend
<philipp64>
huh... that explains why "grep -r /var /etc/init.d /lib/preinit" wasn't showing its creation...
<digitalcircuit>
slh: Understood! It's getting late here, too (nearly 11 pm EST) - I'll give the official snapshot build a try, just to see if it boots, and either way revert back so I have working Internet at home :)
<slh>
04:50 CEST...
<digitalcircuit>
Oof, yeah, try to rest well when you do slh (assuming not a night shift)
schwicht_ has joined #openwrt-devel
schwicht has quit [Remote host closed the connection]
<digitalcircuit>
slh: Today's snapshot fails in pretty much the same way (the waiting for mount message just came moments before the MMC error instead of moments after)
<digitalcircuit>
So.. there's / probably / a chance I'm not messing things up this time :)
<slh>
grrr :(
<digitalcircuit>
I'd offer to git bisect but I need to get food and rest and such. On the upside, I'm happy to have helped discover a problem before it lasted any longer. Err, asides from the more esoteric CPU crash/reset bug.
<Ansuel>
mh ath10k is dead but for another reason.... the packet are handled by cpu0 that are stalled so no packets are handled (i think... no wifi is broadcast so that could also be caused by a bad ath10k crash)
<rsalvaterra>
The RCU stall timout was decreased from 60 to the upstream default of 21 seconds, recently.
<Ansuel>
rsalvaterra: i know i'm trying to understand why it didn't crash
<Ansuel>
i mean in the current state the router spam stall warning every 3 second
<rsalvaterra>
Ok, that's strange. I thought it had be a one-off event.
<rsalvaterra>
*been
<rsalvaterra>
(WTF is wrong with my typing today?)
<Ansuel>
any idea how to debug this? it seems interesting
<stintel>
could just be the amount of clients though
<stintel>
but in general not happy with the EAP245v3, it's slower than the DAP-2695 which is wave1
<nick[m]1234>
I can not imagine that we have a lot of clients around 4 or 5 am in the morning xD
<stintel>
mind you that my graphs are 1 year
<nick[m]1234>
I'm also very happy with eap225 outdoor
<stintel>
you mean not verry happy ?
<nick[m]1234>
no, I like the device. is it cheap and wave2
<nick[m]1234>
however, the memleak is problematic :/
<stintel>
ah, confusing. I said not happy, you reply with "also very happy"
<nick[m]1234>
I would hope we can fix this somehow
<nick[m]1234>
ah okay
<nick[m]1234>
did not read correctly
<stintel>
ugh, it's qca, if I find a decent mt76 based AP (decent meaning at least PoE-PD and RJ45 console port), QCA is out the door
<stintel>
but that seems incredibly hard to find
<nick[m]1234>
yep
<nick[m]1234>
I would also switch
<Ansuel>
(about the stall don't know how this is possible but it seems a bug present in the kernel... something very rare... go figure....)
<Tapper>
Has any one dun a proper readme for DAWN yet. One that lets people know how to use it not just list of options?
<Tapper>
One that a non expert can use.
<karlp>
rj console port is already pretty limiting your options isn't it stintel?
<stintel>
karlp: I'll gladly give my money to the companies who understand that this is needed
<stintel>
EdgeCore seems to get it, unfortunately only QCA
<nick[m]1234>
Tapper: no, i did not write a proper readme. I think it is not important to tune every parameter when I finally merged the changes I did here: https://github.com/openwrt/packages/pull/16299
<nick[m]1234>
so cotequeiroz did the changes.
<nick[m]1234>
stintel: I think I will go to trunk and "-ct" firmware and see if the memleaks still appear
<nick[m]1234>
did not find any bug report for the qca9377 radio?
<stintel>
hmmz now dawn on 1 AP is not showing the data from the other AP
<stintel>
restarted already
<nick[m]1234>
umdns?
<nick[m]1234>
ubus call umdns browse
swiftgeek has quit [Ping timeout: 480 seconds]
<stintel>
the AP not showing data of other AP properly sees the other AP in umdns
<nick[m]1234>
I mean ath10k-firmware-qca9888
<stintel>
restarted both ends several times already, no change :/
<stintel>
hmm, but the other AP doesn't see the one with the lacking data
<stintel>
so that probably explains the problem, it doesn't connect/send data
swiftgeek has joined #openwrt-devel
<nick[m]1234>
sometimes umdns has also issues
<nick[m]1234>
and I use umdns for finding my "mesh" partners
<stintel>
yeah but now reliably accross restarts? :/
<nick[m]1234>
what do you mean?
<stintel>
restarted umdns and dawn several times, problem persists
<nick[m]1234>
but do you see umdns?
danitool has quit [Read error: Connection reset by peer]
<stintel>
I told you
<nick[m]1234>
ah okay.
<nick[m]1234>
I'm sorry but it is a bit hard to debug remotely.
<stintel>
rebooted both APs, problem is OK now
<stintel>
maybe running dawn in gdbserver breaks umdns
danitool has joined #openwrt-devel
<nick[m]1234>
nice
<nick[m]1234>
or at least "okay"
<stintel>
well since running in gdbserver doesn't give anything useful anyway ...
<stintel>
guess we should procd_respawn the thing
<stintel>
so that at least the log flood of the dawn plugin in prometheus-node-exporter-lua is avoided
<Ansuel>
must be hell to work on the ath10k firmware code
<mrkiko>
"Experiences are different for each device, and not rarely different experiences are made even for the same device." ... sounds messy :)
<Ansuel>
in short cosebase is shit we tried to improve it but don't expect it to be that much good
<Ansuel>
codebase*
<stintel>
and we're not selling this anymore, users of old should by new or fuck off
<stintel>
buy*
<stintel>
that's basically the message they've been sending for years
Tapper has quit [Ping timeout: 480 seconds]
<mrkiko>
And - how is the stability situation with ath11k ?
<Ansuel>
stintel: IMHO it's ok that you drop really old and bad device (some ath10k chip existance doesn't make sense at all) problem is that even current one are not that performant/100% stable.... it's just qca good hardware SHIT software
<Ansuel>
mrkiko: ath11k is currently HELL. Leak that will crash your system. In short.
myon98 has quit [Quit: Bouncer maintainance...]
<mrkiko>
Ansuel: really?
<mrkiko>
we do not have openwrt dsupported devices with ath11k yet
<Ansuel>
robimarko did his best to backport tons of patch for ath11k but really the best experience we got was offloading all the handling stuff to the nss core of ipq807x (to solve the leaks)... it seems there is a leak in wmi packet handling and the chip without doing anything (aka no client connected) leak mem consistently until the system crash for OOM
<Ansuel>
the interesting part is that as soon as you make a load (a speedtest of a file transfer or you load a yt video) the leak memorey is freed
<Ansuel>
IMHO the logic how the driver handles memory is wrong and they use some workqueue to free the memory and is triggered only on load and not in idle state...
<Ansuel>
we are waiting for 5.15 backports hoping the problem is solved automagically...
<Ansuel>
with later ath11k version they added pci support but robimarko said it's pratically impossible/doesn't worth the time backporting patch to 5.10.... too much changes to be done... yet he is still trying but he doesn't have that much time
<Ansuel>
(offloading everything fixes the problem as the ring buffer as actually disabled from linux and handled directly from the nss dedicated core)
<Ansuel>
(sorry for the wall text)
<mrkiko>
Ansuel: very interesting !! But - do we support such devices in openwrt yet?
<stintel>
wifi is a shitshow in general :(
<stintel>
like esp8266/esp32, they don't even roam
schwicht has joined #openwrt-devel
schwicht has quit []
<stintel>
intel has in all the years they produce wifi chips probably never produced 1 firmware that doesn't crash
<stintel>
marvell ... no experience but heard no good things about it
<Ansuel>
mrkiko: not upstream but we support the xiaomi ipq807x router ax3600 (and the bigger ax9300) in a separate repo.... problem is that this new soc require the nss firmware or the switch doesn't work and we need to take decision on how to propose all this qca shitfest to openwrt and not receive a big NO GTFO (sorry for the bad words)
<Ansuel>
I'm putting some effort in qca8k so I stopped working on ipq807x and robi doesn't have that much time for work reason. And in all of this we still can't push anything as ath11k is still unusable
<Ansuel>
in short supported, work and perf are even good but adding support for a device that triggers OOM is a NONO
<mrkiko>
Ansuel: thanks for the explanation. I wanted to try one out to see how it works in openwrt. But ... so far even finding ana amzon liunk to buy it hasn't been easy. And - how did you manage to pass the firmwaqre signature check?
<rsalvaterra>
Ansuel: Wait, the AX3600 *requires* working NSS? o_O
<Ansuel>
stintel: marvell was good when that good guy supported it... when it was abandoned wifi chip started to be shit
<rsalvaterra>
I've seen your effort in getting the NSS to work, in the forum. Last time I checked, it crashed after several days, I don't know if it's still the case… :/
<Ansuel>
rsalvaterra: we never actually had proof of that... but robi contected a qca representative and he said that nss core are mandatory for the correct function of the switch (if the wifi chip is also used)... but really nss is not a problem as nss firmware are public (and they are for this exact reason... nss is now mandatory for the correct function of the network system)
<Ansuel>
mrkiko: we currently use an exploit on old firmware to enable serial access and access to uboot... from there you can load wth you want...
<rsalvaterra>
Imagine if the NSS could actually run eBPF code… :)
<Ansuel>
for the bigger brother the ax9300 we found another exploit to give ssh shell... and same path
<Ansuel>
there is another netgear router with the bi ipq8074 soc that has secure boot enabled but that can be bypassed by simply changing the default boot command in uboot (thank god they chose that path and they didn't lock the device entirerly)
<rsalvaterra>
Ansuel: That's similar to being able to disable secure boot in UEFI. Fortunately.
<Ansuel>
rsalvaterra: the nss core on the new soc are incredibile... i honestly think they are as powerful as the normal core present in ipq806x...
<rsalvaterra>
It would be nicer if we could upload our own keys, though.
<mrkiko>
Ansuel: netghear rbk<something> ? I would like to try out things, but I guess I'm better waiting and maybe see what happens?
<rsalvaterra>
Ansuel: I guess they have to be… wire speed are getting really high. Either the work is offloaded to dedicated hardware, or CPU power will have to increase dramatically.
<Ansuel>
rsalvaterra: it's oem choice tho... look xiaomi how he decided to lock uboot... they can use the master combo secure_boot + lock uboot and you can just trash the router... (or secure boot + hard code boot command)
<mrkiko>
Ansuel: i.e.: it would not be nice if I get a device with an updated firmware and no exploit. And I'm not good at soldering UARTs :D
<Ansuel>
i would say let's wait and how the situation will improve... the best thing would be wait for proper oem and ignore anything from xiaomi (also afaik you can downgrade firmware from webui)
<Ansuel>
rsalvaterra: this new soc supports one port with 2.5gbps finally we are adoping that... but they are expensive 300€
decke has quit [Quit: Leaving.]
<mrkiko>
Ansuel: thanks!!
<Ansuel>
wait ax9000 is at 212€ o.O
<rsalvaterra>
God, that AX9000 is fugly.
<Ansuel>
from 359€ not bad... it's a punch in the eye but for the perf it's very good... considering it's the full ipq8074 dev board in a nice enclosure...
minimal has joined #openwrt-devel
<Ansuel>
xiaomi devs with the ax9000: PUT EVERYTHING IN IT AND MAKE A MASSIVE CASE WITH A FAN!
<mrkiko>
but I don't understand why xiaomi, and other manifactuers of course, insist in locking things down this way
<Ansuel>
for xiaomi... chinese logic for network stuff
<Ansuel>
they born in china and they are probably full of backdoor... they then sell them in eu with cleared firmware but still they don't want you to check what they do inside
<Ansuel>
for other proper oem... marketing security
<rsalvaterra>
Ansuel: I don't know about specific backdoors, but I looked at my Redmi AC2100 OEM firewall rules. It's… scary.
<mrkiko>
Ansuel: I remember even xiaomi mt7621 devices not beingh as easy to use :DS
<mrkiko>
oops, I added an S b mistake
<mrkiko>
Ansuel: and they have that xiaomi thing for xiaomi devices. I think it's not supported in openwrt. Or is it another ath11k devices?
<Ansuel>
example the ax9000 have a RCE in the wifi handling... we assume it's a bug but WHO KNOWS
<Ansuel>
mrkiko: what you are referring at?
schwicht has joined #openwrt-devel
<Ansuel>
you mean the bs ai stuff ?
<mrkiko>
Ansuel: Don't remember, I read about it in a gsmarena article. They where talking about a xiaomi-proprietary thing for xiamoi devices to talk to each other
<mrkiko>
but hey, I want openwrt...
<Ansuel>
guess where is the RCE ? ahahaha exactly in that xiaomi proprietary thing
<Ansuel>
i honestly think we can accomplish the same task with DAWN / simple mesh network
Tapper has joined #openwrt-devel
<mrkiko>
Ansuel: is their own hardware or does it use a know driver / protocol to talk to the hardware? Or is it completely homegrown??
<Ansuel>
aahhaha so fun... they just send some special packet and the wifi driver reacts to them and do stuff. nothing fancy or complex
<karlp>
stintel: so, you run ethernet + rj console to every ap in a site? I mean, that seems like a unhappy solution, so I totally understand why people don't put console ports of any form on APs
<Ansuel>
it's all software
<stintel>
karlp: decent enterprise hardware has rj45 console
<rsalvaterra>
stintel: Are those RJ-45 consoles standard? Are the pinouts always the same, everywhere?
<karlp>
right, so even with POE, you're runnign console+eth everywhere.
<stintel>
karlp: never said I run console everywhere
<stintel>
rsalvaterra: quite standard, everything I have is cisco compatible
<karlp>
so you're on a step ladder plugging a console into a false ceiling? I don't get it
<stintel>
karlp: if needed, yes
<rsalvaterra>
Right, I've seen them in Cisco gear, and we all know what Cisco does to standards. :)
<mrkiko>
Ansuel: thanks for the nice chat
<stintel>
also there's a big difference in removing a device from a false ceiling or wall, taking it to your office, plugging in rj45, fixing the problem and reinstalling it
<stintel>
if you need to remove the cover, solder a header, etc ...
<stintel>
it's just not convenient
<mrkiko>
Ansuel: I'm very curious to see how things evolve
<stintel>
especially not if you have many devices
<Tapper>
nick[m]1234 What I mene is that there is no page wiki for DAWN that will let people know how to use it.
<Tapper>
wiki page*
<rsalvaterra>
Right. With the front-facing console, you can solve most problems in situ.
<mrkiko>
I am all for console ports exposed.
<stintel>
yes. it's what all the big boys do
<Tapper>
How do you get it working? What will it do for me running 2 APS?
<Ansuel>
mrkiko: unless the community puts some effort we are stuck :( hope me or robi have some time to improve things
<rsalvaterra>
mrkiko: Serial porn? :)
<Tapper>
rsalvaterra lol
<stintel>
not to mention opening a device to install a serial header will most definitely void warranty
<stintel>
if you don't agree that's fine for you, but there's no need to question my hard requirement for rj45 console port like I'm some kind of idiot ?
<Tapper>
nick[m]1234 will it even be any help to some one with a larg house and just 2 APs or is it just for mesh?
<Tapper>
large*
<mrkiko>
stintel: well, I find consoles very very confortable. Unfortunately I don't have many devices with a console port
<mrkiko>
Ansuel: well, expensivbe hardware and unfriendly OEMs are not helpful factors
<mrkiko>
Ansuel: but I hope situation to improve as well
<svanheule>
nick[m]1234: stintel: my EAP245v1 and v3 don't appear to have this issue, been running quite stable. Although I did stop using DAWN... Not that I ever tested it thoroughly, so I can't really say what made me stop using it (aside from the log spamming)
<svanheule>
nick[m]1234: stintel: I used to have device monitoring too, but then my RPi's SD-card got corrupted and took my Observium instance with it :-/
<nick[m]1234>
svanheule: I switched now to trunk and ct firmware
<nick[m]1234>
lets see if this will help :)
<nick[m]1234>
svanheule: with the new settings it can help to reduce roaming times
<nick[m]1234>
depends on the device
<mrkiko>
In router world, I seen so much good hardware, the software being the problem sometimes. Apreciating openwrt a lot.
<nick[m]1234>
however, I see it still as WIP
<svanheule>
nick[m]1234: I think my phone has issues connecting to 5GHz anyway, which is the device that would benefit most from the fast/assisted roaming...
<nick[m]1234>
svanheule: we will soon have som street completely covered with wifi
<nick[m]1234>
I'm looking into it that I can bycicle through it and have no interruptions
<nick[m]1234>
however that will take years xD
<nick[m]1234>
I work on it in my free time
<nick[m]1234>
and we have so much to do
<nick[m]1234>
at least I will get now a tshirt for my work for hacktober :D
<stintel>
sounds like a fun project :)
<G10h4ck>
is there any reasonable extimation for when we will be able to package rust lang based stuff for openwrt?
<mrkiko>
G10h4ck: I guess it's a matter of submitting needed patches. Does rust support MIPS BTW?
<G10h4ck>
mrkiko I have found blogs post about peole crosscompiling and using the produced binary into mips openwrt routers
<G10h4ck>
also it seems there is a PR for the openwrt toolchain on openwrt github https://github.com/openwrt/packages/pull/13916 but i am unsure of how more time it will take and what will be the results
<G10h4ck>
one of the drawbrack i saw on the blog posts is that the produced binary for just hello word was 2MB because of everithing compiled inside
<G10h4ck>
and that is a no go
<karlp>
that PR is pretty close to finished,
<karlp>
grommish is often here, you can talk to him about it.
<Tapper>
grommish all so spends time on the discord server.
<mrkiko>
G10h4ck: same thing with go (I mean - big bninaries). But squashfs is pretty good at that, or at least it was when I tried it.
<mrkiko>
Tapper: does it run a discord server on a routewr?
<Tapper>
mrkiko no mate. lol windows 11
<Tapper>
Sorry
<mrkiko>
Has someone tried to run Telegram's TDLib on a router? Of course, not storing data in flash
<mrkiko>
Tapper: know nothing about discord.
<Tapper>
It is a voice and txt chat server thing. It's not open so some people don't like it.
<Tapper>
It can all so be a pane in the ars with a screen reader but is usable
<stintel>
it's proprietary crap, and connecting with 3rd party client is violation of user agreement and can result in your account being terminated
<stintel>
so my suggestion: stay away from discord as far as possible :)
<Tapper>
yeah that's true
<stintel>
if there is really a need for hipster chat stuff, look at Matrix
<Tapper>
There is over 200 people on the OpenWrt server now tho.
<Tapper>
A lot of people that would never use irc use it tho
<rsalvaterra>
Ansuel: Archer C6 v2 up and running with DSA. ;)
<mrkiko>
I don't like Discord due to it's name - in italian discord remembers me of "discordia" which is something like "general disagreement",.
<G10h4ck>
thanks for the info
<Ansuel>
rsalvaterra: so the problem was pll :D
<rsalvaterra>
Ansuel: Not sure if it was only that. There were a few bits missing from my device tree changes, compared to mangix's. :)
<mrkiko>
I was thinking it could be something decentralized / small, so now I understand why Tapper was laughting at me when I said about running a server :D
<Tapper>
mrkiko O yeah mate it's not small. It's a bloted pece of shit TBH. lol
<Tapper>
I just use it some times for the voice chat. You know blind people love voice chat and my typing is crappy to add to it.
<mrkiko>
Tapper: :D so maybe you tried Zello and other stufdf like that?
<Tapper>
Yeah mate used Zello
<Tapper>
I got sick of it tho because I could not find chanels to talk on. The serch was not fit for purpose
<mrkiko>
Tapper: what do you use to follow irc?
<Tapper>
mrkiko Instantbird is the onley thing I can find that works with NVDA
<mrkiko>
Tapper: nice! I'm using irssi on Linux at the moment, but it's not so practical when there is high traffic; because I don't know enough how to use it to search for people talking to me in the meantgime, apart from setting myself to /away ... which I usually forget.
guerby_ has quit [Read error: Connection reset by peer]
guerby_ has joined #openwrt-devel
<mrkiko>
Tapper: regarding devices, I remember you where using linksys?
<mrkiko>
wrtm32x?
<Tapper>
I have a wrt3200acm, c7-v2, wdr3600 WD N750, and a r7800
<mrkiko>
Tapper: nice :D
<mrkiko>
The legendary R7800 :D
<mrkiko>
seems cpretty popular device
<mangix>
rsalvaterra: iperf benchmarks please
<Tapper>
Yeah I think I have a wrt1900ac-v2 some were to
<mangix>
iperf3 rather
<Tapper>
The r7800 has mutch better wifi than the wrt3200acm so I run the r7800 as my mane router now
<rsalvaterra>
mangix: Gah, keep forgetting about those.
<mrkiko>
Tapper: so it does routing and wi-fi; and the linksys device dumb ap?
<Ansuel>
Tapper: also the wifi works
<Tapper>
Yeah the wifi works. lol
<mangix>
The wrt1900v1 was interesting. minipcie slots.
<Tapper>
mrkiko R7800 is mane router and AP and I have a c7 at the top of the house as a dumb AP
<mangix>
Replace trash Marvell cards
<Tapper>
Thinking about the Marvell drivers makes me mad.
<Tapper>
All the hipe the built up about the new wrt routers. They were going to be the next wrt54g and all that stuff.
<mrkiko>
Tapper: driver crashes, firmware issues or what?
<Tapper>
all that mate lol
<Tapper>
both
<Tapper>
The driver cant even do some simple things. WPA3 is buggy on it to.
<Tapper>
There is some wifi radios like what you get on iot devices just will not work with the radios no matter what you do.
<Ansuel>
someone fixed wpa3 with a simple fix afaik
<Ansuel>
but stability is still shit
<mrkiko>
So in terms of long term stability the winner was ath9k
<mrkiko>
?
<mrkiko>
Or was it a problem even back then?
<Ansuel>
with ath9k everything was fixable... but that is too old....
<mangix>
It took a long time for ath9k to get its stability.
<mangix>
These newer chips have too much firmware.
pmelange has quit [Quit: Leaving.]
floof58 has quit []
floof58 has joined #openwrt-devel
<hurricos>
mangix: I have a v1. What do you mean, replace the wireless cards? Does the device have internal UFLs?
<Ansuel>
that they are detachable ?
<Ansuel>
they have normal mpci port and separate card
<hurricos>
I know, I know. But no point if you can't replace antennas.
<Ansuel>
?? they are not detchabale?
<hurricos>
oh.
<hurricos>
I haven't checked.
<Ansuel>
yes they are... they should use normal connectory... they can't be soldered to the mpci card
<hurricos>
The SoC does support MSI. There are those cheap brcm46345 cards going around that are 4x4, or I could go buy a MT7615.
<Ansuel>
brcm and openwrt doesn't like each other
<hurricos>
Ansuel: brcm46345 has perfect brcmfmac support, and fw in Openwrt as of May 2020 :D
<hurricos>
I say "perfect", but yes, it is only cfg80211, and if you add too many VIFs, you will wake up in a sweat hearing whispers.
<hurricos>
alternatively you can strip the QCA9890's out of modern eol WAPs
<hurricos>
e.g. Extreme Networks WS-AP3825i
goliath has quit [Quit: SIGSEGV]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Slimey>
wait
<Slimey>
i have a ap based off of Extreme Networks WS-AP3825i
<Slimey>
rebrand but same guts
<Slimey>
good radios they are :)
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
<Ansuel>
mangix: btw i found another reg and another feature that we need to support.... so this reduce MISSING TO CONVERT REMAINING to 1 device
<Ansuel>
the qca9563_xiaomi_aiot-ac2350.dts where BIT 29 is not documented... will add this feature and report back here the needed binding
<Ansuel>
(some device have the reduced qca8327 pin layout and this bit is only present in qca8327.... this has changed in qca8337 where they changed the reg table)
<PaulFertser>
russell--: might be just a coincidence too
<JuniorJPDJ>
I'd like to add some feature. I found gitlab. Merge request is a good way of doing it?
<Ansuel>
mangix: i think you will have to update the ath79 pr
<PaulFertser>
JuniorJPDJ: not sure, do you see other merge requests there? I thought all parts that are hosted on git.openwrt.org are supposed to get e-mail patches only.
<Ansuel>
Conf for cpu port5, Mode rgmii-rxid wonder if this is a typo from oem or is actually needed... would mean that it's not only specific to qca8337
<fda->
"procd: /etc/rc.d/S95done: Command failed: Not found" - i checked it and it is a link to an existing file
<Ansuel>
fda-:problem with gcc11?
<fda->
@Ansuel i have fedora, maybe
<fda->
last image 2,5 wekks ago worked
<fda->
btw, 3. problem: wrong "iw" arguments: kernel: [ 106.644867] netlink: 'iw': attribute type 302 has an invalid length.
<Ansuel>
there is definetly something wrong in your compiled bin it seems
<Ansuel>
target is?
<mangix>
Ansuel: maybe it was advice from QCA (Qualcomm Crack Addicts)
<fda->
bin/targets/lantiq/xway
<fda->
gcc on my fedora 34 system: gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1)
<Ansuel>
you don't compile your image with your host gcc
<Ansuel>
we switched to gcc11 recentely so that could be related
<mangix>
fda-: wipe your entire toolchain
<mangix>
musl 1.2 breaks ABI
<fda->
@mangix i did it before i start make
<mangix>
Ansuel: how do you run your script? ./script.py target/linux/ath79/dts/ == no output
<mangix>
it worked before
<fda->
i build for my other devices mediatek/mt7622 and ipq40xx/generic also new images, but im not sure if i should flash them
<mangix>
oh wait, LOL
<Ansuel>
works for me
<fda->
does wsdd2 works for someone else?
<russell-->
the iw attribute type 302 has shown up for me on several recent builds, including one preceded by dirclean
<russell-->
i haven't tracked it down yet
<mangix>
Ansuel: yeah I tried running it on top of my DSA PR
<fda->
@russell-- in which file i could check? i have also an serial console on fritz7320
<russell-->
fda-: if i knew, i'd tell you
<Ansuel>
mangix: owww.... well then it's correct
<fda->
wsdd2: maybe noone noticed the crash, as the init-script fails to start the daemon as "samba/ksmbd is not running" by default
Tapper has quit [Ping timeout: 480 seconds]
<mangix>
Ansuel: I'm convinced that xiaomi setup is not correct.
<mangix>
all package48 devices are ar9344 based
<fda->
uh, openwrt uses buggy busybox 1.34.0! there is an .1 update
<fda->
mangix: how do you get "wsd_send_soap_msg" ?
<mangix>
fda-: the close is in uuid_endpoint, which is in wsd_init, which calls wsd_send_hello, which calls wsd_send_soap_msg
<mangix>
or maybe the crash is in some asprintf call... no idea.
<fda->
mangix: so from the trace you used only theopen of /etc/machine-id ?
<fda->
maybe its something with fileystem, during start was also "procd: /etc/rc.d/S95done: Command failed: Not found" but when i log in the link is existing and the target file there
<fda->
really bad samba4 is so huge, ksmbd+wssd2 are so buged
<fda->
and no routing is possible etc
goliath has joined #openwrt-devel
pmelange1 has joined #openwrt-devel
Tapper has joined #openwrt-devel
pmelange2 has joined #openwrt-devel
pmelange has quit [Read error: Connection reset by peer]
pmelange1 has quit [Ping timeout: 480 seconds]
swegener has quit [Quit: leaving]
swegener has joined #openwrt-devel
jbowen has quit [Quit: leaving]
<digitalcircuit>
slh: I'll try building from your commit (without the extra PR you merged) to see if it works here, https://github.com/openwrt/openwrt/commit/a46fa5c3a7 If so, then I'll try to git bisect good/bad until I pin down when the NBG6817 fails to boot. (Hopefully the package repos don't need mangled either.)
<digitalcircuit>
(Unfortunately, that's before the toolchain change, so I'll have my "make dirclean" and/or "make distclean" at the ready.)
<digitalcircuit>
(Err, after the change, before removing old support.)
<slh>
I already had musl 1.2 merged in (but using the default gcc of the day)
<slh>
so gcc-10, Linux version 5.10.66 (slh@trident) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 10.3.0 r17525-a46fa5c3a7) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #0 SMP Thu Sep 16 05:59:50 2021
<digitalcircuit>
Ah, noted! So I probably don't need to clear toolchain directory.
<digitalcircuit>
Packages aren't all happy, so I'll probably want to use the script to pin the package repos to a similar timeframe.
<digitalcircuit>
Nevermind - the commit that adds meson to base is right after the commit you were using, slh - it's probably safe to try that to reduce build headaches (pinning repo commit still had issues).
<digitalcircuit>
slh: Thank you! If I run into issues, I'll try those next.
<fda->
thix should be the fix for "attribute type 302 has an invalid length." https://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=4d0c2ad3fd268388b97af0582baa8a89c3639d8b
<fda->
but its not in main repo
<digitalcircuit>
slh: I also appreciate your "make defconfig oldconfig" recommendation too; it has made verifying in menuconfig less annoying (no save prompt, always consistent so far).
<fda->
no, its not the fix ^^ @digitalcircuit "make defconfig" should be enough
* digitalcircuit
makes note
<slh>
mrkiko: xiaomi ax3600 and ax9000 can be flashed without opening the device or soldering, of course for developing you can't do without serial - but you can get OpenWrt flashed and running without that
<slh>
the unpopulated serial header (1.8V!) is also relatively easily reachable (in comparison to other devices)
<digitalcircuit>
On the upside, if the issue happened between your commit and the one I tried (with meson added to base), then that's a very narrow range to git bisect.
<slh>
did you successfully test my commit base?
<digitalcircuit>
slh: I've started that build right now; I'll follow up once I find out
<digitalcircuit>
(I'm assuming a "make dirclean" is enough alongside re-running "scripts/feeds update -a ; scripts/feeds install -a" after switching feed sources; it seemed to detect and re-write the downloaded repos appropriately.)
Tapper has quit [Ping timeout: 480 seconds]
shibboleth has joined #openwrt-devel
<rsalvaterra>
karlp: Brilliant, love it! xD
<shibboleth>
master/latest bootloops on c2600, ad7200
<shibboleth>
happens as soon as the switch/lan LED is turned on