lmore377 has quit [Quit: No Ping reply in 180 seconds.]
lmore377 has joined #openwrt-devel
Grommish has joined #openwrt-devel
valku has quit [Quit: valku]
decke has joined #openwrt-devel
rmilecki has quit [Quit: Konversation terminated!]
Borromini has joined #openwrt-devel
goliath has joined #openwrt-devel
svanheule has joined #openwrt-devel
Grommish has quit [Read error: No route to host]
Grommish has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
<ldir>
jow: ping - I was not as complete as thought on dnsmasq & ubus functionality - from manpage "It sends notifications via UBus on DHCPACK and DHCPRELEASE events"
Acinonyx_ has quit [Ping timeout: 480 seconds]
* ldir
chuckles at the dnsmasq ubus support patch "Originally written by John Crispin <john@phrozen.org>"
<ldir>
so not really " Julian Kornberger" or not 100% at least
rejoicetreat has quit [Ping timeout: 481 seconds]
rmilecki has joined #openwrt-devel
aleasto has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
<titanous>
nbd: yep that worked, there's a new message in the log "WPA: invalid MIC in msg 2/4 of 4-Way Handshake" but it connected fine
<titanous>
checking some other deviceds
Rentong has quit [Ping timeout: 480 seconds]
<jow>
nbd: not sure what we'd gain by that. For the ui it would complicate things even more. Instead of checking interface->l3_device->is vlan?->parent device->is bridge? it would become interface->l3_device->is bridge vlan?->read option device->is bridge?
<jow>
also possible conflict between actual existing netdevs and "virtual" bridge-vlan names
<jow>
granted, this issue exists for @alias as well but there we claim the entire @.* namespace for aliases, so it can't possibly collide
<nbd>
the idea is to use the name of the bridge vlan as actual netdev name
<nbd>
so same namespace, no conflict
<titanous>
nbd: thanks so much for tracking that patch down! is there anything else you need from me to get that into the tree?
<jow>
ah the vlan interface name
<nbd>
titanous: i'll take care of it, thanks for testing
<titanous>
thanks again!
<nbd>
and for reporting the issue in the first place
* ldir
considers installing lolcat just for a laugh
<nbd>
jow: i'd treat the bridge-vlan like a full device section, including typical device options like mtu
<nbd>
i think it also fits well with the other proposal to have more different section types for different device types
<jow>
I am undecided, ui wise it will complicate things even more. Will likely not be able to implement support for that before Q4
<nbd>
at least in that case you'd have a dedicated type instead of needing to check if a vlan is on top of a vlan bridge
<nbd>
so i'm not sure what makes it more complicated on the luci side
<jow>
- a name must be choosen
<jow>
- uniqueness must be validated
<jow>
- interfaces need to be gathered from even more places
<jow>
- generic device configuration needs to be extended to handle both config device and config bridge-vlan sections in he same grid ui
<jow>
- options must be delegated to the proper section type upon writing
Rentong has joined #openwrt-devel
<jow>
- in addition to uniqueness, user provided name must be tested if conflicting with existing netdevs
<jow>
- vlan config (currently a simple table row) needs to be extended with "additiona settings" modal that exposes all the usual device settings
<aparcar[m]>
zorun: hey. I think I didn't really work on the SDK but changed stuff with signing at the image builder. Did you fix it or should I have aook?
<jow>
- conflicts between config device; option name foo and config bridge-vlan; option name foo need to be prevented
<jow>
and a couple more I likely missed right now
goliath has joined #openwrt-devel
<nbd>
"interfaces need to be gathered from even more places" - i don't understand that point
<jow>
you don't need to
<jow>
that specific point is potentially easy to solve (foo.name || foo.device + "." + foo.vlan)
<jow>
plus the usual pitfalls
<jow>
the biggest ux problem I see is that users are now required to pick names for the vlans they create
<jow>
and that those names need to be unique and must not collide with preexisting names
<jow>
which is kinda hard if dsa already reserves generic names like "wan", "lan1" etc.
<jow>
users will be confused about the role of the vlan name
<nbd>
aside from the implementation difficulties, do you think it's a reasonable config model change?
<jow>
can be potentially dealth with in the ui by prefilling the name
<jow>
I am slightly leaninging towards reasonable, yes. But the naming in your paste is not optimal
Rentong has quit [Ping timeout: 480 seconds]
<jow>
we already migrated ifname to device
<jow>
so bridge-vlan.name should be bridge-vlan.devname or bridge.devicename preferably
<nbd>
it was a quick mockup. we can change the option names
<nbd>
devname seems fine
<jow>
other device types should migrated towards devname too
<jow>
except for the simple device type (the one that applies settings to existing netdevs, instead of creating ones) - there it should be device instead of devname, to signify that we're matching a device, not naming one we're creating
<jow>
that's likely easier to do once different device types use different section types
<jow>
and only simple device remains as "config device"
<jow>
so in the end, whenever we name a devide to be created, it should be devname
<nbd>
i think changing the option based on whether we're matching or creating can make things more confusing
<jow>
whenever we reference a device to use, it should be "device"
<ldir>
rsalvaterra: are there not some more kernel symbols? SYSTEM_REVOCATION_LIST & KEYS ?
<nbd>
depending on the use
<nbd>
for vlan it makes sense, because we will have both
<rsalvaterra>
ldir: Hm… Haven't stumbled on those on my mvebu build.
<nbd>
but it would be good if you can always tell from the devname what the netdev is going to be for that section
Tapper has quit [Ping timeout: 480 seconds]
<ldir>
rsalvaterra: I get suspicious of 'Kconfig' file diffs
<rsalvaterra>
ldir: Let me see…
<jow>
things like macvlan too, there you have device (the base dev) and devname (the macvlan slave if)
<ldir>
rsalvaterra: it's your fault... why have I just built 'lolcat'? :-D
<rsalvaterra>
ldir: I found that tiny C implementation and couldn't resist. :)
<olmari>
Just make sure you're doing remote debugging through ultimate crappy internet at train... and issue 'ls' instead ls
<olmari>
hrhm.. I messed THAT uo.. sl instead ls
<olmari>
Lets just say that few moments later sl was no more (:
<rsalvaterra>
I make lots of typos all the time, but ls -> sl isn't one of them, don't know why… :)
<olmari>
the irony was that this happened literally as I said... train did not like train =)
<rsalvaterra>
ldir: As for SYSTEM_REVOCATION_{LIST,KEYS} I think we're fine. I don't know the policy for the generic kconfig, are they supposed to contain *all* the disabled symbols? jow?
Rentong has quit [Ping timeout: 480 seconds]
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Borromini has quit [Ping timeout: 480 seconds]
<ldir>
rsalvaterra: you can add my ack for the kernel bump - X86_64 on apu2 hasn't exploded
<rsalvaterra>
ldir: Thanks! :)
<rsalvaterra>
ldir: apu2c4?
<ldir>
can't remember
goliath has quit [Quit: SIGSEGV]
<ldir>
it's got 4GB ram, 16GB SSD
<ldir>
sits there running CAKE which is a cpu hog
<rsalvaterra>
ldir: I think it's the production machine I have (at the office) with the most overkill amount of RAM. I'm only using about 70 MiB of it. :P
<ldir>
I'm pushing the limits of mine 188MiB used ;-)
<rsalvaterra>
I'd gladly trade 3/4 of the RAM for 4x the CPU power. :P
<philipp64|work>
stintel: it’s not been announced because they’ve been having problems getting the homologation testing done for certification, is my understanding…
<philipp64>
stintel: last I heard was there was an assembly error (that was mid January). I just pinged them again about it.
<philipp64>
someone remind me Vincent's IRC handle?
<philipp64>
of course, GPON-on-a-stick is simultaneously a terrifying concept... that the PHY has that much intelligence, also means that it could do all sorts of shit to your data (including cloning interesting packets and sending them to China) and you'd never know about it, if the amount of stolen bandwidth were low enough... they don't make optical packet sniffing taps (for better or for worse) so you couldn't watch it at the physical layer.
Rentong has joined #openwrt-devel
<philipp64>
At least with smart NIC's, you can put a switch's port into mirroring mode and watch your own traffic for unexpected streams...
<philipp64>
Rentong: are you having some sort of issues we could help you with?
Rentong has quit [Ping timeout: 480 seconds]
<philipp64>
guess not.
<philipp64>
Anyone know what the names are for all of the allowed "types" of RHS's for "option" fields in UCI in the wiki? There's string, and bool... but there's also flavors of strings... IP addresses, netmasks, interface names... are integers considered "strings [of digits]"?
<philipp64>
Would be nice if we had "config_get_xxx" that did more sanity checking...
<philipp64>
But that might be trying to get more functionality out of that model than we can reasonably do...
Tapper has quit [Ping timeout: 480 seconds]
SamantazFox has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 481 seconds]
valku has joined #openwrt-devel
kpoman has joined #openwrt-devel
<kpoman>
Hello everyone ! May I ask couple tips about creating a new package ? I am trying to build ntopng for my rpi4 and have couple questions. Already created a Makefile, download, setup some of the dependencies. It is not creating/calling configure nor building. I do see the build tool creates .configured_68b329da9893e34099c7d8ad5cb9c940 but no configure nor Makefile on the build dir.
Tapper has joined #openwrt-devel
bluew has joined #openwrt-devel
<PaulFertser>
kpoman: how is it supposed to be creating configure? By calling autoreconf?