adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<mangix>
Grommish: ping
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
gromero has quit [Remote host closed the connection]
gromero has joined #openwrt-devel
hbug has joined #openwrt-devel
victhor_ has quit [Ping timeout: 272 seconds]
hbug___ has quit [Ping timeout: 268 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
koniu has quit [Remote host closed the connection]
koniu has joined #openwrt-devel
<Grommish>
mangix: Hey.. What's up?
<Grommish>
Borromini: Most uboot I've seen also support YModem, which is faster, if that might be an option
<Grommish>
mangix: hit me up when you see it.. I'm heading to bed and will catch it in the morning :)
xback has quit [Ping timeout: 265 seconds]
xback has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #openwrt-devel
Darkmatter66 has quit [Ping timeout: 272 seconds]
dangole has quit [Remote host closed the connection]
kontaxis has quit [Remote host closed the connection]
Darkmatter66 has joined #openwrt-devel
kontaxis has joined #openwrt-devel
<hurricos>
nbd: Would you mind a question or three about minstrel_ht?
<hurricos>
I notice something of a 'lock-on' effect in the rate control on a standard ath9k chip -- `watch -n2 -d cat rc_stats` while iperf3'ing with the ath9k as tx-mostly, I can see how once I lock on to MCS15 I keep it easily, but when I lose it and drop back to one of the one-chain MCS indexes it takes a while to get back onto the 2x2 ones.
<hurricos>
is this expected from minstrel_ht, or is there some hardware quirk expected with MIMO here?
<hurricos>
The one thing I notice most shockingly is that when MIMO stops it really stops -- rc_stats shows an increase of a few dozen attempts but *none* are successful
<hurricos>
I also suspect my client chipset too (intel 8265).
<hurricos>
whereas when MIMO starts again it really starts -- goes from 5% to about 85% avg(prob) in two or three seconds.
<hurricos>
Finally, what are the meanings of ABCDPS under 'best rate' in /sys/kernel/debug/ieee80211/phy*/netdev:wlan*/stations/$STATION/rc_stats?
Darkmatter66 has quit [Read error: Connection reset by peer]
blb4393 has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
<nbd>
hurricos: ABCD are the 4 best throughput rates (in order), P is a reliable rate with decent throughput, S is a rate that will be tested next
<nbd>
regarding your MIMO issues, i suspect that this has nothing to do with rate control, but might be SMPS (powersave mode that turns off extra receive/transmit chains to conserve power) on the intel side
<nbd>
if i remember correctly, many intel clients make aggressive use of that
<nbd>
hurricos: i think some changes might be needed to either minstrel_ht or mac80211 for smps to work properly
<nbd>
i will look into it
blb4393 has quit [Quit: ChatZilla 0.9.93 [Waterfox 56.3/MOZ_BUILDID]]
hsp has quit [Read error: Connection reset by peer]
<Grommish>
mangix: Sure, I can test it. I'm not sure what it is, but I can run a build on it
hsp_ has quit [Quit: WeeChat 3.0.1]
hsp has joined #openwrt-devel
<Grommish>
mangix: just target all the boost libraries to see what happens?
voltagex has joined #openwrt-devel
pgwipeout[m] has joined #openwrt-devel
decke[m] has joined #openwrt-devel
olmari has joined #openwrt-devel
Borromini has quit [Ping timeout: 265 seconds]
JuniorJPDJ has joined #openwrt-devel
Tost has joined #openwrt-devel
MatMaul has joined #openwrt-devel
shalzz has joined #openwrt-devel
mangix has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
aparcar[m] has joined #openwrt-devel
agb[m] has joined #openwrt-devel
pavlix has joined #openwrt-devel
llewellyn has quit [Quit: Connection closed]
nick[m]1 has joined #openwrt-devel
fblaese has joined #openwrt-devel
<Grommish>
mangix: cp: cannot stat '/home/grommish/openwrt/build_dir/target-mips64_octeonplus_64_musl/boost_1_75_0/ipkg-install/lib/libboost_fiber*.so*': No such file or directory <- There is only a libboost_fiber.a MIPS64 is a dynamically linked arch
<Grommish>
In any case, its looking for the .so in your Package/install and erroring because it can't find it
voxadam has quit [Read error: Connection reset by peer]
<mangix>
Grommish: locally the PR compiles
<mangix>
I was talking mostly about run testing :)
<Grommish>
Yeah, I'm going to unselect boost fiber and check.. Did you test all libraries in it?
<Grommish>
and I'm game to test whatever you need.. Like I said, I don't know that I've use those libs for anything, so any suggestions?
<mangix>
The PR only concerns boost-context
<mangix>
actually, hmmm. that's interesting
<Grommish>
I should find a way to setup a isolated box you can use to test a box. I've got a serial connection for them
<Grommish>
and I've got 2 shields sitting here
<Grommish>
but it seems like an awful lot fo work and i'm pretty lazy honestly hehe
<mangix>
well, I think QEMU also works
<mangix>
erm malta target
<Grommish>
isn't that just mips though?
<mangix>
it's 4 things
<Grommish>
Ah
<mangix>
MIPS32/63 BE/LE
<mangix>
*64
<Grommish>
Gotcha.. Mine is a 64BER
<Grommish>
err BE
<Grommish>
I'm rebuilding without the fiber to see what happens
<mangix>
I find it interesting that boost on mips64 has been broken since forever
<mangix>
O64 is the wrong ABI
<mangix>
which musl has no support for
<Grommish>
libunwind is broken for mips64 too.. it isn't in the deps for it, but works
<mangix>
Hmm?
<Grommish>
I use libunwind for suricata6, but I had to add a mips64 dep check on it
<Grommish>
locally anyway
<Grommish>
That was as an aside "things mips64 is "broken with" comment, not related to boost
<mangix>
the libunwind depends line is pretty funny
<Grommish>
Yeah.. I put in a PR but got pissy over the comments I got (my fault) and never bothered to redo it
<mangix>
I'm probably to blame for the DEPENDS not being DEPENDS:=!arc
<Grommish>
removing boost_fiber seems to let it go and build.. Now.. what can I use to test these in a way that is meaningful for ya?
<mangix>
pdns
<mangix>
erm
<mangix>
pdns-recursor
<Grommish>
Ok.. I'll run a build with that too :) Will that conflict with default packages?
<mangix>
just running it with a --version parameter is good enough for me
<mangix>
i don't think so
<Grommish>
Ok.. Gimme a few :)
<mangix>
I'll look into the fiber issue
<mangix>
ICU is taking forever to compile...
<Grommish>
just pdns-recursor?
<mangix>
yeah. only pdns-recursor uses boost-context
<mangix>
there was another series of packages but I nuked them
<mangix>
what's strange is that the octeon compiler returns 1 for __mips_isa_rev
<mangix>
and it's still evaluating to true
<Borromini>
enyc: new image, can't just replace the kernel
<Borromini>
ok Grommish already answered you :)
<enyc>
Borromini: from what you were saying... 21.02 to be all kernel 5.4 and thus, testing-kernels are only about helping master in preparation for 22.x
<Grommish>
Does the build system separate MIPS64 vs MIPS with that flag?
<Grommish>
or does it assume MIPS64 is just "MIPS"
<Borromini>
enyc: they are a stepping stone to the next kernel to be used in master, yes
<mangix>
BOOST_ARCH_MIPS evaluates to 32 or 64
<Grommish>
not that is should matter, PAUSE was introduyced into MIPS32 in 2008
<mangix>
or 0
<mangix>
erm, undefined i mean
<enyc>
Borromini: when is the bost useful time to test 21.02 in prep for release, are there specific rc? images or just daily builds, etc?
<Borromini>
enyc: once it get branched you'll get prepped pre-21.02 images
<Borromini>
did you see the e-mail on openwrt-devel?
<enyc>
Borromini: *goes looking*
<mangix>
i see this elsewhere in boost code: #if !defined(__mips_isa_rev) || (__mips_isa_rev < 6)
<mangix>
wonder if I should just do that
<Grommish>
Wait..
<Grommish>
PAUSE wasn't introduced until revision 2.60
<Grommish>
Revision 2.60: June 25, 2008: added PAUSE instruction
<rsalvaterra>
Bugger. The pca953x GPIO driver from Linux 5.11-rc7 still has the same problem on the Omnia.
<mangix>
mips64 supports mips16
<mangix>
so PKG_USE_MIPS16:=0 turns __mips_isa_rev to 2
<enyc>
Borromini: right so it looks like testing the new builds in all their different wifi configs, client mode and other less-usual setups -- r.e. mac80211 change is going to be especially helpful
<mangix>
now i need a good way to ifdef it out :)
<Grommish>
mangix: build system defaults to MIPS16 unless told not to?
<Borromini>
enyc: yes, especially wireless drivers
<Borromini>
if you have spare devices it never hurts to run master on some of them
<Borromini>
especially smaller flash devices tend to break when running into kernel size limits and whatnot
<mangix>
Grommish: yes. adjustable under advanced toolchain settings
<Borromini>
of course better also have serial at hand if things break
<rsalvaterra>
Guys, anyone running master on an Omnia? Or anything with an Armada 38x?
<mangix>
rsalvaterra: Helios 4, AMA
<rsalvaterra>
mangix: do you see spurious GPIO interrupts?
<rsalvaterra>
And I mean tons of them, about 50/s.
<mangix>
Grommish: lol HAS_MIPS16 depends on depends on (mips || mipsel || mips64 || mips64el) but is not hit under octeon
<Grommish>
mangix: Do you know your devices triples offhand? xxxx-openwrt-linux-musl?
<mangix>
50: 0 0 f1018100.gpio 23 Edge 0-0020
<mangix>
51: 0 0 f1018100.gpio 20 Edge f10d8000.sdhci cd
<Grommish>
I know it's an aside, but since you'd probably know offhand, I can use it for my rust testing
<mangix>
i do not actually
<mangix>
i shouldn't be awake right now :P
<Grommish>
haha me either.. I feel your pain
<rsalvaterra>
After a while, the kernel just gives up and shuts the handler up, with a stack trace.
<enyc>
Borromini: I noticed my BT-HomeHub-v5-Type-A just wouldn't client-mode on ath10k in 19.07 but it DOES work with master and all the updated ath10k-firmware etc etc that includes... I'll definitely test all of these with 20.x .....
<enyc>
err 21.02 ;p
<rsalvaterra>
And this is happening on the normal snapshot builds, on the Omnia. It's not my config.
<rsalvaterra>
I'm tempted to just disable the pca953x interrupt controller feature. It "fixes" the problem for me.
<mangix>
what kernel?
<rsalvaterra>
Lunch time. bbl.
<mangix>
i'm running 5.9
<rsalvaterra>
mangix: 5.4.97, on master.
<mangix>
maybe upstream broke it
<rsalvaterra>
5.4.97 with the pca953x GPIO driver from 5.11-rc7 has the same problem.
<rsalvaterra>
I backported it yesterday for testing.
<mangix>
I updated the kernel on my helios 4 but haven't rebooted. Looks like no kernel 5.10 for me :)
* enyc
wonders about the DSA situation for 21.02, not much mention of that lately.
<Grommish>
I thought the DSA issues were the reason it's been pushed back for as long as it has been
<russell-->
did a make dirclean on the dir860l, still hangs the Parsing DT failed doesn't seem to be related, it showed up in the successful firmware built last week too.
<Grommish>
unfortunately, I don't have a Switch in my device, so I can't test anything
victhor_ has quit [Remote host closed the connection]
ericzolf has joined #openwrt-devel
dangole has joined #openwrt-devel
<russell-->
r15727-c382fe857d works
* russell--
suspects the last kernel bump
Borromini has joined #openwrt-devel
<russell-->
r15731-dba76a85de works
Tapper has quit [Ping timeout: 240 seconds]
<russell-->
yep, next commit dies
<russell-->
r15732-e95b1b23f1 kills the dir860l
gromero has quit [Ping timeout: 272 seconds]
Immanuel has quit [Ping timeout: 240 seconds]
<Borromini>
russell--: what are we talking about?
* Borromini
has a dir-860l as well
<Borromini>
russell--: oh the kernel bump?
<Borromini>
i have an eap235-wall (mt7621 as well) working just fine on 5.4.97
<Borromini>
russell--: can you get your hands on a boot log?
HeN has quit [Quit: Connection closed for inactivity]
HeN has joined #openwrt-devel
gromero has joined #openwrt-devel
<Borromini>
russell--: the pice: parsing dt failed pops up on most mt7621 devices. i think the stacktrace will be more useful
<Borromini>
i see that every time on otherwise perfectly functional mt7621 hardware
Immanuel has joined #openwrt-devel
feriman has joined #openwrt-devel
linzst has joined #openwrt-devel
Immanuel has quit [Ping timeout: 240 seconds]
linzst has quit [Remote host closed the connection]
Tost has quit [Ping timeout: 246 seconds]
heffer_ has quit [Quit: heffer_]
Tapper has joined #openwrt-devel
Immanuel has joined #openwrt-devel
<Grommish>
Borromini: Did you everget to check if your uboot supports Ymodem?
<Borromini>
Grommish: no, how so?
<Borromini>
you mean for the archer c2?
<Borromini>
i just found out yesterday about kermit.
<dangole>
kermit rules them all (lantiq bootrom also speaks kermit, if i'm not mistaking. used ckermit a lot with that back in the days)
<Grommish>
uboot supports kermit, but most also support Ymodem
<Grommish>
which is faster and has CRC checking
<Grommish>
In case it happens again, might be worth checking into
<dangole>
sure, uboot gives you choice, depending on what is compiled in. the burn-in romloader in charge of loading uboot from flash to the cpu cache usually doesn't give you choice there...
<Grommish>
I dealt with the pain of tryig to up a 90Mb image via Kermit haha
<Borromini>
Grommish: thanks, will keep that in mind :)
<Borromini>
luckily it was 7 MB only here :P
<Grommish>
Of course, I'm old enough that my first modem was a 1200 Baud
<Grommish>
So I remember when Xmodem was it and Zmodem was just coming out
<Grommish>
and I hate kermit with a paaaasion
* dangole
grew up in Zmodem days with 36kbit/s
<Borromini>
dangole: hi! you merged my MT7613 patch into iwinfo but i noticed only afterwards that i might have messed up the order. the PCI ID is 7663 but the device is MT7613 (it's related to the MT7663 though). so i don't know if that needs reordering.
<Grommish>
Yep.. I had a USR 16.6 that you had to replace the chip with a paperclip to et 19.2
<Borromini>
i think we had 56k. but at that point computers were only for the occasional game if my dad let me :P
<dangole>
Borromini: if i recall correctly the ordering there wasn't all straight to beging with. would be nice to clean it and make it consistent
<Grommish>
Looked like a hard-back book :D
* dangole
was 2:2480/300.38 on FIDOnet, ie. USENET and Mail over UUCP...
<Borromini>
dangole: oh that makes my finger mistake less bad then :P
<Grommish>
I remember Fidonet.. and gopher.. and Youngstown Ohio shudder
<Grommish>
the days of starboards is behind us, thankfully
<Grommish>
dangole: You got any luck with making uboot compile?
* dangole
mostly remembers wos.* (World-of-Sound), sdc.* (Sound Distributor Channel), ... FIDO file groups, ordered by netlabel groups people published Amiga MOD, FastTracker2 XM, ImpulseTracker IT, ScreamTracker S3M, ... and me was full on into that when me was 14 ;)
<dangole>
Grommish: I got U-Boot 2020.10 and ATF 2.2 built from source running on MT7622 on front of me :)
<Grommish>
I just donated an old A600 to a retro gmaing channel who restored it after 20+ years sitting.. I've got the A3000 around here somwhere and an original 1084S monitor in front of me :)
<Grommish>
dangole: is there a trick to compiling it for the CN70xx
<Grommish>
I can't get it to build and my uboot is 2013
<dangole>
Grommish: probably you need to use an old toolchain matching the epoch of that U-Boot...
<Grommish>
I can't get even Marvell's Uboot repo to build ;x
<Grommish>
I'm probably just not doing it right
<dangole>
Grommish: that's odd, we got uboot-mvebu building in our tree and it seems to work fine
<dangole>
Grommish: package/boot/uboot-mvebu
<Grommish>
I don't have a mvebu board though
<dangole>
uboot-kirkwood then...?
<Grommish>
cavium octeon3
<Grommish>
Because Marvell is difficult in the best of times
<Grommish>
I'llhave to dig back into it and see what I"m screwing up
Immanuel has quit [Ping timeout: 240 seconds]
<dangole>
oh, i imagine... try using the toolchain which comes with it in a OS container sufficiently old...
MichaelOF has quit [Quit: Konversation terminated!]
<hurricos>
Cavium NEVER mainlined their stuff. Or well, they re-hired Aaron Williamson to take another run at it, most recent commits to U-boot mainline were like December 2020.
<hurricos>
grommish:
<hurricos>
it doesn't help that Cavium Octeon processors, especially the higher-end ones, are ridiculously overengineered.
<hurricos>
I think most CN68XX boards are like, 32 cores, 8GB RAM.
<hurricos>
and CN78XX boards have like 128 cores or something insane like that
<hurricos>
whatever passes for "embedded" these days. It's like Xeon Phi before Xeon Phi was well-known
dhewg has quit [Ping timeout: 256 seconds]
<Borromini>
guys a question: if my board's serial header is 3,3V i shouldn't connect to it right?
<Borromini>
or am i wrong?
<Borromini>
so far i've done rx/tx/gnd and that works just fine in general
<urjaman>
yeah unless you have a voltage translator or something that'd use the reference, it doesnt matter (or a converter to old RS-232 that needs the power...)
<Borromini>
ok, thanks
<PaulFertser>
Borromini: depends on what you're attaching to that UART. In certain (relatively rare) cases UART adapters can adjust their output voltage to a reference (or just be powered externally) and then you need that board's Vcc as a reference. But most USB UART devices have fixed output voltage so you just need to ensure it matches but do not actually connect Vcc.
<urjaman>
(or well, could even cause issues if you power half of an USB-serial thing from the device accidentally, or try to power the device with an USB-serial dongle ...)
<PaulFertser>
Those "self-powered" dongles are often problematic, they keep powering the target through Tx (target's Rx) pin while the target is turned off. So it would be much better in general if USB UART devices were actually using that Vcc pin for the reference.
<Borromini>
ok, thanks guys
<PaulFertser>
In "more professional" settings such as JTAG adapters most often than not connecting target's Vcc is mandatory.
<urjaman>
yeah i often tack in resistors both ways on the data lines (to limit the cross-powering) if i expect there to be partially powered situations
<PaulFertser>
Yep
<PaulFertser>
Good workaround, but it's not always handy.
dhewg has joined #openwrt-devel
<nbd>
Hauke: ping
* mwalle
doesn't understand the linux/target/. is that loosely based on per SoC?
<shibboleth>
yes?
<mwalle>
but will that also assume it has the same boot method, for example?
<Borromini>
mwalle: no, bootloader isn't something openwrt handles?
<mwalle>
Borromini: its more than just the bootloader, e.g. where does the bootloader get the image from. raw nand? partition? what about device trees, and so on. Can this be different for each target inside a linux/target/<subdir>
<mwalle>
for example, why isn't there an linux/target/armv8 ? there are rockchip boards octeontx boards, and so on, which are all armv8
<Borromini>
i think by now all targets are dts
<Borromini>
* dts based
<mwalle>
it looks like one major difference are the kernel patches per "SoC/architecture"
<mwalle>
but what if you'd need no kernel patches at all because everything is upstream
<Borromini>
then you'd have a clean target
<mwalle>
right but that target could be a rockchip board or a layercape board. thus why are there different subdirectories for rockchip and layerscape
<mwalle>
if i look at the Makefiles there is a thing called "FEATURES" which is different across the various architectures, but there seem to be both SoC specifc stuff as well as board specific stuff
<Hauke>
nbd: pong
Borromini has quit [Ping timeout: 265 seconds]
<nbd>
Hauke: if you want to push the mac80211 update, you can simply remove 300-mac80211-optimize-skb-resizing.patch
<nbd>
i don't have time to rework it at the moment and it's not very important
ericzolf has quit [Remote host closed the connection]
<Hauke>
nbd: ok
<nbd>
are you going to update it to the latest 5.10 stable version as well?
<Hauke>
I plan to prepare that in the next days
<nbd>
ok, great
<Hauke>
I will first update openwrt to 5.10-rc6
<nbd>
ok
feriman has quit [Quit: WeeChat 3.0.1]
feriman has joined #openwrt-devel
Borromini has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
danitool has quit [Read error: No route to host]
<Hauke>
nbd: the adapted patch is in the 19.07 branch, see https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=0a59e2a76e6d58d95b8a0bdeca86090ceb794a59
<Hauke>
this more or less reverts the upstream change which conflicts with this
<Hauke>
should we better remove it there too?
Darkmatter66 has joined #openwrt-devel
adrianschmutzler has joined #openwrt-devel
adrianschmutzler has quit [Client Quit]
Darkmatter66 has quit [Read error: Connection reset by peer]
Darkmatter66 has joined #openwrt-devel
victhor has quit [Read error: Connection reset by peer]
victhor has joined #openwrt-devel
<nbd>
Hauke: yes
lipnitsk has joined #openwrt-devel
<nbd>
lipnitsk: hi, just wanted to let you know that i've pushed some updates to the flow offload code in my 5.10 patches
<nbd>
with a bit of luck there should be no more structural changes coming to the core api
<lipnitsk>
hey - I saw - thanks
<lipnitsk>
I'll see if I can cobble together PPPoE offload.
<nick[m]1>
can someone merge the javascript rewrite of the luci-app-babeld (I'm maintainer)? I would like to go on with further functionality https://github.com/openwrt/luci/pull/4791
<lipnitsk>
nbd: question - why does offload seem to stop at DSA when checking the path? I'm imagining a packet flowing from eth0 (WAN) via LAN bridge to eth1. Reading the code, when walking the net_device_path_stack it seems to break out of the loop if it finds the DSA device - don't we want to continue routing until reaching eth1?
<lipnitsk>
both xt_FLOWOFFLOAD (hw?) and nft_flow_offload (sw?) seem similar in that regard
victhor has quit [Remote host closed the connection]
<lipnitsk>
so the simple route is eth0->dsa->bridge->eth1
<nick[m]1>
ping aparcar Why do u need those apply acl lua code stuff?
<lipnitsk>
what I want to implement is adding a VLAN at eth0 as well as PPPoE, so the route will be something like eth0->eth0.VLAN->pppoe->dsa->bridge->eth1
Jonny[m]1 has joined #openwrt-devel
<russell-->
Borromini: i don't get a stack trace every time, and the messages i do see are different every time
<russell-->
it looks to me (from the messages that appear in working boots vs nonworking) like something to do with enumerating the CPUs, possibly some null pointer dereference in an interrupt handler, but just a guess.
rmilecki has quit [Quit: Konversation terminated!]
rmilecki has joined #openwrt-devel
eliasmagn has joined #openwrt-devel
<eliasmagn>
I would like to discuss the benefits of a stable release branch. I could write a script parsing the github site to find the latest stable release, but when something changes i have to change it. A stable branch would make this unaccessary. In the moment we have tags and releases equal each other. What you people think about that. am i wrong here
<eliasmagn>
for such a question?
<aparcar[m]>
nick: context?
<nick[m]1>
aparcar: javascript rewrite of sysupgrade luci app
<nick[m]1>
its definitely better than the lua code I wrote
<aparcar[m]>
there are multiple comments that aren't marked as resolved
<owrt-snap-builds>
build #781 of archs38/generic is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/archs38%2Fgeneric/builds/781 blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Stijn Segers <foss@volatilesystems.org>, Daniel Golle <daniel@makrotopia.org>, Martin Kennedy <hurricos@gmail.com>,
<nbd>
lipnitsk: dsa has a handler for the tc flow block setup
<nbd>
in the slave device
<nbd>
that handler forwards the call to eth0/eth1
<lipnitsk>
okay, so two hash entries instead of one?
<nick[m]1>
@apa
<lipnitsk>
basically we offload up to dsa and then again dsa and beyond?
<nbd>
lipnitsk: same number of flow entries as before
<nbd>
no, the full thing gets offloaded
<nbd>
just the way it's called is a bit different
<nbd>
i preferred the old approach, but pablo really wants it this way
<lipnitsk>
well whatever makes it upstream I guess
<nick[m]1>
aparcar: I was not able to mark them as resolved. I deleted them now. Yes. this implementation looks more elegant.
<nick[m]1>
thanks for pointing me to this
<lipnitsk>
I was just confused, because I thought we had to walk the full path from eth0 to eth1 when computing the destination address, but the logic seems to stop short at dsa
<aparcar[m]>
nick: I'm fine merging that and it's improved in some future, your choice
Net147_ has quit [Quit: Quit]
Net147 has joined #openwrt-devel
feriman has quit [Quit: WeeChat 3.0.1]
<nick[m]1>
aparcar Nice. Yeah, I just wrote Jonny that he should put also the uci-default into it that enables ubus on babeld. Afterwards, I ping u again. :)
<aparcar[m]>
nick: ack
shibboleth has quit [Quit: shibboleth]
danitool has joined #openwrt-devel
pocock has joined #openwrt-devel
pocock has quit [Quit: Leaving]
Borromini has quit [Quit: Lost terminal]
<eliasmagn>
russell-- you are right i am blind; thank you!
<russell-->
eliasmagn: np
rmilecki has quit [Ping timeout: 240 seconds]
adrianschmutzler has joined #openwrt-devel
adrianschmutzler has quit [Client Quit]
voxadam has quit [Ping timeout: 264 seconds]
Tost has quit [Ping timeout: 246 seconds]
blb4393 has quit [Ping timeout: 264 seconds]
ivanich has quit [Remote host closed the connection]
dedeckeh has quit [Quit: Connection closed]
Darkmatter66 has quit [Read error: Connection reset by peer]