dorf_ has quit [Remote host closed the connection]
<aparcar[m]>
okay looks good to me
<aparcar[m]>
btw zoneinfo isn't really installed per default anyway right?
<aparcar[m]>
Ugh well now that you linted the file that should go into the commit message sorry
<mangix>
added
Tusker has joined #openwrt-devel
<mangix>
and no it is not
<mangix>
it is by default with TurrisOS
dorf_ has joined #openwrt-devel
<aparcar[m]>
oh Turris
<aparcar[m]>
I need to tlak to the autoupdater person
<mangix>
what happened?
<aparcar[m]>
I'd prefer the person would help me with ASU rather than cooking their own soup
goliath has quit [Quit: SIGSEGV]
<mangix>
OTOH they've been reducing the amount of custom stuff they have and upstreaming it
<mangix>
TurrisOS 3 was a disaster.
<aparcar[m]>
not sure, never used it
<aparcar[m]>
they should get in touch
<mangix>
aparcar[m]: anyway, I'm not subscribed since the list is mostly noise. I've also noticed that patches go on there to die. GH ones have a higher chance of getting merged. It
<mangix>
's also easier to make changes.
<mangix>
as you just saw with my 5 force pushes.
<aparcar[m]>
yea I noticed
<aparcar[m]>
please close the patch on patchwork then
<mangix>
as it is, it's quite a large patch. Some extra cleanup could be done as well.
<aparcar[m]>
mangix: I'll think about it
danitool has quit [Ping timeout: 480 seconds]
Rentong_ has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
madwoota has joined #openwrt-devel
madwoota has quit [Remote host closed the connection]
Tapper has quit [Quit: Tapper]
madwoota has joined #openwrt-devel
madwoota is now known as Guest387
Guest387 is now known as madwoota
rmilecki has joined #openwrt-devel
valku has quit [Quit: valku]
nitroshift has joined #openwrt-devel
Borromini has joined #openwrt-devel
m has joined #openwrt-devel
<rmilecki>
jow: could you cherry-pick 01eac366f69ba58c090ddc2cb70aeb069adbdd5a ("luci-mod-network: fix tagging/pvid state parsing in bridge-vlan ports")
dedeckeh has joined #openwrt-devel
decke has joined #openwrt-devel
* rsalvaterra
wakes up and looks at the inbox…
<rsalvaterra>
I see most of the fun happens when I'm asleep. :P
<rsalvaterra>
mangix: Thanks for the heads-up, I'll drop the umdns patch.
<rmilecki>
rsalvaterra: did you manage to find that Atheros router / pcie card?
<rsalvaterra>
rmilecki: Yes, the card. Of all places, in olx.pt(!). Should receive it today or tomorrow. :)
<rmilecki>
great :)
<rsalvaterra>
20 € including shipping… not great, not terrible. :P
<russell-->
well, that went better than expected ... just replaced a 32MB dram chip on a ubiquiti bullet m5 with an apparently pin-compatible 64MB dram chip and in the smoke test, it booted up and is running fine with double the ram
<rsalvaterra>
russell--: Nice! Is that XM or XW?
<russell-->
this one's an xm
<rsalvaterra>
Oooooooh, sweet! I have an AirGrid M2, also XM! :D
<PaulFertser>
I would suggest to add some Pb solder to all the joints before desoldering, that will lower the needed temperature so less chances to lift the trace.
<russell-->
yeah, i did
<russell-->
or, i would have suggested that myself but i'm not sure now whether i did at that step, lol
<russell-->
but, yes, i agree, whether i did or not, that would have been smart
<PaulFertser>
What temperature was set on the air blower?
<blocktrron>
aparcar[m]: I'm aware of that. I had a long day yeterday
<russell-->
i warmed it up at 200°C, the cranked it up to 360°C, iirc
<russell-->
then*
<PaulFertser>
Should have been enough to melt all the Pb-free solder there, it's odd you lifted a trace. Great to hear you managed to fix it though.
<russell-->
it took a few minutes melt
<russell-->
i just watched a couple youtube videos for technique and gave it a whirl
<russell-->
next time i'll add some pb solder though
<PaulFertser>
When desoldering I usually set it at about 350, flow to the minimum and do not use any tape or foil, just heat it all up and be careful to not jerk the board.
indy has quit [Read error: Connection reset by peer]
indy has joined #openwrt-devel
m has quit [Read error: No route to host]
m has joined #openwrt-devel
goliath has joined #openwrt-devel
m has quit [Read error: No route to host]
<aparcar[m]>
blocktrron: thanks
_lore_- has joined #openwrt-devel
_lore_ has quit [Read error: Connection reset by peer]
_lore_- is now known as _lore_
ashkan has joined #openwrt-devel
rejoicetreat has joined #openwrt-devel
Weasel___ has quit [Ping timeout: 480 seconds]
SamantazFox is now known as Guest411
SamantazFox has joined #openwrt-devel
Guest411 has quit [Ping timeout: 480 seconds]
Borromini has quit [Ping timeout: 480 seconds]
Weasel___ has joined #openwrt-devel
Weasel___ has quit [Ping timeout: 480 seconds]
rejoicetreat has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
Rentong_ has quit [Remote host closed the connection]
<karlp>
we got a board pre-heater here recently, it's made things muchhh nicer, almost as big as the change moving to hot air in the first place
robje has quit [Quit: WeeChat 3.2]
robje has joined #openwrt-devel
Tapper has joined #openwrt-devel
Rentong has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
Rentong has quit [Ping timeout: 480 seconds]
Borromini has quit [Quit: Lost terminal]
ashkan has quit [Quit: Konversation terminated!]
aleasto has joined #openwrt-devel
Weasel___ has joined #openwrt-devel
Rentong has joined #openwrt-devel
greearb__ has quit [Ping timeout: 480 seconds]
greearb_ has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
greearb_ has quit [Ping timeout: 480 seconds]
greearb_ has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
nitroshift has joined #openwrt-devel
Tusker has quit [Quit: Time wasted on IRC: 12 hours 52 minutes 48 seconds]
rejoicetreat has joined #openwrt-devel
valku has joined #openwrt-devel
aleasto has quit [Remote host closed the connection]
plntyk 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 [Remote host closed the connection]
Rentong has joined #openwrt-devel
Tapper has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
jlsalvador has quit [Read error: Connection reset by peer]
jlsalvador2 has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
rejoicetreat has quit [Remote host closed the connection]
jlsalvador2 is now known as jlsalvador
Rentong has joined #openwrt-devel
decke has quit [Quit: Leaving.]
danitool has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
rejoicetreat has joined #openwrt-devel
<rsalvaterra>
aparcar[m]: That zram-swap pull request is too Rube Goldberg-ish for my taste, to be honest… see my last comment. :/
dedeckeh has quit [Remote host closed the connection]
<jow>
nbd: I don't think we actually agreed on this part ;) you insist on believing that simply chosing a network simplifies ui/ux, I don't
<jow>
first of all I now have to filter eligible target networks/interfaces by their device
<jow>
then I need to resolve the base device of all the referenced devices
<jow>
for that I need to pull in a lot of runtime state
<jow>
also the fact the wireless operates on an entirely different layer (attached to a layer 3 config which somehow magically resolves to a layer 2 device and automagically guesses vlan settings) vs. how wired bridge ports are handled (attached to devices, totally unrelated to interfaces) is confusing
<jow>
my opinion still is that having an "option bridge" in config wifi-iface would be much cleaner
<jow>
and attempting to use "option network" against an interface that already has an l2 dev should be a rejected as invalid configuration
<jow>
can't even simplify the presentation of the current uci configuration. In the past I could allow users to chose wireless bridge ports in the same ui spot where you select wired ports and then arrange stuff as needed behind the scenes
<jow>
this does not work anymore since now I would need to resolve the layer2 bridge being configuried to a layer3 interface referencing it to write that as option network into the wifi-iface
<jow>
but that is not possible since there might be zero, one or even multiple interfaces referencing a bridge directly or indirectly (through @ or bridge.vid)
<jow>
so it is ambiguous and I can only instruct users to setup their wireless bridge memberships elsewhere, using an entirely different mechanism
<jow>
if this is how people expect stuff to work then fine. Personally I find it confusing
<jow>
option network in its currnet form totally makes sense for standalone interfaces (meaning ifaces not being a bridge), for that it is clear and intuitive
<nbd>
when we talked, i remember you saying that a lot of complexity goes away if you simply let the user select any network configuration and we add support for printing proper error messages when an invalid config was selected
<nbd>
i guess most of our differences come from the fact that netifd presents a different level of abstraction than what you want to implement in luci
<jow>
possibly, but evne leaving LuCI aside I find it confusing that a given wireless config either works or results in undefined/not working behaviour depending on the nature of the target *interface*'s layer 2 *device*
<jow>
which is even more confusing when taking vlan notation into account
<jow>
and the fact that bridges can be freely named and do not necessarily have a "br-" prefix anymore
<jow>
so you have one config interface; option device eth0.10 and one config interface; option device foo0.11 where foo0 happens to be bridge
<jow>
the former is no valid target for wifi-iface.network while the latter is
<jow>
this is not apparent from reading the config and requires system runtime state to disambiguate
<jow>
note that I am not demanding to change / revert / prevent that for now, but I also do not think that this is a viable long term solution for a somewhat intuitive and self-describing configuration
<nbd>
quite a few aspects of the current config model treat things like vlan device on top of a bridge with vlan enabled as implementation details that should be confined ideally just to one place in /etc/config/network
<nbd>
preferably in the future also described in a more abstract way
<nbd>
so that in other places you can simply say, this wifi interface belongs to the LAN network
<nbd>
or this service should listen on WAN
<nbd>
without having to think about what the vlan id is, if it should be tagged or untagged, etc.
<nbd>
and if we clean up the current config data model, i'd ideally like to move it further away from putting things like switch0.1, eth0.5, etc. everywhere
<nbd>
it should still be possible to configure things in this way for people that are intimately familiar with linux networking and want the most direct mapping to their config
<nbd>
but i think it shouldn't be the default mode
<nbd>
right now things are a little bit inbetween in a few places
<nbd>
which is where i think most of the friction comes from
danitool has quit [Ping timeout: 480 seconds]
<nbd>
another thing regarding luci:
<nbd>
i think one feature that would be really helpful for users (and could potentially also make some extra validation unnecessary) is being able to click "test configuration" instead of fully appliying it. that mode should apply the config, run it for something like 60 seconds, collect all error information from network configs and ask the user to confirm for making the changes permanent
<nbd>
so if the user chooses to select a network for a wifi interface that doesn't work (because it does not support bridging), the test would catch that and show the user a meaningful error message
minimal has joined #openwrt-devel
<jow>
luci already does that since a year or so
<jow>
if you apply a config that causes the device to become unreachable it'll get reverted
<nbd>
i mean combining that with collecting error messages from network interfaces
<nbd>
and presenting those to the user
<nbd>
of course i'd have to add some better error reporting support to netifd for that
<nbd>
so after test it would say "the following errors were found in your configuration" and ask "confirm" or "edit" or "revert"
<jow>
I'm not really fond of that "throw config against the wall, see what sticks" approach
Rentong has quit [Remote host closed the connection]
<jow>
but sure, if there's error info available in a structured manner it can certainly be exposed
<nbd>
i think for simple things, validation in the UI makes sense. but for more complex interactions, i think the ui shouldn't try too hard to second guess what configs might be valid or not
<nbd>
it's a significant source of complexity
<nbd>
better to just have the more complex validation happen in a single place
<nbd>
i.e. where it's used
<nbd>
another idea would be to implement a test mode in netifd
<nbd>
that validates a config without making any runtime changes
<nbd>
that would be quite a bit of work though
floof58 has quit [Remote host closed the connection]
<olmari>
Minenfirst guts said that UI shouldn't offer invalid things where possible to avoid, freeform textfield is wholly another thing then
<nbd>
i think it's a tradeoff
<nbd>
if something can easily be validated from the ui without adding too much complexity, it's certainly worth doing so
<nbd>
but if something is hard to validate and the validation keeps getting more complex, it may not be worth carrying the extra development/maintenance burden
<nbd>
especially when it's primarily about hiding a few entries from a dropdown menu
<olmari>
Well.. for example an interface that can't be bridged shouldn't be offered in list (box, ticks) that defines interfaces to ve bridged, etc
floof58 has joined #openwrt-devel
<olmari>
And no, I'm not saying 100% accuracy can always exist, but ought to be goal to aim
Rentong has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<olmari>
From new job I've gotten into, I have to say so far OPNsense webui handles that part very well, while general desing is not always perfect
<nbd>
jow: what do you think about naming bridge-vlan sections, making it possible to reference them from interfaces, and supporting the hotplug magic only for those references
<olmari>
In general past I've also been very pleased with OpenWrt luci, so thank you for that
<nbd>
i think that would make a lot of sense semantically and should make validation easier for you
<olmari>
Maybe that's why this discussion "scares" me sn bit :P
<olmari>
An*
<jow>
nbd: would need to think about it
<nbd>
sure
Rentong has quit [Ping timeout: 480 seconds]
<nbd>
olmari: i'll take a look at OPNsense
<olmari>
At places it is kinda cumbersome (the opnsense ui), defining vlan is done first, then you can make interface having the vlan in it.. then again even most massive clusterfuck of networking definitions finds fast in ui selector and no misstatgets exists
<olmari>
I inherited technival polyuni networking onto my main joblist, lets just say there is alot of it (:
<ldir>
hmmm Isäntänimi
Tapper has joined #openwrt-devel
<nbd>
jow: internally we could make the bridge vlan a kind of device type
<nbd>
possibly even expose a way to explicitly bring it up and down
<russell-->
looks like i declared victory on my soldering job a little prematurely, despite booting and running for a while, getting some random segfaults and other anomolies, so ... more microscope time ;)
* rsalvaterra
is still waiting for RGB LED support for his Omnia…
<mangix>
rsalvaterra: I thought that was upstreamed
<rsalvaterra>
mangix: The device tree, yes. The multicolour LED framework, yes. The Omnia LED driver, no. :(
<mangix>
weird.
<rsalvaterra>
mangix: The Omnia is weird. The LEDs can be both hardware and software controlled. Software has more flexibility, hardware frees up the CPU but can't do everything. I think upstream wants a driver which is able to offload to hardware what the hardware can support.
<mangix>
rsalvaterra: so what is this hw buffer management?
<mangix>
and does it make bufferbloat worse? :)
<rsalvaterra>
Oh, I think that works as a kind of page cache for the NICs.
<rsalvaterra>
I haven't noticed any difference in bufferbloat.
<mangix>
I remember commits by __lore__ adding support for XDP. Require software buffer management though.
<rsalvaterra>
If you need to keep bufferbloat under control with, say, cake SQM, hardware (and software) *flow* offloading need to be disabled. Which makes sense, flow offloading tries to avoid NAT lookups, cake does NAT lookups to identify the flows. :P
<rsalvaterra>
mangix: XDP is beast I haven't dealt with yet, but I definitely remember that commit, for sure.
<mangix>
I'm looking at the commits for mvneta right now. It's still being worked on and optimized. That's nice.