<digitalcircuit>
slh: Answering my own earlier question - making a verbose build shows if the patch was correctly applied (though it seems it should be safe to assume so if the build succeeded).
<dwfreed>
note that the patch applying doesn't mean it will actually work :P
<dwfreed>
(even aside from whether it fixes the problem)
<slh>
sadly it didn't, would have been an easy fix
<digitalcircuit>
dwfreed: Err, what do you mean by that - whether it works as compared to whether it fixes the problem?
<digitalcircuit>
(As slh said, but with more detail)
<slh>
quite a pity that these devices show up so rarely on the second market (and when they do, only for pretty unreasonable prices close to the original list price)
* digitalcircuit
nods.
<dwfreed>
digitalcircuit: patches have very little context generally, making it difficult to know if the patch will even function as intended
<mangix>
what devices?
<dwfreed>
nbg6817
<dwfreed>
it seems at some point ZyXEL switched to a different emmc chip
<digitalcircuit>
dwfreed: Ah, good point! In my case, since Ansuel pointed out some reasonable-looking commits, I've aimed for "does this make the router boot", then if something does get it working, presumably then there will be getting context/checking surrounding commits/etc to properly revert/fix upstream/etc.
<digitalcircuit>
I'm still going to try to find a fix for the CPU crash reset thing, but I admit I have lost some enthusiasm after half a year (unrelated life stuff has been happening too).
<Ansuel>
e9hack yes but it's not related... he notice that port6 work only with vlanid 1 as soon as he change that, the port stops to work
<Ansuel>
so magix can you test with v5 a configuration like that?
<mangix>
how is vlanid changed?
<Ansuel>
he posted a configuration example in the last message of the pr
<mangix>
I'll look at it later.
<Ansuel>
if you confirm that, pls write on the pr as i will quit irc shortly
<dwfreed>
Ansuel: you should set up quasselcore on a VPS somewhere, so you can see messages when you come back :)
<dwfreed>
quassel's split architecture was designed for staying connected to IRC
<Ansuel>
not a bad idea
<Ansuel>
and the client will be able to connect to quassel remove server?
<dwfreed>
yeah
<digitalcircuit>
Yep! It's how I'm using Quassel here.
<digitalcircuit>
(Incidentally, I paused helping out a bit with Quassel to try to help fix stuff in OpenWRT)
<Ansuel>
digitalcircuit: new for the damn mmc?
<digitalcircuit>
Ansuel: No news quite yet - one of the final MMC build combos just finished (my "test-fix-5.10-nbg6817-new-mmc" branch as linked earlier). I'll test it now...
<Ansuel>
well time to sleep
<Ansuel>
should i send v6 or not ?
<digitalcircuit>
Build does NOT work, unfortunately, but that's not the last thing to try.
<Ansuel>
:( don't want to tell you the bad idea but as a last resort you can consider testing all the various kernel version
<Ansuel>
you can just remove all the patches that doesn't apply to the new kernel... considering you just need a mmc working condition you can just ignore any workaround/improvement/fix that openwrt do
<Ansuel>
quick and dirty way to add new kernel to openwrt
Ansuel_ has joined #openwrt-devel
victhor has quit [Ping timeout: 480 seconds]
<digitalcircuit>
Ah, okay! That was actually my next consideration - somehow doing a Linux kernel git bisect inside OpenWRT, focusing on commits that impact the "mmc" directory. As you say, as long as the MMC initializes and the rootfs partition mounts, I've got enough of a result (it doesn't have to actually function beyond that).
<digitalcircuit>
I'm happy to explore this process for now (I'll want to stop soon too, anyways), and if you have more advice you can share it tomorrow/later - try to get some rest :)
<digitalcircuit>
Thank you for your help!
<Ansuel_>
i mean you can also consider doing a mmc bisect directly there
<Ansuel_>
but i don't know if you will have to update also other stuff
<Ansuel_>
aside from the 3 commits is pointed out i think bisecting is the only option...
<Ansuel_>
to do thing quicker i would work on kernel version level and not on mmc commits...
<Ansuel_>
find a version where it does work and you will have less commits to try
<digitalcircuit>
That's a good point - starting with major versions (5.5, 5.9, 5.6, etc), then either doing minor versions, or actual git bisect.
* digitalcircuit
shall look into the kernel management part of OpenWRT's build process (e.g. getting it to accept other versions).
<Ansuel_>
include kernel version
<Ansuel_>
and copy the patch dir and config for generic and ipq806x
<Ansuel_>
trust me major version will be sufficent
<Ansuel_>
i bet it does brake with 5.6 random guess
<mangix>
Ansuel_: I run quassel on my NAS
<mangix>
which is on 24/7
JiiPee- has joined #openwrt-devel
<Ansuel_>
i would run it on my rouer but i use it for testing
<Ansuel_>
again don't bother to port the patch... just delete them
JiiPee- is now known as JiiPee
<mangix>
Ansuel_: yeah simple device like raspberry pi is good
<digitalcircuit>
Understood! Copy all patches, keep the ones that apply cleanly, but if any fail to build, drop them.
<mangix>
I run quassel as a docker container
<mangix>
dunno how good openwrt support is for that
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<digitalcircuit>
Whew, that was a lot of 5.4's IPQ806x patches thrown out just to brute-force getting Linux kernel 5.6 compiling. Hopefully it actually compiles successfully so I have something to attempt to boot, but I'll be surprised if that happens.
<digitalcircuit>
---I jinxed, build failed a minute after that message.
<digitalcircuit>
(In hindsight maybe I shouldn't have copied the "generic" Linux 5.4 patchset as well.)
<slh>
switching between kernels just isn't fun, with the many layers of different patches applied
<digitalcircuit>
I might have a go at browsing the commit history of the "mmc" Linux kernel subdirectory in the off-hand chance anything else stands out. I'm doubting it will though.
Tapper has joined #openwrt-devel
<dwfreed>
I would drop all patches that aren't related to booting the device or bringing up the switch
<digitalcircuit>
That makes sense as well!
nitroshift has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
dedeckeh has joined #openwrt-devel
bookworm_ has quit []
bookworm has joined #openwrt-devel
hgl has joined #openwrt-devel
goliath has joined #openwrt-devel
<hgl>
sorry if this is not the right channel to ask, but I couldn't get ARP to work for devices connected with wired VLAN (but works for the same wireless VLAN), and I've pasted configs in the forum yesterday, haven't got responses. I start to feel it might be an OpenWRT bug. I'd be grateful if someone could shed some light. https://forum.openwrt.org/t/why-arp-doesnt-work-for-devices-connected-with-wired-vlan/108752
hgl has quit [Quit: Bye]
hgl has joined #openwrt-devel
hgl has quit [Quit: Bye]
rmilecki has joined #openwrt-devel
hgl has joined #openwrt-devel
Ansuel_ has quit [Ping timeout: 480 seconds]
Ansuel has quit [Ping timeout: 480 seconds]
<russell-->
hgl: yuo might try a different vlan id, sometimes 1 is special
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
Ansuel has joined #openwrt-devel
Ansuel_ has joined #openwrt-devel
indy has quit [Remote host closed the connection]
indy has joined #openwrt-devel
<hgl>
russell--: I just changed it to 10, doesn't seem to fix the issue, still couldn't get ARP response back
<Habbie>
mangix, Ansuel_, with 4622+4528+4562, no other patches, I have working WAN+LAN, but no WAN+LAN LEDs. If I understand correctly, that's two surprises, because without mac6-exchange, I should not be expecting WAN/LAN at all? and with 4562, i should expect LEDs?
Ansuel_ has quit [Ping timeout: 480 seconds]
Ansuel has quit [Ping timeout: 480 seconds]
Dgrey has quit [Ping timeout: 480 seconds]
pmelange has joined #openwrt-devel
danitool has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Tusker has quit [Quit: Time wasted on IRC: 10 hours 33 minutes 32 seconds]
Ansuel has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
<rmilecki>
i'm trying to compile custom u-boot config and I experience:
<rmilecki>
HOSTLD tools/dumpimage
<rmilecki>
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /home/rmilecki/openwrt/openwrt-master-bcm4908/staging_dir/host/lib/libssl.a(ssl_init.o): in function `OPENSSL_init_ssl':
<rmilecki>
ssl_init.c:(.text+0x59): undefined reference to `pthread_once'
<rmilecki>
is that a missing -lpthread somewhere?
<rmilecki>
is it missing in tools/libressl/Makefile, or in my u-boot package, or in u-boot sources? :|
dangole has quit [Remote host closed the connection]
<rmilecki>
i tried modifying tools/libressl/Makefile to use:
<rmilecki>
HOST_CFLAGS += $(HOST_FPIC) -lpthread
<rmilecki>
but it didn't help
<nbd>
rmilecki: the link uses the static ssl lib
<nbd>
rmilecki: which means -lpthread in libressl won't do anything to fix this
<nbd>
and yu need to add it for dumpimage
<rmilecki>
nbd: thanks, I'll try to modify u-boot sources
goliath has joined #openwrt-devel
wvdakker has quit [Ping timeout: 480 seconds]
wvdakker has joined #openwrt-devel
robimarko has joined #openwrt-devel
<robimarko>
digitalcircuit: I glimpsed at the MMC issue
<robimarko>
Which eMMC are they now using?
victhor has joined #openwrt-devel
<robimarko>
Hauke: Any chance of you looking at my 100BaseX and SFP backports for Mochabin patches?
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
blocktrron has quit [Quit: WeeChat 3.2]
blocktrron has joined #openwrt-devel
<fda>
yesterday i noticed DDNS caused 100% cpu load @1 core. (maybe a sed of the logfile) so i uninstalled. load dropped now to 0: https://ibb.co/26KDPtG - https://ibb.co/KzWwh39
<fda>
i have a fast e8450 and a slow german internet connection so i didnt notice speed drops, but with older devices this should be a problem
<mrkiko>
fda: are you in the uBI layout?
<fda>
yes
Larhzu has quit [Quit: leaving]
Ansuel has joined #openwrt-devel
slh has quit [Ping timeout: 480 seconds]
Ansuel has quit []
slh64 has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
<Habbie>
do i see correctly that packages ship /etc/config/theirname containing defaults, and uci commit overwrites those files? what happens on package upgrades?
<Ansuel>
a config-default is created and a warning is printed
<Habbie>
ah cool
<Habbie>
perfect, thanks :)
Dgrey has joined #openwrt-devel
<Dgrey>
Hello @all, just a simple message to thank you for your hard and impressive work. We (Ubisoft entertainment) have been using OpenWrt for more than a year now and on hundreds of devices. It just works :)
<Dgrey>
It provided us the perfect example to invest more time in the open networking in the medium term. On an another subject, I know that you organise sometimes (under normal circumstance) events. Do you know if something is schedulded ? We are willing to participate.
<Habbie>
Dgrey, hey, that's awesome to hear!
<rsalvaterra>
Dgrey: There is some interest in organising an event, yes, but no dates (or even definite plans) at the moment. :)
Acinonyx_ has joined #openwrt-devel
Dgrey_ has joined #openwrt-devel
<Dgrey_>
@rsalvaterra okay thank you for the information, I will track the annoucements :)
<hurricos>
Question is, which version is the most recent Extreme Networks Extreme OS?
Dgrey has quit [Ping timeout: 480 seconds]
Dgrey_ is now known as Dgrey
jbowen has joined #openwrt-devel
minimal has joined #openwrt-devel
danitool has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
<pmelange>
is there a way to be notified (via ubus) when wireless is finished initializing?
<pmelange>
the olsrd init script is doing a wait_for network.interface.$interface, but that only waits for object creation. The object can be created in a non-initalized state causing the wait_for to be released. Also, the object network.wireless is fully created, even if the interfaces have not been initalized.
<fda>
@mrkiko i have changed availabe frequencies and governor, by git the device runs all the time at 100% which causes mor heat and power consumption
<fda>
but UBI is not required for that - it is even not recommeneded! the replace bootloader causes 125mhz not to work anymore (maybe to low voltage set)
<Ansuel_>
thinking of dropping softether vpn and switch to strongswan for site-to-site
<Ansuel_>
am i crazy ?
<robimarko>
Honestly, wireguard would be smarter
<Ansuel_>
i want to stick with l2tp as i'm lazy and i want to use standard tool so supported on my android phone and windows device with no additional program
<Ansuel_>
but i should consider site-to-site using wireguard + normal strongswan for normal device
<rmilecki>
jow: any chance you're familiar with that?
<rmilecki>
that patch fixes:
<rmilecki>
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /home/rmilecki/openwrt/openwrt-master-bcm4908/staging_dir/host/lib/libssl.a(ssl_init.o): in function `OPENSSL_init_ssl':
<rmilecki>
ssl_init.c:(.text+0x59): undefined reference to `pthread_once'
<mangix>
That is, SDK is built on host not requiring lpthread and SDK being ran on host that does.
<mangix>
Proper place for patch is probably libressl
nindoja has joined #openwrt-devel
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
<Ansuel_>
2 slh?
<slh>
this one is irssi under screen, the other quasselcore. I'm not happy with quassel-client on the desktop, but it's an o.k. solution for android - same (well, 180°) with irssi, unusable on android, fine on the desktop
<hauke>
robimarko: I will have a look at the patches on the weekend
robimarko_ has joined #openwrt-devel
<robimarko_>
hauke: Thanks, they are the last part for MOCHAbin support
<jow>
rmilecki: what mangix said
danitool has joined #openwrt-devel
Ansuel has joined #openwrt-devel
<mangix>
slh: quasselweb is better
Ansuel_ has quit [Ping timeout: 480 seconds]
Dgrey_ has joined #openwrt-devel
Dgrey__ has joined #openwrt-devel
jbowen has quit [Ping timeout: 480 seconds]
pmelange has quit [Read error: Connection reset by peer]
pmelange has joined #openwrt-devel
Dgrey has quit [Ping timeout: 480 seconds]
Dgrey__ is now known as Dgrey
Dgrey_ has quit [Ping timeout: 480 seconds]
<Habbie>
what's the point of uci ACLs in luci if a module can also just execute commands as root?
<Ansuel>
i think the last idea is to start running things with a separare user
<Ansuel>
so no more everything running as root
<Habbie>
ok, so it's a future plan, then it's good that these things are already being declared
<Habbie>
i've spent some time getting root shells from the web interfaces on various devices
<Habbie>
but playing with openwrt it was immediately clear to me that this is easy
<Habbie>
and, most likely, not unintentional
kenny has quit [Quit: WeeChat 3.3]
* Habbie
builds with led-open-drain and power-on-sel
robimarko_ has quit [Quit: Page closed]
<Ansuel>
Habbie anyway you should tag jow for this kind of thing
<Habbie>
ah, in general i don't like tagging people, but i'll keep it in mind :)
<Habbie>
mangix, no wired LEDs with led-open-drain+power-on-sel
<Habbie>
mangix, power and wifi LED still work fine
<rmilecki>
mangix: jow: I tried patching libressl but it didn't help
<robimarko>
No, its the hex value you get when doing 1 << port_nr
<Habbie>
ah :)
<Habbie>
oh, LAN works - they're in reversed order
<Habbie>
anyway, this is clear, i'll poke at that board file
<Ansuel>
swapped port can be fixed by the dts
<Habbie>
ah, i see it's swapped in 'ip l' output too
<Habbie>
Ansuel, got a keyword hint for thAT?
<Habbie>
that
<mangix>
Habbie: uhhhh so the LEDs are switch or GPIO controlled?
<nindoja>
poking around a build for the netgear r7800. I've got a plain build, using the official OpenWRT config, that works. After modifying the image (I'm creating a new squashfs for the sysupgrade.bin), I can get the image to flash and the new files show up. However, when I flash back to the plain build (or even the official openwrt release for 21.02 for the device), the modifications I made seem to persist.
jbowen has quit [Ping timeout: 480 seconds]
<nindoja>
Is sysupgrade -F the wrong way to flash/reset the filesystem to a different image?
<Habbie>
mangix, 'netdev' trigger makes them work, Ansuel concludes GPIO from that
<Habbie>
'custom flash interval' trigger also works
<mangix>
yep
<mangix>
GPIO
<Habbie>
nindoja, -F is force, the only time i ever used it was a mistake - do you maybe want -n ?
<mangix>
Habbie: that is quite bizarre that they stopped working with the migration to qca8k though
<slh>
robimarko: digitalcircuit's nbg6817 has a Kingston M62704 eMMC, while they originally used a Kingston S10004 in earlier revisions (e.g. my nbg6817, which works fine with kernel 5.10), see for the details https://github.com/openwrt/openwrt/pull/3954#issuecomment-933033672
<mangix>
rmilecki: the issue is not in passing lpthread to CFLAGS. The issue is with the pkg-config file
<Habbie>
mangix, right
<Habbie>
mangix, do you want me to do anything? test another dts change? tinker with board.d until it works?
<nindoja>
I have been doing -F because the image metadata doesn't exist on the sysupgrade.bin after I modify it (rough steps are untar the sysupgrade.bin, unsquashfs the root file, make changes, mksquashfs, then retar). -n is just for configuration changes. I should have clarified, the modifications I'm making are to add a new binary and library to the image.
<mangix>
Habbie: what's not working?
<nindoja>
I know the right way to do that is through the package management system, but I'm trying to work without that at the moment
<Habbie>
mangix, two things - out of the box, the LEDs (fixed by setting them to netdev in luci); and lan1..4 are lan4..1
<mangix>
Habbie: is that behavior different than before the qca8k patches?
<mangix>
lan1 and 4 being reversed makes sense
<Habbie>
leftmost LED matched leftmost port on master, yes
<Habbie>
i never checked if 'ip l' was correct
<mangix>
the thing is, these GPIOs have nothing to do with the switch. Them not working properly has to be something else.
<mangix>
Maybe qca8k is resetting it?
<mangix>
Ansuel: ^^
<Ansuel>
mangix: not working proprely == not correctly configured in board.d
<Ansuel>
with gpio leds you need to use netdev trigger and configure them to the dsa port
<Ansuel>
it's normal that they doesn't work as no trigger is attached to them
<mangix>
Ansuel: yeah but I'm not touching GPIO LEDs
<mangix>
just the switch definitionm
<mangix>
ooooooooooooohhhhhhhhhh
<mangix>
I think I know the isssue
<Ansuel>
with gpio leds we used a special switch0 trigger than now that we don't use swconfig
<Habbie>
love it when mangix goes ooooohhhh
<Ansuel>
we don't have it anymore
<mangix>
actually
<mangix>
I don't
<Ansuel>
Habbie: big realization
<mangix>
LOL
jbowen has joined #openwrt-devel
<mangix>
Ansuel: so 01_leds needs to be changed
<mangix>
lovely...
<Ansuel>
:D you are welcome
<Ansuel>
but not for everyone...
<robimarko>
slh: Ok, thanks. Ideally he would enable debug prints in the MMC core to see if the MMC replies to anything at all
<slh>
mangix: the good part, the switch to DSA invalidates the old configuration anyways, so no migration scripts required
<Habbie>
slh, i had to rm /etc/config/network
<slh>
Habbie: yeah, with the LEDs fixed via board.d/01_LED, you'd also have to rm /etc/config/system
<slh>
as in, no compatibility anyways
<Habbie>
slh, right! that's the answer to something i was indeed wondering about
<Habbie>
ah, 'no migration scripts' does not mean 'zero migration steps' - rm is the migration step :)
<slh>
no, rm is just the lazy man's hack to get close enough
<Habbie>
ack
<slh>
sysupgrade -n -F <image.bin> would be the correct way
<Habbie>
big rm button
<Habbie>
mangix, Ansuel, anyway, i can test more things if you want, let me know :)
<jow>
Habbie: luci views are migrated to client side rendering and interact with uci through an http rpc api
<jow>
Habbie: in the future there will be little to non page rendering code running on the server (router) side
<Habbie>
jow, right, that explains things like 'when i pick a different wifi security mode, it takes a second for the password prompt to appear' i think?
<jow>
which password prompt?
<Habbie>
the wpa password/passphrase/key
rua has joined #openwrt-devel
<jow>
I am not following
<jow>
you mean the prompt on the lcient?
<Habbie>
in my browser, yes
<jow>
i nthe browser?
<jow>
uhm
<jow>
the psk keny entry appears instantly here when changing the wifi security mode
<Habbie>
ah
<Habbie>
takes long enough here (not actually a second) that i figured there was some interaction with luci on the server side
<Habbie>
but, ok, that's not what you meant :)
<jow>
I am really not sure what you mean
<mangix>
huh
Ansuel has quit [Ping timeout: 480 seconds]
<mangix>
where is mac6-exchange on ar71xx?
<Habbie>
jow, what i mean is that when i switch 'Encryption' from 'No Encryption' to 'WPA2-PSK' in Luci, it takes noticeable time (but not an actual second) for the Key text input to apear
<Habbie>
*appear
<Habbie>
jow, and firefox developer tools show a few ubus calls happening at that point, but i see now those happen all the time anyway
<mangix>
Ansuel_: anyway back to my question. For these mac6-exchange devices, will port0 need to be changed to port6?
<jow>
Habbie: that takes like ~50ms here
<Habbie>
also i need to be off, see you all tomorrow
robimarko has quit [Quit: Page closed]
<Habbie>
jow, which is noticeable compared to a purely client side thing
<Ansuel_>
mangix yes but not just the label but also the reg
<Habbie>
jow, not a complaint - just trying to understand what is happening
<jow>
it is not doing server side round trips for that
<Habbie>
ah
<jow>
dependency evaluation
<Habbie>
right
<mangix>
Ansuel
<Habbie>
jow, so when you said 'migrated to client side, interact with uci through an http rpc api' that is also when those uci ACL jsons will start to be important?
<mangix>
that will be rather...interesting
<jow>
Habbie: yes, in fact on master and 21.02 (to some extend on 19.07 too) they already are important
<Habbie>
jow, ah
<Habbie>
jow, except right now a module could get around them by just calling the shell, right?
<jow>
only a router side Lua module
<Habbie>
right
<jow>
a view .js rendered i nthe browser cnanot spawn a shell
<jow>
base luci and most popular apps are all client side jd
<jow>
*js
<Habbie>
ah
<Habbie>
this is where i mention i only looked at luci-app-unbound
<Habbie>
which calls init.d stuff
jbowen has quit [Quit: leaving]
<jow>
yeah, it's one of the few unmigrated ones
<Habbie>
right
<Habbie>
i noticed nothing else is doing init.d stuff
<Habbie>
so i should probably be using something else as an example :)
<Habbie>
thanks for the info, bbl
<jow>
good night
<Ansuel_>
mangix: what do you mean ?
<Ansuel_>
wow the unbound app is still not ported?
<jow>
I'm not using it and the rest does not seem to care
<Ansuel_>
jow: question do you have plan to drop lua? the concern is about rpcd things using lua code instead of shell
<jow>
Ansuel_: yes, long term I would like to drop Lua
<jow>
the rough steps are: a) remove Lua completely rom the rendering code
<jow>
b) remove Lua from the dispatching logic (means the server side LuCI counterparts not requiring Lua)
<jow>
c) remove Lua from the default images
<jow>
you can still use it for rpcd plugins though, the same way you could use any script language (awk, shell, Lua, Perl, PHP) basically anything that can read stdin and write stdout (and parse JSON if needed)
<Ansuel_>
ok so the main idea is remove lua use from luci. the dispatching logic seems hard to detach from lua
<jow>
yeah it needs to be rewritten
<Ansuel_>
no plan about it i assume
<jow>
I have some rough ideas but I need to refine the scope
<jow>
at some point we'll likely drop support for Lua based luci applications
<Ansuel_>
i honestly think a good idea would be adding some warning to start the "enforing idea"
<jow>
could be that /www/cgi-bin/luci ends up being a C executable or similar which does what the previous Lua conglomerate used to do
<Ansuel_>
ow wow in c
<jow>
maybe we'll even dlopen() liblua.so on the fly if needed to still support the legacy runtime
<jow>
routing will cease being done in Lua for sure, means legacy apps must migrate their Lua controllers index() functions to declarative JSON
<hauke>
d/bu8
<jow>
but I'd like to retain the ability to call Lua module functions as route actions
<jow>
or legacy Lua templates
<jow>
but that's all future stuff, the Lua to JS migration is going on for several years already, no need to rush things now
<jow>
I think a steady move bit by bit with as little disruption as possible is stil lthe best way to go
<stintel>
jow: when you have a minute check your /q ;)
<Ansuel_>
i see and the hope is have ereything migrated when the big changes will occur
<rmilecki>
mangix: i use master, so it's libressl PKG_VERSION:=3.3.4
<rmilecki>
mangix: i think those commits you linked are present since 2.9.1
Tusker has joined #openwrt-devel
<Ansuel_>
nice it could be i maage to reproduce e9hack problem
<Ansuel_>
he just reported that badly and in a confused way i think
<mangix>
rmilecki: then that makes no sense. check staging_dir/host/lib/pkgconfig/libcrypto.pc
<mangix>
Ansuel_: good to hear
pmelange has left #openwrt-devel [#openwrt-devel]
<Ansuel_>
nope still can't reproduce it just no traffic with tagged configuration
<Ansuel_>
expected? as i'm sending not tagged packet?
<Ansuel_>
uhh nice e9hack answer the github post
<slh>
I'd bet on this being a side effect of the multi-cpu patches
<Ansuel_>
me too... and i honestly hope it's that
<mangix>
Ansuel_: you wrote otherwise in the thread.
<mangix>
wouldn't surprise me though. last time I used those patches I had no traffic on lan1 and lan3
<slh>
yep, with multi-cpu patches I can't get bridge-vlan filtering working on my nbg6817 and g10 - without it, it just works (but performance is pretty bad)
<slh>
while addressing the individual ports (without VLANs being defined, without multiple VLANs on one port) is working
<Ansuel_>
it must me something broke
<Ansuel_>
mhhhhhhhhhhh i wonder if the problem is that we blindly assign vlan to both cpu port?
<Ansuel_>
the current implementation assign the cpu port all to the first one but what if the port is connected to something else?