<mrkiko>
so - first lantiq, then infineon, then intel and now Maxlinear? :D
GNUmoon has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
<dwmw2_gone>
hauke: but open source router drops do exist, don't they?
<dwmw2_gone>
Isn't that where we're getting the vrx518 source code from anyway?
<dwmw2_gone>
Anyway, I will shortly have a spare VDSL line for playing silly buggers with, and can probably set it up for remote access if anyone wants it (blogic, dhewg, hauke, blocktrron and others I think I've seen you all poking at this in various forms).
<dwmw2_gone>
I can stand up a box next to it with serial ports connected, remote power control to power cycle it.
<rsalvaterra>
(That's just one patch, the idea is to completely remove tmp-on-zram support.)
<Pepes>
svlobanov: I get to work just now. I will take a look, but give me a few minutes after I will go through all new emails, etc.
<aparcar>
jow: if you think it was a bad decision please elaborate
<blocktrron>
dwmw2_gone: nice! Although I'll be on fiber soon and don't have to put up with this 90s technology anymore
<dwmw2_gone>
:)
<blocktrron>
Will be gpon, still has an ugly side to it
Tapper has quit [Ping timeout: 480 seconds]
<rsalvaterra>
What's the ugly side of GPON?
<Habbie>
shared bandwidth?
<rsalvaterra>
Habbie: If the ISP is competent, that shouldn't be a problem.
<stintel>
all bandwidth is eventually shared somewhere :)
<stintel>
I've never really had issues with that on cable or on my GPON
<Habbie>
same
<Habbie>
but i recently heard of an ISP selling x gbit where 3x was already the full capacity of a GPON setup
<Habbie>
in which case local bandwidth sharing really does become a problem
<rsalvaterra>
The only problem I have with my cable connection is not having IPv6.
<stintel>
same here with my GPON - had native IPv6 on cable for several years in Belgium so that's a downgrade
KGB-0 has quit [Ping timeout: 480 seconds]
<neggles>
Habbie: it only becomes a problem if they have the OLT configured poorly & you expect to actually hit your maximum speed every time, all the time
<Habbie>
ack
<Habbie>
an engineer i trust to be competent told me this was a problem ;)
<neggles>
heh, that's fair
<neggles>
if the OLT is assigning downlink timeslots fairly, and they stick to a reasonable number of houses per fiber, it's fine - down here in AU at least, the average throughput per residential GPON connection (across a full month) works out to around 2.5-3mbit
<rsalvaterra>
3 Mb/s, WTF…?!
<neggles>
that's averaged across a few thousand customers and an entire month of time
<olmari>
...how anally can one build "fiber" then.. :D
<rsalvaterra>
Sure, but what about the perceived bandwidth per customer?
<neggles>
i.e. if you have 3000 *residential* users (most of whom are on 100/20 plans in this case - it does go up as the average plan speed goes up, but not as fast as you might think) sharing one crossconnect pipe
<rsalvaterra>
I had the idea internet connections in Australia were generally bad, I guess my idea wasn't entirely wrong. :)
<neggles>
10G is enough capacity to allow everyone sufficient throughput to hit the majority of their plan speed the majority of the time
<neggles>
it's gotten a lot better in most of the country over the last couple of years - i'm on a HFC connection that's got ~1.6Gbps/~600Mbps shared across ~32 houses, with a plan that's hard-limited at 1005Mbps/55Mbps
<neggles>
i can typically hit 800 during the day and 300 during the 10pm-local-time peak
<neggles>
(the mt7621a in the routerboard i still haven't gotten around to replacing is doing its best okay)
<neggles>
3mbps/user only works when it's scaled across at *least* several hundred users, preferably a couple thousand - you do need much more available bandwidth in the last segment, but the ~2.8Gbps downlink that you get from regular GPON is fine for ~32 connections - it's not super likely that you'll have multiple people trying to cap out a 1Gbps link at
<neggles>
the same time for a long period
<SwedeMike>
yeah, 3x uplink speed for 32 users should be fine
<SwedeMike>
rule of thumb should be that at least 2 out of 32 can run full-speed at the same time without affecting the others, that sounds like a good rule of thumb
<SwedeMike>
average throughput here in Sweden is also there in the ~5 megabit/s, but one can't really use that for dimensioning the local loop
<SwedeMike>
neggles: so we're in 100% agreement
KGB-0 has joined #openwrt-devel
<SwedeMike>
rsalvaterra: I've only talked to people operating AE networks, not GPON. I imagine different tech, different problems.
<neggles>
yes'm - the 3mbit/user was more meant to illustrate just how little bandwidth most people use when you zoom out a bit
<stintel>
I think I'm the only GPON user in my building :P
<neggles>
but providing a 1Gbps downlink service over GPON (2.48G/1.24G) is completely reasonable, and GPON's getting a bit long in the tooth these days anyway
<SwedeMike>
neggles: with 1:32 splits, yes, I wouldn't agree on the same for 1:128 splits
<neggles>
anyone who's doing a 1:128 split on GPON needs to be shot
<neggles>
or upgrade to 10G-PON before offering anything north of a couple hundred Mbit
<SwedeMike>
sounds about right
<neggles>
alternatively, just offer a "best effort" plan
<neggles>
you get whatever free bandwidth there is available, and once things are capped out, you get shaped first
<neggles>
that's effectively what the 1000/50 (HFC) & 1000/400 (FTTH) plans are here - you're only given the same throughput guarantee as the 100/20 "fast" plan (yeah, yeah, I know, I know) but if they *can* give you more you'll get it
<SwedeMike>
at least that sounds honest, and with a proper scheduler it can degrade gracefully
<Habbie>
my influx data suggests my cable connection averages several tens of kilobytes per second over a few weeks
<neggles>
yup. we partly solved the honesty/"carrier not buying enough interconnect" problem, too - ISPs have to measure speeds using regulator-supplied equipment during evening peak on the various plan tiers, and they have to display these "average night-time throughput" numbers on the plan pages
<neggles>
several have been hit with rather hefty fines for lying
<neggles>
my ISP goes one step further - they made the throughput charts for each of their interconnects to NBNco's network public
<neggles>
Habbie: over the last month I've averaged 2.4Mbit/s down and 2.25Mbit/s up
<Habbie>
yeah
<Habbie>
i don't think my data is right
<Habbie>
i've doubted the numbers coming out of the router before
<neggles>
1.55TB total
<neggles>
half of that's upload, cloud backups
<neggles>
Habbie: what's your poll interval? it's not uncommon for stuff to have small packet counters that roll over inside a few minutes
rua has quit [Ping timeout: 480 seconds]
arifre has quit [Remote host closed the connection]
<Habbie>
good question, i don't know, but i also see i have an increasing byte counter, should be a better source, let's see :)
<stintel>
3.84Mbps up 1.04Mbps down total 1.27T
<stintel>
5min polling
<stintel>
with observium
<Habbie>
ok, so i have a byte counter that resets on reboot, that makes sense
<neggles>
yeah, standard snmp port bytes/bits
rua has joined #openwrt-devel
<Habbie>
ah, and also clearly a 32 bit wrap
<neggles>
yeah, I was going to say, it's usually a 32-bit counter that rolls over at ~4.3GiB
<Habbie>
13TB since jan 9th, roughly
<neggles>
O_O
Tapper has joined #openwrt-devel
<neggles>
that's... *how?!*
<Habbie>
that's 120 mbit/sec average, so clearly this data is also wrong
<Habbie>
my line isn't even that fast
<stintel>
:D
<neggles>
yeah I was going to say
<Habbie>
but, how: 6 hours of netflix a day plus the occasional torrent
<Habbie>
and google stadia is a hog too
srslypascal is now known as Guest1031
<neggles>
netflix caps out at 40mbit
srslypascal has joined #openwrt-devel
<olmari>
funny how at some countries these types of averaging etc is generally accepted by regulatories at all.. I mean yes some overprovisioning can still be okay when generally one can get what is advertised.. This goes for every media that is not needed to be shared by tech... with radiowaves there is always some limits with things as airspace is shared, with babling there is no need other than being cheap.. and adjacently too cheap :P
<Habbie>
but that should still add up under 10 average
<neggles>
typically less if you've got HEVC support in your client
Guest1031 has quit [Read error: Connection reset by peer]
<Habbie>
clearly i need better data in a better system
<olmari>
and yes there helps ISP's alot when much none of internet service give such speeds anyway, but that is different thing ;D
<neggles>
i've been using librenms for quite a while now
<neggles>
have heard good things about zabbix though
<Habbie>
this is home assistant pulling from my ISPs Arris CPE
<Habbie>
so, poor
<neggles>
oof
<neggles>
does it pull over SNMP? or is it scraping a webpage
<Habbie>
it kind of looks like the arris wraps from 4gb to .. 2gb
<neggles>
you might be able to turn it on in the webui, otherwise - are they plugged into something vaguely intelligent?
<Tapper>
I know that I don't have a vote but If i did I would vote for Yes, please start using GitHub issues. A11y is just better on github
<Habbie>
neggles, something intelligent like what?
<neggles>
well, I monitor the switch port that my HFC NTD is plugged into
<mrkiko>
Tapper: agree
<Habbie>
neggles, oh right, i can't currently do that, no
<neggles>
dang.
<Tapper>
If there is a OpenWrt dev on the fence about this then pleas say yes for us. lol
<Habbie>
neggles, my switches are too cheap
<Habbie>
(one would be scrapable, though ;) )
<neggles>
the switch my NTD is plugged into cost ~$50 :P
<neggles>
brand new, no less
<mrkiko>
Tapper: well, even gitlab has a tool to interact with it without the web interface (I use terminal), but... I am more familiar with GitHub
<mrkiko>
Tapper: that said, how is it going?
<Habbie>
neggles, i've never bought a switch for $50.. sometimes two, though ;)
<mrkiko>
Tapper: what routers are you using these days :D
<neggles>
Habbie: the big one that's upstream of the small one the NTD's plugged into was $250, but it's got a bunch of very nice things and 48 PoE+ ports :P
<Tapper>
I just got me a r6260 from ebay for £11
<Habbie>
neggles, nice :)
<neggles>
on the other hand I have probably fifty grand (sticker/new price, when new) worth of network gear sitting in my rack, so, perhaps I am not the best benchmark
<Tapper>
I set it up as a dumb AP and it is doing nicely.
<mrkiko>
Tapper: nice hardware for sure for the price. What do you plan to use it for?
<Habbie>
neggles, haha, i stopped doing that 15 years ago
<Tapper>
I swiched it out for my c7-v2
<mrkiko>
Tapper: oh, nice! are you using it on AC or 2.4 ghz?
<Tapper>
both
<neggles>
Habbie: in my defence, I didn't pay for most of it
<Habbie>
neggles, same
<Tapper>
ethernet back bone
<neggles>
client moves office or upgrades network, I "dispose" of the old gear...
<Habbie>
neggles, who pays for the power, though? :)
<neggles>
Habbie: the majority of it is not even plugged in, I pull on average uhhhhh...
<Habbie>
i put my openwrt 'lab' behind a smart switch the other week, will save me something like 80 EUR/year
<neggles>
looks like i'm averaging somewhere in the 400W region right now
<neggles>
but I have two more boxes than usual powered up, and one has an Accursed Octeon in it that's responsible for 20% of that system's idle power
<Habbie>
wow
<Habbie>
expensive "hobby"
<neggles>
eh, what hardware I *do* buy is tax-deductible, as is 20% of my power bill :D
<Habbie>
80% of expensive is still expensive ;)
<Habbie>
oh but this is not your full power bill, ok
<Habbie>
i could theoretically expense the 80 EUR but getting rid of it made more sense to me
<stintel>
only 400W average? :D
<neggles>
yeah it's about 1/4 to 1/2 of the power bill depending on whether it's summer or not
<Habbie>
right, 'free' heating
<neggles>
and our central heater is gas-fired
<neggles>
It's Not Electricity So It Doesn't Count, I Swear
<stintel>
everything is electric here
<stintel>
my total power draw is 1.26kW ATM
cmonroe has joined #openwrt-devel
<Habbie>
427W right now, whole house
<neggles>
stintel: hehe, I put a lot of effort into keeping network equipment power draw + idle power draw low - that's 400W running an R720, two R730s, two 8gen intel NUCs, two raspberry pis, an Aruba S2500-48P, and a Mellanox SX6012
<Habbie>
excluding heating
<neggles>
plus a few wifi APs and a mikrotik hEX S
<neggles>
the mellanox is insanely efficient - <30W idle power for a 12x40G switch
<neggles>
whole house is 1.5kW right now because of the AC
<Habbie>
heater is reporting 4.5kW
<Habbie>
(not electric)
clayface_ has joined #openwrt-devel
<Habbie>
but it'll shut off shortly, i trust
clayface has quit [Ping timeout: 480 seconds]
<stintel>
the AC is on again here :P
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<rsalvaterra>
Random question: is dieharder good enough for testing the randomness of the contents of a file?
<eduardo010174>
Someone can help me? What are the steps before a pull request is placed upstream?
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<neggles>
rsalvaterra: the man page explicitly says to not use it for that
<neggles>
interesting
<Habbie>
rsalvaterra, maybe you want binwalk's entropy tricks?
<karlp>
345W for the house here. (hot water heating off the street though)
<rsalvaterra>
neggles: I understood what the page said, but I believe it's a matter of semantics. I'm aware I'll be testing the *generator* that was used to create the file. ;)
<karlp>
lights are on, only extras we could even turn on are cooking and a tv...
<karlp>
oh, washing machine of course
<neggles>
rsalvaterra: technically you wouldn't really be testing the generator either
<rsalvaterra>
neggles: I'd be testing the generator at a certain point in time.
<rsalvaterra>
(I don't know if it makes sense.)
<neggles>
again, kind of? there might be sequences in the file that fail a given test, but the overall output of the generator is still random, and that file was still random, it just happened to *look* like it wasn't for a moment
<neggles>
random sequences often appear decidedly non-random - entropy calculations are more relevant for static files, but it depends on what your goal is
<neggles>
I mean if your goal is just to determine whether the file "looks" random enough that nobody could conclusively say it's not (i.e. checking that your plausibly-deniable encryption is actually plausibly-deniable) then a binwalk entropy chart with a flat line on it ought to cover that
<rsalvaterra>
neggles: Pretty much that. Imagine the case of filling up a partition with random data before encrypting it with LUKS, for example.
<neggles>
then yeah, entropy chart from binwalk or something else that does assorted entropy calcs should do
<neggles>
if the entropy of the file is effectively 1 throughout its length, you're good
<rsalvaterra>
Ok, in that case, dieharder -g 201 does the trick too. :)
<neggles>
otherwise, use dieharder to test /dev/urandom or whatever CSPRNG you're using & if it passes then you can just assume its output is good
<neggles>
n.b. i am not a cryptographer and depending on your threat model you may need to try harder than that :P
<neggles>
AIUI the best way to do that with LUKS is to just zero-fill the LUKS volume (on the inside) before you format/use it - that way all of the randomness is generated by the same system that will be generating it when filled with actual data, so you don't have any 'suspicious' changes in entropy where you cut across
<rsalvaterra>
Everything's vulnerable to rubber-hose cryptanalysis… :/
<neggles>
everything short of "I don't know the key, I never knew the key, it was only ever in RAM, and you powered it down", yes :P
<nbd>
we should remove that nasty debug msg: "mt7621-nand 1e003000.nand: Using programmed access timing"
<nbd>
so where does it loop?
<stintel>
hold on
<stintel>
still working on the ubi variant bootlog
<stintel>
the thing is, I got jffs2 errors due to the bad blocks and couldn't figure out how to fix that so I tried UBI but that's getting stuck in that loop
<nbd>
but probably slowed down a lot because of the printk
<stintel>
I see
<stintel>
right, serial console doesn't help in that case
<stintel>
*facepalm*
<stintel>
I gave up after >10m
<nbd>
hm
<stintel>
I'll change the dev_warn to dev_dbg
<stintel>
and try again
<nbd>
it's weird that ubi prints a stack trace on reading the block with ecc errors
<nbd>
so there may be something else going on as well
<stintel>
I'm not sure I saw that stack trace on every attempt
<stintel>
do you know if mtk is working on the mtk_nand driver to support the mt7621 nand controller as suggested in response to that patch?
<nbd>
no idea
<xback>
stintel: I had this scanning too on a ath79 Mikrotik rb2011 board which contained some broken blocks. ik took roughly 30 minutes but works flawlessly afterwards. never had the "repairing" again on sequential boots
<stintel>
interesting
<nbd>
once that issue is sorted out, i would recommend sticking with ubi and enabling the mtk bad block table support for the kernel part
<nbd>
i recently added that for linksys ea7xxx
<stintel>
yeah I saw that
<nbd>
so i guess the ecc error issue is probably something like this:
<stintel>
didn't fully understand that, first range is the partition and second range is the alternative blocks? or how should I interpret that
<nbd>
with ecc errors, the corrupt data should probably still be returned on the read call
<nbd>
maybe it's not getting the data for some reason
<nbd>
and that's why it keeps retrying
<nbd>
and gives up after some attempts
<nbd>
the bbt range is the size of the kernel partition
<nbd>
it does not have a pool of replacement blocks
<nbd>
it only works with sequentially written blocks
<nbd>
and simply skips over bad blocks
<nbd>
so it's only suitable for the kernel partition
<nbd>
and would fail horribly for something like jffs2
<nbd>
it's nasty, but that's what the boot loader expects...
<stintel>
actually what I am trying here is to also put the kernel in ubi
<nbd>
by replacing the boot loader?
<nbd>
or does the boot loader support ubi?
<stintel>
or I misunderstood things
<stintel>
I'm not touching the boot loader, it's NAND only and I am not capable of recovering a TSOP48 chip
<nbd>
if the boot loader doesn't support ubi, you can't put the kernel on ubi
<nbd>
since the boot loader needs to be able to read the kernel
<stintel>
since target/linux/ramips/patches-5.10/410-mtd-rawnand-add-driver-support-for-MT7621-nand-flash.patch was rejected by upstream, does it make sense to move the files it adds to target/linux/ramips/files/... instead? that looks a bit cleaner than editing the patch for changing this msg afterwards: "mt7621-nand 1e003000.nand: Using programmed access timing"
<nbd>
fine with me
gladiac has quit [Quit: k thx bye]
gladiac has joined #openwrt-devel
<Habbie>
ERROR: package/feeds/base/cryptodev-linux failed to build.
<fda>
i found only the later "nftables-nojson" etc
<jow>
yes
<stintel>
you don't
pmelange has joined #openwrt-devel
<stintel>
it sets default for the next 2 package defines and is called there
<stintel>
to avoid duplicating those identical lines for both package variants
<fda>
ah, thx!
Strykar has quit [Ping timeout: 480 seconds]
Strykar_ is now known as Strykar
felix_ is now known as felix
<fda>
i'll test fw4 at weekend on a device. i hope it is not much work to chnage custom iptables rules to nft
<stintel>
if you use the wrapper, it shouldn't be
<stintel>
but ideally you rewrite them in /etc/nftables.d compatible form
pmelange has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
mattytap__ has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
mattytap_ has quit [Ping timeout: 480 seconds]
<dangole>
dwmw2_gone: I found a way to allow whole-flash sysupgrade for the U7623-02, so transitioning to the new image code is less painful now. It'd be great if you can give it shot and let me know what you think.
<dangole>
dwmw2_gone: code is here, as usual: https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=shortlog;h=refs/heads/mt7623-cleanup
<dwmw2_gone>
on phone... building... thanks
<dwmw2_gone>
ok, I'm on the vendor system. What do I do?
<dwmw2_gone>
I've been playing with it a bit to remember what the compat issues were.
<dangole>
dwmw2_gone: the build should have generated a -factory.img.gz file. you should be able to flash that when coming from older versions of OpenWrt (and hopefully factory image, in case it supports whole-flash with "SDMM" magic like the old OpenWrt image did)
<dwmw2_gone>
The old firmware used block2mtd and hard-coded MTD partitions.
<dwmw2_gone>
and has nonsense in the MBR, and its sysupgrade only upgrades the "firmware" partition of the "MTD", which starts with a zImage.
<dangole>
dwmw2_gone: ouf... block2mtd... what a nightmare
<dwmw2_gone>
So the kernel we build (in master right now) has hard-coded blkdevparts= which matches how the 'legacy' image is laid out.
<dwmw2_gone>
The upgrade procedure until now has been to upgrade using the 'legacy' image. And then you can upgrade again from there which does a whole-system flash, upgrading U-Boot too.
<dangole>
dwmw2_gone: ok, so the method I suggested previously (replacing /lib/upgrade/firmware.sh) is probably the only reasonable way to overcome that.
<dwmw2_gone>
The new U-Boot can boot a FIT image, and will pass it the correct memory information, correct root=, and no blkdevparts= because now the MBR is right.
<dwmw2_gone>
In terms of user friendliness, "upgrade from vendor firmware using the -legacy image, and then you can use the normal upgrade image thereafter" is a whole lot simpler.
<dangole>
dwmw2_gone: ah cool, so one way could be to tell users of the stock ROM to first flash OpenWrt 21.02 legacy image and from there use the *-factory.img.gz currently generated from my staging tree
<dwmw2_gone>
yes.
<dwmw2_gone>
Or we could keep building a legacy image :)
<dwmw2_gone>
The non-legacy image can still be brought into line with the BPi-R2 build
<dangole>
dwmw2_gone: you mean to generate the legacy image as well using the new image code? If it is just a legacy uImage with weird kernel cmdline, that sounds possible
<dwmw2_gone>
The original vendor firmware has U-Boot environment at offset 0x600 in the eMMC, 4KiB of it.
<dwmw2_gone>
So we could even switch to putting the MAC address there, instead of in a FAT partition.
<dwmw2_gone>
With the caveat that 19.07 does put it in the FAT partition and we should upgrade nicely from that at least, even if we throw away the config (and change MAC) on upgrade from the vendor firmware
<dwmw2_gone>
I won't fight you for that though :)
<dwmw2_gone>
But all of that stuff is under our control. The *invariant* if we want to do seamless upgrade is that it's a legacy uImage... which doesn't barf on the invalid MBR (hence the command line)
<dwmw2_gone>
dangole: hm, maybe the best option for legacy is a uImage with a built-in initramfs containing the full-MMC image. And a /init script which just zcat's it to /dev/mmcblk0 and reboots?
valku has quit [Quit: valku]
<dangole>
dwmw2_gone: yes, that would be amazing. sadly this really is very far from possible with our build-system and it's current understanding of initramfs.
<dangole>
dwmw2_gone: To overcome that limitation I made a hacky installer which does exactly that: ship the production image to be flashed inside an initramfs which does the job...
<dangole>
dwmw2_gone: but imho that's overkill if an easy solution can just be to tell users to flash 21.02 legacy image and then -factory.img.gz from there.
<dangole>
dwmw2_gone: U-Boot env sized only 0x1000 is too small to contain scripted dual-boot and TFTP upgrade logic... that's why I increased it to 0x10000 which is more than enough.
nlowe has joined #openwrt-devel
nlowe_ has joined #openwrt-devel
nlowe has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
<dangole>
dwmw2_gone: updated the tree, now just always using SDMMC_BOOT header which is apparently ok for the vendor Preloader. and updated instructions how to install/upgrade.
<dangole>
dwmw2_gone: once you verified the upgrade patch works when running 21.02 I would go ahead and push this to master.
<dangole>
*upgrade path
<fda>
stintel: i prevented nft all the time and use iptables syntax :)
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
kenny has joined #openwrt-devel
<fda>
from the (l)uci-conf view is the switch from fw3 to fw4 without any user changes ?
<stintel>
option extra is not supported but otherwise should be compatible
<fda>
opntion extra? is this "Extra arguments" - "Passes additional arguments to iptables. Use with care!" ?
<stintel>
I think so
<fda>
makes sense for cmd-arguments :)
<fda>
btw, the predefined "Support-UDP-Traceroute" rule is by default ipv4 only. maybe there should be 2 additional for ipv6: REJECT for the incomming and FORWARD for depelated ips
<fda>
"delegated"
<stintel>
feel free to send a patch :)
<fda>
my commit-comments are not good enough...
<stintel>
so improve them
<fda>
im a developer
<stintel>
a good developer writes good commit messages
<fda>
seems im a bad developer ;-)
<fda>
about 30% of my commits where accepted, 30% not wanted and 30% comment-bad
<fda>
but it depends hard on the repo, eg luci does not complain much
rua has quit [Ping timeout: 480 seconds]
<fda>
so im just usin custom rules for thing which are not predefined or not the way they should...
<stintel>
nat6 should have never been in the first place
rua has joined #openwrt-devel
<fda>
stintel: better than ipv6 only
<fda>
Slimey: sry, im not english native
<Slimey>
ah
<fda>
sry, better than IPV4 only
<Slimey>
fda it is a long running default slap in some IRC clients, notably mIRC
<fda>
ive never seen it
<fda>
i had to google "walrus"
<fda>
or walrut
<fda>
ah, whatever :D
<fda>
has "rus" any meaning in english?
<fda>
stintel: but after some time using nat6 i#ve to say its nice! no changing ipv6 in the lan, and only short ULAs
<Slimey>
I shall go back to my spread sheets :|/
<stintel>
nbd: xback: and still no progress, and that's with the printk disabled... I think it's safe to say something else is going on
<nbd>
definitely
<dwmw2_gone>
dangole: so what exactly do you want me to test? Upgrading from vendor to 21.02 using the legacy image, then to your non-legacy build?
<dangole>
dwmw2_gone: update from vendor to 21.02 legacy image and from there use the *-emmc.img.gz generated from my staging tree
mrkiko has joined #openwrt-devel
<dangole>
fda: your commit messages were fine, if you ask me. just some changes you suggested were not acceptable (target-wide change of default cpufreq governor) and I've suggested alternative ways to achieve the same thing to you. i really didn't mean to discourage you! your contributions are generally very welcome and useful!
<stintel>
ah, I actually think changing the default governor to schedutil could be acceptable
<stintel>
I vaguely remember seeing such PR
<fda>
dangole: the comment about comments was not about you!
<fda>
stintel: chnaging ONLY governor is dangerous, as the one device (e8450) is maybe not able to soft-reboot anymore IF it is in slowest mode AND below 1volt...
<stintel>
that sounds like a bug
<dangole>
stintel: i agree, but it would be acceptable as a change in generic rather than just for one specific subtarget (mt7622) while the same arguments also apply to all other targets/subtargets.
<stintel>
dangole: makes sense
<fda>
stintel: dangole says a bug in uboot
<dangole>
stintel: cpufreq for mt7622 is weird. officially the SoC doesn't even support it. depending on preloader/atf, reboot may or may not work at 0.9V supply voltage.
<dangole>
stintel: when using 'ondemand' this is really a problem because then system often chooses the lowest freq at reboot which operates at 0.9V and then hangs. with schedutil is works, because it doesn't so aggressively push for the lowest rate. just raising the voltage on that lowest rate to 1.0V also fixes it, but who knows the long-term side effects that may have...
<dwmw2_gone>
Wed Jan 19 17:10:41 UTC 2022 upgrade: Device unielec,u7623-02-emmc-512m not supported by this image
<dwmw2_gone>
Wed Jan 19 17:10:41 UTC 2022 upgrade: Supported devices: unielec,u7623-02
<dwmw2_gone>
sysupgrade.itb
<dwmw2_gone>
Image check failed.
<dwmw2_gone>
Invalid image type.
<fda>
dangole: there are no whatever-term effects as long voltage is not more than maximum. it is reduced only as it is possible to save energy+head with below-max freqency
<dangole>
dwmw2_gone: i thought i had removed all those suffixes from both, the compatible string in DTS as well as SUPPORTED_DEVICES. are you sure this image was generated from the current checkout of my staging tree and isn't just a left-over from a previous build?
<fda>
if voltage for selected frequency is to low, it will simplay crash and maybe reboot
<dangole>
dwmw2_gone: because 'grep "512m" target/linux/mediatek' doesn
<dwmw2_gone>
Supported devices: unielec,u7623-02
<dwmw2_gone>
that's the image I'm trying to flash
<dangole>
t shoud anything meaningful
<dwmw2_gone>
Device unielec,u7623-02-emmc-512m
<dwmw2_gone>
comes from the 21.02.1 that's running
<dangole>
ah ok
<dangole>
try flashing the *-emmc.img.gz instead, it should now be recognized as whole-flash image by sysupgrade
<dwmw2_gone>
it'll have the same issue because of the appended metadata?
<fda>
beside that, i have to say after ~6 months the e8450 is a great device with openwrt - beside 5ghz wlan which is crap
<fda>
meanwhile i disabled wlan and using an additional acces point which has very good wlan, throughput and range
<fda>
and is also stable with openwrt, 28days uptime. a avm1200
<dwmw2_gone>
Wed Jan 19 17:16:32 UTC 2022 upgrade: Image metadata not present
<dwmw2_gone>
Wed Jan 19 17:16:32 UTC 2022 upgrade: Use sysupgrade -F to override this check when downgrading or flashing to vendor firmware
<dwmw2_gone>
gz
<dwmw2_gone>
Image check failed.
<dangole>
fda: i'm very happy with MT7915E ax radio, dunno what you are talking about, works great with all my clients and range is ok when selecting a DFS channel with 27dBm
<dwmw2_gone>
I'm sure -F will work, of course. But we didn't need that before
<dangole>
dwmw2_gone: ah ok, so it needs metadata as well...
<fda>
dangole: 5ghz work well for you?? i tried in ac and ax mode, disabled PMF, used lowest channel (36) but in the next room there is no more wlan...
<dangole>
dwmw2_gone: and the metadata needs to match the odd -emmc-512m suffix... maybe '-F'
<fda>
the avm1200 covery the whole garden and house
<dwmw2_gone>
-F would work but needing that would be a regression from what I have implemented before.
<dangole>
dwmw2_gone: so you suggest to keep the odd suffix to be compatible? imho that's a bit risky as people may then just flash the sysupgrade image and end up with a brick...
<fda>
dangole: and the e8450 sees other APs, but the other does not see the wlan of the e8450
<stintel>
hauke: minor spelling error in your taskset patch: "It is already builT"
<dangole>
fda: try a channel between 100 and 140, there the chip delivers full TX power of 27dBm, otherwise it's just 23dBm or 20dBm...
<dangole>
fda: and, of course, use 80Mhz channel width if you want range
<stintel>
meh, I'm lost with this fit partition kernel in ubi stuff
<dwmw2_gone>
dangole: I don't see the problem
<dwmw2_gone>
I thought this is the reason we had two device strings in the first place?
<fda>
dangole: okay, ill try. 80 was yet set. does ax/ac matter (i have no ax devices)
<dwmw2_gone>
the legacy image allows you to update to another legacy image. Once you're running new enough code, that'll let you update to either type of image?
<dangole>
dwmw2_gone: metadata is meant to prevent users from accidentally flashing the wrong image. hence, if the new single-FIT image claims to be compatible with the old image, that can result in people bricking their device without receiving a warning that the image may not match
<dwmw2_gone>
right
<fda>
dangole: the max selectadble power in luci is 20, so "default" is to use 27?
<dangole>
dwmw2_gone: hence i decided to drop the '-emmc-512m' suffix to make people hesitate and maybe check if they are doing the right thing before proceeding...
<dangole>
fda: it should depend on the channel, but I don't know, I'm a text-mode-only user when ever that's possible and don't usually touch web-stuff unless something really forces me to do so
<fda>
dangole: have you set the max-power to defualt or by uci to 27?
<dwmw2_gone>
so the vendor firmware is only checking for the uImage magic (27051956) I think.
<dwmw2_gone>
But that's probably good enough since that's the important part.
<dangole>
dwmw2_gone: i can just add the old string as additional SUPPORTED_DEVICES for the new image and append metadata to the emmc image, then '-F' would not be needed but we would risk that users fail to check and blindly update and then end up with a brick
<dwmw2_gone>
what would they upgrade *from*, that would cause a brick?
<dangole>
dwmw2_gone: say they run openwrt-21.02 and (just like you did before) try to flash the sysupgrade.itb image.
<dwmw2_gone>
I thought the idea was that we would treat the two flash layouts as different boards. You can upgrade from one to the other but not vice versa.
<fda>
Luci shows with "default power" selcted: "Current power: unknown"
<dwmw2_gone>
but that should work, shouldn't it? It currently needs -F but ideally shouldn't need it.
<dwmw2_gone>
hm, yeah, that didn't work :)
<dangole>
dwmw2_gone: did it write the image to the emmc or refuse?
<dangole>
dwmw2_gone: thanks for the dump. i'll try to figure while whole-emmc upgrade still makes assumptions on additional partitions and tries to even mount them...
<fda>
dangole: i set my avm1200 also to channel 36->100 and not the e8450 cant see the avm1200 anymore ^^
<dwmw2_gone>
that's what's in the 21.02 release, *saving* config to the recovery partition?
<dangole>
fda: it may take time for it to start beaconing because it needs to scan 60s for radar pulses...
<fda>
dangole: seems avm1200 has a problem with channel 100, from syslog:
<fda>
Frequency 5500 (primary) not allowed for AP mode, flags: 0x10095b NO-IR RADAR
<fda>
wlan1: IEEE 802.11 Configured channel (100) or frequency (5500) (secondary_channel=1) not found from the channel list of the current mode (2) IEEE 802.11a
<fda>
Could not select hw_mode and channel. (-3) -- wlan1: interface state UNINITIALIZED->DISABLED -- wlan1: AP-DISABLED -- wlan1: Unable to setup interface. -- nl80211: deinit ifname=wlan1 disabled_11b_rates=0
<dangole>
fda: for ipq40xx i'm the wrong person to ask.
<fda>
dangole: as ch36 worked good with avm1200 i switched back - and seconds later e8450 found the wlan. so its okay for me
<dwfreed>
make sure you're setting country code?
<dangole>
dwmw2_gone: SAVE_PARTITIONS is supposed to be UPGRADE_OPT_SAVE_PARTITIONS I guess? (trying to understand mtk_mmc_full_upgrade function)
<fda>
dwfreed: it was set to "default", ill test
<fda>
dwfreed: the avm1200 is now also visible on ch100 after set country to "DE"
<dwfreed>
:)
<fda>
wow, now the avm1200 could see the e8450 to with a country set
<fda>
dangole:
<mrkiko>
is it normal / expected the rx bitrate seems to be lower than tx bitrate
<dangole>
dwmw2_gone: did it actually update U-Boot? because it says "3126560 bytes read in 154 ms (19.4 MiB/s)" without showing menu options or anything...
mattytap__ has quit [Remote host closed the connection]
<dangole>
mrkiko: from the AP perspective typically yes, that's normal, because clients typically have less TX power than the AP
<dwfreed>
if the ap isn't sending much data, the rx bitrate will drop to preserve airtime fairness
<dangole>
dwmw2_gone: so this whole-emmc-flash wasn't really whole-emmc :( i'll try to figure out way
<fda>
conclusion: set country to yours and keep power to default
<fda>
country: dont forget to set it to both radios
<mrkiko>
fda: thanks!!
<fda>
?
mrkiko has quit [Quit: leaving]
<hauke>
dwmw2_gone: the prpl repos are curently still partly public, there you can find some recent vrx518 driver
Borromini has joined #openwrt-devel
nlowe_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dangole>
hauke: "currently still" doesn't sound good
<dangole>
hauke: as in "do i want to locally mirror all that now before it's too late?"
<hauke>
stintel: thanks
<hauke>
I do not know what the plans are
<dangole>
dwmw2_gone: I assume the *-emmc.img.gz images works just fine when writing with SP Flash Tool, right? (I remember you did try that before)
<hurricos>
Hey ynezz: I maintain https://gitlab.laboratoryb.org. It doesn't see very much use at all, but you can feel free to reach out to me with any questions
<hurricos>
I find maintenance is actually quite simple. https://github.com/sameersbn/docker-gitlab is very robust. The only real maintenance I have to do is involving the upgrade process, which requires setting aside two hours every 6 months to be consistent.
<fda>
dangole: after set the country, with e8450 5ghz now works, with all channels! maybe the default is bad?
<fda>
compared to avm1200: "default" country make ch36 work, but not 100 - i think this is better default for people like me
<Slimey>
IPQ80xx and IPQ6010
<fda>
could the default for this single device be change, dangole ?
<dangole>
fda: the levels are stored in the calibration EEPROM data and are chip-specific. Linux regdomain/CRDA implementation then **further limits** this to comply with local laws, or in case of country being not set by the user, comply with the intersection of all global regulation.
<dangole>
fda: OpenWrt's defaults there are simply the Linux Kernel's regulatory domain database and are the same for all devices (at least those using mac80211-based Wifi drivers)
<dangole>
fda: so Ch.36 is always allowed, but the power level depends on the hardware. in case of the RT3200, the hardware limits the transmit power on the lower 5GHz band more than on the upper half of the band.
<dangole>
fda: hence you got to set the country code to enjoy full power and there isn't much we can do about it
<fda>
the problem was, that for me even ch36 wiht e8450 was unuable, with luck in the same room
<dangole>
fda: as this is a common problem for all 5GHz devices, commercial devices usually either come with a preset country or force the user to set it before allowing normal operation.
<fda>
but why then the 1200 worked?
<dangole>
fda: because the hardware allows for higher tx power in the lower 5ghz band
<PaulFertser>
There's also a thing that your AP might be accepting country "hints" from the other APs it hears around.
<fda>
hm, strange thing
<fda>
the avm1200 is from a german company, maybe they changed the default country..
<Slimey>
PaulFertser hmm never thought of that
<Slimey>
something in the tags it might read on?
<PaulFertser>
Nobody told me there'd be days like these -- strange days indeed
<PaulFertser>
Slimey: there's a country IE in the beacons.
<Slimey>
good movie :P
<Slimey>
yes in the beacon
<dangole>
PaulFertser: 802.11d, yes. but imho it's implemented mostly for letting clients know the country set by the AP. and maybe if you set channel to 'auto' so the AP scans before...
<fda>
my 2 devices are in the same house, so they oculd hear mostly the same other devices
<dangole>
PaulFertser: for sure there is no logic in OpenWrt to store the country once detected via 802.11d
<PaulFertser>
Slimey: what movie?
rua has quit [Ping timeout: 480 seconds]
<Slimey>
"strange days"
<PaulFertser>
dangole: yep, no code to do that exists. But e.g. Intel cards are going to temporarily restrict themselves for sure.
<fda>
what about to use as default in openwrt the country with the smallest allowed frequencies?
<fda>
or wifi-power
<fda>
should be better than unset/not working
<PaulFertser>
Slimey: I should probably watch it. But I do not see Lennon's song mentioned in the sound track.
<PaulFertser>
fda: OpenWrt's defaults are fine and sane. A user should just set the country, and it's great OpenWrt allows to do that easily.
<fda>
PaulFertser: i did until today NEVER set the country iwht openwrt
<fda>
its on the "advanced" tab which is not required for basic functions - imho
<PaulFertser>
fda: there're no tabs in /etc/config/wireless.
<fda>
-.-
<PaulFertser>
You check "iw reg get" and "iw list" and you see you're limited by regulatory so you set the country.
<f00b4r0>
fda: the default is world regdomain which is exactly that: the lowest common denominator.
rua has joined #openwrt-devel
<fda>
PaulFertser: i piped both commands to a file, then switched germany/default country and did it again
<fda>
both files math 100%
<PaulFertser>
fda: then it means the switch didn't work, try rebooting. "iw reg get" shows the currently selected regulatory region.
<fda>
PaulFertser: you are right!. after set default its still "country DE: DFS-ETSI"
<fda>
reboot+timout...
fda- has joined #openwrt-devel
<fda->
PaulFertser: very funny: i set to default and reboot. after that its still "DE"
<PaulFertser>
Probably default just keeps old setting.
fda- has quit []
fda- has joined #openwrt-devel
fda- has quit []
fda- has joined #openwrt-devel
<fda->
another reboot later ... yes, if you set anything except default and set then default again, iw reg get shows the country last selected
<fda->
so if you ever changed country it will always work
fda has quit [Ping timeout: 480 seconds]
<fda->
as i never changed it, i was maybe "undefined"
<mrkiko>
so it's possible to stick "config rule" sections in /etc/config/network ? :D
<fda->
luci runs "uci del wireless.radio1.country"
<fda->
(btw, i used "iw pty1 reg get")
<aparcar>
hurricos: Hi, thanks for reaching out. I think nobody is super excited about maintaining gitlab, at least over the last 3 years. Do you want to step up?
DLange has quit [Quit: \o/]
DLange has joined #openwrt-devel
kb1sph has quit [Ping timeout: 480 seconds]
mrkiko has quit [Remote host closed the connection]
<hurricos>
I'd love to :D
<hurricos>
aparcar: However, a few tricky bits come to mind: 1) I'm not an OpenWrt maintainer / developer; 2) I'm not as familiar as I'd like to be with what the OpenWrt developer community wants out of the solution, particularly RE: CI, and 3) I recognize Github CI currently provides a working and popularly used solution for the package repositories.
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
<hurricos>
I did spend a little bit of time toying with https://gitlab.com/ynezz/openwrt-device-runtime-testing. I recognize from this that Gitlab has more potential for having work distributed (hosting runners is very easy).
GNUmoon has quit [Ping timeout: 480 seconds]
<hurricos>
As mentioned in the mailing list, there's also lots of custodial / moderation work to be done in addition to maintinance.
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<neggles>
dangole: I have figured out a workaround that avoids having to use sysupgrade-tar :D
<neggles>
if I do `fit none <dtb> with-rootfs`, I get a FIT with kernel + dtb + rootfs in a third image - with CONFIG_FIT_PARTITION=y (not 100% sure that’s actually necessary), and a couple of extra cmdline arguments, the parser finds and attaches the rootfs image from the FIT even though it’s not external/static-offset
<neggles>
and firstboot creates/mounts the automatically expanding rootfs_data ubifs volume
dangole has quit [Remote host closed the connection]
<neggles>
fda-: it also depends on the specific wifi driver and how the OEM device / caldata is set up - eg the ath10k / QCA9990 in this sophos APX sets the country automatically from caldata & OpenWRT will honor the max TX power in a given channel if you leave it on “auto” with “unknown” country
<neggles>
but if you set the country it allows selection of more channels
<neggles>
and a surprising number of OEM caldata files don’t contain a default country code
goliath has quit [Quit: SIGSEGV]
arifre has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
rua has joined #openwrt-devel
nlowe has joined #openwrt-devel
ordex_ has joined #openwrt-devel
<ordex_>
Hi there, I am writing the Makefile for a new kernel module, but I get the following error when importing my local feed: Makefile:59: *** Package/kmod-ovpn-dco is missing the TITLE field. Stop.
<ordex_>
but actually I have a TITLE field in the package definition
<ordex_>
what might be wrong?
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ordex_>
I swear I changed nothing around those lines
<hurricos>
I fixed it! You're welcome.
<ordex_>
maybe because it's late :D
<ordex_>
haha
<ordex_>
well done!
<ordex_>
btw I checked that ovpn-dco package, looks good, but I am working on a "-dev" version. So we'll have a feed people can install to get the bleeding edge code for testing
* hurricos
sweats, having done absolutely nothing, but still feeling the existential dread associated with things suddenly working and not knowing why
<ordex_>
:D
<hurricos>
Yeah, best of luck :o I wasn't aware of a way to accelerate OpenVPN like this, looks nice.
<ordex_>
yeah, it's not "usable" yet
<ordex_>
as it requires a modified version of openvpn itself
<ordex_>
it'll be part of this -dev feed too
<ordex_>
as the code is not yet merged
eduardo010174 has quit [Quit: Leaving]
<ordex_>
ah, it works because I Was passing the wrong path to the feed :S
* ordex_
tries again
<ordex_>
yeah, getting the same error again
<ordex_>
hurricos: sorry :p
<hurricos>
Try mutating it from the original package IMO
* Slimey
mutates
<hurricos>
You can then start a bisect if the changes don't work
<ordex_>
I did that too
<ordex_>
somehing stupid must be missing
<ordex_>
something*
<ordex_>
ah yeah
<ordex_>
found the issue
<ordex_>
on the last line
<ordex_>
I did not pass the right identifier to KernelPackage
<ordex_>
darn
<ordex_>
I knew it was late
<ordex_>
hurricos: thanks for the support! :D
philipp64 has joined #openwrt-devel
ordex_ has quit [Quit: Page closed]
guifipedro has quit [Ping timeout: 480 seconds]
guifipedro has joined #openwrt-devel
<neggles>
oh he left
<neggles>
line 23: define KernelPackage/ovpn-dco-dev, line 37: define KernelPackage/ovpn-dco/config