<neggles>
when you pull the CC pins up to VCC with a specific pair of resistances, it exposes the Cr50's debug USB interface on SBU1 and SBU2; that little board has the right resistors and the micro-USB is hooked to the SBU pins
<neggles>
google sold a cable for this, SuzyQable, with a USB hub chip in it so you can access the CCD USB as well as the regular one at the same time, but the USB hub chip they chose is out of stock until "uhh....." so it's been discontinued, so i had to make my own
<nbd>
it disabled amsdu capab for all interfaces if CONFIG_MESH is disabled
<xback>
nbd: ow .. right!
<xback>
nbd: thanks for checking that fast
<xback>
nbd: should be better .. https://git.openwrt.org/?p=openwrt/staging/xback.git;a=blobdiff;f=package/kernel/mac80211/patches/subsys/800-mac80211-mask-nested-A-MSDU-support-for-mesh.patch;h=e7da94c9cdaf5bf85600ae95a647e8b94dc5ae11;hp=415c6dfb803639cd726ee3f9b35359712b3e075d;hb=b1ef0b4999ac40d6de5113bb7681024a0d9bcc25;hpb=ab077301969b8a25ac7403eecdc490fbde673782
<nbd>
yep
schwicht has joined #openwrt-devel
<karlp>
neggles: cool thanks, is that standard usb-c debug mode or is that a google variat?
felix_ has joined #openwrt-devel
felix has quit [Read error: Connection reset by peer]
bluew has quit [Ping timeout: 480 seconds]
xback has quit [Remote host closed the connection]
rua has joined #openwrt-devel
borek has joined #openwrt-devel
borek1 has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
borek1 is now known as borek
danitool has quit [Remote host closed the connection]
<neggles>
karlp: it's standards-compliant
<neggles>
the standard is quite loose, though
<neggles>
normal usb-c operating modes only pull one CC line, or put an e-marker chip across both, and that's how orientation detection is handled
<neggles>
if you pull both CC lines high, or both low, that's debug accessory mode
<neggles>
in debug accessory mode all of the data line pins are undefined and can be used for whatever you want
<PaulFertser>
btw, it hurts me to look at that picture, feels like the dongle can get broken off any time
<neggles>
heh
<neggles>
i did break one already
<neggles>
so now i'm using a very light cable and it's supported by the QuartzPro64 sitting next to it :P
schwicht has quit [Ping timeout: 480 seconds]
<neggles>
even with the PCB and shipping costs they cost maybe $3 so it's not a big deal, it's just annoying that it has to be a 0.7mm thick PCB
<neggles>
all of the type-C connectors that expose both SBU/CC pins require a 0.7mm PCB, save for a couple which have a hidden row of pins that would *suck* to reflow by hand
schwicht has joined #openwrt-devel
<neggles>
probably should've made it shorter, but i made two designs, one with an 80 cent usb hub chip on it
<neggles>
Macs with type-C use this + special debug messges sent over USB-PD to mux out a bunch of UARTs, some JTAG, and a couple of USB device endpoints in this mode, kinda neat
<neggles>
chromebook CCD is actually quite tame, it only uses SBU1/SBU2 which are explicitly "do whatever you want with these" pins even in normal mode
srslypascal is now known as Guest2252
srslypascal has joined #openwrt-devel
schwicht has quit [Ping timeout: 480 seconds]
Guest2252 has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
Ansuel has joined #openwrt-devel
hanetzer has joined #openwrt-devel
schwicht has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<ynezz>
neggles: last time I've tried, there was no linux distro available for chromestar, did the situation changed lately?
<neggles>
ynezz: you can run a mostly-mainline kernel on these ones, MT8183, and if you're happy with using Depthcharge to load the kernel you can run any arm64 userland you like
<karlp>
neggles: if you want a stronger pcb, this happily exposes SBU and CC, (I'm using SBU on another project) and doesn't require a 0.7mm pcb. not sure where you got that limit from? GCT USB4105-GF-A (from mouser7digikey) or XKB u262-16 (all variants) from lcsc..
<neggles>
needs to be a male connector
<karlp>
oh, right.
<neggles>
standards-compliant USB-C cables don't have both CC lines connected
<neggles>
so you have to have the plug right there
<karlp>
I admit, I've not needed the male parts much :) but I do use SBU on our own stuff.
<neggles>
the GCT USB4155 is an option, along with various similar ones from XKB et al, but they're harder to solder
<karlp>
I take it you've got a board straddle one now, hence the thin pcb requirement?
<neggles>
yep
<karlp>
but easier to solder only one row on each side?
<neggles>
yahuh
<karlp>
faire nough, I'll leave you to it then :)
<neggles>
I did find one design where someone is abusing a vertical-mount
<neggles>
if you carefully straighten out the pins on a molex vertical-mount connector, it's got a ~1.2mm gap
<neggles>
and can be coerced into working with 1.6mm
<karlp>
meh, hand straightening things sounds worse.
<neggles>
it's not a big deal, just gotta be careful
xback has joined #openwrt-devel
<neggles>
maybe should've gone with the "just put pads on there and solder a cable to it" option
<neggles>
but it works :)
janvenekamp has joined #openwrt-devel
schwicht has quit [Ping timeout: 480 seconds]
<neggles>
worked first try, too!
schwicht has joined #openwrt-devel
<robimarko>
Mangix: Are you neheb on github?
<Habbie>
(yes)
<stintel>
robimarko: he is - it's transliteration of Пенев
<robimarko>
Ok, got me a bit confused
<stintel>
it's not just you :)
<robimarko>
Just wanted to let him know that SAE works with mbedtls now
<karlp>
in the past mbedtls was qutie a bit slower as well? no obvious issues with it?
<robimarko>
karlp: I havent tested performance, just whether it works
<robimarko>
I am getting 770 Mbps on my phone via speedtest, so not bad
<Ansuel>
main problem of mbedtls is no hw crypto support right?
<robimarko>
For certain it doesnt support ARMv8 crypto extensions
<robimarko>
But for those OpenSSL or WolfSSL are the ones to go for
<Ansuel>
honestly i would just install openssl for new target
<Ansuel>
we have the space sooo
goliath has joined #openwrt-devel
<svanheule>
Ansuel: I sent you a mail about the LED trigger offloading a while back, maybe it got lost. Feel free to leave some comments on the Realtek port LED patches I posted yesterday.
<Ansuel>
svanheule if i didn't answer it it probably got lost for some reason
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
robimarko has quit [Read error: No route to host]
robimarko has joined #openwrt-devel
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
<janvenekamp>
Hi. Back in august I submitted a patchset for uci.
<janvenekamp>
I have not received any feedback since. I was wondering if there is anything wrong with it?
<janvenekamp>
How do I go about?
<svanheule>
Ansuel: sent you an updated mail. I hope the summary of the Realtek port LED HW can help with designing a generic offloading interface.
minimal has joined #openwrt-devel
<Ansuel>
did you found by chance the generic implementation that i proposed at times?
<svanheule>
Ansuel: I did see it, but I haven't look at it since June/July
<svanheule>
I'll try to have a look this evening, see how it compares to my current implementation
<stintel>
janvenekamp: I guess nobody feels comfortable enough with UCI codebase to review / accept
<Mangix>
The error message is with lto-compiler. No idea if there's such a binary
<Ansuel>
i'm rebuilding everything
<Ansuel>
btw seems strange that it can be a parallel problem
hanetzer has joined #openwrt-devel
guidosarducci has joined #openwrt-devel
<Mangix>
What?
<Mangix>
The zstd+Ubuntu error is when compiling packages that use fLTO
<Mangix>
Not when compiling gcc
guidosarducci_ has quit [Ping timeout: 480 seconds]
gladiac has quit [Quit: k thx bye]
Gaspare has joined #openwrt-devel
<stintel>
anyone aware of broken sysupgrade on x86/64?
<stintel>
in master at least?
<stintel>
fails with ENOSPC, reboots without flashing
<stintel>
I've compared OpenWrt image size and VM storage image size, it's not too small, to be sure I also started over with a clean OpenWrt image, boot that, try sysupgrade, fails
cmonroe has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
minimalist has joined #openwrt-devel
minimal has quit [Read error: Connection reset by peer]
minimalist has quit [Remote host closed the connection]
<Ansuel>
stintel we should be able to repro that with qemu
Ansuel has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
Ansuel has joined #openwrt-devel
Ansuel has quit []
Ansuel has joined #openwrt-devel
Ansuel has quit []
Ansuel has joined #openwrt-devel
<jow>
[Pokey]: mk24 latest reply summarizes it very well
<[Pokey]>
jow: Indeed, my issue is resolved, but I don't know why my previous setup did not work and LuCI did not warn me about any incompatibility. It would be nice to understand why what I did didn't work and maybe if LuCI could detect this?
<jow>
there is little chance for LuCI to "detect" such issues
<jow>
the required complexity for recognizing all potential misconfigurations would far outweigh the complexity of the existing codebase
<[Pokey]>
Not even "this port is also in a bridge which is part of the interface. For (reason I don't understand) this isn't going to work"
Gaspare has quit [Quit: Gaspare]
Borromini has quit [Quit: Lost terminal]
<[Pokey]>
I'm also curious why it didn't work too
<jow>
"lower" devices enslaved into a bridge usually cannot do their own l3 communication anymore
<Ansuel>
Mangix btw i think i found a way to repro... mips work correctly but arm fails
<Mangix>
that is...interesting
<jow>
receveived packets destined for the lower device netdev will be "swallowed" by the bridge device netdev
<Mangix>
on fedora, my config is mipsel. on ubuntu, it's mips64
<jow>
and userspace software expecting to receive frames on the lower dev will never receive anything
<Ansuel>
Mangix i got the hint by checking the issue and the other guy also was compiling arm stuff
<Ansuel>
i'm checking by compiling ipq806x on ubuntu 22.04
<jow>
this is why things like dhcp clients etc. will never receive a lease
<jow>
when they operate on a netdev which is part of a bridge
Movedtomkg20001mkg20001io[m] has joined #openwrt-devel
mkg20001 has joined #openwrt-devel
nick[m]1 has joined #openwrt-devel
oliv3r[m] has joined #openwrt-devel
olmari has joined #openwrt-devel
pavlix has joined #openwrt-devel
schmars[m] has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
tohojo has joined #openwrt-devel
MatrixTravelerbot[m]1 has joined #openwrt-devel
whatevs111[m] has joined #openwrt-devel
will[m]1 has joined #openwrt-devel
znullptr[m] has joined #openwrt-devel
<[Pokey]>
jow: surely that suggests that whether or not it works is on a per device basis, and a flag could be included in the firmware to indicate so, so if a device is detected in a bridge it cannot be selected in any interface?
<[Pokey]>
Also am I right in thinking that this means devices are L2 and Interfaces are L3 and the only time that is not true is for the sake of WiFi networks, which have to be assigned to interfaces? And that would also mean the sole purpose of an Unmanaged interface is either to allow WiFi or to provide an interface for a custom Daemon to control such as OpenVPN?
<jow>
[Pokey]: probably a flag could be added, but that covers only one probably misconfiguration
<jow>
there's countless others
<[Pokey]>
jow: I do feel like that specific one is pretty important
<jow>
yeah because you've just encountered it
<jow>
others deems their recent misconfiguration to be important to handle
<[Pokey]>
Indeed, of course, just an entire device becomes unusable would be at the very least a good note on the bridge configuration modal
<jow>
yeah maybe, but as I wrote initially, the logic would be complex
<jow>
also not only in the modal, you'd also need to warn in the interface config when selecting an interface which is part of a bridge
<jow>
and when creating a rule
<jow>
*ip rule
<jow>
and when creating a route
<jow>
and when setting firewall zone device matches
<[Pokey]>
Fair, yea, there's a lot of places. Maybe I could add it to the Wiki?
<jow>
I do think a warning would make sense, I can't think of any constellation where assigning a bridge-port device to it's own logical network would be useful
<jow>
but I don't see it happening anytime soon unless someone provides a patch which in turn is highly unlikely as there's not many people experienced with the relevant openwrt/luci internals
<jow>
and those who are, do not require such warnings
<[Pokey]>
Just too much work to put it in the interface though I understand
<[Pokey]>
Yea
<[Pokey]>
I might have a peek as I know lua but no guarantees
<jow>
it's JS these days
<[Pokey]>
Oh fair
<jow>
at least all he relevant code is
<[Pokey]>
I know that too
<[Pokey]>
Hmm. Edge case? Can you put one in more than one bridge?
<[Pokey]>
Kinda pointless I know
<jow>
but it's not so much about the language, but about understanding LuCI's internal state and how to acquire the relevant data
<[Pokey]>
Yea
<jow>
no, on Linux a netdev cannot be part of more than one bridge
<[Pokey]>
And the only other edgecase I can think of is virtual ethernet for VLANs on one specific device
<jow>
as soon as ypu put a netdev such as eth0 into a bridge you can consider it "deaf"
<jow>
the containing bridge will receive all the frames for it
<jow>
the eth0 (or whatever) itself can tx but will not rx
<[Pokey]>
So you'd put the VLAN virtual ethernet on the bridge instead
<jow>
yes
<jow>
or you do a vlan on the netdev and put that into the bridge
<jow>
but that only works on some hardware
<jow>
(afair)
<[Pokey]>
New edgecase! XD
<[Pokey]>
I'll try that on all of my devices actually
<jow>
I honestly don't remember if that is supposed to work or not
Tapper1 has quit [Ping timeout: 480 seconds]
<[Pokey]>
I can't think why it wouldn't
<[Pokey]>
As soon as it comes out of that virtual interface it basically becomes untagged right?
<[Pokey]>
And tagged in the way in too
<jow>
consider eth0 having it's ip config etc.
<jow>
thne eth0.10 being part of a bridge
<jow>
now a frame arrives, vlan 10 tagged
<jow>
kernel has to decide where to deliver it
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<[Pokey]>
I'd consider eth0 at that point to just be a "virtual ethernet" equivalent which is configured for all untagged
<jow>
both eth0 and eth0.10 would be valid
<[Pokey]>
Not sure if the kernel would agree with my logic though
<jow>
in the former case it would nto end up in the bridge
<jow>
if I do tcpdump -i eth0 -e vlan I do see all vlan tagged traffic on eth0
<jow>
so I would expect that "eth0" sees all traffic
<jow>
even vlan tagged one
Ansuel has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
<[Pokey]>
Which also makes sense
<jow>
but that would mean that eth0.10 simulatenously within a bridge wouldn't work
<jow>
unless there's expections, which would be counter-intuitive
<[Pokey]>
You can't create a vether as untagged right?
<jow>
not sure what you mean with vether
<[Pokey]>
Virtual ethernet
<jow>
well there's macvlan
<[Pokey]>
I'm just being lazy
<jow>
which is yet another cna of worms
<[Pokey]>
Yea I don't have a clue with that
<[Pokey]>
All interesting things to consider
<[Pokey]>
Oh there was one other thing I was curious about. Why are WiFi devices restricted to interfaces and not bridges like ethernets
<jow>
due to their dynamic nature
<jow>
the resulting wireless interface name is not known in advance
<jow>
and some wireless operation modes might result in more than wireless interface name
<jow>
that's why you can't select wifi device from bridge config
<jow>
which means you can only indirectly attach logical wireless networks (which might result in 1+n arbitrarily named netdevs) to logical networks
<[Pokey]>
In that case if you wanted to connect an ethernet and a WiFi together but have the router not mess or interact with them you would need an unmanaged interface configured?
<jow>
which might either be "empty" l3 config containers or l3 config containers referring to a bridge device
<jow>
yes, you would need an unmananged dummy interface whose sole purpose would be holding a bridge the wifi can attach onto
<[Pokey]>
Nice, understood
<jow>
this specific requirement is an openwrt implementation detail though
<[Pokey]>
It literally is a case of interfaces being L3 except for that one circumstance then
<jow>
on a traditional linux system with bare hostapd you'd tell the target bridge device in the cnfig directly
<jow>
but in openwrt's netifd the ownership/refcount model for network entities requires bridge devices to have an "owner" in order to "come into existence"
<jow>
he3nce the need for unmananged dummy networks
<jow>
which complicates the ui design a lot
<[Pokey]>
Ah I get you. So OpenWRT does not command the kernel to create the bridge device if it is not "owned" by an interface
<jow>
because now you can potentially have multiple logical networks (unmananged or not) sharing the same bridge device
<[Pokey]>
Ye
<jow>
so you also can't fake assigining wifi's to bridges in the bridge config dialog because you don't know, from a ui pov, which transient logical network to use
<[Pokey]>
Would you agree the term "interface" is confusing?
<[Pokey]>
Or rather, misleading
<jow>
either create an unmananged one on demand, or reuse an existing one which happens to use the bridge device already or if there's multiple logical networks sharing the bridge device (think dhcp + dhcpv6) it's not clear which one to refer to in order to link a wifi-iface to a bridge
<jow>
yeah, there's some discussion on the ml
<[Pokey]>
Ah okay nice
<jow>
interface in luci is actually "logical network" (as in layer 3 config container)
<jow>
and device is linux netdev (as in "eth0") which people outside of openwrt usually refer to as "interface"
<[Pokey]>
That's what initially really confused me
<jow>
since we cannot simply swap or replace those terms in order to retain backwards compat, the way forward would be rebranding "interface" as "network"
<jow>
in luci and uci (while still accepting "interface" as keyword)
<[Pokey]>
That's exactly the word I expected after I learned what it actually meant
<jow>
and keeping "device" as "device"
<[Pokey]>
Yea
<jow>
there's some proposals to add versiong to configs in order to be able to introduce an entirely new vocabulary
<jow>
but imho this is not viable
<jow>
*versioning
<[Pokey]>
I'm guessing that the network config container you mention doesn't actually create any kind of Linux netdev under the hood, it's just a visual construct to represent the configuration OpenWRT will use to assemble and configure all the routing rules and daemons
<jow>
kind of
<jow>
the distrinction is blurred
<[Pokey]>
Hrm
<jow>
there's still "network" protocol handlers which do spawn netdevs or deal with l2 specific pecularities
<jow>
mainly due to the fact that in netifd "network" protocol handlers can be implemented in shell and shipped as runtime extensions
<jow>
while "device" type handlers require C code additions
<jow>
so the former was abused to achieve the altter
<jow>
arguably, gretap is a device type and not a "network" protocol
<jow>
or gre
<jow>
for l3 tunnels the question is particularily difficult
<[Pokey]>
It's not until you look at this you appreciate how much work OpenWRT does behind the scenes when you mash a button on LuCI
<jow>
due to their p2p nature, it does not really make sense to fully seaprate them into a l2 part and a l3 part, since you can't really run e.g. a dhcp client on the resulting tunX device
<[Pokey]>
That makes sense
<[Pokey]>
What would happen if you tried?
<jow>
afair it simply wouldn't work, the dhclient would get an EAFNOTSUPP or simular when attempting to bind to the netdev
<jow>
*similar
<jow>
there's also network protocol handlers that steer daemons which in turn do spawn netdevs
<jow>
such as ppp, openconnect
<[Pokey]>
Not too dissimilar to a VPN would I imagine
<jow>
yes
<jow>
anyhow, lots of food for thought, I do need to hit the bed now
<[Pokey]>
No worries, thank you for going into it all for me
<[Pokey]>
I will never properly have the time to master openwrt but I can site work slowly to get there