<mrnuke>
slh: It was right there on top of dmesg : "[ 0.260571] CPU: IPQ8072A, SoC Version: 2.0"
<mrnuke>
Silly me
<slh>
o.k., good news
<slh>
that should be quite reasonable to get working
<slh>
there are two pending PRs for other ntgr devices on robimarko's github
<mrnuke>
slh: that is good stuff! Thanks for the pointers!
philipp64 is now known as Guest871
philipp64 has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Guest871 has quit [Ping timeout: 480 seconds]
valku1 has joined #openwrt-devel
valku has quit [Read error: No route to host]
valku1 is now known as valku
valku has quit [Quit: valku]
felix has quit []
felix has joined #openwrt-devel
Joral has joined #openwrt-devel
csrf has joined #openwrt-devel
<Joral>
I am looking for a little guidance. I have a Cisco ISA570 SMB router. The factory firmware was absolutely atrocious and after some digging I discovered that it has a Marvell 88F6282 Kirkwood processor. Using tftpboot I was able to get it to boot the image for the Cisco ON100 (which I think has the Feroceon 88FR131, at least that is what's in dmesg). Not really sure where to go from here but am willing to do what I can to help get a profile set up
<Joral>
The two major differences I have seen between mine and the ON100 are that mine has 9 LAN ports instead of the one and mine also has a NETL7 deep packet inspection coprocessor that I don't see in the images of the ON100. It would be cool to find a driver for that but not necessary as a first pass.
hexagonwin has quit [Remote host closed the connection]
hexagonwin has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
<Habbie>
scripts/feeds update -a wants to update from a git remote before writing an index, but the remote is not available - can i tell it to generate the index anyway?
hexagonwin has quit [Remote host closed the connection]
hexagonwin has joined #openwrt-devel
<Habbie>
i'll just make another local clone
rua has joined #openwrt-devel
borek has joined #openwrt-devel
borek1 has joined #openwrt-devel
borek has quit [Read error: Connection reset by peer]
borek1 is now known as borek
borek1 has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
borek1 is now known as borek
robimarko has joined #openwrt-devel
Tapper has quit [Quit: Tapper]
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
bluew has quit [Quit: Leaving]
netprince__ has quit [Read error: Connection reset by peer]
frwol has joined #openwrt-devel
<frwol>
hi
<rsalvaterra>
nbd: Were the airtime fairness issues the reason I was seeing the airtime weight always at 256, no matter how I distributed the weights between interfaces?
<nbd>
no
<rsalvaterra>
Hm… ok.
<nbd>
did you use dynamic mode?
<rsalvaterra>
option airtime_mode '3' on the radios.
<nbd>
i'm not 100% sure, but i think in that mode hostapd dynamically adjusts fairness values
<nbd>
whenever queues are backlogged
<rsalvaterra>
Don't remember which mode it is, I have the airtime configuration disabled at the moment.
aleksander has joined #openwrt-devel
GNUmoon has quit [Remote host closed the connection]
<aleksander>
jow, hey! wondering if you could suggest what to do with one issue I'm seeing in the modemmanager protocol handler. I can get the status of the interface out of sync w.r.t. the modem status in ModemManager if I run the following "ifup wan && usleep 100 && /etc/init.d/network restart"
<aleksander>
the outcome is that the original --simple-connect triggerd by the ifup succeeds, but upon netifd restart the interface is still down
<aleksander>
the modem is reported as connected in ModemManager, but given that netifd was restarted, the IP settings were not setup in the network interface, and ifstatus wan reports the interface as down
Piraty_ has quit []
<aleksander>
is there some way to have netifd do an implicit ifdown on the interface during its initial boot, or something like that?
Piraty has joined #openwrt-devel
schwicht has joined #openwrt-devel
<jow>
aleksander: is the modemmanager process supervised by netifd?
<aleksander>
jow nope
<jow>
that's the problem then, you need to manually synchronize
<jow>
either by re-checking the state from the script triggered upon connect
<jow>
or by somehow restarting modemmanager before an ifup
<jow>
maybe you should launch a dummy monitor process from the proto handler, which tells modemmanager to disconnect upon termination
schwicht_ has joined #openwrt-devel
<jow>
that's actually the only somewhat sane way I see
<jow>
could be something simple like a `trap TERM 'mmcli whatever'; while true; do sleep 60; done` kind of script
<jow>
which you then register using proto_run_command()
<aleksander>
hum
<jow>
see ppp.sh for reference
<nbd>
shouldn't /etc/init.d/network restart do an ifdown already before restarting netifd?
<aleksander>
and that process would only just trigger disconnection of all modems available on TERM, and the TERM would be triggered when netifd exits
<jow>
aleksander: or a specific modem managed by the interface
<aleksander>
nbd, thing is, the --simple-connect may still be ongoing in MM during a ifdown
<aleksander>
ah, true, only the modem managed by the interface would make sense
<aleksander>
I'm going to check whether I receive the ifdown event in the protocol handler upon netifd restart as nbd says
<aleksander>
I should be able to cancel the ongoing connection request if any
schwicht has quit [Ping timeout: 480 seconds]
<jow>
problem is that this would only work for a clean restart
GNUmoon has joined #openwrt-devel
<jow>
not e.g. a netifd crash + start which will wipe any ip settings off interfaces and reinitialize them but not notify external, unmanaged processes and not necessarily sending a prior ifdown (afair)
<jow>
in the interest of robustness it's likely better to tie the modem state mngt. to the interface instance lifetime instead of relying on event notifications
<aleksander>
aha, that makes sense
<aleksander>
will let you know what I come up with; thanks for the hints!
borek has quit [Remote host closed the connection]
<nbd>
jow: didn't see it yet, will take a look soon
<aparcar[m]>
robimarko: thanks for the pointer
schwicht has joined #openwrt-devel
schwicht_ has quit [Read error: Connection reset by peer]
GNUmoon has quit [Remote host closed the connection]
<rsalvaterra>
aparcar[m]: I just fetched master, yay! Now do GCC 12! :D
* rsalvaterra
runs
<rsalvaterra>
It's not like it's going to break anything… unless it's selected, of course. :)
borek has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
Jonny[m] has joined #openwrt-devel
<nick[m]1234>
Where can I find information about the result codes when getting a response back from rpcd?
<nick[m]1234>
I search for "result : [2]"
<robimarko>
rsalvaterra: 5.15 point bumps should be ready?
<rsalvaterra>
robimarko: Yes, I think they're ready. However, I'd like for zx2c4_to take a look at the crypto-lib-blake2s package I removed, as BLAKE2s should now be built-in the kernel. I think it's correct, and it builds/runs fine, but I'd just feel safer that way. :)
<rsalvaterra>
robimarko: I see you have a couple of pending fixes for mvebu 5.15 too.
<jow>
nick[m]1234: the result codes are straight ubus error codes
<nick[m]1234>
jow fixing these ubus python bindings. however, not so important anymore. ;)
<nick[m]1234>
jow: btw, there was a discussion on the mailinglist moving the iptables stubs to the header, fixing the runtime of iptables with the update
<jow>
nick[m]1234: you mean a discussion on the netfilter list?
<nick[m]1234>
jow: yes
<jow>
we do some seriously nonstandard stuff in openwrt, like packaging all usually dynamic extensions into one big library (libipt*ext.so)
<nick[m]1234>
jow: and why?
<jow>
let me try to remember the rationale
<jow>
ah yes, so the problem is the following:
<jow>
core extensions like DROP/ACCEPT/REJECT etc. are usually statically linked into iptables
<jow>
since fw3 does not use iptables but libxtables directly, it had to statically link these extensions again, leading to bloat... you basically had the same iptables userspace extensions statically linked into both /sbin/iptables, /sbin/ip6tables and /sbin/fw3
<jow>
that's why we hacked the iptables build to move what's normally libext.a (the static extension bundle) into a dynamic libiptext.so which can be shared among iptables, ip6tables and fw3
<jow>
the libiptext.so however relies on a working init_extensions() to initialize and register all the extensions it bundles
<jow>
if init_extensions() is stubbed, the library will contain the relevant code (match parsers, target structs etc.) but the matches/targets will not get registered
<nick[m]1234>
sounds like a good rason
<jow>
hence the failure to find stuff like `comment` or `ACCEPT`
<jow>
nick[m]1234: maybe we can avoid any reverts, patches or upstream modifications if we simply pass -DNO_SHARED_LIBS in the libiptext build
<nick[m]1234>
jow: let me try :) Maybe I will put the infromation you gave me in a respone email to the list for documentation reasons for the iptables people?
<jow>
sounds like we should use the approach of the 124 plugin files
<jow>
the details are blurry, this stuff was long ago, May 2015, stuff might have changed in 7 years
<jow>
the main/unique problem fw3 had compared to other programs interfacing with libxtables is that it required access to the parsing routines of the various match extension and that it needed to track loaded extensions in a specific way (to be able to re-init them) which ruled out any dlopen() based autoloading through libxtables
<jow>
because libxtables api programming model was built with the assumption that the host program performs a one-off parsing and then exits while fw3 does multiple parse passes to populate multiple tables
<jow>
and in between these passes we required a reliable way to reset the internal state of all loaded extensions
<jow>
ah and we did that by hijacking xtables_register_match()
<jow>
and xtables_register_target()
<nick[m]1234>
You mean we should extend the makefile by 124 plugins? Hmmm, all you wrote sounds reasonable. I wonder if firewall3 was the only project directly relying on libxtables. Why was the work not upstreamd to iptables?
<jow>
using dlsys(RTLD_NEXT, ...)
<jow>
and that (afair) only worked when all extensions are grouped into a shared executable
<jow>
that was the rationale
<jow>
I think it's the only project aiming to be an alternative frontend to libxtables (like a hypothetical iptables-uci) and thus it requires a kind of deeper integration slightly surpassing what's possible through the official api (without hacks)
<jow>
others either wrap the iptables or iptables-restore executables in some way or build the internal match/target structs directly
<jow>
while fw3 ideally would do the latter, it would basically imply rewriting code for the userspace part of all used extensions
<jow>
and it would not support stuff like `option extra` where you can blend in arbitrary iptables argument without some serious work to replicate iptables' option parsing logic, leading to yet more (logically) duplicated code
<jow>
the TL;DR versions is that we basically want to do multiple passes using the libxtables api and there's no official/public interface to reset the match and target parser state in between
<jow>
and using dlclose() is no option since musl does not support it
arinc9 has quit [Remote host closed the connection]
<jow>
and in order to capture libxtables extension load attempts, we need to be able to use dlsym(RTLD_NEXT, ...) to hijack it's xtables_register_match() and xtables_register_target() functions
rsalvaterra_ has joined #openwrt-devel
rsalvaterra_ is now known as rsalvaterra
arinc9 has joined #openwrt-devel
<jow>
being able to reset the parser state was also required for error recovery
<jow>
while all official iptables frontends simply abort on parse errors, we just wanted to skip the current rule being constructed and simply continue with the next
<jow>
various attempts at using setjmp() / longjump() to break out of the xtables fatal error routines were unsuccessful due to opaque internal state in libxtables
<jow>
but thinking about it, it is indeed likely that we do not strictly need the libiptext.so approach for that to work, the current implementation model will properly deal with dlopen'd extensions
<jow>
but it might be that the overhead of having *any* extension separate compared to having the most common ones lumped together is significant
<jow>
could also be that 7 years ago there was no option (or I was not aware of it) to move *all* extensions into separate shared objects
<nick[m]1234>
"we do not strictly need the libiptext.so " ? So back to statically linked?
<jow>
no to "have *everything* as separate "lib{ipt,ip6t,xt}_*.so"
<nick[m]1234>
Btw, I just added "TARGET_CFLAGS += -DO_SHARED_LIBS" to libiptext. Did not help. However, maybe I did something wrong.
<jow>
it'll be a somewhat larger operation
<jow>
I'd not involve upstream at all for this and instead find a clean(er) way to handle it on our end
<jow>
have to run, sorry
<nick[m]1234>
jow: I see. thanks. however, with the introduction of firewall4, would you do this large rewrite?