**** BEGIN LOGGING AT Sun Feb 07 02:59:58 2021
Feb 07 04:16:23 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 98.4% packages reproducible in our current test framework.)
Feb 07 04:28:31 <owrt-snap-builds> build #781 of ath79/nand is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fnand/builds/781
Feb 07 08:57:41 <russell--> why doesn't sysupgrade notice that i just gave it -n?
Feb 07 08:57:47 <russell--> "Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall."
Feb 07 09:20:50 <Namidairo> "force required"
Feb 07 09:21:04 <Namidairo> gotta --force it
Feb 07 09:21:56 <Namidairo> otherwise everyone would go around soft bricking their routers with broken switch configurations
Feb 07 09:45:57 <russell--> Namidairo: -n wipes the config, what extra does -F do?
Feb 07 09:47:19 <Namidairo> it didn't make sense but afaik, it was the least bad solution that kept compatibility with older images
Feb 07 09:47:28 <zorun> -F means "force"
Feb 07 09:47:39 <zorun> which means "if you brick your device, you have been warned"
Feb 07 09:48:23 <russell--> but it's warning me that my old config isn't expected to work, but *I JUST TOLD IT NOT TO USE THE OLD CONFIG* right in the command line
Feb 07 09:48:24 <zorun> in this case it's more of a hack indeed, it should be harmless (if you have the right image)
Feb 07 09:49:46 <zorun> russell--: Namidairo is right, it's a hack, this mechanism is supposed to prevent you from flashing the wrong image, and it has been (ab)used to warn about incompatible changes
Feb 07 09:51:09 <zorun> so you need both -n and -F
Feb 07 09:51:30 <russell--> yeah, i know, it just seems stupidly redundant
Feb 07 09:52:28 <PaulFertser> Hey zorun. Can you please tell what should be the right advice to the new users on IRC who want to contribute to the wiki?
Feb 07 09:52:36 <russell--> (fwiw, i never save the old config, my fingers are pre-programmed to type -n on sysupgrades)
Feb 07 09:52:43 <zorun> russell--: I see :)
Feb 07 09:53:21 <Namidairo> backed up configs are good for reference though
Feb 07 09:53:31 <zorun> PaulFertser: what do you mean?
Feb 07 09:53:39 <russell--> Namidairo: i pre-backup my configs
Feb 07 09:53:43 <PaulFertser> zorun: people say the wiki has registration disabled for the new users.
Feb 07 09:54:27 <zorun> ah, I guess that's because of spam?
Feb 07 09:54:34 <zorun> so an admin should create the accounts manually
Feb 07 09:55:48 <PaulFertser> Probably but e.g. do not know how to contact the admin and so the potential contributors are not improving the wiki, and I have no idea what to tell them.
Feb 07 09:57:57 <zorun> https://forum.openwrt.org/t/wiki-registration-disabled/87800
Feb 07 09:59:25 <zorun> PaulFertser: I can add you as admin if you want to help creating accounts
Feb 07 09:59:32 <zorun> but I agree it's not a good situation
Feb 07 10:00:37 <PaulFertser> zorun: please do, I'm frequently available on IRC but I never use the forum, so was not aware of that announcement, and it's also unclear if tmomas is OK with getting requests via e-mail (and not only forum PMs).
Feb 07 10:01:47 <zorun> PaulFertser: done and thanks!
Feb 07 10:02:01 <PaulFertser> zorun: thank you!
Feb 07 10:02:13 <zorun> you should leave the password field empty, the user will receive an email to define it
Feb 07 10:02:25 <PaulFertser> Got it.
Feb 07 10:03:07 <russell--> maybe document how to register in https://openwrt.org/wiki/wikirules which is linked from the sidebar under "Contributing to wiki"
Feb 07 10:07:50 <PaulFertser> zorun: I see you resetted my password, and I received a new one via unencrypted e-mail, and the e-mail doesn't advice me to change it. Is it ok?
Feb 07 10:10:38 <PaulFertser> russell--: I'd rather add the information to the new user registration page, let me check if I can do that.
Feb 07 10:17:54 <zorun> PaulFertser: err, did I?
Feb 07 10:18:48 <PaulFertser> zorun: somehow I received an e-mail from the wiki with the new password without doing anything myself, so in a way, yes :)
Feb 07 10:19:25 <zorun> PaulFertser: ok, I checked the "notify user" box while changing your groups, maybe that's why
Feb 07 10:19:43 <PaulFertser> Dokuwiki is odd
Feb 07 10:19:48 <zorun> sometimes yes
Feb 07 10:32:11 <PaulFertser> I made edits to https://openwrt.org/register_yourself_in_the_wiki
Feb 07 10:43:12 <ynezz> as a last resort just /msg ynezz wikiuser username email
Feb 07 10:44:04 <PaulFertser> Should I add your nick to the page I mentioned?
Feb 07 10:45:43 <ynezz> I don't know, if I'm going to eventually automate it in the future, then this could be abused again by the spammers
Feb 07 10:46:24 <ynezz> but for the time being, yes
Feb 07 10:46:55 <ynezz> we can change it in the future, maybe use some different trigger name
Feb 07 10:47:38 <PaulFertser> Thank you ynezz !
Feb 07 14:00:26 <totalnoob75> Hi all, how could I find out if commit b0ecae504b58bf65627138fe14eb605ad77224c9 of 23 November 2020 has made it into the releases released since then, 19.07.5 and 19.07.6? Github only shows me the most recent 250 commits. Thanks in advance.
Feb 07 14:04:52 <PaulFertser> totalnoob75: it hasn't. Usually device support is not backported to bugfix release branches
Feb 07 14:07:21 <totalnoob75> I figured as much. Thank you.
Feb 07 14:07:32 <plntyk> totalnoob75, some projects that use openwrt might add support for their 19.07 based releases - gluon does this sometimes
Feb 07 14:08:23 <plntyk> some has to add a pull request there that gets accepted tho
Feb 07 15:11:33 <Borromini> nbd: ping
Feb 07 16:51:28 <nbd> Borromini: pong
Feb 07 16:51:54 <Borromini> nbd: hi. i noticed today the MT7613BE radio is unable to use DFS channels
Feb 07 16:53:00 <Borromini> https://paste.debian.net/1184412/
Feb 07 16:53:22 <Borromini> tested on three EAP235-Wall devices
Feb 07 16:54:08 <nbd> right, i see that it is currently disabled in the code
Feb 07 16:54:45 <Borromini> oh
Feb 07 16:55:15 <nbd> not sure if it was because of lack of testing or because of an actual issue
Feb 07 16:55:28 <Borromini> ok. we can find out quickly enough if it's an actual issue :D
Feb 07 16:55:58 <Borromini> i have two i'm test driving still for that message 73 timeout issue
Feb 07 18:54:50 <Borromini> nbd: would you mind whipping up a patch or could you tell me where to enable it?
Feb 07 19:00:54 <svanheule> Borromini: maybe here? https://github.com/openwrt/mt76/blob/master/mt7615/mac.c#L2268
Feb 07 19:03:13 <Borromini> that looks like it yes :)
Feb 07 19:04:45 <nbd> in mt7615_init_wiphy (init.c) and in that mac.c function, replace is_mt7663 with mt7615_firmware_offload
Feb 07 19:05:11 <nbd> however, even if it works for you in that test, it still needs to be validated before we can enable it
Feb 07 19:05:31 <nbd> i.e. bring it up on a dfs channel and send a few radar pulses to see if it reacts
Feb 07 19:06:27 <nbd> i have a SDR that i could use to run that test, but i don't have time to hack up the pulse generator in gnuradio at the moment
Feb 07 19:06:50 <Borromini> ok. is that something i can do with a regular client radio? intel 802.11ac stuff e.g.?
Feb 07 19:07:16 <Borromini> or can i just try bringing up the AP and wait until a radar kicks it out?
Feb 07 19:07:53 <Borromini> ok sdr is software defined radio so i guess i can't do that with regular consumer stuff
Feb 07 19:08:45 <PaulFertser> If you know you have a radar nearby that would work :)
Feb 07 19:10:33 <Borromini> i used to get kicked off regularly. small civilian airport nearby as well here (few km)
Feb 07 19:13:11 <PaulFertser> If you know the channel where it happens then worth a try I'd say. Preferrably with an ath10k device working in parallel on the same channel so that you could compare the timestamps.
Feb 07 19:13:41 <Borromini> why ath10k?
Feb 07 19:14:08 <Borromini> i have mt7615 radios up and running, mt76 driver does support dfs on these already
Feb 07 19:14:26 <Borromini> asking out of curiosity, i have a spare ath10k radio if needed
Feb 07 19:14:43 <PaulFertser> I'd expect ath10k to be better tested in this regard but probably it's just my speculation.
Feb 07 19:15:41 <PaulFertser> Judging by QCA being interested in certification and having all the tools and directly using the upstream code for that. nbd will correct me if I'm wrong.
Feb 07 19:17:37 <Borromini> ok
Feb 07 20:01:20 <rsalvaterra> TIL by appending ".patch" to the URL of a GitHub pull request, you can download the whole thing as a patch. I have seen the light.
Feb 07 20:05:37 <Borromini> you didn't know?
Feb 07 20:06:13 <rsalvaterra> Not at all.
Feb 07 20:06:45 <rsalvaterra> Now it's easier to test kernel updates. :)
Feb 07 20:10:03 <lipnitsk> nbd: ping
Feb 07 20:13:28 <Borromini> rsalvaterra: yeah. would be even neater if he used patchwork though.
Feb 07 20:13:35 <Borromini> git-pw apply blabla
Feb 07 20:14:31 <rsalvaterra> Yeah. I didn't know about the .patch (and .diff) thingies because I only use GitHub as a remote repository. :P
Feb 07 20:17:19 <Borromini> :)
Feb 07 20:17:42 <nbd> lipnitsk: pong
Feb 07 20:17:53 <nbd> lipnitsk: sorry that i didn't respond to your emails, i was too busy
Feb 07 20:18:24 <lipnitsk> np, just wanted to make sure you were aware and not doing double work
Feb 07 20:18:28 <lipnitsk> I'm not blocked or anything
Feb 07 20:19:09 <lipnitsk> fiddling with enabling PPPoe offload on 5.10 on my er-x. Just wanted to sync up and make sure I'm not totally on the wrong path here
Feb 07 20:19:49 <lipnitsk> I do have my changes published on github, so whenever you are getting ready to post your patches it might be good to sync up
Feb 07 20:24:30 <lipnitsk> I have quite a bit of understanding to do still to figure out the new nftables flow API and how to add a new path or paths (PPPoE, 6rd, etc), so that will keep me busy for a while
Feb 07 20:26:14 <lipnitsk> nbd: also thanks for all your amazing work on the mtk eth driver
Feb 07 20:28:07 <nbd> just a quick heads up, there's going to be some changes to the nftables flow api patch series
Feb 07 20:28:17 <nbd> pablo (who's doing the upstream work) sent me some new patches
Feb 07 20:28:27 <nbd> i will have to rework the xt_FLOWOFFLOAD module as well based on that work
Feb 07 20:28:34 <lipnitsk> yeah I figured you must have been working closely with him
Feb 07 20:28:36 <nbd> i expect to have it in my staging tree in the next few days
Feb 07 20:28:44 <Borromini> nbd: i replaced is_mt7663 in mt7615/init.c but the compiler doesn't like that: https://paste.debian.net/1184437/
Feb 07 20:28:47 <lipnitsk> okay, sounds good
Feb 07 20:29:32 <nbd> Borromini: use phy->dev instead of &phy->dev->mt76
Feb 07 20:29:35 <lipnitsk> is ndo_fill_forward_path staying the same or changing a lot?
Feb 07 20:29:50 <Borromini> nbd: ok, thanks
Feb 07 20:29:50 <nbd> lipnitsk: it's staying the same
Feb 07 20:30:25 <lipnitsk> nbd: I'll keep an eye on your tree
Feb 07 20:30:28 <nbd> lipnitsk: with a bit of luck, pablo's work will be posted upstream soon
Feb 07 20:30:52 <lipnitsk> are you hoping to push your patches to openwrt in a few weeks?
Feb 07 20:31:26 <nbd> the only thing i'm waiting for is that the release branch is created
Feb 07 20:31:43 <nbd> other than that, the 5.10 patches are ready in my opinion
Feb 07 20:31:44 <lipnitsk> 5.10 is not going on the branch?
Feb 07 20:31:50 <nbd> right
Feb 07 20:32:09 <nbd> we aim for supporting only one kernel version in a release branch
Feb 07 20:32:16 <nbd> and porting everything to 5.10 would delay things too much
Feb 07 20:32:38 <lipnitsk> okay. Yeah once offload stuff is working on 5.10 some can be backported to 5.4 if needed
Feb 07 20:33:02 <lipnitsk> different API, but not too complicated, I think
Feb 07 20:33:17 <lipnitsk> if there is a material performance benefit, that is
Feb 07 20:34:35 <lipnitsk> nbd, if I found some bugs or fixes to your patches, do you want me to email to you or just wait until it is on master?
Feb 07 20:38:06 <nbd> better send them to me early
Feb 07 20:38:10 <nbd> no need to wait for it to hit master
Feb 07 20:38:30 <nbd> i don't like pushing known bugs to master :)
Feb 07 20:38:44 <lipnitsk> nbd, will do.
Feb 07 20:38:47 <nbd> thanks
Feb 07 20:40:20 <Borromini> nbd: sorry but hitting this with the mac.c replacement as well: https://paste.debian.net/1184444/
Feb 07 20:42:15 <Borromini> with this in mac.c: https://paste.debian.net/1184445/
Feb 07 20:46:25 <nbd> same kind of change: replace &dev->mt76 with dev
Feb 07 20:46:44 <Borromini> ok, thanks
Feb 07 20:59:36 <Borromini> rsalvaterra: i just had connectivity loss again on mt7615, so i don't think that rekeying issue is what i'm seeing
Feb 07 20:59:47 <Borromini> was with that patch applied
Feb 07 21:01:00 <rsalvaterra> Borromini: something else, possibly? It's MT7613 in your case, right?
Feb 07 21:01:16 <Borromini> no this is MT7615
Feb 07 21:01:36 <Borromini> i have two MT7613 radios that are supposed to replace the MT7615 ones
Feb 07 21:02:23 <Borromini> s/radios/devices/
Feb 07 21:03:48 <rsalvaterra> Have you done this test? https://github.com/openwrt/mt76/issues/494#issuecomment-772423778
Feb 07 21:04:22 <rsalvaterra> I believe you said you could access some devices, but you couldn't access others.
Feb 07 21:05:15 <Borromini> the issue manifests itself as temporary connectivity loss
Feb 07 21:05:30 <Borromini> e.g. a ping will go through 10 times, then drop for 9, over and over
Feb 07 21:06:02 <rsalvaterra> Ok, so it's something entirely different. #494 is about permanent connectivity loss. :)
Feb 07 21:06:37 <Borromini> so for a few seconds everything is dead, then works again, and if you have more relaxed connections then everything just feels slow. but traffic stops and it's radio related, from what i can tell, since pinging client -> radio breaks, and pinging doesn't run through the server afaik
Feb 07 21:06:48 <Borromini> yeah, was worth the try though.
Feb 07 22:09:30 <aparcar[m]> how do I create a dropdown menu with the new LuCI js interface?
Feb 07 22:18:06 <ldir-> git-pr 3848 name_of_github_remote
Feb 07 23:04:01 * enyc meows
Feb 07 23:06:19 <enyc> Hauke: hrrm I see the hostapd mention above....   is https://openwrt.org/docs/guide-developer/releases/goals/21.xx correct r.e. needing a ??kernel?? 5.10 backport set from you ...?   -- idea being newer mac80211 kernel drivers?
Feb 07 23:23:24 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
**** ENDING LOGGING AT Mon Feb 08 03:01:12 2021