<Mangix>
is just realized. why is there a tools/cmake ?
<hanetzer>
finally build tested all three sunxi variants. last one fails due to a new firmware (with a new cpu arch and toolchain) we don't provide yet :D
Ansuel has quit [Ping timeout: 480 seconds]
dangole has quit [Ping timeout: 480 seconds]
<hanetzer>
Mangix: I assume because some package needs it to build?
felix has quit [Read error: Connection reset by peer]
felix has joined #openwrt-devel
<stintel>
probably because we require minimum version for some core packages, and people on debian or so might be out of luck
<Mangix>
i'm skeptical of that
<stintel>
elaborate ?
<stintel>
we also have autoconf, automake, m4, etc in tools
<Mangix>
tools/cmake was added in 2001. minimum supported platform for openwrt is ubuntu 18.04. that's cmake 3.10. that's very recent.
<ynezz>
Mangix: can we rely on CMake forward/backward version compatibility? BTW there are projects still using 12.06 (CMake 2.8) for example and it still builds just fine :P
goliath has joined #openwrt-devel
<ynezz>
Mangix: and I suspect, that removing tools/cmake would become a support nightmare
<dwfreed>
I bet they're setting path in .bashrc even when non-interactive
<dwfreed>
(can't explain why it works when interactive, but notably they're also running their shell *in emacs*)
<pepes>
I am thinking. I would like to have dedicated U-boot package installable within opkg and I could copy the U-boot image from staging_dir and put it to whatever I want. Because right now, I compiling it twice. :-( Is there way, how can I use the same versioning from different package? So, I could know the version of U-boot by opkg.
goliath has joined #openwrt-devel
MaxSoniX has joined #openwrt-devel
danitool has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
robimarko has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel
[Pokey] has joined #openwrt-devel
<[Pokey]>
9c27b0Hey there, forwarded here for this question, is the Realtek8811AU chipset supported and if so does this chioset support multi AP broadcasting?
cp- has joined #openwrt-devel
<PaulFertser>
[Pokey]: do you have VID/PID for the device?
<[Pokey]>
PaulFertser: negative on two counts. I'll look at GitHub but I am assessing what to purchase for multiple AP broadcasting so no PID/VID available I'm afraid
<PaulFertser>
[Pokey]: for USB wifi adapters that page is the best reference.
<[Pokey]>
Noted, thanks
<dwfreed>
oh sweet jesus why is that in color
<jow>
indeed
<\x>
[Pokey]: I have an MT7612U, it can do 2 ssids
<T-Bone>
dwfreed: isn't there a channel mode to prevent color input?
<[Pokey]>
At this point \x I am considering my best USB 2.0 option for maximum featureset at a reasonable price with an external SMA antenna connector, preferably two
<\x>
ath9k-htc stuff then if you dont want mt7612u
<robimarko_>
f00b4r0: DT/Zyxel arrived today, quickly configured it using the really good CLI
<f00b4r0>
hehe :)
<robimarko_>
And boom, it supports MIB 281 and 309
<dwfreed>
f00b4r0: note you'd lose the color from the buildbot reports
<robimarko_>
And my IPTV finally works
<robimarko_>
As IGMP finally works on the GPON
<f00b4r0>
dwfreed: I won't hide that I find it extremely annoying :)
<robimarko_>
So I am not getting multicast just dumped
<f00b4r0>
robimarko_: so full win then?
<robimarko_>
Yeah
<robimarko_>
Everything is working, internet, IPTV and VoIP
<robimarko_>
And finally using bridge VLAN filtering so its all HW VLAN-s
<f00b4r0>
👍
<robimarko_>
Only thing left is to get 2.5G working on the CRS
<robimarko_>
Though, I am not sure whether it actually supports 2.5G
<f00b4r0>
I thought all SFP+ ports supported HGSMII?
Ansuel has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<robimarko_>
Well, not really
<robimarko_>
They dont have to support even 1G
bluew has quit [Remote host closed the connection]
bluew has joined #openwrt-devel
<f00b4r0>
robimarko_: didn't know that. So much for backward compat then :)
<Ansuel>
just notice bcm27xx have 908 patches... my god and i was scared of having 77 patch for ipq806x now that everything is correctly split and pushed upstream...
<stintel>
raspberry pi is a disaster
<robimarko_>
Cause its effectivelly using the RPi kernel
<robimarko_>
And not the upstream
<robimarko_>
Whole target needs to be redone
<stintel>
well without the rpi kernel half of the crap won't work
<stintel>
but I've long had the idea to make a bcm28xx target for rpi that uses upstream kernel without all these backports
<Ansuel>
still amazed how one of the most used board is broadcom...
<stintel>
well backports, they're not even backports because it's not from an upstream kernel
<stintel>
Ansuel: the problem is that alternatives have the same shitty wifi issues
<Ansuel>
they are just port?
<stintel>
license vagueness, people refusing to "sign off"
<f00b4r0>
classic hot potatoe
<stintel>
all of this cheap mini sbc stuff is basically the same shit
srslypascal has joined #openwrt-devel
<stintel>
the day I find an alternative to raspberry pi that comes without videocore and without wireless firmware, I'm ditching *all* my RPIs
<Ansuel>
without wireless firmware... don't think so
<dwfreed>
rpi foundation really needs to start pushing all their shit upstream
* f00b4r0
likes FriendlyElec's boards, but uses them headless
<stintel>
well if the firmware is in linux-firmware.git that's also acceptable :)
<Ansuel>
dwfreed lots of fun if the base code is crap and that thing is broadcom
Misanthropos has joined #openwrt-devel
gladiac has joined #openwrt-devel
<rmilecki>
i think one distro recently started publishing images for RPi
Misanthropos has quit [Read error: Connection reset by peer]
minimal has joined #openwrt-devel
<jow>
hmm, people struggle again converting the default network config bridge to a bridge-vlan tagged one, since the existing lan interface needs to be changed from br-lan to br-lan.# to regain connectivity
<jow>
should we do the same we did for swconfig in the past and a ship a vlan friendly configuration by default?
<jow>
means rename br-lan to br0 or switch0 or whatever, make lan default to br0.1, wan default to br0.2
<jow>
then arrange bridge vlans 1 und 2 to cover the lan and wan port(s) egress untagged respectively
<jow>
s/und/and/
<f00b4r0>
why? Seems that would entirely defeat the purpose of DSA?
<jow>
why is explained above. A large chunk of the userbase is challanged by the requirement to convert the existing br-lan interface to bridge-vlan when adding vlans
<stintel>
we should just provide some proper examples
<jow>
we had the very same situation with swconfig a few years back and eventually switched to tagged by default so that users simply can add another vlan
<stintel>
once youonce you get it, it's not that hard
<stintel>
wtf happened there
<f00b4r0>
jow: but then there's a catch: this will break roaming on mt76 devices :P
<Habbie>
you out-cruyffed yourself, stintel
<jow>
stintel: sure, once you get it nothing is hard
<f00b4r0>
jow: also, doesn't this depend on how one uses bridge-vlan?
<jow>
yes. from my observations, one half of the users doesn ot use vlans, but those who do expect to be a ble to simply add another one on top of the existing config, that's how it is with swconfig right now on the majority of boards
<jow>
dsa/bridge-vlan based config is a regression in that sense since now the very same workflow fails
<f00b4r0>
i've got one where I have a single bridge vlan and I do the assignment within, and I declare 802.1q devices (which aren't bridges) to access the various vlans
<jow>
since an additional step is required to configure the existing logical lan interface to vlan
<f00b4r0>
let me install luci to check how it looks there
<jow>
could try to add back auto migration but it is quite complex with the newstyle uci configuration
<stintel>
the first thought that popped to my head was "isn't mips dead?"
<jow>
if bridge has no vlans and vlan is enabled, the add vlan 1, add all preexisting ports untagged, find all logical interfaces using bridge as device and change them to bridge.1
<f00b4r0>
Ansuel: with luck it'll come to us :)
<Ansuel>
stintel it was on my todo list to experiemnt with that but was very curious if there were any benefits... if there are some for mips i expect more for other target
<f00b4r0>
jow: interestingly, luci shows greyed out devices for each of the bridge-vlan vlans, although these devices aren't declared anywhere
<jow>
f00b4r0: the point is that you need to reconfigure your lan after you setup the vlans
<jow>
most people will miss this step
<jow>
it also requires you to save but not apply your vlan settings
<jow>
thne change lan, only then apply
<Ansuel>
that seems really bad
<jow>
you basically need to touch different places and bring them in sync to "introduce" vlans
<jow>
on swconfig based systems, lan already uses vlan 1, so you can just add another vlan, modify the existing on, start tagging ports
<jow>
this is not the case anymore
<jow>
doing the same right now will cut you off
<f00b4r0>
jow: https://imgur.com/a/CIVPJVM - probably a bit more intricate than most setup. I wonder why the greyed "vbridge0.*" devices show up though
<jow>
and it used to be the very same with swconfig a few years ago (there was a vlan 1 for lan by default but the problem there was the cpu port which had to be changed from untagged to tagged, then the lan device from eth0 to eth0.1) to add further vlans
<jow>
f00b4r0: totally unrelated to my point though
<Ansuel>
jow wonder if a solution would be add to luci a way to "first setup" a vlan configuration if anyone needs that
stintel[m] has left #openwrt-devel [#openwrt-devel]
<olmari>
heck, it is even same with any traditional managed switch from nay big player :)
<jow>
Ansuel: thats what I call "auto migration". It exists for swconfig in cases where the default config is not sane
<jow>
Ansuel: but with bridge vlans it is harder, you can only rely on heuristics
<f00b4r0>
jow: I'll try to reproduce what you mentioned because it's not immediately obvious to me. It's expected (to me) that enabling VLANs will require special care (as it would on a switch as pointed above). Similary switching protocol on single-ethernet devices in Luci is "tricky"
<jow>
f00b4r0: well on swconfig systems it didn't require special care to flip a port from tagged to untagged or to add a second vlan without a soft-brick
<jow>
in this sense, we have a clear ux regression
<jow>
eventhough it's "obvious" and "expected"
<f00b4r0>
i see
<ynezz>
but this has changed in 21.02, right?
<ynezz>
it's not new in 22.03
<ynezz>
I mean, DSA was introduced in previous release already
<jow>
ynezz: yes but now it begins to affect more popular devices
<Ansuel>
21.02 had only mvebu as real user of dsa
<Ansuel>
am i wrong?
<f00b4r0>
Ansuel: mt7621
<jow>
It is something we should think about
Kiste has joined #openwrt-devel
<olmari>
Also for general public (even assuming generally tech-sawwy enough to use openwrt) this concept is not always immediately obvious... that as literal hardware there is separately switch and its controls, and then linux/cpu side where one does "L3 stuff"
Misanthropos has joined #openwrt-devel
<f00b4r0>
jow: I'll take a look. But as I mentioned there's a big caveat that enabling bridge-vlan on mt7621/22 devices by default will break roaming for all of them
<jow>
f00b4r0: yes, this is clearly a bug that should be adressed
<Ansuel>
imho we should check if an auto migration is doable... most of the time basic user stay with the default configuration so a migration to vlan can be done... if someone have a more complex config he should be able to understand what changes to do... an alternative would be add something to detect a soft brick and disable the apply button
<jow>
the assumption is that the existing default untagged lan vlan 1 is totally transparent
<jow>
s/is/should be/
<f00b4r0>
Ansuel: I thought the DSA automigration was ruled "impossible" though?
<jow>
f00b4r0: lan device config auto migration
<jow>
luci specific when interacting with vlan controls
<jow>
not automatic translation of swconfig to bridge-vlan
<Ansuel>
jow what about a confirmation dialog and a warning if we detect that the user is doing something that would result in soft bricking ?
<f00b4r0>
jow: oic. Users start from the br-lan and enable vlan filtering on that?
<jow>
d
<jow>
f00b4r0: yes
<jow>
f00b4r0: surprise #1: it's empty, what to do?
<jow>
f00b4r0: surprise #2: add vlan 1, add all ports as untagged, hit save & apply, brick
<f00b4r0>
i just did that and thanked the autorevert :)
<jow>
step 3: bug report, "vlans do not work with 22.03"
<jow>
(just joking)
<f00b4r0>
;)
<f00b4r0>
what's not immediately clear to me is why doing just what you described results in a broken config
<jow>
because a change of `config device br-lan` to `config device br-lan.1` is missing
<jow>
in `config interface lan`
<f00b4r0>
oh
<jow>
hence my suggestion to at least program the lan portion to use vlan 1 by default and make all lan ports untagged in it
<jow>
but as you already pointed out, it will trigger roaming issues in mt76 at least
<f00b4r0>
i'm thinking that a warning message in the Luci "Bridge VLAN filtering" window would probably be a good "hot fix"
<f00b4r0>
it's also semi-confusing that the newly added br-lan.1 does not show up in the Devices list after adding
<f00b4r0>
(which would also be another hint)
<Ansuel>
so if br-lan.1 is created and ports are still to br-lan add a warning ?
<Ansuel>
(or deny apply?)
<f00b4r0>
or even simpler, at the bottom of the window, add something along the lines of "remember to adjust your respective interfaces "Device" settings before applying changes"
<Ansuel>
people will 100% ignore that
<f00b4r0>
really?
<Ansuel>
they will flag it as a generic warning like "broken glass can cut your finger" on milk bottle in us
<f00b4r0>
their problem then :P
<olmari>
While I have absolutely no say what you should do, generally peoples will be ignorant, there is surprisingly little you can do about that without being irritating to others... And if some automation is thought, then the automation has to be darned foolproof while same time not getting into way of daily life...
mcbridematt has quit [Remote host closed the connection]
mcbridematt has joined #openwrt-devel
beany is now known as Guest2036
Guest2036 has quit [Quit: Guest2036]
cbeznea has quit [Ping timeout: 480 seconds]
<jow>
Ansuel: the solution will likely be changing all `br-lan` users to `br-lan.#` where `#` is the ID of the first VLAN upon pressing save
<jow>
Ansuel: then hope that the user didn't configure an empty first vlan, e.g. as placeholder for later
<jow>
or due to buggyness of certain boards where id 1 is problematicv
<jow>
so maybe use the first vlan containing at least one port
<jow>
... and hope that this isn't a vlan containing just the wan port because the user wants his wan on 1
<jow>
...
<jow>
or maybe prompt a modal overlay prompting: "Migrate existing networks to VLAN: [select box]"
<jow>
and preselect the first one with the most ports
torv has quit [Ping timeout: 480 seconds]
<jow>
bounce back doing nothing on cancel, save bridge-vlan settings along with option device adjustnents on save/continue
beany has joined #openwrt-devel
<jow>
and only invoke if there's interfaces referring to the bridge itself
<jow>
and only prompt if there's more than one potential vlan to move to
<jow>
probably missed some more corner cases
torv has joined #openwrt-devel
cbeznea has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
valku has joined #openwrt-devel
Tapper has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
<Ansuel>
jow that was my idea should work with basic configuration... for complex one we should assume the user having enough knowledge to fix/do the migration himself
mcbridematt has quit [Remote host closed the connection]
mcbridematt has joined #openwrt-devel
Piraty_ has quit [Remote host closed the connection]
<ynezz>
Ansuel: it looks like they've applied some FUP? :P
<Ansuel>
ynezz mh?
<ynezz>
fair use policy, so one busy project couldn't consume all free runners
<ynezz>
previously it was possible to run hundreds of jobs in parallel, but now I see long queues everywhere
<robimarko_>
It was getting abused hard
<ynezz>
ok, but our kernel builds are not crypto mining :p
<Ansuel>
ynezz seems the case... problematic for us for the kernel build workflow
<Ansuel>
but i'm working on that to remove 20 minutes from each job
<Ansuel>
(include precompile host tools in a container image and use that to build kernel workflow)
<ynezz>
let's hope that downloading of that fat container is not going to take 21 minutes :)
<ynezz>
BTW how much did it grow?
<robimarko_>
I also assume that they are having a lot more projects using free runners than ever
<Ansuel>
i need to find the correct way to do it... my crazy idea was to provide only the staging dir with precompiled bins and make the buildroot use that
<Ansuel>
but i assume that requires some changes on some openwrt makefile
<ynezz>
Ansuel: BTW you could try to build test your changes under your account and see if you get runners faster
<Ansuel>
ynezz yep that's what i do. had to do many test to understand how to make a matrix build with macos os and ubuntu + container image
<Ansuel>
example online: 0... only documentation is an issue solved where they say that you can use null value for container... had to sort all the hack to make it running
<Ansuel>
(i cancelled a job as I force pushed it)
<maxmadzz>
how to build openwrt on apple silicon?
<maxmadzz>
target x86-64-linux-musl
goliath has joined #openwrt-devel
PaulFertser has quit [Ping timeout: 480 seconds]
PaulFertser has joined #openwrt-devel
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
<rmilecki>
jow: my opinion is to stick to VLAN-less config by default
<rmilecki>
1. We already have some 21.02 targets and most/many 22.03 targets having that setup by default
<rmilecki>
2. Setting ports into separated networks is much simpler for me without VLANs
<rmilecki>
3. I believe we can educate people into DSA by tutorials (we actually have nice forum/wiki tutorial and some video)
<rmilecki>
4. Basic DSA usage should get more popular so people should be able to follow also non-OpenWrt specific tutorials
<rmilecki>
I think however it would be nice to add LuCI warning like "Your VLAN n is missing interface"
<Ansuel>
robimarko_ that issue is.... lets laugh about it
<robimarko_>
Ansuel: I just dont get the logic behind stuff like that
<Ansuel>
custom firmware done by someone based on your branch and they put your link in it IMHO
dangole has joined #openwrt-devel
<robimarko_>
Wouldnt be the first time
<Ansuel>
robimarko_ wth happen to the enlarge commit o.O
<Ansuel>
can't understand the cause of the breakage
<robimarko_>
I assume DEVICE_DTS_DIR
<Ansuel>
let me check
<robimarko_>
DEVICE_DTS_DIR
<robimarko_>
Ughh,broken copy/paste
<robimarko_>
KERNEL_INITRAMFS definition
<Ansuel>
$$(DEVICE_DTS_DIR)/$$(DEVICE_DTS).dtb
<robimarko_>
Change it to: $$(KDIR)/image-$$(DEVICE_DTS).dtb
<robimarko_>
As I changed to use the buildroot built DTB-s
<robimarko_>
As that avoids the need to patch the kernel to build DTB-s
<robimarko_>
As well avoids the need for kernel rebuild if DTB is changed
<Ansuel>
interesting wonder if other target would benefit from this
<robimarko_>
I forgot that it was even possible
<robimarko_>
Until somebody sent a patch for IPQ40xx to convert it
<ynezz>
make --trace tools/install 2>&1 | grep 'due to'
<Ansuel>
one problem i notice it that without the zip in dl/ the tool is recompiled everytime
<ynezz>
check_download_integrity ?
<robimarko_>
Ansuel: I am messing with AX9000 and single FW
<robimarko_>
Some things I want to test there first
<Ansuel>
ynezz grep 'due to' doesn't give me info... example i delete zstd host tool from build_dir. i run make tools/install and zstd is recompiled
<Ansuel>
ok wait i need to test something
<ynezz>
Ansuel: then grep for 'does not exist'
<Ansuel>
ok the big hack here is keeping the .built file in the build_dir zstd folder for example
<pepes>
Guys, I am thinking. I would like to have dedicated U-boot package installable within opkg and I could copy the U-boot image from staging_dir and put it to whatever I want. Because right now, I compiling it twice. :-( Is there way, how can I use the same versioning from different package? So, I could know the version of U-boot by opkg. Any ideas?
<jow>
pepes: there's no clean way
<jow>
you could define a shared .mk file that just declares the version, then include that in both places
<jow>
or you could use a construct like PKG_VERSION:=$(if $(DUMP),x,$(shell sed -ne 's#PKG_VERSION:=##p' $(topdir)/package/boot/u-boot-foo/Makefile))
<pepes>
Thanks jow! I will try it, but it looks like it is going to help. THanks! I will let you know about it.
<jow>
there should be an advanced developer menuconfig knob
<jow>
"don't build common host utilities"
<Ansuel>
ynezz ohhh nice idea!
<jow>
which then skips widely available stuff like tar, cmake, ...
<Ansuel>
jow let me check with a quick search
<jow>
and only builds rare or openwrt specific things like firmwar-eutils
<jow>
Ansuel: it was a suggestion
<jow>
personally I am annoyed by constant cmake rebuilds due to branch switching
<jow>
and I'd love to have a nob to simply use host cmake
torv has quit [Remote host closed the connection]
<Ansuel>
jow mhhh using host version could cause build error tho
<ynezz>
Ansuel: you don't want that on CI, correct, but during local development it's handy
torv has joined #openwrt-devel
<ynezz>
on the other hand, with cached tools you would need to know how to evict that cache, that's quite tricky :P
<Ansuel>
that option would be specific to CI and using a speciall crafted docker image
<Ansuel>
(the HAVE_CACHED_TOOLS)
<Ansuel>
the option proposed by jow would be handy and interesting to implement
<ynezz>
this is going to desync the cache in some point of time and you would get false CI positives/negatives
<ynezz>
in other words, folks might merge green PRs, which would then result in build regressions on our buildbots etc.
<Ansuel>
mhhh wonder if the real solution is to copy in the docker image the staging dir and only the .built .configured and .prepared file in the build dir. If for whatever reason the package in the cache is old, then it will get recompiled
<Ansuel>
(till the docker image is updated)
<jow>
Ansuel: iirc there's also already an option for it
<jow>
that should clean up the build dirs minus the stamp files iirc
<Ansuel>
let me test on local build
<Ansuel>
if that's the case than it's really good
<Ansuel>
This allows you to symlink build_dir into a scratch location, e.g. a ramdisk, which does not have enough space to keep a complete build_dir.
<Ansuel>
just what we need
<ynezz>
so many knobs :)
<jow>
that was exactly the purpose of this option when nbd implemented it
<jow>
because we wanted to use a shared build dir on the uildbots
<Ansuel>
and now we are trying to do the same with a docker image
<jow>
at a fast location, but without having to retain the build cruft of all workers, just the stamps
<Ansuel>
interesting every package is getting recompiled with the option on
<Ansuel>
and only the stamp file are present in build_Dir
<jow>
CONFIG_AUTOREMOVE is factored into the stamp file names
<jow>
si it will invalidate everything built without it
<jow>
*so
<jow>
at least this is my understanding
<jow>
try building twice after enabling it
<jow>
the subsequent run should not rebuild
<Ansuel>
yep now it's building cmake so i have to wait a little
<Mangix>
unfortunate that tools/cmake does not use ccache
Borromini has quit [Quit: Lost terminal]
<Ansuel>
corner case not something you compile daily
<ynezz>
I do :P
<Ansuel>
rip ahahha
<jow>
I have the feeling that I do have to recompile cmake every time I touch my tree
<jow>
easily happens when switching branches back and forth and cmake was bumped yet again to last hours version in master
<russell-->
mrnuke: i have your realtek-poe patch build on my ews2910p-v3, you want something in particular tested?
<Ansuel>
800/900...
<Ansuel>
960*
<Ansuel>
ok nice the option works correctly
gladiac has quit [Quit: k thx bye]
<Ansuel>
but i assume it has to be enabled
<Ansuel>
on other workflow too
<Ansuel>
yep removing the option makes the host package to recompile... good to know
<rmilecki>
jow: "help me transition this config to dsa" suggests it's a finite group of people who are used to swconfig ;)
<jow>
rmilecki: the other group is "I can't get VLANs to work"
<Ansuel>
me: openwrt bricked my device !??!
<jow>
tomato is so much simpler
<f00b4r0>
docker-compose is driving me mad
<Mangix>
f00b4r0: :)
<Ansuel>
?
<mrnuke>
Ansuel: cool! Can I review it? LGTM :P
<mrnuke>
russell--: Do you know how to use `ubus call poe sendframe` to find the port on/off, and port reset commands?
<f00b4r0>
what an incredible pos
<Mangix>
f00b4r0: use a GUI like portainer
<f00b4r0>
i wish
<f00b4r0>
ynezz: ok, both containers are running and hopefully up ;P
<f00b4r0>
ok I spoke too soon. Starting the other stops the first
<f00b4r0>
I give up, I've wasted enough time
<f00b4r0>
oh. --remove-orphans does that
<f00b4r0>
looks like there should really be only one compose file
<Ansuel>
you can't compose the composed
<f00b4r0>
it looks I should use macvlan instead of ipvlan. I'll fix that later
owrt-snap-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-snap-builds has joined #openwrt-devel
owrt-2102-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-2102-builds has joined #openwrt-devel
owrt-2203-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-2203-builds has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
<ynezz>
f00b4r0: good work, Connected to buildmaster; worker is ready.
<f00b4r0>
ok
<ynezz>
thanks! :)
<f00b4r0>
is it ok if I shut it down to fix my networking minor mistake? :)
<f00b4r0>
or were you about to run a test build?
<ynezz>
there is pleny time till 22.03.1 I would say :p
<ynezz>
s/pleny/plenty/
<f00b4r0>
what about 21.02.4? ;)
* f00b4r0
hides
<Ansuel>
curious what you guys are doing
<f00b4r0>
we're back online
<f00b4r0>
ynezz: you're welcome to try running a snap build to make sure it actually works if you'd like. I think all is set now. Probably want to backup these compose files somewhere :)
srslypascal is now known as Guest2052
srslypascal has joined #openwrt-devel
Guest2052 has quit [Ping timeout: 480 seconds]
<ynezz>
Ansuel: adding two buildbot build workers to 22.03 images
zatwai has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
zatwai has joined #openwrt-devel
bluew has joined #openwrt-devel
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
<f00b4r0>
ynezz: I'm going to reboot the box
xes has quit [Ping timeout: 480 seconds]
ptudor_ has joined #openwrt-devel
<stintel>
bah, hit that kernel panic in __xfrm_state_delete again
ptudor has quit [Ping timeout: 480 seconds]
<stintel>
it happens so rarely this is going to be impossible to bisect
<stintel>
unless maybe I reduce the lifetimes of my tunnels to a few minutes
<Ansuel>
why not seconds
<dwfreed>
why not wireguard
* dwfreed
ducks
<hanetzer>
ynot zoidberg?
<stintel>
wireguard is way more unstable for me and I haven't found the time to properly debug that, combine that with (before this bug appeared) perfectly stable setup, ...
<stintel>
also having to use different ports for every s2s connection bothers my ocd
<f00b4r0>
what?
<f00b4r0>
oh. You want fully segregated connections I'm guessing
<stintel>
yes, I have /30's for each s2s tunnel and bgp over that for dynamic routing
<stintel>
last time I tried, impossible with wg
<f00b4r0>
ynezz: ok things are looking better now. I'll fine tune tomorrow
<stintel>
unless you use different ports
<f00b4r0>
stintel: i never played with bgp so I can't comment
<zorun>
BGP over point-to-point wireguard links is a no-brainer, it just works
<zorun>
but yes, you do have to use different ports for each tunnel
<Ansuel>
cp: '/home/runner/work/openwrt/openwrt//logs' and '/home/runner/work/openwrt/openwrt/logs' are the same file
<Ansuel>
GOD DAMN
<stintel>
yes, and that bothers me terribly\
<stintel>
every new tunnel requires a new firewall rule
<zorun>
I'm doing exactly this, a full-mesh of p2p wireguard connections with Babel to do the routing (latency-sensitive)
<f00b4r0>
zorun: so I really want to ask what kind of mesh scenario requires this because I'm curious, but I'm also starving now. Mind if I ask again tomorrow? ;D
<zorun>
stintel: udp dport 50000:50099 ACCEPT (not UCI syntax but you get the idea)
<stintel>
zorun: still bothers my ocd ¯\_(ツ)_/¯
<stintel>
guess I got too used to ipsec
<zorun>
f00b4r0: sure :D
xes has joined #openwrt-devel
<zorun>
f00b4r0: want to come to Roma in two weeks for the Battlemesh? I'll probably be there :)
<f00b4r0>
zorun: might be a bit short notice ;)
<f00b4r0>
ynezz: there's one thing that's outside of my control: build properties for -01 show "nproc: 24" which is wrong (probably leftover from previous setup)
<f00b4r0>
(I noticed the -01 builder does use make -j24)
<f00b4r0>
and now I'm really off
<stintel>
19|02:25:23< stintel> bloody hell, wtf is wrong with wireguard really. another link that went down and is impossible to bring up again
<stintel>
19|02:29:18< stintel> for some reason it is using :1 for the endpoint on one end
<stintel>
19|02:29:27< stintel> instead of the correct port
<stintel>
19|02:39:34< stintel> and if I ifup the wireguard interface again, the endpoint port of the peer on the other end changes
ptudor_ is now known as ptudor
<stintel>
so at random, one end of the wireguard tunnel decides to change its port to :1
<stintel>
ifup, situation reverses - the other end switches to port 1
<stintel>
it's completely wtf deluxe
<stintel>
iirc recovering from that situation required a reboot
<stintel>
so yeah, I gave up on it
<dwfreed>
you do not have to use different ports for different links if there's no security implications of them sharing a common interface (but equally you can configure fw3/4 to put different subnets of the same interface in different zones)
<dwfreed>
a single wg interface can have as many peers as you want
<stintel>
it didn't work
<stintel>
with a /29 and multiple peers with an IP in that /29, traffic always went over 1 of the tunnels
<zorun>
dwfreed: not if you want to do dynamic routing
<stintel>
making the other ends unreachable
<stintel>
trust me, I tried
<stintel>
and making a lab setup this complicated to reproduce takes a lot of effort
<dwfreed>
OpenWrt in x86 VMs
<stintel>
sure, still takes more effort than I'm willing to spend, since my ipsec setup otherwise works fine for >5 years
<dwfreed>
zorun: sure, if your wg policies require you to allow peers much broader IP ranges so you can let BGP handle actual routing, then multiple peers on one interface isn't going to work
<hurricos>
Is anyone here very familiar with MII configuration register values?
<hurricos>
I'm trying to reproduce the oem u-boot's MII config on a new u-boot for the Aruba AP175