<rsalvaterra>
mangix: A bit long in the tooth. In-order.
<aleksander>
hey everyone; back again with netifd and the modemmanager protocol handler; trying to find the best way to let netifd know that the underlying network interface is no longer connected (something that MM can detect). Is there any way we can notify netifd that the real network interface is no longer connected so that it reports the netifd interface also as disconnected? (and so that autoconnect works)
<aleksander>
right now, if the modem gets disconnected ModemManager will know that, but netifd still says the interface is connected, so it will never trigger a reconnection
<jow>
aleksander: I think you need to send an update
<jow>
that should tell netifd that the logical interface "$ifname" should be teared down
<aleksander>
jow but where do I add those lines? the modemmanager protocol handler implements setup and teardown; and I would need to send that asynchrnously out of those
<f00b4r0>
hmm, if I select coova-chilli in buildroot I do get kmod-ipt-coova. How comes I can't find it in the official repo?
xback has joined #openwrt-devel
<aleksander>
jow, or can any other process call those lines?
<jow>
aleksander: any process should be able to call those
<jow>
they translate to ubus calls behind the scenes
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aleksander>
jow, ah! lovely; I think I can then integrate that as part of MM
<jow>
just source /lib/netifd/netifd-proto.sh
<aleksander>
thanks, that's a nice way forward
nlowe has joined #openwrt-devel
<jow>
f00b4r0: I suppose due to the deps. kmod-ipt-coova depends on (not selects) coova-chilli
<f00b4r0>
jow: so it would never be built by the buildslaves? darn.
<jow>
f00b4r0: since phase1 builds CONFIG_ALL_KMODS=y but does not select coova-chilli, it'll never get enabled
<f00b4r0>
I think this dependency is broken. There's no reason why the ipt module should depend on the userspace executable
pmelange has left #openwrt-devel [#openwrt-devel]
<jow>
it is. it likely was added for cosmetic reasons
<jow>
(menuconfig layout)
<jow>
you can simply drop it
<f00b4r0>
OK. But in the meantime the kmod isn't in the repo and that breaks my imagebuilder script :P
<f00b4r0>
hmm. It looks worse than that. The Build/Configure select different build options for the executable depending on whether or not the kmod package is enabled.
<f00b4r0>
*sigh*. Chilli is such a trashcan ;P
hgl- is now known as hgl
<hgl>
jow, I'm trying to add xfrm interface support to LuCI, but an xfrm interface usually requires two "config interface", one for the proto, the other the static IP, and LuCI shows them as two interfaces in the Interfaces page. I wonder if it's possible to merge them in LuCI?
danitool has quit [Ping timeout: 480 seconds]
* rsalvaterra
looks at the source…
<rsalvaterra>
f00b4r0: Why the hell does coova need a *kernel module*…? o_O
danitool has joined #openwrt-devel
<f00b4r0>
rsalvaterra: offloading of sorts
<f00b4r0>
allows authenticated traffic to go from turtle speed to decent.
<rsalvaterra>
It feels seriously wrong, though.
<f00b4r0>
that's because it is ;P
<rsalvaterra>
:)
KGB-0 has quit [Ping timeout: 480 seconds]
<jow>
hgl: no, it is not possible to merge them
<jow>
hgl: if it appears weird in the ui it is an indication that the underlying configuration is not really clean either
<jow>
maybe xfrm should be reimplemented as device configuration
<jow>
in some cases proto handlers have been abused to implement device config (such as spawning tunnels)
<jow>
I do understand that it does not solve your problem at hand though. But somehow logically merging these ifaces would require hacks in various layers of LuCI
<stintel>
xfrm and vti are weird in uci yes
<jow>
I think they should become config device types
<jow>
this requires adding C code unfoetunately
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
<hgl>
jow, I guess I should just submit xfrm.js, so LuCI can at least show stuff like TX & RX? Or it should happen after xfrm config cleanup?
dedeckeh has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
piraty_ has joined #openwrt-devel
dangole has joined #openwrt-devel
piraty_ has quit []
piraty_ has joined #openwrt-devel
KGB-0 has joined #openwrt-devel
Piraty has quit [Ping timeout: 480 seconds]
<dangole>
dwmw2: any chance you could check the offset the env was writtin to /dev/mmcblk0p1 on the U7623? hexdump should tell, but as the partition is only 2MIB total, you can also just send the whole thing to me to have a look.
<dwmw2>
Ah, you're back :)
<dwmw2>
It's at 0xc0000. I had a fw_env.conf which said 0xb0000. Rebuilt and reflashed and it seems better now
<dwmw2>
*BUT* I don't see anything that attempts to write the MAC address to the environment, or get it from there.
<dwmw2>
It used to go in a file in the recovery partition, but you've deleted that part.
<dwmw2>
I'm frowning at the third PCIe port now and trying to work out how to enable it
<dwmw2>
oh, that may be a stupid error on my part
<dangole>
dwmw2: U-Boot read the variable ethaddr and applies to device tree before starting Linux, in that way it is inhertied. and yes, nothing is writing it, because writing it automatically without a good source of randomness didn't seem a good idea, but maybe we can do that now that fw_setenv should work, e.g. after some huge delay after boot, to have better chances for entropy
<dangole>
dwmw2: (for that to work there needs to be an alias set for ethernet0 in the fdt U-Boot is feeding to Linux, I have added that as well)
Tapper has joined #openwrt-devel
<jow>
hgl: yeah, submit the current state of work to gather feedback
<dwmw2>
I don't think we should get too hung up on the randomness.
<dwmw2>
The kernel will assign a random MAC at boot time.
<dwmw2>
If you really want to *wait* until we have a decent amount of entropy and then generate a "more random" MAC, that would involve *changing* the MAC once it's running. Or on the next boot, which is precisely what we're trying to *avoid*
<rsalvaterra>
kabel: Turris Omnia, although offline at the moment.
<dangole>
dwmw2: i've added a script to /etc/uci-defaults to make the ethaddr persistent on all mediatek devboards (u7623, r2, r64). tested on r2 and r64.
<dangole>
dwmw2: also chose correct AHCI kernel module and picked your commit enabling pcie0 to get SATA to work
<dangole>
dwmw2: anything else missing?
<dangole>
kabel: i got iEi Puzzle M901 and M902 sitting on my desk (ie. CN913x with some AQR copper phys)
<dangole>
dwmw2: the button is yet not wired up in U-Boot, i might do that later on to allow resetting env and booting recovery image by holding button (using a GPIO-connected button on the R2 for testing)
<kabel>
dangole: and one also for cortexa72 (not yet done, will send link. But basically there are unneeded kernel config options for cortexa72 target: armada 37xx drivers are enabled, which are cortexa53 specific)
<kabel>
rsalvaterra: as for turris omnia, I am going to try to make the SFP cage hotpluggable, without need to reboot the board
<rsalvaterra>
kabel: Yay, finally a cortex-a9-specific kconfig! :)
<kabel>
rsalvaterra: are you able to test this afterwards? this will probably take some time
<kabel>
anyone here using ESPRESSObin? :)
<rsalvaterra>
kabel: Sure, I can give it a spin on my Omnia. I don't have any 64-bit MVEBU targets, though.
<dangole>
stintel: genuine Ubiquiti 802.3at injector arrived today. and works only with 1G link with UniFi 6 LR, 2.5G doesn't come up (with Intel X550T on the other side) :(
<dangole>
stintel: you were using a multigig PoE switch to try, i suppose...
<rsalvaterra>
dangole: Ouch. That really sucks… :(
<kabel>
dangole: I also have Puzzle M902 for testing, and CN9130-CRB
<kabel>
dangole: I need to do some throughput tests on the Puzzle
<dangole>
rsalvaterra: yeah, 20 eur spent for nothing.... annoying, but not the end of the world.
<kabel>
dangole: I wasn't able to achieve 10Gbps from one 10G port to another, with iperf :(
<kabel>
dangole: I want to try with XDP
<kabel>
dangole: did you do some performance tests?
<dangole>
kabel: no, i just make sure links do come up at all supported speeds and fixed platform basics, ie. imported driver for uC controlling LEDs and fan and providing hwmon temperature sensor
<stintel>
dangole: yes, Huawei S6720-32C-PWH-SI
<dangole>
kabel: i only have one fast system with 10GE nic, that makes it difficult to test throughput (i would need another fast box with 10GE nic on the other side)
<kabel>
dangole: I tested from one port on the puzzle to the other :)
<stintel>
dangole: but don't you need 802.3bt for >1GbE PoE ?
<kabel>
dangole: ~6Gbps
<kabel>
dangole: but all rx interrupts went to core 0, I think this can be somehow balanced, with multiple streams
<stintel>
yes, 802.3bt introduced support for 2.5GBASE-T, 5GBASE-T and 10GBASE-T
<dangole>
kabel: ah ok, running both iperf instances on the device itself. then 6Gbps is quite nice actually :)
<dangole>
stintel: ok, i guess i have to hunt for 802.3bt injector then...
<kabel>
dangole: well, core 0 was at 100%, core 1 at 50%, cores 2 and 3 at 0% :)
<dangole>
kabel: try installing 'irqbalance' (and configure it), so irqs get distributed to all cores
<kabel>
dangole: I want to try DPDK, and also writing some XDP routing apps. I am certain it can achieve more
<kabel>
dangole: yes, irqbalance + other things needs to be configure in kernel
<dwmw2>
dangole: sounds good; refetching and rebuilding now to test. Can we go back to having the debate about removing the support for upgrading from legacy? :)
minimal has joined #openwrt-devel
<dwmw2>
SP Flash tool is a *pain*, and requires having the preloader in a file.
<dwmw2>
I would *like* to make the binary preloader available for download, just like the BPi ones. But haven't yet.
c0sm1cSlug has joined #openwrt-devel
<dwmw2>
And the flash tool is *still* a pain. I'd really like to support in-place upgrade from the OpenWrt that the vendor ships on it (and from stock 19.07)
<dwmw2>
I'll test the R2 and R64 too. Do you believe it all does the right thing for both eMMC and SD installation on those? With Linux/OpenWrt automatically using fwcfg on the correct device>?
<dwmw2>
And do we still have the "Install to internal eMMC" option when we boot from an SD card?
Tapper has quit [Read error: No route to host]
<dwmw2>
Also, is there a reason we have to see that 'bad CRC' message on the first boot? Why can't we put a valid environment into the image that gets flashed?
Tapper has joined #openwrt-devel
<dwmw2>
MAC address works nicely now; thanks
<dangole>
dwmw2: yes, there is an option in the bootmenu to trigger installation to eMMC (or SPI-NAND) from U-Boot. it can also be triggered by changing bootcmd using fw_setenv from within OpenWrt.
<dangole>
dwmw2: regarding sysupgrade on existing boards: as the previous sysupgrade format used to be whole-flash eMMC image, when updating from vendor firmware (or old OpenWrt), can't we just tell users to use the *-emmc.bin.gz file?
<dangole>
dwmw2: It's a one-way road at this point, obviously. going back is more difficult.
russm has quit [Ping timeout: 480 seconds]
<dwmw2>
no, the old sysupgrade format isn't the whole-flash
<dangole>
dwmw2: I guess the easiest way would be to just write the *-emmc.bin via dd straight to the eMMC then. if needed i can hack up a script users can just run which will patch /lib/upgrade/platform.sh and actually do whole-flash write :)
<dwmw2>
well, that's what sysupgrade does. It should unmount or mount r/o, then run from a ramdisk while it overwrites the system, etc.
<dwmw2>
Which is why I was careful just to make an image that the existing sysupgrade would cope with.
<dwmw2>
Being able to flash it from the web is definitely a win.
<dangole>
dwmw2: i agree, but it's a devboard and as you can see, this compatibility required ~400 lines of shell code... replacing /lib/upgrade/platform.sh on existing installations would allow to still umount everything properly and switch to ramdisk for flashing...
<dwmw2>
Sure, but it's ~400 lines of shell code I already wrote and tested, that was working :)
<dwmw2>
Actually it's closer to 40. And most of those are comments. It's some variable settings, then more like 4 lines; the dd lines I pasted above.
<dangole>
dwmw2: i just hope to get rid of all those endless duplications of get_sdcard_img.sh scripts, generating arbitrary things like FAT partitions as if it was an IBM PC in the 80s...
<dangole>
dwmw2: and all this is duplicated over and over again, standing in the way of a decent more-embedded-like boot approach (ie. validated squashfs and dual-boot).
<dangole>
dwmw2: like, i understand this on x86, and i can see how it happened to the bcm27xx rasbpi targets
<dwmw2>
Yeah. I suppose as long as there is a tested and documented way to upgrade, that's fine.
<dangole>
dwmw2: 8 files changed, 40 insertions(+), 512 deletions(-) btw. and yes, there are about 420 of the removed lines are non-comments....
<FLD>
is there a way to get more debug information for device bring up than just: "Error: Unknown error (DEVICE_CLAIM_FAILED)" ?
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
russm has joined #openwrt-devel
<dwmw2>
dangole: although much of that isn't just the legacy imagge creation
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<f00b4r0>
jow: in jshn.sh I understand that json_get_keys will perform string modification on the keys, so that when the keys are mac addresses, semicolons are replaced with underscores in the resulting variable. Is there a way to avoid that and get the raw JSON data?
<f00b4r0>
(parsing the output of hostapd.wlan0 get_clients
srslypascal is now known as Guest244
srslypascal has joined #openwrt-devel
Guest244 has quit [Ping timeout: 480 seconds]
<dangole>
dwmw2: i've updated my tree and added instructions for users of existing installations or vendor firmware to the commit description. i'll also add it to the wiki once merged.
<dwmw2>
I shall reinstall the vendor firmware and test :)
<dwmw2>
thanks
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
dangole_ has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
snh_ has joined #openwrt-devel
valku has joined #openwrt-devel
dangole_ is now known as dangole
snh has quit [Read error: Connection reset by peer]
<dangole>
dwmw2: just thinking, we could also add support for EMMC whole flash image to sysupgrade in 21.02 tree, so next 21.02 release would allow for a smooth upgrade path to 22.xx on the U7623
snh_ has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
GNUmoon has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
GNUmoon has quit [Remote host closed the connection]
snh_ has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
<hurricos>
I am told that DEVICE_PACKAGES are not built into the OpenWrt initramfs by default / by the OpenWrt builders (though you can make them so if you just build one board).
<hurricos>
I'm guessing it's just the per-device DEVICE_PACKAGES this applies to?
GNUmoon has joined #openwrt-devel
<hurricos>
If not, how do packages get added to the OpenWrt initramfs?
<hurricos>
Oh, I think chunkeey already answered the question when he posed it:
<hurricos>
> Unfortunately the OpenWrt builders' way of creating all images at once has the limitation that there's effectively a per-subtarget base-installation, any of the DEVICE_PACKAGES are not included.
<aparcar>
jow: reading this, don't you think we can enable custom packages even for snapshots? In case there are overlaps it
<aparcar>
it's shared anyway
<aparcar>
it uses some md5 checksum "caching"
<aparcar>
nbd: thoughts?
felix has quit []
felix has joined #openwrt-devel
Borromini has joined #openwrt-devel
<jow>
aparcar: not sure what you mean
<jow>
f00b4r0: unfortunately there is no way, the original key data is lost at this point
<f00b4r0>
jow: ok, thanks. For mac addresses I can always revert the change, especially now that I know ash supports pattern substitution in variables :)
<jow>
depending on what you intend to do, jsonfilter might be a suitable replacement, it also allows exporting values in a format suitable for shell eval
<dansan>
My sys.process.list() isn't returning anything (process list view in in LuCI empty). How can I get debug messages from server-side lua code? Do I just need to open a file and write to it for debug messages?
<dansan>
i.e., ubus call luci getProcessList {} returns an empty result array
Borromini has left #openwrt-devel [#openwrt-devel]
philipp64 has quit [Quit: philipp64]
srslypascal has quit [Quit: Leaving]
GNUmoon has joined #openwrt-devel
srslypascal has joined #openwrt-devel
GNUmoon has quit [Quit: Leaving]
GNUmoon has joined #openwrt-devel
<karlp>
dansan: opening a file and writing is about all I've ever done, yeah.
<dansan>
karlp: thank you. I was trying to export a logging function from uhttpd, but I guess I don't know enough about lua to know 1.) how to properly access it and 2.) what to do if we don't have that function exported.
<dansan>
I really wish there was an (up-to-date) high-level document for LuCI that detailed the flow of information, from client-side javascript, to lua code and including every step in between. uhttpd could also use an optional "access" log -- maybe even just written to a unix socket so it doesn't use memory when nobody's using it.
<dangole>
dwmw2: pushed update to U-Boot 2022.01 on top of my staging tree after testing on R2 and R64 in all boot modes and works fine. would be cool if you can test on the U7623 as well :)
philipp64 has joined #openwrt-devel
<digitalcircuit>
I'm currently compiling a fresh build of Ansuel's 5.15 + DSA PR to try my crash test script on that.
<digitalcircuit>
Regarding https://github.com/digitalcircuit/openwrt-ipq806x-qa-cpu-reset , I am not dead yet! I've gotten the second ZyXEL NBG6817 from a family member (they temporarily don't need it), so I can now take offline my previously-primary NBG6817 that I've soldered on serial headers, letting me run any kind of testing without disrupting the home Internet.
<digitalcircuit>
(Thankfully, backup/restore works flawlessly. Backup on the primary NBG6817, reset the second one, restore, and I could just swap the routers out seamlessly.)
<slh>
good luck :)
philipp64 has quit [Quit: philipp64]
<digitalcircuit>
slh: Thanks! And I appreciate your/others' patience, too.