srslypascal has quit [Remote host closed the connection]
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
slh has quit [Remote host closed the connection]
slh64 has quit [Quit: gone]
danitool has quit [Ping timeout: 480 seconds]
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
valku1 has joined #openwrt-devel
valku has quit [Read error: Connection reset by peer]
valku1 is now known as valku
valku has quit []
valku has joined #openwrt-devel
valku has quit []
srslypascal has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
slh64 has quit [Remote host closed the connection]
slh64 has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
svanheule has quit [Quit: svanheule]
svanheule has joined #openwrt-devel
srslypascal has joined #openwrt-devel
rua has joined #openwrt-devel
svanheule has quit [Quit: svanheule]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
svanheule has joined #openwrt-devel
<dwfreed>
Lechu: assoc for an AP means it's active and can be used
<dwfreed>
hmm, maybe your description is accurate? at least according to the wiki it should be
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<dwfreed>
Lechu: tested with my own AP and assoc did nothing like you described, so not sure if it's broken or not; unless you have a lot of clients coming and going, it's probably better to have one led for "ready" and one for throughput
<dwfreed>
Lechu: I use the netdev link on trigger for "ready" (because it won't come up until after DFS is done and the AP is ready to start handling clients), and then tx/rx netdev for throughput (blinks faster, more responsive to changes); phy*tpt is a slow steady blink for activity according to wiki if you prefer that
<dwfreed>
the ID probably isn't specific enough? considering the surrounding ones have 8 byte IDs
<dwfreed>
and that one is only 4
rsalvaterra has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
<Namidairo>
*checks datasheet*
<rsalvaterra>
dwfreed: Right. Given the situation, I believe reverting is the obvious solution for now.
<rsalvaterra>
It's the difference between a working and a non-working system.
<Namidairo>
explains I didn't run into it
<Namidairo>
*explains why
<rsalvaterra>
Not all Redmi AC2100 have Toshiba NAND. Some of them are ESMT.
<dwfreed>
2022-05-29 09:31:34 < dwfreed> the ID probably isn't specific enough? considering the surrounding ones have 8 byte IDs
<dwfreed>
2022-05-29 09:31:46 < dwfreed> and that one is only 4
<dwfreed>
rsalvaterra: what you missed while you were pinged out ^
<neggles>
dwfreed: yeah, it's missing 0x72
<neggles>
not sure where the last 3 bytes come from
<rsalvaterra>
Oh, I missed that indeed.
* rsalvaterra
was replacing the Omnia with the Redmi. :P
<neggles>
TC58NVG0S3HTA00 ID bytes are 0x98 0xf1 0x80 0x15 0x72
<neggles>
TC58BVG0S3HTA00 is 0x98 0xf1 0x80 0x15 0xf2
<Borromini>
rsalvaterra: i might be able to free up an MT7621 device if you still need testing
<Borromini>
gotta get my RB5009UG going again first though =)
GNUmoon has joined #openwrt-devel
<castiel652>
right. I am blind lol. missed that one different letter.
<Namidairo>
that's why the B was bolded
rua has joined #openwrt-devel
rsalvaterra_ has joined #openwrt-devel
rsalvaterra_ is now known as rsalvaterra
<neggles>
heh
<neggles>
i replied to thread :)
<neggles>
aw jeez it's an upstream problem
<Namidairo>
yeah I was just looking into that too
<f00b4r0>
hmm. Nanopi R2S is causing "frame too long" errors on my switch, despite MTU being classic 1500. /me scratches head
<Borromini>
f00b4r0: and 1492?
<f00b4r0>
Borromini: ?
<Borromini>
lowering the MTU?
<f00b4r0>
i can try, but regardless, 1500 is correct and shouldn't cause FTL
<Borromini>
ok
<f00b4r0>
then again, realtek NICs ;P
<dwfreed>
connect it directly to another device that can do jumbo frames and then tcpdump?
<f00b4r0>
that wouldn't work, the errors appear to be random (depending on traffic I assume), so I need a way to replicate said traffic
<dwfreed>
have the other device serve as a man in the middle
<dwfreed>
then tell tcpdump to capture any frame larger than 1500
<neggles>
f00b4r0: which port on the R2S?
<f00b4r0>
LAN
<neggles>
that's the USB3.0 one right
<f00b4r0>
iirc yes
<neggles>
interesting
<neggles>
are you running VLANs?
<f00b4r0>
i am
<neggles>
heh.
<neggles>
if you have an iperf3 server you can connect to, try iperf3 -c serverip -S 0xb0
<neggles>
see if that makes it lose its shit
<f00b4r0>
but I'm running tcpdump on the device and I'm indeed seeing weird stuff. e.g. packets with length 2048
<f00b4r0>
unless I'm confused with tcpdump output
<neggles>
f00b4r0: so my theory here is "mismatched L2/L3 MTUs"
<neggles>
for L3MTU=1500, L2MTU w/o VLANs is 1510, and with is 1514, or QinQ'd is 1518
<neggles>
(the iperf suggestion was wrong, i forgot that DSCP is inside the IP header, not eth header)
<f00b4r0>
ran your iperf3 command on LAN: no prob
<neggles>
yeah I got mixed up on header bytes
<neggles>
but if something's being dumb and you've ended up stacking two VLAN tags
<dwfreed>
f00b4r0: tcpdump might be showing the pre segment offloading
<neggles>
that'd give you an L3MTU=1500 packet which is still too long at L2
<f00b4r0>
dwfreed: i see. Hence the need for a middleman
<dwfreed>
yeah
<f00b4r0>
neggles: the switch considers jumbo frames starting at 1518
<f00b4r0>
well, 1519 in fact
<dwfreed>
if you've got real fancy equipment, you could put a logic analyzer on the lines, but just tcpdumping in on a mitm that can do jumbo frames is probably sufficient
<neggles>
f00b4r0: if the switch is intelligent enough to tell you about packets that are too long, it should be able to mirror a port / dump said packets, no?
<f00b4r0>
dwfreed: makes sense. It's a remote setup so this kind of experiment will have to wait I guess. Port mirroring wouldn't do because then I couldn't remotely connect to the middleman
rua has quit [Ping timeout: 480 seconds]
<neggles>
ah
<f00b4r0>
neggles: heh :
<f00b4r0>
:)
<neggles>
touche, sir
<f00b4r0>
interestingly it's only the R2S' lan NIC that triggers thsi
rua has joined #openwrt-devel
<neggles>
there's probably something stupid happening in the driver
<f00b4r0>
the WAN also goes through the switch (for $reasons) and no errors there. No errors on any other connected device
<dwfreed>
like segment offloading not actually happening
<f00b4r0>
^
<dwfreed>
that's something you could try; turn off all the transmit-side offloading with ethtool
<dwfreed>
see if the issue goes away
<neggles>
oh and... flow control?
<dwfreed>
eh, flow control isn't super important unless you're saturating the link super hardcore
<f00b4r0>
so tso and gso basically?
<dwfreed>
most switches can do linerate on all ports
<dwfreed>
f00b4r0: yeah
<neggles>
dwfreed: oh no no i mean
<neggles>
the NIC might be sending pause frames
<neggles>
...badly
<dwfreed>
oh, eww
<f00b4r0>
turned off, let's see if this keeps happening
<neggles>
what switch is it?
<f00b4r0>
neggles: Zyxel GS-2210 iirc
<f00b4r0>
yes, confirmed
<neggles>
hm. no idea what their software is like
<neggles>
some stuff you can run tcpdump on or configure to accept a too-long packet + print the contents of it to the log
<neggles>
how frequently does it happen though
<f00b4r0>
looks fairly random
<neggles>
¯\_(ツ)_/¯
<neggles>
must be pixies
svanheule has quit [Ping timeout: 480 seconds]
<f00b4r0>
what bugs me is that the large packets tcpdump captured seem to come from LAN clients, but these clients are also running with MTU 1500 so I'm not sure how a 2048 packet even occurs on the router?
<dwfreed>
there's a receive side segment reassembly
<f00b4r0>
ah, right
<f00b4r0>
according to tcpdump this seem to only occur with ipv6 connections
<f00b4r0>
ah no, scratch that :)
svanheule has joined #openwrt-devel
<f00b4r0>
error still happening with tso/gso off, *sigh*
<f00b4r0>
maybe it's a cable problem, as odd as it would be
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
goliath has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
robimarko has quit [Ping timeout: 480 seconds]
cbeznea1 has joined #openwrt-devel
valku has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
Borromini has quit [Ping timeout: 480 seconds]
schwicht has joined #openwrt-devel
<Lechu>
dwfreed: thing is: I couldn't see it blink when I forced one station to repeatedly connect and disconnect to an AP ;-)
minimal has joined #openwrt-devel
<enyc>
hrrm I wonder what sort of pragmatism is needed for https://github.com/openwrt/openwrt/issues/9956 from the OpenWRT side of things... e.g. just don't include the sdio kmod whatnot in the default image for 22.03.0 ?
<enyc>
The 3rd radio really is not needed, but do need it so the 5ghz radio can be configured and work without falling over and failing needlessly if it happens to be on a DFS channel.
dannyAAM has quit [Quit: znc.saru.moe : ZNC 1.6.2 - http://znc.in]
dannyAAM has joined #openwrt-devel
rua1 has quit [Ping timeout: 480 seconds]
yk has joined #openwrt-devel
<yk>
Hi devs
rua has joined #openwrt-devel
SamantazFox has joined #openwrt-devel
yk has quit [Quit: Page closed]
* enyc
meeps
<dwfreed>
Lechu: yeah, same, I have different SSIDs for each radio, and changed one set of LED's to my 2.4 radio's assoc trigger, and repeatedly swapped my phone between 2.4 and 5, and got nothing
<dwfreed>
Lechu: assoc might just be broken
ekathva has joined #openwrt-devel
Borromin1 is now known as Borromini
minimal has quit [Quit: Leaving]
Borromini has quit [Quit: Lost terminal]
<hurricos1>
mrnuke: why have you chosen to commit what you've committed against your openwrt repo?
<hurricos1>
why not call it something different? :P
<hurricos1>
ah
<hurricos1>
because that would be you doing the job I said I'd do and still haven't done ._. lmao
<hurricos1>
aiee
<mrnuke>
too lazy to create new repo when I have one already there!
<hurricos1>
hahahaha fair shake
<mrnuke>
BTW, can someone explain the difference on rtl8380 between declaring an sfp with 'compatible = "sff,sfp" ' versus using the "SWITCH_SFP_PORT()" macro?
<aparcar[m]>
hauke: if you find the time please have a look on how to speed up the qemu bootup times