rmilecki has quit [Quit: Konversation terminated!]
rmilecki has joined #openwrt-devel
rmilecki has quit []
rmilecki has joined #openwrt-devel
<KanjiMonster>
russell--: weird that it succeeds with the second chip, but fails on the first one; one would think both are the same. is this main? have you tried older releases?
<KanjiMonster>
doesn't appear to be in any stable trees
<russell-->
same built works on a different device
<russell-->
i have a distant memory that i've had flash chips go bad on these before and somewhere i have a tube of replacements
<KanjiMonster>
russell--: have you looked at the commit and the linked email? looks like there are chip versions that don't support spdf, so maybe the first one doesn't and the second one does
<russell-->
oh, interesting
<russell-->
that might well explain it
<russell-->
i had a third device not come back up after a remote flash
<russell-->
maybe it also has the effected flash chips
<KanjiMonster>
the original report/patch is from someone with a tp-link wdr3600
n3ph has quit [Ping timeout: 480 seconds]
n3ph has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
<russell-->
looks like the fix didn't get backported?
skynet2 has joined #openwrt-devel
xback has quit [Ping timeout: 480 seconds]
xback has joined #openwrt-devel
rua has joined #openwrt-devel
rmilecki has quit [Quit: Konversation terminated!]
rmilecki has joined #openwrt-devel
rmilecki has quit []
rmilecki has joined #openwrt-devel
rmilecki has quit []
<russell-->
applied a hack patch derived from e9hack's patch locally, trying a new build to see if that fixes it
<stintel>
interesting that those packets are > MTU
<stintel>
so I enabled stderr in usteer init script and see this: Sat Oct 26 21:13:38 2024 daemon.err usteerd[4305]: sendmsg: Not a socket
<stintel>
hmmm but only once, and also with ipv6 disabled
<stintel>
so I guess that's just an initial message that is being sent before the socket is created properly
<stintel>
and the main issue is that using IPv6 the packet is not fragmented
<dwfreed>
is usteer setting dont_fragment or something?
<stintel>
not that I can see
<stintel>
the IPv4 code uses sendmsg, the IPv6 code uses sendto, looking at some docs currently
<dwfreed>
weird that it uses different send functions
<stintel>
written by different people :)
goliath has joined #openwrt-devel
<stintel>
I could just say fuck it and use IPv4 but that's broadcast, while on IPv6 it's multicast
<dwfreed>
probably worth stracing it to figure out why it's failing
<stintel>
couldn't find anything
<stintel>
then again I haven't done this kind of stuff in a while
<stintel>
I suspect it might just be the newer kernel that is behaving differently
<stintel>
I'm seeing ~15k BSS-TM-RESP in the logs of my 2 APs in my apartment in march this year
<stintel>
and I don't think hostapd will trigger bss transition requests by itself
<stintel>
I added MSG(NETWORK, "Sending IPv6 message on %s (len=%d)\n", interface_name(iface), blob_pad_len(data)); in interface_send_msg_v6
<stintel>
let's see
<stintel>
it's definitely sending the messages but the kernel silently drops them if they're > MTU
<stintel>
I don't even see sendto calls in strace, only sendmsg
<stintel>
but reading how musl handles all that gives me a major headache
<dwfreed>
musl is probably internally using sendmsg for sendto
<stintel>
yeah that's what I suspect
<dwfreed>
there is a note on the wikipedia page that IPv6 fragmentation does not have to be supported past 1,500 bytes
skynet2_ has joined #openwrt-devel
skynet2 has quit [Ping timeout: 480 seconds]
skynet2_ has quit []
skynet2 has joined #openwrt-devel
<Slimey>
blah cisco blah
<Slimey>
cert shenanigans
<stintel>
* get fragmented if they exceed the interface mtu
<stintel>
*/
<stintel>
#define IPV6_PMTUDISC_OMIT 5
<stintel>
ah paste fail
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<stintel>
* weaker version of IPV6_PMTUDISC_INTERFACE, which allows packets to
<stintel>
going to try and set that sockopt
goliath has quit [Quit: SIGSEGV]
<stintel>
no cigar
goliath has joined #openwrt-devel
<stintel>
grabbed a qca based AP and seeing same issue
<stintel>
it's sending packets over IPv6 until it learns enough clients, then packet too big and no longer appears in tcpdump (running on the AP itself)
<stintel>
haha and meanwhile the qca crap shat itself already