danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Tusker has joined #openwrt-devel
slh has quit [Ping timeout: 480 seconds]
<plntyk>
xdarklight, hauke : while debugging i also saw CONFIG_PANIC_ON_OOPS_VALUE=1 set in target/generic/config which wasnt that useful for reading the message on non-serial terminal
<plntyk>
some inconsistency there too with other targets set that to =0
<digitalcircuit>
(I carbon-copied Ansuel via the Cc field in my mail client)
blogic_ is now known as blogic
Rentong has joined #openwrt-devel
rmilecki has joined #openwrt-devel
<slh>
digitalcircuit: weird, I haven't gotten it in my list inbox yet, so only judging from the mailing list archive, it would have been better to mention the crash fix above the --- delimiter, but that might be fixed up by the committer (/might/), the really important things seem to be fine (untested). but please keep an eye on stability/ stress testing, as it might still not be the real reason behind your
<slh>
issues
<digitalcircuit>
slh: Ah, good point, thank you! I wasn't sure how much the cherry-picked commit could be edited; in hindsight I could've put a lot moe detail in. And I'll continue to monitor stability and stress testing (with and without SFTP upload test). Unfortunately the power company had an outage today, interrupting uptime, but otherwise no reboot yet. I'll keep testing until this gets merged (including rebasing new builds as needed).
dedeckeh has joined #openwrt-devel
<digitalcircuit>
slh: In your opinion, would it be worthwhile submitting a "PATCHv2 21.02" to fix up the commit adding the crash rationale, link to issue, etc?
<slh>
digitalcircuit: give others at least a day to comment
<digitalcircuit>
slh: Makes sense! And thank you for your patience and guidance - this is new territory for me.
Tapper has joined #openwrt-devel
m has joined #openwrt-devel
coltect_ has joined #openwrt-devel
coltect_ has left #openwrt-devel [#openwrt-devel]
decke has joined #openwrt-devel
goliath has joined #openwrt-devel
Ycarus has quit [Read error: Connection reset by peer]
Ycarus has joined #openwrt-devel
danitool has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
<digitalcircuit>
To anyone following here, I'm also open to attempting to try different workloads or other sorts of regression testing, too. I should have mentioned that in my bug report comment (edited it to add that).
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
<jow>
nbd: most device specific settings, such as txqueulen, mac, mtu, ipv6 (the low level sysctl), rp_filter, icmp_redirect etc. are only available for untyped "config device" sections in netifd
<jow>
nbd: in case one wants to apply these settings on a declared device (e.g. 8021ad, bridge, macvan, ...), two device sections are needed
<jow>
nbd: once config device; option name xxx; option type ...; ... to declare it and once config device; option name xxx; ... to apply generic device settings on top of it
<jow>
nbd: do you think it makes sense to let the various netifd device types (bridge, 8021q, 8021ad, macvlan, veth, ...) inherit the generic device settings?
<jow>
this way the two distinct required device sections could be unified into one
<jow>
a specific issue that prompted me to think about that is the ability to change the mac address of vlan interfaces
<jow>
in case a vlan interface is declared as config device; option type 8021q/8021ad, a second config device without type is needed just to apply the mac
<jow>
I also considered simply adding option macaddr to the 8021q and 8021ad device types, as less invasive solution
Rentong has quit [Ping timeout: 480 seconds]
<jow>
that likely covers 80% of the use cases
<nbd>
jow: there is inheritance for device options already
<jow>
there is?
<jow>
hmm
<nbd>
so if that doesn't work, there's a bug somewhere
<rmilecki>
jow: there is that uci extend thing
<jow>
let me try
<jow>
that would simplify some ui things considerably
<rmilecki>
jow: .next = { &device_attr_list },
<rmilecki>
jow: you have that in vlandev.c and veth.c
<jow>
probably makes sense to hide the mtu option for 8021q and 8021ad types in the ui
<rmilecki>
alias.c is has no params
<rmilecki>
bridge.c: has .next = { &device_attr_list }
<rmilecki>
macvlan.c: has .next = { &device_attr_list }
<rmilecki>
veth.c: has .next = { &device_attr_list }
<rmilecki>
vlan.c: has .config_params = &device_attr_list (doesn't extend, just limits to device attrs)
<rmilecki>
vlandev.c: has .next = { &device_attr_list },
<jow>
rmilecki: yep so basically all, alias is special and out of scope here
<rmilecki>
i believe so
<jow>
afair you cannot declare it in the config anyway
<jow>
its an internal type
Rentong has joined #openwrt-devel
<jow>
ah the mtu on vlan interfaces can be set, but it must not exceed the mtu of the parent interface
<lemmi>
which is *really* annoying in some cases. if you also set the mtu for the parent interface accordingly, other vlans will inherit that same mtu if not set explicitly
Rentong has quit [Ping timeout: 480 seconds]
<jow>
lemmi: yep, but on the other hand it also makes sense when thinking about it, frames emitted by vlan devices are sent over the parent device physically, so you would not want them exceed the parent interface's limit
<lemmi>
actually i don't think it makes a lot of sense
<lemmi>
what would makes sense is that all interfaces need to be withing the hardware's limit and that's it
<jow>
and I think that all logical sub-interfaces should be withi nthe configured main interfaces limit, which also seems the approach the kernel guys opted for. Basically hierarchical enforcement of the mtu limit
Rentong has joined #openwrt-devel
<lemmi>
to bad you often don't get a choice to skip the hierarchy
feriman has quit [Quit: WeeChat 3.2]
<lemmi>
and to me, it's that hierarchy that doesn't make a lot of sense
<jow>
yeah, I guess both approaches have their upsides
<jow>
intuitively I wouldn't expect a "sub ressource" to be able to exceed the limits of the "parent ressource", generically speaking
<lemmi>
it would be sooo convenient to be able to do that. because that way the untagged interface could stay plug-and-play and just work in all environments and then have a separate local vlan with large mtu for your network filsystem/tunnels whatever
<lemmi>
you could potentially emulate this by setting the mtu high on the interface, add macvlan interface to it and force that to 1500 and use that as the untagged thingy
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
<rsalvaterra>
jow: About MTU, that's actually something I've meant to ask for a while… Let's say I want to increase the MTU on a one-armed router. Should I increase it on the network interface, the switch ports, or both?
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<aparcar[m]>
nick: I think babeld is the way to go, everyone seems to like that and even though I really like BMX6/7 the development is de facto non existent. Would be nice to see some best practices from the different Freifunk communities and see what they came up with. Ideally we pack things together as modular packages and provide them via freifunk.git
<aparcar[m]>
I don't have a mesh community on hawaii but I could spin up some devices to test things
<nick[m]4>
aparcar: haha, I always thought that would be some "fake place". Now I'm a bit jealous *.*
<nick[m]4>
what do you mean with " freifunk.git" ?
<nick[m]4>
something under the hood of openwrt, or us?
<aparcar[m]>
so I can just install freifunk-bremen and it pulls in some dependencies
<nick[m]4>
aparcar: that is some kind of problematic, since we first have to "re-unite" with that package feed again. We forked, since the package feed was not building with openwrt, and the one developer was against it to revert changes that broke the building process
<Dandel>
plntyk, That would be useful, but i am looking at linkus ea9500v2 which is close to the Asus GT-AC5300 but with some minor nuance differences ( Nand, flash, and some other potential items )
rejoicetreat has quit [Remote host closed the connection]
m has joined #openwrt-devel
<plntyk>
Dandel, look at the commits for that target and find out if components are usable - some bcm stuff has unsupported wlan chips
feriman has quit [Ping timeout: 480 seconds]
<Dandel>
From what I can tell, The open source archive includes full source code to the wifi chips used in my router
mm has joined #openwrt-devel
<mm>
Ping
<m>
Pong
mm is now known as Guest2524
Guest2524 has quit []
<plntyk>
when doing support for new hardware you likely need serial console access too
<rmilecki>
Dandel: you must be careful with cferam
<rmilecki>
Dandel: if you flash firmware with wrong JFFS2 partition or with JFFS2 partition containing wrong cferam, you'll brick your device
<rmilecki>
Dandel: so extract proper cferam, submit it to the bcm63xx-cfe repo
<rmilecki>
Dandel: build firmware and verify it has a valid JFFS2 partition with correct cferam
<Dandel>
I have access to the original firmware update image.
Rentong has quit [Remote host closed the connection]
nitroshift has quit [Quit: Gone that way --->]
<Dandel>
rmilecki, what is the command I use to extract the cferam?
<rmilecki>
Dandel: i use jefferson
<rmilecki>
it's python script
<rmilecki>
Dandel: also get the latest vendor firmware to make sure you extract the latest cferam
<Dandel>
I have the latest firmware for my device. Where do i get the script?
Rentong has joined #openwrt-devel
Tusker has quit [Quit: Time wasted on IRC: 10 hours 5 minutes 37 seconds]
netprince__ has joined #openwrt-devel
netprince has quit [Ping timeout: 480 seconds]
<rmilecki>
Dandel: did you try google?
<rmilecki>
"jefferson jffs2"
<Dandel>
Yes, I thought jefferson was a utility for the broadcom cfe
<Dandel>
I extracted the image. Should I also upload 94908.dtb as well? this may be useful for finding some other values.
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
<Dandel>
I haft to go for a while. I was able to get the cferam file out of the version 2.1.1.186574 firmware located at https://www.linksys.com/us/support-article?articleNum=198573 ( not exactly sure how to analyze the cferam.000 file yet )
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Dandel has quit [Quit: Page closed]
Larhzu has quit [Quit: leaving]
danitool has joined #openwrt-devel
Rentong has joined #openwrt-devel
decke has quit [Quit: Leaving.]
Rentong has quit [Remote host closed the connection]
Tapper has quit [Quit: Tapper]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
<neoraider>
aparcar[m]: pong - just ping me again when you're back
feriman has joined #openwrt-devel
feriman has quit [Read error: Connection reset by peer]
feriman has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
valku has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
<rsalvaterra>
This is probably a great example of how not to submit a driver upstream. :P
AdrianFL has joined #openwrt-devel
AdrianFL has quit []
<wb9688>
One commit per file is stupid imho
<rsalvaterra>
It's not just stupid, it's downright harmful. It completely breaks bisectability, as one of the first commits is the makefile. *facepalm*
<PaulFertser>
Hard to believe it's not a joke. How one can write a functioning wireless driver for Linux without understanding git commits?
<rsalvaterra>
Also, RFC v1, with 256 patches? That's more than most stable kernel releases!
<rsalvaterra>
(I must say I like the number, though.)
<rsalvaterra>
PaulFertser: That's what I'm complaining about. If you write a driver and open source it, I want to see the development history. I want to know the rationale for each and every change that was made.
<rsalvaterra>
Oh, well… I'm just looking forward to reading the replies.
* rsalvaterra
fetches the popcorn
<jow>
rsalvaterra: well, there can't be any reviews because "Any retransmission, dissemination, copying or other use of, or taking of any action in reliance upon this information is prohibited."
<jow>
I like those stupid standard disclaimers :)
<rsalvaterra>
LOOL!
<rsalvaterra>
Really, you can't make this crap up… :D
<jow>
it's priobably not that poor guy's fault, likely the company smtp gateway adding that crap
<jow>
and another company policy to only use company mail addresses :P
<PaulFertser>
rsalvaterra: submitting for review is performed without the development history usually, patches are squashed beforehand.
<rsalvaterra>
PaulFertser: Sure, when (and only when) it makes sense to squash them. A new driver is a contained piece of software, so it shouldn't need to be broken up in a lot of commits.
<rsalvaterra>
jow: Yeah, but people contributing to Linux should at least know how to do it correctly. It's not for lack of documentation, for sure.
<jow>
the specs read interesting on paper though
<rsalvaterra>
Like, "oh, the SMTP server stamps the legal boilerplate, I need to talk to the sysadmin to avoid it for upstream contributing accounts".
<rsalvaterra>
jow: Yep, the specs look interesting. I hope the firmware doesn't do a lot.
Rentong has joined #openwrt-devel
<jow>
... and that this chip is obtainable in a minipcie / pcie form factor
<jow>
or as part of a supportable soc
<rsalvaterra>
jow: Great, but I don't think my Omnia has the oomph to drive it at full blast… :)
<rsalvaterra>
This ElasticMIMO thingy looks really nice too…!
<rsalvaterra>
Is this proprietary stuff, or a trade name for some generic 802.11ax feature that I've missed?
Rentong has quit [Ping timeout: 480 seconds]
<rsalvaterra>
The doppler imaging is scary, though.
m has quit [Remote host closed the connection]
<xdarklight>
nbd: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=a603e82dd342680d584c4eb5f1b222e056379890 seems to work fine for me as well - thank you!
Tapper has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
<ldir>
anyone know if the 'login/session' timeout of luci can be configured ?
Rentong has quit [Ping timeout: 480 seconds]
<hauke>
I took me 1 or 2 months to be able to send mails to external addresses in text format without legal disclaimer
<wb9688>
"The RFC is divided into separate patches on a per-file basis to simplify the review process."
<wb9688>
Just no…
dorf has joined #openwrt-devel
<hauke>
I think the split into one patch per file was requetsed for some initial driver submissions
<wb9688>
Oh, interesting
<hauke>
I think it was ath11k, it was applied as one patch later
<aparcar[m]>
mangix: ping
<mangix>
aparcar[m]: pong
<aparcar[m]>
mangix: ideas regarding /usr/bin/ld: /home/user/src/openwrt/openwrt/staging_dir/host/lib/libcrypto.a(libcrypto_la-err.o): undefined reference to symbol 'pthread_once@@GLIBC_2.2.5' ?
<blocktrron>
rsalvaterra: quantenna also does this motion / presence detection bs
<mangix>
Sounds like a missing link to lpthread
<aparcar[m]>
neoraider: ping
<aparcar[m]>
mangix: how do I do that for a hots build?
<rsalvaterra>
blocktrron: Oh, balls.
<mangix>
HOST_LDFLAGS ?
<blocktrron>
WOndering why all set-top boxes and CPEs from the two biggest german ISPs are based on either of these two
<blocktrron>
(Although this might sound a bit of conspiracy-ish)
<rsalvaterra>
blocktrron: In Germany, of all countries…? o_O
<rsalvaterra>
blocktrron: Eh… Here in Portugal the vast majority of CPEs are Technicolor, all Broadcom-based.
<blocktrron>
the cheap stuff is bcm
<aparcar[m]>
neoraider: I've sent you and some other mesh people a email a week ago or so, I'd be curious where freifunk and specifically gluon is heading and if things can be done in a compatible way. Not sure where would be the right channel to have this discussion. I remember talking to you some 3 years back at some 2xC3 about that
<rsalvaterra>
ONTs are usually Huawei.
<wb9688>
Intel Puma unfortunately also existed…
<neoraider>
Ugh... I have a really crappy Technicolor cable modem. Glad I could disable the router functionality and use my own OpenWrt box, the modem implements NAT so badly that I lost IPv4 connectivity on a regular basis
<rsalvaterra>
Uh… I have a Puma-based Hitron cable router… demoted to bridge, of course.
<neoraider>
aparcar[m]: I still intend to answer, I should be able to get to it this weekend
<aparcar[m]>
neoraider: great thanks :)!
<blocktrron>
Let's at least hope their driver doesn't go the way qtnfmac went
<blocktrron>
With driver ending up upstream, company being bought, firmware never released
<rsalvaterra>
Oh, so that's what happened to qtnfmac…! I liked their chips on paper, they looked really neat.
<hauke>
based on the last comments it looks good to me
KGB-2 has quit []
KGB-2 has joined #openwrt-devel
valku has quit [Quit: valku]
_lore_ has quit [Ping timeout: 480 seconds]
KGB-2 has quit []
Borromini has quit [Quit: leaving]
KGB-2 has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<xdarklight>
hauke: I backported v1 of that additional memory leak fix and Aleksander sent a v2. so either I backport v2 or we wait for the next stable release which includes these fixes
<hauke>
xdarklight: ok
<hauke>
I am fine with both versions
<slh>
hauke: I just (successfully-) used failsafe on a BTHub5 (master/ swconfig) yesterday (with a ~24h old build); master/ DSA seems to work for me on the O2 Box 6431 (it's my play-around system for DSA)
<hauke>
ok then it looks like it is only broken on some devices in 21.02.0-rc3
<hauke>
for me it does not work on ath79
<xdarklight>
hauke: I'll update the pull request tomorrow or on Saturday with v2 of Aleksander's patch and ask people to confirm that everything works equally good or better compared to the swconfig driver
<stintel>
hauke: and the hifive unmatched is waiting for me in the FedEx depot in Sofia until I return from visiting my family for the first time since the pandemic
Tapper has quit [Quit: Tapper]
<karlp>
whats the plan for 20? i know youre not in teaching
<karlp>
youre not putting them all in the north sea are you?
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
mangix has quit [Remote host closed the connection]