<ynezz>
hauke: neoraider: it runs every 6 hours, and the idea behind is to help with the patch workload/handling/filtering, and it doesn't mean, that your patches are not reviewed, just the handling of the patch is on the author/project member
<ynezz>
hauke: neoraider: we were doing that patch assignment manually anyway, so I've thought, that it would be better to automate it
<ynezz>
hauke: neoraider: I usually send a patch, wait a week or two, and if there is no review response, it usually means, that nobody spotted something obviously stupid and thus merge it
<dhewg>
nbd: that looks better, works on first glance. I'll keep an eye open
<nbd>
dhewg: thanks! i'm currently doing another rework of the fast xmit code to clean it up some more, but that will take some more time. i pushed to master what you tested so far
<dhewg>
okay, nice, thanks for the fix!
<spyrral>
brcm charges $60k for a development board, what a deal
<jenders>
Does anyone know who is able to regenerate the package index on the wiki? It's still pointing at the index for 21.02: https://openwrt.org/packages/index/start
<jenders>
Regenerating the index should probably be added to the release plan.
<jenders>
fwiw I have contacted a few wiki admins but nobody is familiar with the process to regenerate the index.
rua has quit [Remote host closed the connection]
T-Bone has quit [Ping timeout: 480 seconds]
<djfe_>
there are comments in the page source for the wiki page you linked:
<djfe_>
"This page is updated automatically every sunday and can not be edited." "If you spot mistakes or your package isn't being loaded, please notify a wiki admin or bobafetthotmail in wiki/forum"
<djfe_>
Does anyone know bobafetthotmail?
<jenders>
I tried contacting him via wiki DM a few weeks ago but he hasn't responded
<jenders>
I imagine he gets a lot of DMs
rua has joined #openwrt-devel
<djfe_>
other admins listed are: jow, thess, tmomas, zorun
<jenders>
have contacted tmomas who was unfamiliar but those other names are new to me, I'll reach out
<djfe_>
when oldwiki was down, hauke forwarded my message to "Zoltan" but I won't share that mail address publicly here since I'm not sure who he is
<jenders>
Gotcha, that makes sense
<djfe_>
ah, his nickname is wigyori
<jenders>
Very helpful, ty!
<djfe_>
actually he is even listed for oldwiki and sources archive on the infrastructure page ^^
<jenders>
That's a good resource! I had referenced the contacts page but this looks more complete
<jenders>
I'd also like to propose an update to the pkgdata template so that individual package pages link to the latest corresponding package on downloads.openwrt.org via the architectures links. Currently these links point to the wiki pages for each architecture which isn't as useful IMHO. Is this something others would find useful as well?
jenders has quit [Remote host closed the connection]
jenders has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
jenders has quit [Remote host closed the connection]
jenders has joined #openwrt-devel
jenders has quit [Ping timeout: 480 seconds]
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
danitool has joined #openwrt-devel
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
f00b4r0__ has quit [Quit: Quitte]
Ryncewynd has joined #openwrt-devel
rua has quit [Quit: Leaving.]
djfe__ has joined #openwrt-devel
djfe__ has quit []
jenders has joined #openwrt-devel
rua has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
rua has quit []
rua has joined #openwrt-devel
Borromini has joined #openwrt-devel
rua has quit [Remote host closed the connection]
djfe has quit [Read error: Connection reset by peer]
<Znevna>
djfe: considered running znc on your router? :P
<djfe>
just when I was finished setting up Quassel correctly? never :P ^^
<djfe>
I made a mistake and setup monolithic Quassel first, when I used Quassel Core later, it logged in twice and quassel client only got djfe_ as a result.
<djfe>
I might switch to a bouncer running on an openwrt machine later though, so thx for recommending znc
<djfe>
All that spam should be a thing of the past now that I have a working bouncer and I registered my nickname
<Znevna>
quassel is also some sort of bouncer right?
<radian>
Znevna: it has its own protocol, yes
<djfe>
yes and I can be logged in on desktop and android at the same time :)
<radian>
if you want to use znc, make sure route_replies is loaded in
<djfe>
noted
<radian>
it'll crash if you're running it on a 4/32 device
<radian>
well, if you add in a bunch of networks + tls overhead, yes
<radian>
I remember tls causing the lag indicator to light up on my client
<djfe>
good that I never owned a 4/32 and only started with all of this in the past half year or so
<radian>
4/32 is plenty usable...
<radian>
you can do iscsi with 32MiB of RAM with no issues, actually
<radian>
it's not enough to run an ioquake3 server, however, don't do 128MiB of swap, either, watchdog will just kick in and reboot the device (disabling it won't help...)
<djfe>
the thing I struggled with the most was finding out, why I couldn't connect to my Quassel-Core remotely on Android while it was working on PC. Eventually I found out that I had to setup my dyndns differently for ipv6. Quassel only tries ipv6 on Android if dns outputs both... Good thing myfritz.net allows me to setup sub-subdomains for individual ipv6 machines these days.
<radian>
yikes, why not use v6?
<radian>
oh, I see, your prefix isn't static
<djfe>
v6 is working now :)
<djfe>
it could be static, I'm actually not sure.
<radian>
imo, just get a $12/year VPS and do a tunnel back to home
<djfe>
at some point sure, I'm still studying ^^
<radian>
openwrt with uci will make it cumbersome to do that, however, best to stick to plain gnu/linux
<radian>
pbr should be easy, but the abstractions make it seem hard
<djfe>
The thing is a dyndns is the better solution until I get a VPS since it allows me to use my bouncer from ipv4-only networks.
<nbd>
dhewg: got the mesh rework done faster than i expected. i pushed it to my staging tree
<nbd>
it also has some extra fixes
<nick[m]12>
nbd: new things? I saw you pushed a new commit on master
<nbd>
i'm talking about another rework on top of that in my staging tree
<nbd>
but it's more experimental
<nbd>
once that is validated, i think the code is ready for upstream
<djfe>
nbd: If I disable a WiFi within LuCI on Snapshots, then it won't disable the wifi chip (MT7905) correctly because it runs into an error. wifi down works fine though.
<djfe>
Is this something that needs to be fixed in OpenWRT or in LuCI?
<djfe>
daemon.notice netifd: radio0 (5837): WARNING: Variable 'data' does not exist or is not an array/object
<djfe>
daemon.notice netifd: radio0 (5837): Bug: PHY is undefined for device 'radio0'
<nbd>
i think there's a bug that i still need to fix which causes bogus radio* sections to get created
<nbd>
i don't know what triggers it, but i see it occasionally
<djfe>
Maybe important: If wifi was enabled on boot, then disabling WiFi via LuCI will work fine once. But that's it.
<spyrral>
open(fucking)wrt
<djfe>
Anyways I wanted to bring this to your attention, so it can get fixed before the commit hits a release at some point. Good to know that you might have an idea already :)
<djfe>
spyrral: ?
<djfe>
> i don't know what triggers it, but i see it occasionally
<djfe>
The bug I'm talking about happens everytime actually
<nbd>
i'm talking about something that occasionally messes up the config in a way that stays
<nbd>
and could be causing your issue
<djfe>
that makes sense ty
<spyrral>
djfe: can you call me to confirm that my phone number is active? it's +19492948374
<djfe>
lol
<djfe>
spyrral might be a bot
<spyrral>
djfe: what's the square root of 4, troon?
<spyrral>
fuck US people, death to the US, glory china
<spyrral>
can't wait for taiwan to be reintegrated into china, PLA is stronger than the shit US military complex
<spyrral>
(don't call the CPC "CCP", it's also wrong)
<Kufat>
Hi all. Any specific reason why openwrt still uses a version of Automake from ~7 years ago? I'm packaging oidentd to re-add it and I've had to patch out dist-zstd from configure.ac since it's not supported in that version of automake. NBD, patch is already done, but I'm curious
<dhewg>
nbd: ok, I'll check it out, but let me run this version a little longer to verify it
<Kufat>
(oh, I forgot there was someone here by that name, apologies for the accidental ping if you have your client set up for that, heh)
<spyrral>
fuck the US
<spyrral>
glory china
Lynx- has joined #openwrt-devel
valku has joined #openwrt-devel
<Znevna>
spyrral no broadcom today?
<spyrral>
huh?
<Slimey>
heh
djfe has joined #openwrt-devel
<Slimey>
i think he ment US = broadcom , china = qualcomm
<spyrral>
qualcomm isn't chinese
<spyrral>
mediatek is
<Slimey>
as long as they arent broadcom
<Znevna>
no, I just think that spyrral is the same noisy user that pops in here once in a while
<spyrral>
openwrt has gotten so lazy, you give the fucking community docs and nothing still happens
<spyrral>
10 years ago, someone would be immediately working on a u-boot port
<Znevna>
ah, there it is :p
<Slimey>
i need a nap
<spyrral>
Slimey: tried meth?
<spyrral>
sleep is for the weak
<Slimey>
thats kinda the idea, getting weak
<djfe>
Znevna: right on time :D
<spyrral>
.seen mrkiko
<spyrral>
great channel, nobody is even running a bot here
<spyrral>
mrkiko wants to wait on vendors to give him fuck-all source, I don't get why he's still afk
<Znevna>
spyrral: try reaching out to dd-wrt, i'm sure that you two would get along
<spyrral>
don't they have some agreement with brcm?
jenders has joined #openwrt-devel
<spyrral>
I can't tell if you're trying to be derogatory, actually
<Kufat>
I'm trying to do a build for BananaPi-R3 (mediatek ARM) and I'm getting complaints that acme depends on acme-acmesh, which doesn't exist. I do see feeds/packages/net/acme-acmesh and there appears to be a sensible makefile in there, so I'm not sure why it's not being picked up. (acme-acmesh doesn't show in menuconfig.)
<Kufat>
also getting similar complaints about luci-lua-runtime
jenders has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Kufat>
Huh, gues they somehow got missed by scripts/feeds install -a; I installed them manually and that seems okay
<spyrral>
Znevna: can I suck your dick?
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<nbd>
that's a warning that i also get without my patches if i don't use wpa_supplicant
<nbd>
make sure you have wpad-mesh-wolfssl (or similar) installed
<nbd>
i haven't figured out the cause yet
<nick[m]12>
let me check again
<nbd>
hm, found one more bug in the latest patches related to mesh path discovery
Borromini has joined #openwrt-devel
<nbd>
dhewg: i think the bug is also there in the version that you tested
<nbd>
it doesn't update the mesh path from incoming packets in some cases
<nbd>
leading to temporary ping loss
jenders has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lmore377_ has joined #openwrt-devel
lmore377 has quit [Ping timeout: 480 seconds]
<nick[m]12>
nbd: it looks like only broadcast packages pass the mesh on current openwrt-master with ipq40xx. I have to debug this a bit further.
srslypascal has quit [Quit: Leaving]
nixuser has joined #openwrt-devel
jenders has joined #openwrt-devel
<nbd>
nick[m]12: please try adding the latest 2 commits from my staging tree on top of current openwrt master
<nbd>
i managed to fix some issues with mesh path discovery based on unicast packets
<nbd>
dhewg: the last issue that i fixed was there even before the fast xmit patches
<nbd>
it led to issues where nodes that didn't previously communicate with each other couldn't reach each other via unicast
<nbd>
i could trigger it by restarting wifi on all nodes and then trying to ping an address behind a bridge from one of the nodes (preferably over multiple hops)
<nbd>
with the latest version from my staging tree, that works instantly
Znevna has quit [Quit: ZNC 1.8.1+deb1~bpo10+1 - https://znc.in]
Znevna has joined #openwrt-devel
<nick[m]12>
nbd: I will give it a try
lmore377 has joined #openwrt-devel
lmore377_ has quit [Ping timeout: 480 seconds]
<bluse-blue[m]>
compiling and testing over here as well
Borromini has quit [Quit: Lost terminal]
<dhewg>
huh weird, but it worked for me this morning
<dhewg>
but I'll give it a try tomorrow
<bluse-blue[m]>
just compiled latest trunk with both patches from nbd's staging on top ... no ping to the mesh 1-hop neighbours possible ... although olsr shows those neighbours with good etxgood
<bluse-blue[m]>
s/etxgood/etx/
<bluse-blue[m]>
* nbd: nick just compiled latest trunk with both patches from nbd's staging on top ... no ping to the mesh 1-hop neighbours possible ... although olsr shows those neighbours with good etx
<nick[m]12>
nbd: latest master with two latest commits from your staging does not improve the situation
<nick[m]12>
also seems that multicast ipv6 packets can not be send over the mesh
<nick[m]12>
at least on ff02::1%... ping the neighbor does not respnd
<nick[m]12>
however, the broadcast packets arrive. Sadly, I can not restart the wifi on the counterpart since I can not reach it anymore after updating one site. ^^
<bluse-blue[m]>
nbd: nick the bananaPi under test does send out icmp pakets ... the mesh 1-hop neighbor respones .. but the banaPi does not report those .. only multicast pakets are visible in txpdump on the wl2-mesh0 interface
<bluse-blue[m]>
s/txpdump/tcpdump/
<bluse-blue[m]>
* nbd: nick the bananaPi under test does send out icmp pakets ... the mesh 1-hop neighbor respones .. but the banaPi does not report those .. only multicast pakets are visible in tcpdump on rx at the wl2-mesh0 interface
<bluse-blue[m]>
<nick[m]12> "however, the broadcast packets..." <- no 2nd link to that node possible ? .. mesh only ?
Paradox17 has joined #openwrt-devel
Paradox17 has quit []
Ryncewynd has quit [Quit: Leaving]
<nbd>
oh, i figured out what's going on
<nbd>
i was testing mesh with forwarding enabled
<bluse-blue[m]>
ah
<nbd>
and there's a bug specific to forwarding-disabled setups
<nbd>
one moment, i'll make a patch
<bluse-blue[m]>
top deluxe ;) ... ready to re-compile, flash and test da mesher mesh
<schmars[m]>
are we trying to fix ath10k deaf radio bugs? count me in
<nbd>
bluse-blue[m], nick[m]12: update the commit in my staging tree
<nbd>
(latest commit in the branch)
<bluse-blue[m]>
on it
champtar_ has joined #openwrt-devel
Obi-Wan- has joined #openwrt-devel
maciekb has quit [Remote host closed the connection]
maciekb has joined #openwrt-devel
Obi-Wan has quit [Remote host closed the connection]
champtar has quit [Ping timeout: 480 seconds]
<bluse-blue[m]>
nick nbd compiled, flashed ... all links reachable .. da fix did it ;) .. thx!
<nbd>
cool, thx for testing
<nbd>
will push it to master
<nick[m]12>
nbd: for me it does not fix it :/ Still same behavior. I cherry-picked ca3b8b60 and 179ae537
<bluse-blue[m]>
I did: (1) reset --hard to commit of trunk ..(2) git fetch nbd staging ... (3) git chery-pick both top patchen from nbd staging ... (4) make package/mac80211/clean && make
<bluse-blue[m]>
s/patchen/patches/
<bluse-blue[m]>
* I did: (1) reset --hard to commit of trunk ..(2) git fetch nbd staging ... (3) git chery-pick both top patches from nbd staging ... (4) make package/mac80211/clean && make -> flash & test & working state
<nbd>
nick[m]12: not sure what those commit hashes refer to
<nbd>
nick[m]12: i don't have them in my tree
<bluse-blue[m]>
* nick: I did: (1) reset --hard to commit of trunk ..(2) git fetch nbd staging ... (3) git chery-pick both top patches from nbd staging ... (4) make package/mac80211/clean && make -> flash & test & working state
<nick[m]12>
whups. sorry, I mean 57a5de15b3 and af560367c
<nick[m]12>
so latest patches in your staging
<nbd>
you're using mesh without forwarding as well, right?
<bluse-blue[m]>
nick: lets breake out to jitsi ... quite sure my testing setup validates the new patch is fixing mesh operation?
<nick[m]12>
yes
<bluse-blue[m]>
* nick: lets breake out to jitsi ?... quite sure my testing setup validates the new patch is fixing mesh operation on ath9k and mt7615?
<bluse-blue[m]>
s/.../?.../, s/?/ on ath9k and mt7615/
jenders has quit [Ping timeout: 480 seconds]
<nick[m]12>
nbd: the only thing I could imagine is that we put the mesh to a bridge and do the "mesh daemon" stuff on another router and not directly the meshing device
<bluse-blue[m]>
thx for your effort .... I do reflash da evernet now... gn8!
<djfe>
nice :)
<djfe>
gn8
<djfe>
nick[m]12:did you test the patch for ex6100v2, yet?
<djfe>
how did you come up with rgmii? or just a guess?
<nick[m]12>
good night. probably someone could also push a quick refresh of the mac80211 patches, otherwise it could be that github CIs fail again because of dirty patches.
<nick[m]12>
djfe: I have chosen rgmii by comparing the device to other devices. But indeed it was only a guess.
<djfe>
good to know, I'll test it out now
<djfe>
Would you recommend enabling all ports, to see which one of them works?
<djfe>
my first test was swport5 (without rgmii) and it didn't work.
<djfe>
I'm connecting serial now, to see what's going on
<nick[m]12>
enabling all ports could be a good strategy. ;) Actually, never made use of that strategy. As far as I know almost all single port devices used port5.
<nick[m]12>
djfe: instead of using serial port connection, why not using wifi? I typically enable it by default when doing something with the switch/ethernet...
<hauke>
djfe: I think I looked into most of the tickets where you marked me
<djfe>
you are sysupgrading without resetting the config, then?