Huntereb has quit [Read error: Connection reset by peer]
Huntereb has joined #openwrt-devel
Huntereb has quit [Read error: Connection reset by peer]
Huntereb has joined #openwrt-devel
Huntereb has quit [Read error: Connection reset by peer]
Huntereb has joined #openwrt-devel
mgiganto has joined #openwrt-devel
<mgiganto>
helloooooooo
AndyCap has quit [Ping timeout: 240 seconds]
<mgiganto>
Any idea why my WRT32X serial console doesn't allow me to enter any command? not at u-boot, not at booting, failsafe or running openwrt
<mgiganto>
tx cable seems to be working, because if I disconnect tx cable, then the things that I receive are no sense
<mgiganto>
i am just trying to flash a firmware with the kernel partition increased from 3mb to 4mb, but no luck yet
AndyCap has joined #openwrt-devel
<m4t>
do you have a good ground connection?
<mgiganto>
I suppose to, otherwise I would not able to receive anything at all, right?
ivanich has quit [Quit: Konversation terminated!]
<m4t>
well, receiving garbage after disconnecting TX makes me wonder
<mgiganto>
I disconnect TX from my usb fttdl, so it would be RX in the router
<m4t>
looking at wiki for the wrt series: If eSATA LED lights immediately after reboot with no serial output, add a 4.7KΩ resistor between Gnd & Rx on adapter
danitool has quit [Ping timeout: 245 seconds]
<mgiganto>
no esata light, and I have serial output all the time, it is the input what doesn't work
<mgiganto>
I can see the device boot log
DonkeyHotei has quit [Ping timeout: 264 seconds]
<m4t>
i thought you said it was garbage if TX is disconnected
<m4t>
anyways, i dunno what the deal is. i would double check the pinout and ensure connections are good. wiki says it should respond to input during the 3s autoboot delay
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #openwrt-devel
Huntereb has quit [Ping timeout: 245 seconds]
<zx2c4>
blocktrron: there a reason you can't just merge that now?
Huntereb has joined #openwrt-devel
Huntereb has quit [Read error: Connection reset by peer]
Huntereb has joined #openwrt-devel
<mgiganto>
m4t, you were 100% right, I though I had the gnd on the black, but I had it on green and therefore no gnd at all, now I get prompt!
<m4t>
mgiganto: cool :)
<mgiganto>
any idea of why the img that I compiled with kernel size of 4mb instead of 3 is not booting?
Huntereb has quit [Read error: Connection reset by peer]
Huntereb has joined #openwrt-devel
<mgiganto>
I think I may need to check the limit size of the kernel in u-boot
<mangix>
zx2c4: speaking of wireguard stuff, it's outdated in 19.07.
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #openwrt-devel
Slimey_ is now known as Slimey
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
<Festivenari_>
so, uh, I've been looking around the docs and in the source code, and there doesn't seem to be support for the BCM63137 (however, the BCM63138 SoC is supported)
Net147 has quit [Read error: Connection reset by peer]
gladiac133779 has quit [Quit: k thx bye]
Net147 has joined #openwrt-devel
gladiac133779 has joined #openwrt-devel
Net147 has quit [Excess Flood]
Net147 has joined #openwrt-devel
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
Net147 has quit [Read error: Connection reset by peer]
LoopHoldYoaBrown has quit [Ping timeout: 245 seconds]
<lipnitsk>
dangole: thanks for fixing my fix. I guess I didn't fully understand all the intricacies of wildcard matching. Glad that we could get rid of those ugly ifdefs though..
Net147 has joined #openwrt-devel
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
rmilecki has joined #openwrt-devel
feriman has joined #openwrt-devel
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
ivanich has joined #openwrt-devel
silverballz has joined #openwrt-devel
feriman has quit [Ping timeout: 260 seconds]
silverwhitefish has quit [Ping timeout: 246 seconds]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #openwrt-devel
Borromini has joined #openwrt-devel
silverwhitefish has joined #openwrt-devel
silverballz has quit [Ping timeout: 276 seconds]
<rsalvaterra>
guidosarducci: Yes, a clean master always fails to build tc, for some unfathomable reason… :/
<Borromini>
race condition?
<rsalvaterra>
guidosarducci: And yesterday I had a build failure with firewall3. It built fine after I retried with make -j 1 V=s.
<rsalvaterra>
Borromini: I'm starting to think so.
silverballz has joined #openwrt-devel
silverballz has quit [Client Quit]
danitool has joined #openwrt-devel
<Borromini>
rsalvaterra: i've seen a lot of builds fail on a few packages lately, and just running a make -j1 'fixes' it
silverwhitefish has quit [Ping timeout: 260 seconds]
<PaulFertser>
Bus 001 Device 003: ID 0db0:3871 Micro Star International MS-3871 802.11bgn Wireless Module [Ralink RT8070]
<PaulFertser>
I disabled hwcrypt manually though.
<rsalvaterra>
PaulFertser: You don't need to, and it's counterproductive. The driver should now fall back to software only for the unsupported features (MFP and the WPA3 handshake).
feriman has joined #openwrt-devel
<mangix>
i assume that also works with mwlwifi?
<PaulFertser>
rsalvaterra: now yes, i needed it when I was using older kernel.
<mangix>
hmm maybe it only works if mac80211 has access to the data path
<rsalvaterra>
mangix: I was going to write about that… the problem is when the firmware does so much you can't even fall back to software for the unsupported features.
<mangix>
what's stranger is why it's a mac880211 driver
<rsalvaterra>
However, as far as mwlwifi is concerned, I could be talking out of my a**, as I haven't looked at the code.
<mangix>
sorry, softmac
<mangix>
if there's nothing soft about it
<rsalvaterra>
And I can't believe after all these years nobody thought about falling back to software, if possible…
<Festivenari_>
So, uh, is there a flag to get around the "But that file is already provided by package" error (I'm compiling a build and now it's doing this)?
<Festivenari_>
and for some reason, the affected files are sysctl-tcp-bbr.conf and sysctl-br-netfilter.conf
Antoine- has joined #openwrt-devel
Tost has joined #openwrt-devel
<mangix>
rsalvaterra: sounds too easy to be true :)
<mangix>
also, this was done with mt76 and ath10k in the past when enabling 802.11w resulted in a speed decrease.
<rsalvaterra>
However, I don't have any mwlwifi hardware (thank God).
<rsalvaterra>
Woohoo! lipnitsk's pull is merged! Time to kill my Redmi RM2100. :P
<blocktrron>
zx2c4: I'd rather wait some time for the backport, as otherwise we have to apply and track bugfixes to both branches
* rsalvaterra
hasn't even soldered the UART pins… #yolo
<blocktrron>
mangix: someone stated mwlwifi applies magic to some management frames, thus you can't fall back to SW crypto for that
<blocktrron>
Similar to iwldvm
<rsalvaterra>
blocktrron: Yeah, that's what I thought. Firmware being too smart for its own good.
<mangix>
ath10k does the same i believe
<mangix>
luckily there's ct
<blocktrron>
you can drive ath10k with sw-crypto
<rsalvaterra>
mangix: I'm starting to hate ath10k hardware with a passion (I have two QCA9880 on my Omnia).
<blocktrron>
also i did not experience speed decrease with MFP /WPA3 and ath10k using the AP chips
<mangix>
why two?
goliath has joined #openwrt-devel
<rsalvaterra>
With -ct firmware, I have stable WPA3, but the cards crash from time to time (they recover automatically, but it's annoying as hell).
<rsalvaterra>
mangix: Because I can…? :P
<mangix>
blocktrron: stintel did. don't remember which driver and firmware
<rsalvaterra>
They're dual band cards, so I have one for each band.
<blocktrron>
The QCA6174 however gets impacted a lot, this might be fixable as the firmware itself does not indicate MFP capability and the driver simply expects the HW to support MFP
<mangix>
the 9880s are...pretty much abandoned by qualcomm
<rsalvaterra>
Yeah, it's Wave 1 hardware.
<mangix>
wave 2 was more stable from what i remember
<rsalvaterra>
I'll replace them, eventually. Probably with MT79xx.
<mangix>
blocktrron: funny. that happens to me with stock firmware
<mangix>
ct firmware does not crash
<blocktrron>
crash?
<blocktrron>
Or what do you mean with stock firmware?
<mangix>
the ct-htt firmware
<rsalvaterra>
blocktrron: It's a well-known crash. With the official firmware, the card just dies. With ct-htt firmware, it recovers.
<mangix>
so the stock qualcomm ath10k firmware crashes for me when i enable 802.11w and takes the driver with it. ath10k-ct is able to restart the firmware and continue working
<blocktrron>
For which card?
<blocktrron>
I'm running SAE-MFP with QCA9880 and 9888 since over a year using the QCA firmware /driver
DonkeyHotei has joined #openwrt-devel
<mangix>
blocktrron: qca9880
<mangix>
a compex card. forgot the model number
<rsalvaterra>
WLE900VX
<rsalvaterra>
(They're the ones I have.)
<mangix>
maybe it's better now. i think i last tested stock ath10k driver/firmware 2 years ago. been on ath10k-ct driver/firmware since
<mangix>
rsalvaterra: don't hold your breath for 11ax minipcie cards
<mangix>
even the turris people are having issues
Borromini has joined #openwrt-devel
Borromini has quit [Ping timeout: 245 seconds]
ivanich has quit [Quit: Konversation terminated!]
Borromini has joined #openwrt-devel
ivanich has joined #openwrt-devel
<Q_>
My QCA9880 keeps working with stock firmware, it crashes (and recovers) with the ct firmware.
<Q_>
When I do a channel analysis with the stock firmware, I actually see more APs.
Borromini has quit [Ping timeout: 245 seconds]
DonkeyHotei has quit [Ping timeout: 245 seconds]
Borromini has joined #openwrt-devel
<rsalvaterra>
mangix: Yeah, not holding… I'm fine with ac Wave 2 for the moment. :P
<rsalvaterra>
I don't even have ax devices.
<Festivenari_>
actually, I think to solve the issue, I need to start from a new .config file
<Festivenari_>
I must've botched something up
Borromini has quit [Ping timeout: 246 seconds]
goliath has quit [Quit: SIGSEGV]
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
<rsalvaterra>
Sometimes I think the build system just hates me.
<rsalvaterra>
"Oh, you're making kernel_oldconfig? I'm going to rebuild the whole toolchain before that, because f*** you."
<grift>
damnit another issue ... v3 ... that is why i try to not get involved in packaging
<grift>
we probably should move checkpolicy to packages ...
<grift>
i guess its for refpolicy
Borromini has joined #openwrt-devel
zkrx has quit [Ping timeout: 245 seconds]
zkrx has joined #openwrt-devel
victhor has quit [Remote host closed the connection]
<Grommish__>
adrianschmutzler: Haven't you learned not to leave grift or aparcar[m]1 or rsalvaterra to their own devices? ;p
<grift>
dont commit my V3 patch set: i didnt test policycoreutils thoroughly enough
<aparcar[m]1>
Grommish__: im missing context what's up?
<Grommish__>
aparcar[m]1: Oh, nothing negative :) grift was asking what to put for a commit message and adrianschmutzleranswered. I was bring up the rabbit-hole of things that tend to happen when things get shuffled :D
<Grommish__>
You know how it goes :)
<grift>
i can understand both sides
<grift>
i have that same passion for perfection when it comes to policy
<grift>
to me packaging is nuisance
<grift>
but if packaging is your thing then i can fully understand that you want perfection
<grift>
well actually thats i guess a wrong analogy
<grift>
as its not about packaging
<Grommish__>
Oh, I was referring to the phenomia of fixing one thing that breaks soething else
<Grommish__>
I had a car that did that, and i finally settled on not needing a gas guage and I never had another issue ;p
<Grommish__>
I've come to appreciate the standardization of things where I once didn't
<grift>
well yes but theres also a good side to that
<grift>
it might lead of improvement in the end
<Grommish__>
*nod*
<grift>
due to "missing commit message" comment, i noticed two other bugs
<Grommish__>
grift: You handled it better than i did when I hit that wall
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<Grommish__>
I jusst said never mind and abandoned the commit like a chit
<Grommish__>
Not my brightest moment
<grift>
i guess theres a couple of aspects to it: first is patience and the second one is confidence
<grift>
at least with rebasing, testing etc
snh_ has joined #openwrt-devel
<grift>
package maintenance can be hard
<grift>
you have to know what changed and how that affects your package
<grift>
and if something breaks you have to deal with it
<grift>
its not just the technical aspect of packaging
snh has quit [Ping timeout: 265 seconds]
snh_ is now known as snh
<Grommish__>
Yeah, mine was more of an ego issue where I took it as a personal affront as to why the version bump needed a commit message, and since I had it working locally, I literally said "eh, I've got it, if you want it, you can commit it, if not, I don't care" :/
<Grommish__>
again, not a highlight
<grift>
yes i think i know what you mean but i do think thats also a confidence issue
<grift>
becuase with enough confidence its no big deal to address it
<Grommish__>
Right
<Grommish__>
I just was pissy about it and I freely admit my failing at it :) I've done better since
<grift>
it does also require a bit of patience and tolerance
<grift>
but yes i totally understand
<grift>
you see in this industry its often "hit and run"
<grift>
you dump some code and never look back
<grift>
and maintainers know that
<Grommish__>
*nod* Which is exactly why the papertrail should be there
<grift>
so they demand quality
<grift>
because they know that probably someone else will have to pick up the pieces later
<Grommish__>
Yep
<Grommish__>
Its the nature of the project that people come and go
<grift>
yes its a pity though
<Grommish__>
or simply change devices and platfors
<Grommish__>
I get to dip in the ramips targets here soon
<Grommish__>
which I've never had the occasion to deal with
<grift>
on the one hand people want to "grow" but on the other hand a lot of knowledge gets lost when people constantly get "promoted" away
<Grommish__>
Its so much more complicated than the octeon target
<grift>
i have zero affinity with switches, boards, chips and shorting stuff :-)
<guidosarducci>
rsalvaterra: I've seen multiple reports of package build failures in recent weeks, which I can't reproduce and aren't reflected in buildbots. I've also encountered the unexpected tools/toolchain rebuilds you mention. Little doubt in my mind of build system problems. Extremely damaging because it raises doubts on well-written and tested PRs.
<Grommish__>
:)
dedeckeh has joined #openwrt-devel
<lipnitsk>
I have seen where a package build failure somehow becomes a package/libs/toolchain failure which wipes enough stuff to cause the full toolchain rebuild. I'll try to pay attention to it next time it happens to try and triage
<lipnitsk>
dangole: maybe you should sync up with Adrian on the agreed way to merge things. Seems he didn't quite like your squashing of my ramips changes.
<lipnitsk>
rsalvaterra: how is your RM2100 doing? Working ok?
<Borromini>
lipnitsk: FYI, Hauke pushed a separate .102 bump to 21.02...
<lipnitsk>
oh okay
<lipnitsk>
let me see.
<Borromini>
i'm hoping more MT7613BE stuff gets ported so we can see if i'm just the only one having problems with those radios
danitool has quit [Read error: Connection reset by peer]
danitool has joined #openwrt-devel
victhor has joined #openwrt-devel
<Borromini>
lipnitsk: kernel bumps aren't bundled with other patches, usually
<Borromini>
sorry if i gave you the wrong impression in the PR comments.
<lipnitsk>
yeah, well I'm glad Hauke bumped it - somebody needed to, so that we can have all the latest WireGuard patches
<lipnitsk>
It's a bit of a conflict when you are cherry-picking since on master the change did contain the bump as well as patch update
<Borromini>
:)
<lipnitsk>
but it should all be cleaner now. I'm rerunning update_kernel.sh just to refresh all targets, but I've updated the branch already
philipp64 has joined #openwrt-devel
<Borromini>
ok, thanks
<guidosarducci>
russell--: I'd appreciate a review of my iproute2 size update (https://github.com/openwrt/openwrt/pull/3961) as the maintainer (jow and ldir are pinged on a minor point). This has gone through much testing, and would be a key update before a 21.02 backport. Thanks again!
<Hauke>
normally I do the kernel bumps for the branches independent of each other
<lipnitsk>
yeah, it is probably better that way - patches may diverge
LoopHoldYoaBrown has joined #openwrt-devel
<lipnitsk>
I'm fixing up the branch now after rebasing on top of the latest 21.02
<lipnitsk>
man, refresh does take so long, I wonder if quilt can be improved in that regard..
<lipnitsk>
two issues with quilt: 1. handle renames; 2. speed up refresh
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
<zx2c4>
lipnitsk: i just made 080-wireguard.patch as a single patch that also doubles as an executable shell script that you can run to update itself... Genius or terrible? Unclear...
<guidosarducci>
Hauke: re: "make kernel_oldconfig", are you OK with using it and then manually fixing things up, or prefer taking the raw results? This is related to malta 5.10 update: https://github.com/openwrt/openwrt/pull/3881.
<Hauke>
guidosarducci: fix it up in the same commit just mention waht you did
<Borromini>
zx2c4: awesome, thanks =)
<Hauke>
*what
LoopHoldYoaBrown has joined #openwrt-devel
<guidosarducci>
Hauke: OK, thanks. So the main thing for you is knowing it's been run rather than skipped?
<lipnitsk>
zx2c4: you mean that will replace the whole patch series so folks here are less scared?
<zx2c4>
Yea
<zx2c4>
One auto updating file
<lipnitsk>
some dark magic?
<lipnitsk>
does it just add a layer of abstraction somehow? is it still checked into the repo?
<mangix>
Hauke: uClibc++ is now gone from the packages feed.
<lipnitsk>
zx2c4: so patch/quilt is happy to execute scripts in .patch files?
<zx2c4>
lipnitsk: nono, you run it yourself when you want to update
<zx2c4>
`./080-wireguard.patch` will cause it to update itself, for easier maintenance
<zx2c4>
quilt/patch just sees it as a normal patch, with a big comment section at the top
<lipnitsk>
I see. so quilt will just treat the script as a no-op message
<zx2c4>
right
<zx2c4>
downside is that by combining these all into one file, if it doesnt apply, its harder to see what broke
<zx2c4>
upside is that its a cool hack
rmilecki has quit [Ping timeout: 260 seconds]
<lipnitsk>
lol, yeah. a fun exercise if nothing else... I don't know, folks will probably complain or ask why this is so special. It might be worth seeing if this is generalizable at a higher level somehow. Let's see what core folks think of this idea.
thess has joined #openwrt-devel
<lipnitsk>
alternatively maybe it is something acceptable for the update_kernel.sh script or the tools repo
thess has left #openwrt-devel [#openwrt-devel]
<lipnitsk>
zx2c4: the good news is that 5.4 is gonna be deleted from master soon enough. And 21.02 shouldn't need updating that often. What's the update frequency for the backports on average up till now?