<grift>
a few days ago some tiny change to config-generate was pushed and selinux blocked the access which broke the network entirely. luckily I had that busybox patch applied because otherwise I would have been completely locked out
n3ph has quit [Quit: WeeChat 4.5.2]
KGB-2 has joined #openwrt-devel
n3ph has joined #openwrt-devel
n3ph has quit []
n3ph has joined #openwrt-devel
GATfly has joined #openwrt-devel
KGB-2 has quit [Quit: KGB-2]
KGB-2 has joined #openwrt-devel
GATfly has quit [Ping timeout: 480 seconds]
valku has joined #openwrt-devel
wvdakker has quit [Read error: Connection reset by peer]
wvdakker has joined #openwrt-devel
<f00b4r0>
nbd: just in case you can get me out of this: I'm trying to load a dead simple SCHED_CLS eBPF program using ucode-mod-bpf; open_module(), get_map() and get_program() all succeed but when I call tc_attach() on the target device, libbpf fails with "libbpf: Kernel error message: Cannot find specified filter chain"
<f00b4r0>
i suppose I'm missing something but coming empty handed on the google side
GATfly has joined #openwrt-devel
GATfly has quit [Ping timeout: 480 seconds]
GATfly has joined #openwrt-devel
<f00b4r0>
(if I load and attach the program by hand with bpftool it works, even more puzzling)
n3ph has quit [Ping timeout: 480 seconds]
GATfly has quit [Ping timeout: 480 seconds]
GATfly has joined #openwrt-devel
Lynx- has joined #openwrt-devel
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<dwfreed>
f00b4r0: strace bpftool to see what it's doing differently?
<f00b4r0>
that's an idea
<f00b4r0>
seem bpftool is issuing a bpf() call, whereas the ucode module goes the netlink route. They don't compare at all, *sigh*
<dwfreed>
ah
<dwfreed>
may have to look at the appropriate netlink code in the kernel then
<f00b4r0>
yeah I think I'll pass
<dwfreed>
or create it with bpftool, then inspect it via netlink
<f00b4r0>
i'd rather write a loader in C from scratch ;P
<dwfreed>
see if you can replicate what netlink shows
<f00b4r0>
I've also uncovered some maximally weird ucode behaviour, where the exact same line of code behaves differently depending on whether called directly (./test.uc) vs indirectly (test.uc require()'s a file containing that very same line)
<f00b4r0>
I guess I'm back to my usual habit of breaking corner cases ;P
merbanan has quit [Remote host closed the connection]
merbanan has joined #openwrt-devel
<f00b4r0>
(by "behaves differently", I mean in the first case it works, and in the second case it triggers a JIT compiler error ;P)
<dwfreed>
nice
<f00b4r0>
ha. I see the bpf prog name being truncated to 16-char in the ucode calls
<f00b4r0>
maybe that's that
goliath has quit [Quit: SIGSEGV]
<f00b4r0>
nope. Oh well, tomorrow is another day
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
danitool has joined #openwrt-devel
n3ph has joined #openwrt-devel
sorinello has quit [Ping timeout: 480 seconds]
GATfly has joined #openwrt-devel
cmonroe has joined #openwrt-devel
GATfly has quit [Ping timeout: 480 seconds]
minimal has quit [Quit: Leaving]
n3ph has quit [Ping timeout: 480 seconds]
n3ph has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
GATfly has joined #openwrt-devel
GATfly has quit [Ping timeout: 480 seconds]
GATfly has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
GATfly has quit [Read error: Connection timed out]