<f00b4r0>
simzon[m]: out of curiosity, have you tried using a bridge-vlan style configuration instead? I'm using this and haven't seen the bug described here ever since.
totkeks has joined #openwrt-devel
* russell--
noticed a mesh-point association regression on archer c7 (2.4GHz) somewhere between efc0c4666b5a and 730db6b89374 ... with 730db6b89374 same configuration doesn't connect to other devices on efc0c4666b5a
* russell--
is going to try to duplicate the problem under more controlled conditions
<simzon[m]>
<f00b4r0> "simzon: out of curiosity, have..." <- I think i tried few months ago, without success. But maybe i have to try again. What bugs me on this is why this is the "default" setup in uci-defaults, if not well supported.
<simzon[m]>
s/without/to/, s/success/have many vlan-uware bridges having the dot1q interfaces as members/, s/./:/
<SwedeMike>
/win 2
<SwedeMike>
oops
nixuser has quit [Remote host closed the connection]
dannyAAM has joined #openwrt-devel
gromero_ is now known as gromero
dannyAAM has quit [Ping timeout: 480 seconds]
totkeks has quit [Ping timeout: 480 seconds]
dannyAAM has joined #openwrt-devel
valku has joined #openwrt-devel
nixuser has joined #openwrt-devel
dannyAAM has quit [Ping timeout: 480 seconds]
skynet2 has joined #openwrt-devel
skynet2_ has joined #openwrt-devel
skynet2 has quit [Ping timeout: 480 seconds]
skynet2 has joined #openwrt-devel
<f00b4r0>
simzon[m] not sure what "default setup" you're talking about. Using VLANs isn't a default setup in DSA configs.
skynet2_ has quit [Ping timeout: 480 seconds]
<f00b4r0>
your snippet is missing "option vlan_filtering '1'" on the bridge device as well as the list of ports comprising that bridge. Not sure if it makes a difference but in the bridge-vlan sections, 'ports' is nominally a 'list' not an 'option'
<efahl>
aparcar[m]: I'm thinking don't show any targets for a release until they all build, in fact, don't even show the release until then
dryimpact3 has joined #openwrt-devel
<aparcar[m]>
firmware selector already shows only devices that are in fact available
<aparcar[m]>
so what we could do is that the firmware search checks first .versions.json and if a new version is in there, check if a profile file exists for that version
<ukleinek>
(and only show the release once)
<aparcar[m]>
only then really susggest it
dryimpact has quit [Ping timeout: 480 seconds]
dryimpact3 is now known as dryimpact
<aparcar[m]>
that requires minor rewrites of owut and luci
<aparcar[m]>
but prevents people from seeing updates that arent there yet
<aparcar[m]>
efahl: also I'm somewhat a fand of shifting away from the /json/v1 stuff, it's now all available upstream, it should always be used instead. that drops lots of legacy code form ASU
<aparcar[m]>
efahl: would you be okay to do those code changes?
<efahl>
sure. I need specifics, replace the json/v1/overview with .versions.json and some other things?
<efahl>
The 'package_changes' is really the only data that's known only by the ASU server.
<aparcar[m]>
exactly
<efahl>
And there's some pretty scary stuff related to aggregating packages from indexes using that kernel version stuff for the kmods.
<aparcar[m]>
what do you mean?
<aparcar[m]>
the kernel verison is also part of the profiles.json
<efahl>
Locating the feeds for the kmods requires knowing the kernel version, building the file names and all that.
<efahl>
Only applies to snapshot builds, so you need to parse the version id, too, to know that.
<efahl>
All that stuff I added in 'is_post_kmod_split' in util.py...
geekythings has joined #openwrt-devel
<efahl>
The two functions json_v1_target_index and json_v1_arch_index offload an awful lot of work from the clients.
<efahl>
I'd be sad to see that go.
<efahl>
The overview, branches and profiles, though, are really just repackaging, so they can be migrated out pretty easily.
<efahl>
If we were to create one new call that put package_changes, arch index and target index all in one call, that would be nice.
<efahl>
In owut I just get the arch and target indexes and smash them together in one big list right away anyhow...
<aparcar[m]>
i don't even thing we need the targets.json, we just need to check for a new version via .versions.json and then verify that an image does exists at /targets/ profiles.json
sorinello has quit [Ping timeout: 480 seconds]
<schmars[m]>
i think i'm dealing in a similar problem space at the moment? overhauling our autoupdater here - i have only have a "vendorname,devicename" string to work with, and try to find a matching image from profiles.json
<schmars[m]>
i've had our buildbot combine the profiles.json of all targets into one big root profiles.json, because strictly speaking i dont know which target i should peek into
<schmars[m]>
(otherwise it wouldn't work if a target changes name (e.g. qualcommax) or device is moved to a different target (e.g. ath79/tiny))
<schmars[m]>
but thankfully i dont need to also find feed urls and stuff like that :-)
<aparcar[m]>
schmars: can't we merge the autoupdater and asu efforts?
<schmars[m]>
probably, eventually
<schmars[m]>
right now i'm dealing with hundreds of 19.07 and 21.02 nodes :D
<schmars[m]>
well, we're already building all our own images for everything
<schmars[m]>
and then there's the x86 devices, which have the generic image but board name is the actual name, e.g. lenovo-10rs002age here at home
<efahl>
yeah, in 'owut' I just say "x86? you are 'generic', whether you like it or not"
<schmars[m]>
sounds good :)
dannyAAM has quit [Ping timeout: 480 seconds]
<efahl>
does ubus system board always return a good value for release.target on your ports?
<schmars[m]>
i have to check out all the new stuff happening now. do the autoupgrade of these 19.07 and 21.02 nodes, then i'm free
<schmars[m]>
my device ports? cant say i have any
goliath has quit [Quit: SIGSEGV]
<schmars[m]>
output of ubus call system board looks good on that lenovo device if thats what you mean
<efahl>
I'm assuming that your updater looks at that and compares with the "target" value in the giant profiles.json, then uses the profile name in the list...
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<schmars[m]>
even prints the correct CPU in the "system" field
<schmars[m]>
ah. i wanted to look at /tmp/sysinfo/board_name
<efahl>
so there shouldn't be any collisions, just those 3-4 special cases of the "generic" ones.
<schmars[m]>
then find the matching target in profiles.json, and make a download URL from that
<schmars[m]>
yeah, those will be finde
<schmars[m]>
yeah and use the profile name, which is the key in the profiles object