<russell-->
in the case i'm seeing, sysupgrade uniformily fixes the corruption of the squashfs on a ubi volume
<ynezz>
so does in their cases
<ynezz>
"In my case I "solved" the issue by booting the 19.07 initramfs-kernel.bin to RAM (option "1: System Load Linux to SDRAM via TFTP" in the bootloader) and then sysupgrading to the 19.07 squashfs image."
<russell-->
in my case, the original flash was fine, remained working for a month or year, but squashfs corruption accumulated until a reboot resulted in failure to fully complete
<russell-->
i can reflash the original version and all is well again
<ynezz>
it's same for them, they just did reboot after sysugprading their devices
<ynezz>
then flashed again when booted the device from initramfs and all was fine
<russell-->
i never see a problem on sysupgrading
<russell-->
it's on plain reboots when squashfs corruption has occurred
<russell-->
that's not what they are reporting
<russell-->
if you have an erx running, read all the /rom files and see if you get errors
<ynezz>
and how do you think, that your squashfs gets corrupted? cosmic rays? I assume it's a same nand driver issue
<russell-->
i don't know how, but the evidence in 6 different devices is that it does
<ynezz>
it's just exhibited differently in your case
<russell-->
very differently
<russell-->
it's fine for months, and then it isn't
<russell-->
find /rom -type f | xargs sha256sum > /dev/null
<russell-->
dmesg
<ynezz>
well, rom resides in nand, squashfs is just layer above that, right?
<russell-->
it's squashfs on a ubi volume on a nand partition
<ynezz>
squashfs is shared by all targets, if there would be issue, we would know it and fixed it already
<russell-->
i'm not blaming squashfs, i'm reporting 7 different devices showing the same corruption
<russell-->
i have replaced one, which is why i said 6 before
<russell-->
(replaced with a different device)
<russell-->
... because the user complained about lack of robustness
<ynezz>
ubi is shared by other nand targets, if there would be issue, we would know it and fixed it already
<ynezz>
so it really boils down to the issue with nand driver, as described in those issues I've referenced
<russell-->
for all i know, it has been fixed already, but it was still present as of r16261-g85fa8ad8af, because i saw it there too
YSC has joined #openwrt-devel
<russell-->
e.g. one device i reflashed in late october, suddenly in february this year:
<russell-->
Feb 3 11:19:04 10.11.250.56 kernel: [ 5286.646845] SQUASHFS error: xz decompression failed, data probably corrupt
<russell-->
Feb 3 11:19:04 10.11.250.56 kernel: [ 5286.660653] SQUASHFS error: Failed to read block 0x5c69f2: -5
<russell-->
Feb 3 11:19:04 10.11.250.56 kernel: [ 5286.672244] SQUASHFS error: Unable to read fragment cache entry [5c69f2]
<russell-->
a block it had presumably been reading fine for 3+ months
<russell-->
then, to correct it, i reflashed with sysupgrade (remotely) the same firmware i built in late october 2021, and it was fine again.
cbeznea has joined #openwrt-devel
csharper2005 has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
dgcampea has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
csharper2005 has quit [Remote host closed the connection]
danitool has joined #openwrt-devel
grift has joined #openwrt-devel
<russell-->
so, in the bridge-vlan context, if i want an interface's device named something other than e.g. switch.NNN, is the recommended way to wrap that in another bridge?
<dwfreed>
I guess the question is why does it matter? adding more bridges is not going to help performance any
<russell-->
because, for example, i want it to have a name, or possibly because i want to add wlan interfaces to a bridge
<russell-->
although so far this is on switch hardware with no wlan
Borromini has joined #openwrt-devel
<rsalvaterra>
mangix: I backported the 5.16 zstd update, yes, it's in my tree.
<dwfreed>
russell--: wlan interfaces can be added to a vlan-aware bridge already
<dwfreed>
but layering another bridge just because you want it to have a name seems really stupid, because it will hurt performance
<russell-->
is there some other way to get a name?
<dwfreed>
you can change the interface's name
<dwfreed>
dunno that netifd itself allows this, but Linux in general does
<dwfreed>
Linux has no requirement that interfaces have any particular name, even vlan interfaces
<dwfreed>
(because internally it doesn't give a shit what the interface name is, everything is by ID)
<russell-->
so, how do you map switch.200 to foo
<dwfreed>
ip link set name foo dev switch.200
<russell-->
a year ago i could just add tagged interfaces to a bridge and that worked
<dwfreed>
sure, but you're going to make performance suffer doing that
<dwfreed>
and I doubt that DSA is going to handle that situation correctly, so they'll be software bridges, which is even worse
<russell-->
not that i ever noticed
<russell-->
it doesn't anymore, but it did then
<russell-->
i thought DSA was all about making switch ports magically look like interfaces and to hide all the details of making it work, bridge-vlans just re-expose all the ugliness
<russell-->
or so it seems
<russell-->
lacking any documentation to explain how actually it is really beautiful afterall
<Borromini>
stintel: do you happen to have a 'wireless' entry under 'Network' in LuCI on the EAP615? No worries - I configured wireless through /etc/config/wireless ;)
<Borromini>
but I notice it's not there (22.03 HEAD) and it is there on e.g. a R6800 (ac MT7615)
ecloud_ has quit [Ping timeout: 480 seconds]
cbeznea has joined #openwrt-devel
<neggles>
russell--: you can name it without renaming it
<neggles>
do you want to rename the bridge vlan sub-interface, or the network that attaches to it?
cbeznea has quit [Read error: Connection reset by peer]
<neggles>
but, DSA does make switch ports magically look like interfaces
<neggles>
it's just that if you want to actually use the *switch* part of the switch, rather than routing every packet through the software on the CPU, you have to use a single vlan-aware bridge
<neggles>
adding more bridges does work, it's just counterproductive - it does nothing you can't do with a single bridge other than make configuration more complex & remove any abillity to offload packet forwarding
<neggles>
it's also quite fraught with peril once vlan tagging comes into the equation.
<f00b4r0>
russell--: I think this is what you're looking for, if I read you correctly: https://pastebin.com/eSipuwRC
<f00b4r0>
this creates a bridge-vlan "vbridge0", with member ports "lan" and "wan" (this is a DSA device but it works the same with swconfig ones), creates a 802.1q device at VID 3 named "vlan-private", member of the bridge-vlan.
mattytap_ has joined #openwrt-devel
mattytap__ has joined #openwrt-devel
mattytap has quit [Read error: Connection reset by peer]
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Read error: Connection reset by peer]
mattytap_ has quit [Ping timeout: 480 seconds]
Misanthropos has quit [Ping timeout: 480 seconds]
<stintel>
Borromini: I do
Kardy has quit [Quit: Leaving.]
<Borromini>
stintel: hmmm. weird. mind showing me your diffconfig for the 615?
<grift>
if i wanted to build my kernel with CONFIG_NF_CONNTRACK_SECMARK how would i go about that? `make kernel_menuconfig` seems to not allow me to set that?
srslypascal is now known as Guest2124
srslypascal has joined #openwrt-devel
Guest2124 has quit [Ping timeout: 480 seconds]
<PaulFertser>
grift: you can search for the option with / and then you'll see what it takes to make it visible. However in this case where you want to tweak netfilter-related options you should rather do that in package/kernel makefiles.
<Borromini>
neggles: thanks. I suppose you got the wireless tab as well no
<neggles>
believe so
<neggles>
lemme check
<Borromini>
is this your diffconfig?
<neggles>
yes
<Borromini>
yeah, i forgot for a minute master doesn't enable LuCI so it will always show up in diffconfig =)
<neggles>
i can grab the whole .config if you like
<Borromini>
no this is fine, ty
<Borromini>
was a bit confused by the luci stuff being there but it's not included by default in master, so makes sense
<Borromini>
diffconfig should be plenty :)
<neggles>
yeah
<neggles>
this build doesn't have my custom repo in it either
<neggles>
which makes life easier
<f00b4r0>
nbd: your suggestion works, the results don't seem quite as consistent as with the "wrong" patch, but this could be just related to different radio conditions. I'll submit v2 with your Suggested-by, ok?
<neggles>
bgnax and nacax sound like benzodiazepine analogs
<Borromini>
thanks :)
<Borromini>
hehe
<Borromini>
how many you got in use?
<neggles>
technically zero
<Borromini>
all for testing purposes? :)
<neggles>
tbqh I bought it thinking it was mt7622 not 7621 😅
<neggles>
also it was very cheap and i have a bit of a dearth of wifi6 HW
<Borromini>
oh :P
<Borromini>
well we have no AX clients here either... but the EAP235 was driving me crazy with its crappy MT7613 radio. And this is a drop-in replacement form factor wise.
<Borromini>
so easy call, although it took months for them to get delivered
<neggles>
ubiquiti's wifi 6 stuff is underwhelming and I'm kind of getting sick of ubnt bullshit
<Borromini>
i'm over ubnt as well. my brother's home is all UniFi AC AP's
<Borromini>
'nie wieder', as the Germans like to say =)
<neggles>
i have had no trouble at all with my own setup
<neggles>
nanoHDs are really quite solid, and I don't use their firewalls
<Borromini>
i only set up their APs as well so far, but all with OpenWrt, not OEM firmware
<neggles>
but i have a couple UDM-Ps deployed at client sites and while they mostly work, when they screw up, they screw up
<Borromini>
then what bs are you getting sick of?
<Borromini>
ok :)
<neggles>
the UDM-SE fixes most of the issues, as does just dropping a HDD into the UDM-P, since the problem is the stupid things running out of disk space
<neggles>
and SE/UDR have 128GiB from factory
<neggles>
but it's just tedious to deal with
<neggles>
only reason I don't run OpenWrt on everything is lack of a unifi-style central management system
<Borromini>
:)
<Borromini>
I suppose openwisp doesn't offer the same thing like UBNT
<neggles>
but if I can get 802.11k/r/v working in a way that iphones will behave with & a set up a few other misc things which unifi either doesn't support or "supports" (but is actually broken)
<neggles>
i might just yeet ubiquiti
<neggles>
not really
<neggles>
i considered aruba's instant-on stuff since they offered us an insanely low price for a pack of ten of 'em
<neggles>
but they only go to 2x2
<Borromini>
ok. you got clients that do more?
<neggles>
oh yeah.
rua1 has joined #openwrt-devel
<Borromini>
not consumer stuff then I assume?
<neggles>
macbook, laptop
<Borromini>
ok.
<neggles>
even without higher chain counts on clients, more chains on AP = better coverage and multipath handling
<neggles>
and with wifi 6, proper MU-MIMO in both directions
<Namidairo>
silly apple and their 3x3 cards
<neggles>
2x2 on 2.4ghz i'm fine with
<neggles>
but I want 4x4 on 5GHz
<neggles>
so I guess i'm waiting for MT7986 APs?
rua has quit [Ping timeout: 480 seconds]
<Borromini>
MT7915 isn't doing more than 2x2?
* Borromini
has no idea on the max it can be configured for
<neggles>
MT7915 can do 4x4 on a single band
<neggles>
or 2x2 DBDC
<neggles>
but so far it's exclusively been deployed as a 4x4 on 5GHz, combined with the 4x4 802.11n built into an MT7622, or 2x2 DBDC with an MT7621
<PaulFertser>
mt7915e for 4x4 or mt7915d for DBDC, so it's not switchable.
<Namidairo>
it has to be the one configured for dbdc yes
<Namidairo>
it's sitting with the other CPU config options
<neggles>
cause there's a 7976 and 7916
<neggles>
ahhh
<neggles>
"Filogic 820 represents a series with different CPU models. The wireless baseband and MAC have been integrated in the CPU, that is, the MT7916AN (wireless baseband and MAC) has been integrated into it. Therefore, the XDR3020 will not have the MT7916AN chip in the picture below."
<neggles>
the pics are from a ZTE with the 7976DN which is a radio
f00b4r0 has quit [Read error: Connection reset by peer]
f00b4r0 has joined #openwrt-devel
<neggles>
interesting
<neggles>
welp either it'll show up somewhere sooner or later or it won't :P
rua has joined #openwrt-devel
<neggles>
n.b. i am wrong MT7976 is the radio frontend for the MT7916 heh
<neggles>
so yeah that would probably make the MT7981 the 2x2:3 variant of the MT7986
<Namidairo>
they could cut it down in other ways
<Namidairo>
make it dual core for example
<neggles>
probably dual-core yeah
<neggles>
2x2:2 + 2x2:3 is interesting, and that'd make it the obvious choice to replace the MT7621 as the "of course this router has one of those in it" chip of the next X years
<neggles>
everything is MT7621s and IPQ4019s :P
<Borromini>
is IPQ40xx better wrt VLANs etc on DSA?
<Borromini>
or still quirky as f?
rua has quit [Ping timeout: 480 seconds]
arthur_melo has joined #openwrt-devel
rua has joined #openwrt-devel
<neggles>
Borromini: quirky how?
<Borromini>
well i thought it had VLAN 1 hardcoded etc
<Borromini>
stuff that would make the switch die on you if you tried to re-use those VLAN IDs without knowing it.
<neggles>
i mean it's generally a really bad idea to use VLAN 0 or 1 anyway
<neggles>
behaviour of 0/1 across all classes and vendors of switch is not consistent and never has been - some use vlan0 to refer to untagged, some don't have a concept of vlan 0 and use vlan 1 as default
<neggles>
it appears the qca switch core the ipq4019 uses is one of the latter - by default all ports are set to untagged on vlan 1, which is *technically* the more standard-compliant way to do things
<neggles>
but i have not looked at it very closely so could easily be wrong.
ekathva has joined #openwrt-devel
<Borromini>
neggles: yeah, i learned that the hard way with IPQ40xx :P
<neggles>
everyone learns that the hard way sooner or later :P
<neggles>
whole bunch of additions to mainline u-boot for octeon mips
* stintel
been working remote from the middle of nowhere, close to no screen time outside of work
<neggles>
fair enough :)
<stintel>
and right now it's travel mode on
<stintel>
but thanks for the ping
<stintel>
interesting stuff
<neggles>
the one-line summary is "oh hey look a networking driver, and the groundwork for more general upstream support"
<mattytap__>
stintel: <wave> enjoy the weather
Misanthropos has quit [Ping timeout: 480 seconds]
<stintel>
mattytap__: haha about that ... yesterday 22C or so, today 6. fortunately it's still ~20 in my destination
<stintel>
mattytap__: thanks
<stintel>
they even predict snow here soon
<mattytap__>
stintel: I knew it! - you are installing a datacentre in the arctic using repurposed kit running FOSS
* neggles
gasps
<stintel>
:D
<mattytap__>
stintel: like on Ice Station Zebra - but with computers
<stintel>
hmm, not sure I know this tihng
<neggles>
oh hey there's a whole other series full of things like an oct-remote-console pretend-o-serial driver in here too, yay - not particularly exciting in and of itself, but this is proof that there *are* still people properly working on mipsteon
* neggles
is tentatively optimistic
<stintel>
was there any progress on the NAND driver ?
<neggles>
stintel: not as of yet, but i did find some recent discussion about it
<neggles>
and it does work in u-boot
<stintel>
ok so there might be some hope after all :)
<stintel>
good stuff
<neggles>
the linux and u-boot side just have disagreements about ECC... octeon iii has HW ECC that actually works
<neggles>
but octeon ii and older only do 1-bit ECC in hw
<Borromini>
is Marvell thinking about improving Octeon support? o_O
<neggles>
they appear to be actively doing it
<stintel>
was good catching up, off to my gate :)
<Borromini>
just when I sold my EdgeRouter 4 eh :P
<neggles>
stintel: have fun! *waves*
<Borromini>
oh well, got bigger and better instead =)
<Borromini>
enjoy your holiday (?) stintel :)
<stintel>
visiting fam in hometown for easter
<stintel>
48h and back home
<neggles>
Borromini: ehh. i wouldn't count on it actually being good for 6-12mo minimum
<neggles>
and that's being very optimistic
<Borromini>
=)
<Borromini>
stintel: yes BE is having great weather atm... Enjoy!
* Borromini
is camping out in his city garden
<Borromini>
neggles: got me an Armada based edge router, far better support (except for the 2,5Gbps which isn't sorted out yet)
<neggles>
would anyone happen to know what the minimum required set of dsa_switch_ops are
<neggles>
i also don't have a clue how to implement dsa vlans on a switch without IVL...
<neggles>
stupid documentation
minimal has joined #openwrt-devel
<hauke>
neggles: vlan is not needed for DSA
<neggles>
hauke: yeah, i have given up on that part for now
<hauke>
you need tagged frames DSA
<hauke>
to detect from which port you got the packet
<neggles>
yeah
<neggles>
AR8236 is *almost* the same as AR8229
<neggles>
er
<neggles>
AR9331*
<neggles>
but it uses the qca8k tag format
Tapper has quit [Ping timeout: 480 seconds]
<neggles>
I think I've got a decent handle on it; if you point qca8k at the switch it does partially initialize it, mdiobus reads/writes/etc work, and i receive qca-tag-format frames on the cpu port
<neggles>
so i've taken qca8k, copied it, deleted 3/4 of the functionality, and am modifying it to poke the registers this chip is expecting... not very suitable for upstreaming, but if this works I can look at maybe adding drivers/net/dsa/qca/ar8216.c rather than this
<neggles>
should be possible to get rid of the swconfig ar8216 driver if it does work :)
<neggles>
would have to implement vlan offload for that, but. baby steps.
<hauke>
it sounds promising if somethig already works with the qca8k driver
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<neggles>
hauke: yes, there are a lot of similarities in their registers; the qca8k-supported switch chips are all descended from the AR8216/36 line, but there are a lot of major changes as well
<neggles>
qca8k doesn't have any handling for switches without IVL or with major register map differences either; i'm quite sure the correct way to add support would be through qca8k but that's definitely beyond my capabilies
Borromini has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
mattytap_ has joined #openwrt-devel
mattytap__ has quit [Read error: Connection reset by peer]
shibboleth has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
wus has joined #openwrt-devel
Tapper has joined #openwrt-devel
<wus>
greetings. i want to do some https connections from my router and i'd prefer to do this in lua. I have not had much luck in findni documentation about an http client
<wus>
is there a lua http client available with luci or as package? and if so, some usage examples ?
<hurricos>
stintel: would you like a dose of cursed?
<hurricos>
I'd guess all of these devices are just hodge-podged together legacy crap that works becuase an entire team has devoted their lives to it for 40 years
<hurricos>
all things considered, more likely there's some Octeon-I stuff under the hood here
dave14305 has joined #openwrt-devel
dave14305 has quit []
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
Misanthropos has joined #openwrt-devel
Borromini has joined #openwrt-devel
danitool has joined #openwrt-devel
<hurricos>
neggles: good card to retrofit old 3x3 802.11n APs that have PCIe slots with: Yes. That's exactly what I'm planning to do when I get my order of 2xMT7916
<hurricos>
Almost all of those APs are QorIQ which have the spare CPU cycles to shred the cost of oruting
<hurricos>
... err, not routing, just ... the general interrupts you'd expect to come with "too much traffic"
<hurricos>
neggles: Nice to see Aaron Williams posting about OcteonIII again
<Grommish>
Ah ha.. PKG_HOST_ONLY:=1 removes the need for /host calls
<Grommish>
Or apparently not..
<svanheule>
lynxis: didn't know they have a lite mode for 2.5G too. I know they had a 500M mode (Gig Lite), where (IIRC) they use only 2 pairs, but with gigabit-style signalling
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
danitool has joined #openwrt-devel
<schmars[m]>
given i can boot a typical device into tftp by pressing the reset button, would it be okay to leave it pressed? i.e. physically modify it to always be activated? always booting into tftp is desired, i'm just wondering if there are other consequences, e.g. the bootloader becoming responsive only after releasing it, unintentionally booting failsafe from tftp (which might be okay i guess?) or during openwrt runtime. i understand that it's
<schmars[m]>
probably mucho device-dependent
<schmars[m]>
context: thinking about an automated testbed for the devices we use in our network, i think have the power issue figured out, now looking into how deep i can go with the flashing automation
<schmars[m]>
* flashing automation without wearing out the flash to quickly
<schmars[m]>
* flashing automation without wearing out the flash too quickly
<schmars[m]>
(sorry i just realized that matrix chat edits probably look terrible for irc users. let me know and i'll switch to weechat)
<Habbie>
i think you only did one edit, it was not too bad :)
<Habbie>
i've recently also been pondering automating the reset button externally
<Habbie>
i'm sure for some devices (and firmwares) it could just work to press it always
<Habbie>
it sounds like a question the answer to which is easy to find out by trying
<Habbie>
alternatively, a microcontroller and a bit of soldering can go a long way i'd think
arthur_melo has quit []
noltari_ has quit [Read error: No route to host]
noltari has joined #openwrt-devel
<slh>
schmars[m]: on many devices, pushing the reset button while running OpenWrt will invoke a factory reset/ reboot
<schmars[m]>
that could probably be prevented by fiddling with /etc/board.d/03_gpio_switched - neat. guess i'll have to get a poe switch and see where this leads :-)