SlimeyX_ has joined #openwrt-devel
SlimeyX has quit [Ping timeout: 480 seconds]
SlimeyX_ is now known as SlimeyX
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
tlj has joined #openwrt-devel
minimal has joined #openwrt-devel
indy_ has quit [Remote host closed the connection]
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
indy has joined #openwrt-devel
Monkeh has quit [Remote host closed the connection]
Monkeh has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
minimal has quit [Quit: Leaving]
indy has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
valku has quit [Quit: valku]
indy has joined #openwrt-devel
slh_ has joined #openwrt-devel
slh has quit [Read error: No route to host]
slh64 has quit [Remote host closed the connection]
slh has joined #openwrt-devel
SamantazFox has joined #openwrt-devel
tlj has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #openwrt-devel
gladiac has joined #openwrt-devel
MaxSoniX has joined #openwrt-devel
digitalcircuit has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
SlimeyX_ has joined #openwrt-devel
indy_ has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
digitalcircuit has joined #openwrt-devel
SlimeyX has quit [Ping timeout: 480 seconds]
SlimeyX_ is now known as SlimeyX
gladiac is now known as Guest956
gladiac has joined #openwrt-devel
Guest956 has quit [Ping timeout: 480 seconds]
indy_ has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
cbeznea has joined #openwrt-devel
cmonroe has joined #openwrt-devel
cmonroe_ has quit [Ping timeout: 480 seconds]
gladiac has quit [Quit: k thx bye]
MaxSoniX has quit [Remote host closed the connection]
MaxSoniX has joined #openwrt-devel
goliath has joined #openwrt-devel
danitool has joined #openwrt-devel
<aparcar[m]> hurricos: so we should go with the two step renaming of PCI interfaces
winternull has joined #openwrt-devel
slh_ is now known as slh64
robimarko has joined #openwrt-devel
<mangix> anyone know about fit images?
<mangix> I'm all out of ideas regarding https://github.com/openwrt/openwrt/pull/4470
borek has joined #openwrt-devel
<russell--> aren't fit images just a composite of file blobs with a header indicating where to find stuff?
<robimarko> Pretty much yes, I doubt its FIT image causing it to not boot
<robimarko> Probably load/execution adress
<mangix> robimarko: I've tried to keep the diff between stock firmware and OpenWrt as small as possible
<mangix> the interesting part is that without fit, I must use uimage-lzma-loader
<mangix> I think the kernel size is too big.
<robimarko> I assume that load adress is too small, this happened to me previously
<robimarko> Or it clashed with something else
<robimarko> And then you are stuck with nothing after U-boot starts the kernel
<mangix> yeah I tried multiple load addresses, no dice.
<mangix> alright non fit boots
<mangix> I think I'm done with this
<mangix> I got it working...
<mangix> now to figure out why...
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
gladiac has joined #openwrt-devel
SlimeyX_ has joined #openwrt-devel
winternull_ has joined #openwrt-devel
Slimey_ has joined #openwrt-devel
Vaughn_ has joined #openwrt-devel
_0x4a6f_ has joined #openwrt-devel
aparcar_ has joined #openwrt-devel
schwicht_ has joined #openwrt-devel
dwfreed_ has joined #openwrt-devel
jbowen_ has joined #openwrt-devel
mangix_ has joined #openwrt-devel
hgl_ has joined #openwrt-devel
winternull has quit [synthon.oftc.net larich.oftc.net]
SlimeyX has quit [synthon.oftc.net larich.oftc.net]
schwicht has quit [synthon.oftc.net larich.oftc.net]
matoro has quit [synthon.oftc.net larich.oftc.net]
mangix has quit [synthon.oftc.net larich.oftc.net]
Slimey has quit [synthon.oftc.net larich.oftc.net]
swalker has quit [synthon.oftc.net larich.oftc.net]
Vaughn_ is now known as Vaughn
SlimeyX_ is now known as SlimeyX
Slimey_ is now known as Slimey
hurricos has joined #openwrt-devel
mangix_ has quit []
mangix has joined #openwrt-devel
eigma has joined #openwrt-devel
aparcar_ is now known as aparcar
_0x4a6f_ is now known as _0x4a6f
matoro has joined #openwrt-devel
SlimeyX_ has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
SlimeyX has quit [Ping timeout: 480 seconds]
SlimeyX_ is now known as SlimeyX
robimarko has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest1036
srslypascal has joined #openwrt-devel
Guest1036 has quit [Ping timeout: 480 seconds]
<mangix> alright I sort of figured out why it's not working
<mangix> when Data Size: 15670586 Bytes = 14.9 MiB , it does not boot
<mangix> when Data Size: 6595575 Bytes = 6.3 MiB, it boots
<mangix> I'm guessing 8MB limitation
<robimarko_> Its gotta be a memory mapping issue then
<mangix> keep in mind this is initramfs. I'm not flashing images yet.
<robimarko_> I understand, but it really doesnt matter to U-boot
<mangix> hmm? how so?
<robimarko_> There is no difference if you are starting a kernel or kernel that has initramfs included
<robimarko_> Unless you are passing the initramfs as a separate image in FIT
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
StifflersMagic has joined #openwrt-devel
schwicht_ has quit [Read error: Connection reset by peer]
schwicht has joined #openwrt-devel
schwicht_ has joined #openwrt-devel
schwicht has quit [Ping timeout: 480 seconds]
hitech95 has joined #openwrt-devel
<hitech95> Can I say that I'm dumb enough to don't understand if the my7621 have 3 or 2 MAC imterfaces in the CPU side?
<f00b4r0> 2
<hitech95> F00b4r0, yeah but one of that is the rgmii2?
<f00b4r0> yes
<hitech95> So how they manage to get wan+4lan without using an external phy?
<hitech95> They use vlan even on the official BSP?
<f00b4r0> the internal switch can mux one of the phy to the second cpu port
<f00b4r0> #10238 is precisely taking advantage of that
<hitech95> Oh ok, so you loose rgmii2 but you gain the fifth port
<f00b4r0> have to run sorry; bbl
<hitech95> Np
<hitech95> So if I want two ETH ports:
<hitech95> or I have an independent eth port and i have to run a Linux bridge if I want all part of the LAN or I have to use vlans and use 2 of the first
<hitech95> And I suppose that the mux works only for port 4 of the switch, and that port cannot be part of the switch itself by disabling one of the others ports....
<hitech95> 2 ports of the switch.
minimal has joined #openwrt-devel
<mangix> hitech95: port0 and 4 can be mixed.
<hitech95> So, port 0 can be both gmac0 or 1? And port4 can also be gmac0 or 1?
<mangix> the gb-pc1 has two ports. That PR also made it work.
<mangix> Yes
<hitech95> I'm reading the programming guide for the gbit switch but I cannot find this information
<mangix> No idea about that.
<hitech95> So anyway the best solution would be to use port 0 and port 4. So in the worst case you always have 2 links to the CPU :D
<f00b4r0> hitech95: you have the programming guide for the switch? nice :)
<hitech95> Yea, it's available online ... I'm trying to make my Own LTE CPE based on a mt7621 SOM.
c0sm1cSlug has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<f00b4r0> ok i must be super incompetent at googling then cause I couldn't find it
<f00b4r0> ;)
<f00b4r0> all I found was an approval datasheet which is essentially useless
c0sm1cSlug has joined #openwrt-devel
<hitech95> Search the HLK-7621 SOM, go to the download section, you have the datasheet
<f00b4r0> ooOOh! Nice, thanks!
<f00b4r0> stintel: (very) tempting :)
<stintel> I backed the 8GB
<stintel> a bit meh there is no 2 or 4 combo pledge
<stintel> getting 140 is a bit much
<stintel> especially since that only gives a ~1EUR discount compared to the 8GB early
<f00b4r0> ;)
<f00b4r0> i've been meaning to get into risc-v, that might be just the right opportunity. It seems feature-packed and aggressively priced
<f00b4r0> I'll back the 4GB, because I'm cheap :)
<stintel> I have a HiFive Unmatched
<stintel> it's just not powerful enough to render 5120x1440 without getting annoyed
<stintel> it should be comparable to RPi3
<stintel> RPi4 is much more powerful, I'm impatiently waiting for the successor to the Unmatched
<stintel> hoping to use that as thin client in my office, move the noisy workstation and UPS into the rack and have a silent office
<f00b4r0> aiui risc-v really shines in perf/watt tho, how does it fare in your experience?
<stintel> ah my matrix messages are not coming through :(
<jow> ynezz: ping
<ynezz> jow: kong
<f00b4r0> jow: got my pm? :)
<jow> this fix looks wrong to me
<jow> f00b4r0: sec
<f00b4r0> sure
<jow> ynezz: note that we define namelen as strlen() and we allocate namelen + 1 (strlen() + 1) bytes of storage, then copy up to strlen() bytes in a strlen() + 1 buffer
<jow> so the gcc message seems to be a false positive
<ynezz> jow: ok, I'll take a deeper look
<ynezz> maybe we should stop using gcc? :P
<jow> I guess gcc really want to be sure that the destination is strncpy() length + 1
<jow> it does not understand implicit \0
<ynezz> but that implicit \0 is from the calloca
<jow> yes
<jow> so one can't effectively use strncpy(..., s, strlen(s))
<jow> it'll always yield a warning
<jow> even if care is taken to arrange for a trailing \0 by sizing the destination appropriately
<ynezz> I probably need to lookup first why it's visible only with -O2 flag, why its not reported with -Os
<ynezz> does that size optimization optimize out this checks as well? :p
<jow> I guess an easy fix would be using memcpy instead
<jow> same semantics, no string specific checking
<stintel> f00b4r0: copy-pasting what I wrote in Matri
<stintel> Not really using the unmatched as it's too slow
<stintel> At some point I might throw in an extra NIC and play with OpenWrt and test routing performance
<stintel> But I have way too many things to play with already 😂
<stintel> Meson, m200, bsap3040 to name a few
<stintel> Recently distracted with woodpecker CI too
<ynezz> jow: if that's your preference, fine with me
<jow> ynezz: could you test it? simply replace the original strncpy() with memcpy()
<jow> without adding - 1
<jow> ah wait, gcc 10 with -O2
<jow> thought it requires some fancy bleeding edge variant
<ynezz> yeah, thats the point, check the referenced issue
<f00b4r0> out of curiosity why are you using namelen - 1 when you already allocate +1 ?
<ynezz> jow: BTW that latest commit of yours in rpcd doesn't compile "rpcd-2022-08-24-82904bd4/ucode.c:932:36: error: 'uc_parse_config_t' has no member named 'module_search_path'"
<jow> f00b4r0: to appease gcc
<jow> it unconditioanlly warns on strncpy(..., s, strlen(s))
<jow> because one looses the \0 of s in this case
<jow> which might or might not be desired
<jow> in our case it is desired/expected, but gcc is too stupid to know
<jow> hence ynezz' attempt to silence it with -1
<f00b4r0> ah. I assume from what you wrote above that it's new behaviour? I have some code using this type of construct and no warning in gcc8, so I guess I should brace for impact then ;)
<f00b4r0> stintel: got it thanks :)
gladiac has quit [Quit: k thx bye]
jbowen_ has quit []
<ynezz> f00b4r0: are you using -O2/-O3 flag?
<jow> ynezz: s/strncpy/memcpy/ fixes it too
<ynezz> f00b4r0: it's not visible with -Os, so in order to reproduce it you need `-Wall -Werror -O2`
jbowen has joined #openwrt-devel
<ynezz> jow: thanks, are you willing to fix with that change yourself or should I update the PR?
<jow> ynezz: just pushed a fix
<ynezz> jow: thanks!
<hitech95> I'm reading the mt7630.txt the point about port 5 modes/configurations. And i cannot figure out point 2.
<hitech95> Mac 0-3 and phy0-3 are the switch one.
<hitech95> Gmac0 is connected to mac6, and mac5 is connected to gmac1.
<hitech95> Port5 i suppose is the port4 of the datasheet.
<hitech95> This is the part im not understanding: "2. Port 5 is muxed to PHY of port 0/4: Port 0/4 interfaces with 2nd GMAC."
goliath has quit [Quit: SIGSEGV]
Gaspare has joined #openwrt-devel
Gaspare has quit []
Gaspare has joined #openwrt-devel
guidosarducci has quit []
guidosarducci has joined #openwrt-devel
<jow> hmm, do we have an example of a cmake package with host install?
<tmn505> fwtool
gladiac has joined #openwrt-devel
<jow> thanks
<hitech95> fb0b40r0, i probably got how it works. H
<hitech95> f00b4r0, ^
<hitech95> Technically mux A should have 3 choices, one completely disconnect the port.
<hitech95> This way I can use porta and port4 as my wan+lan or lan+lan (it will depends on the DTS configuration)
<hitech95> I see Still not a solution for dual port back hauling on DSA. Mainline is still fighting that?
<\x> is dual port back hauling the dual cpu one that is available on some platforms swconfig days?
gladiac has quit [Quit: k thx bye]
Gaspare has quit [Quit: Gaspare]
goliath has joined #openwrt-devel
<hitech95> \x, yes
<\x> i have some mt7621a here but even when i was using them on swconfig days i didnt see the two cpus thing like those linksys wrt stuff
<\x> on the switch config
Gaspare has joined #openwrt-devel
gladiac has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
robimarko_ has quit [Quit: Leaving]
<domon> Hello, please, explain, why in some devices, for flash uboot image into spi flash use like such commands:
<domon> tftp 0x84000000 uboot&&erase 0x9f000000 +$filesize&&cp.b $fileaddr 0x9f000000 $filesize
<domon> But not sf? sf command event no enabled in uboot :/
borek has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
borek1 has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
borek1 is now known as borek
winternull_ has quit [Ping timeout: 480 seconds]
jlsalvador has quit [Quit: jlsalvador]
<f00b4r0> mrnuke: see, more PCB real estate used :^)
SlimeyX has quit [Read error: Connection reset by peer]
<nbd> f00b4r0: hi
<f00b4r0> nbd: hi
<nbd> f00b4r0: i've made some good progress on unetd
Misanthropos has joined #openwrt-devel
<nbd> it's in my staging tree now
<nbd> you were interested in it, right?
<f00b4r0> sure!
<f00b4r0> is it ready for testing now?
<nbd> yes. it can now synchronize signed network json data across nodes
<nbd> and there's an admin script written in ucode
<nbd> which makes setup really simple
<f00b4r0> sounds good, I'll give it a spin later this week then
<nbd> here's a simple example script that i made which sets up two openwrt routers with unetd to connect to each other: https://termbin.com/nlxe
<nbd> it also sets up a vxlan tunnel between them
<f00b4r0> got it. It sure looks simple
SlimeyX has joined #openwrt-devel
<nbd> it uses ssh to connect to the routers and prepares the uci network interface
<nbd> generates fresh keys
<nbd> and puts the public keys in the json
<nbd> auth key is also autogenerated if it's not present
<f00b4r0> ok. I assume it needs ssh-key set on target routers beforehand, or will it prompt for passwd otherwise?
<nbd> it will prompt for passwd if there is no key
<f00b4r0> excellent
<nbd> it runs a normal ssh command
<nbd> and i also added a mode where you can configure a gateway for a host
<nbd> this ensure that the host will only set up a wg connection to its gateway
<nbd> and all others will route to it using the gateway
<f00b4r0> that's really cool. It's gonna make my use case a heck of a lot simpler ;-)
<nbd> you just need to add a firewall entry to allow routing from unet to unet
<nbd> on the gateway host
<f00b4r0> ok
<nbd> if you have a node with a public ip, you can leave out the endpoint address for all other hosts
<f00b4r0> ok. All but one node have public IPs in my case
winternull_ has joined #openwrt-devel
<nbd> and you can even run unet-cli on a machine that does not run unetd
<nbd> it can send data to unetd instances anyway
<f00b4r0> i see you've been really thorough about this :)
<f00b4r0> i'll definitely take it for a test drive later (got a couple more busy days before I can start playing again)
<nbd> cool, let me know how it goes
<f00b4r0> sure thing!
<f00b4r0> btw since you're here, pardon my attention hijack but you wouldn't happen to have any idea about the mt7621 dsa issues (bridge-vlan roaming being broken and DSCP markings issue) that are plaguing current 22.03? I hit a deadend poking around tbh.
<nbd> only took a superficial look so far, didn't have time to go into detail yet
<nbd> didn't spot anything so far
<nbd> i hope that i will have more time for it next week
<nbd> please keep reminding me if i forget
<nbd> too much wildly different stuff on my plate at the moment
<f00b4r0> ok. Let me know if I can provide more details. Last check was me digging into the ethernet driver, with no luck. Really frustrating that everything seems to work correctly in 5.15 but no amount of backport solves it in 5.10
<f00b4r0> sure; will do!
<nbd> btw. regarding the sign/upload step at the end of my unetd script:
<nbd> for the node that doesn't have a public ip, you can put in connect=<ip of one node> in the add-ssh-host step
<nbd> and then you only need to upload the data to one of your nodes
<nbd> even at the bootstrap stage
<nbd> it will contact the others and spread it around
<nbd> and once the network is up, updates will be distributed over the wireguard link
<f00b4r0> that's brilliant
<nbd> i also made sure that the data transfer outside of the link (for bootstrap) is encrypted and only accessible to members of the network
minimal has quit [Quit: Leaving]
<nbd> it only contains public keys, but i did it for defense in depth and all that...
<ynezz> looks almost like self-hosted tailscale
<ynezz> cool
<nbd> i did look at tailscale as well
<nbd> i like their approach as well
seer has quit [Quit: quit]
<nbd> it's just for a different use case
seer has joined #openwrt-devel
winternull_ has quit [Quit: Leaving]
Gaspare has quit [Quit: Gaspare]
<mangix> f00b4r0: that's on mt7622 only, right?
Gaspare has joined #openwrt-devel
Borromini has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
<f00b4r0> Mangix: what is?
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
tlj has joined #openwrt-devel
<mangix> f00b4r0: mt7530 issues
<mangix> actually...doesn't mt7622 use mt7531?
cbeznea has quit [Quit: Leaving.]
Borromini has quit [Read error: Connection reset by peer]
Borromini has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
f00b4r0 has quit [Ping timeout: 480 seconds]
schwicht has joined #openwrt-devel
schwicht_ has quit [Read error: Connection reset by peer]
f00b4r0 has joined #openwrt-devel
<f00b4r0> Mangix: the mt7530 issues are mt7621
<mangix> what are they?
<mangix> IIRC you were mentioning issues with backporting stuff to 5.10
<f00b4r0> Mangix: my connexion is flimsy right now (on *3G* backup :P), see the mailing list. There's a roaming issue when there's a bridge-vlan involved (the stale fdb entry on the ethernet port blocks roaming to cpu port - aka wireless), and there's also a dscp issue with dropbear (there's a GH issue)
<mangix> f00b4r0: DSCP issue is only on mt7622
<f00b4r0> the roaming problem is fixed in 5.15, however backporting the "fix" triggers a different throughput problem where all switch ports throughput max at the slowest speed (while still reporting higher speed)
<f00b4r0> ok
<f00b4r0> i haven't experienced the dscp issue so I'm not sure
<mangix> I have. It happens on my RT3200 but not my RT1800
<f00b4r0> ok
<mangix> mt7622 vs mt7621
<hauke> Mangix: does the dscp issue happen after some time or after some data was transfered?
<mangix> hauke: nope. Immediate.
<mangix> example: I ssh into root@openwrt. After that I cannot input anything
<hauke> for me ssh to my RT3200 over wifi still works
<mangix> thiis is over WiFi. Over ethernet works
<mangix> I think the issue has to do with Wireless Ethernet Dispatch
<hauke> I am also going over wifi
<mangix> I don't think that's supported by mt761`
<hauke> on openwrt 22.03
<mangix> *mt7621
<jow> Mangix: it has been reported that the issue also happens when mt76 wifi is involved somewhere along the network path
<jow> Mangix: so not sure if it's wireless ethernet dispatch related
<f00b4r0> i have to bail. Hopefully regular internets will work again tomorrow. ttyl
<mangix> So I'm currently running a WAX202 as a router. No issues. If I switch back to my RT3200, the issue will show up.
f00b4r0 has quit [Quit: Textual IRC Client: www.textualapp.com]
<hauke> Mangix: did you activate some offloadings?
<jow> Mangix: if you reproduce the issue, can you confirm that forcibly resetting the DSCP fixes it immediately?
<jow> resseting as in doing an nftables or iptables mangle rule to set the DSCP mark in tcp/22 packets to 0
<mangix> hauke: so strictly speaking, WED is a form of offload. Aside from that, I doubt it. I'll need to check again.
<mangix> iptables/nftables is alien to me.
<mangix> bookmarked
<jow> dropbear recently started tagging it's interactive session tcp traffic with DSCP class AF21
<mangix> the only *testing* I've done with this is with an ax210
<jow> this triggers the issue
<mangix> yeah I noticed openssh is not affected
<jow> even on older mt76 driver versions, so it likely is an older problem
Borromini has quit [Quit: Lost terminal]
<jow> and it likely affects other software too that uses DSCP markings on its traffic (torrent clients, voip clients, ...)
<mangix> Ugh, this gives me memories of the whole comcast mess.
<jow> at some point nbd mentioned that DSCP class AF21 maps to TID 4 instead of TID 1 in the wireless frames
dwfreed_ is now known as dwfreed
<jow> which maybe triggers some bad/broken queueing in mt76
<mangix> doesn't make sense though. My mt7621 device uses mt7915 DBDC and it's not affected
<jow> maybe a hardware quirk?
<mangix> It's not just this one, my RT1800 too
<mangix> the mt7915 in the RT3200/E8450 is non DBDC
<mangix> and supports WED
<jow> I didn't follow closely which mt76 soc flavors are specifically affected
<mangix> with the RT3200, I've only used AUC builds since it's NAND
jlsalvador has joined #openwrt-devel
<mangix> I've heard recovery is a bit...special.
<jow> what's DBDC anyway, exactly? Seen that it means dual-band, dual-concurrent
<jow> so two radios, each broadcasting simulatneously on two bands?
<mangix> That's basically it, yeah
<mangix> under lspci, it shows up as one device
<jow> I see
<jow> that's what the multi-phy stuff was added for a while back
<jow> the `+1` thing in the phy paths
<mangix> mt7621 uses DBDC because its PCIe is 1.1 instead of 2.0
<jow> I suppose
<dwfreed> my newest gl.inet travel router has that
<mangix> mt7622 has PCIe 2.0, so 160MHz can be supported properly.
<dwfreed> had to update to a 22.03 snapshot to get things working correctly with it
<hauke> I will prepare a patch to deactivate WEB and see if it fixes the problem for people
<dwfreed> mt1300
hitech95 has quit [Remote host closed the connection]
<stintel> 01:00.0 Unclassified device [0002]: MEDIATEK Corp. Device 7916
<stintel> 02:00.0 Unclassified device [0002]: MEDIATEK Corp. MT7915E 802.11ax PCI Express Wireless Network Adapter
<stintel> this is dbdc
<mangix> hrm interesting
<stintel> 11|13:44:16< nbd_> stintel: the 7916 device is just a secondary pci interface belonging to the 7915 chip
<stintel> 11|13:44:37< nbd_> it shows up on devices with a pcie gen1 host interface
<mangix> I do know one lane is used for 2.4ghz and the other for 5ghz.
MaxSoniX has quit [Quit: Konversation terminated!]
Gaspare has quit [Quit: Gaspare]
c0sm1cSlug has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
c0sm1cSlug has joined #openwrt-devel
tlj has quit [Remote host closed the connection]
ptudor_ has joined #openwrt-devel
ptudor has quit [Ping timeout: 480 seconds]