<dwfreed>
stintel: did you ever figure out if there are actually 2 CPU ports attached to the switch chip in the m300?
rafelbev has quit [Remote host closed the connection]
gch981213 has quit [Ping timeout: 480 seconds]
<stintel>
dwfreed: the oem bootlog and gpl drop seem to suggest this is the case but I never managed to have any traffic with any other port besides the one is currently configured as CPU port in the DTS
<Znevna>
if we add an alternate name for a device using DEVICE_ALT0_MODEL, can we ommit the vendor if it's the same as DEVICE_VENDOR ?
<stintel>
interesting ... wg_dsa_count is 1 for the T2081
<stintel>
ah nvm that just means there is a single switch chip
<dwfreed>
I mean, does the marvell dsa driver support multi port?
<stintel>
+ // Set which ports are CPU ports based on platform
<stintel>
we actually use the forum DMs to communicate with some team members
<stintel>
that aren't on IRC
<dwfreed>
restricted to team members, then?
<stintel>
anyway
<stintel>
last day of my 2w holiday
<stintel>
afk
cbeznea has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
hhasert has joined #openwrt-devel
Ryncewynd has joined #openwrt-devel
hhasert has quit []
Borromini has joined #openwrt-devel
csharper2005 has joined #openwrt-devel
csharper2005 has quit []
csharper2005 has joined #openwrt-devel
TTuner has joined #openwrt-devel
<TTuner>
hello, is there anyone around who has tried or runs openwrt on top of rpi zero 2 w?
<robimarko>
If you dont have WLAN working
<robimarko>
Thats expected AFAIK as no FW is includede
TTuner has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
floof58 is now known as Guest436
floof58 has joined #openwrt-devel
Guest436 has quit [Ping timeout: 480 seconds]
sorinello has quit [Quit: Leaving]
sorinello has joined #openwrt-devel
xes_ has quit [Read error: Connection reset by peer]
xes has joined #openwrt-devel
<aiyion>
The device I'm currently testing behaved interesting, as I tested it last (a few days before christmas). Wireless interfaces were not showing up in `ip a` but only after I fired them up. And then they wouldn't be called wlan1, but just pyh0-sta0 fo example.
<aiyion>
I'm just building the patch again rebased on tonights master to see if the issue is gone. Any thoughts when such such behaviour may occur?
<Borromini>
aiyion: phy0-sta0 is the new naming introduced in master recently afaik
<Borromini>
i thought it was a netifd change but I'm not finding it
<Borromini>
can't comment on the behaviour you're seeing
<aiyion>
mhm. I booted the new image from tonight.
<aiyion>
The interfaces wlan0 and wlan1 are listed.
<aiyion>
I enable the default openwrt ssid in luci and they disappear from `ip a` and phy0-ap0 and phy1-ap0 spawn.
<aiyion>
Is that really intended behaviour?
<aiyion>
I disable them again and wlan0 and 1 do not show up again.
<aiyion>
... funny. That is until I reboot after disabling again. Then they're back.
<chsarper2005>
Ryncewynd: maybe. thanks for the idea. it looks like there is no existing function in OpenWrt (like macaddr_add) for my case and I need to write a new one.
<rmilecki>
csharper2005: huh? we have function for that
decke[m] has quit [Quit: Client limit exceeded: 20000]
<rmilecki>
normally you're allowed to set 0x2 in the left most octet as that means locally-assigned Ethernet address
<rmilecki>
0x68 -> 0x72 i can't explain
<karlp>
depending on the board, that's not wildly unreasonable.
<karlp>
intel mac on wan, realtek on lan for instance...
<karlp>
or mediatek on lan/2g/5g, realtek usb ether on wan, could be anything.
<rmilecki>
that WAN has local bit set so it seems like some vendor messing with that
<rmilecki>
maybe they implemented some incorrect logic
<rmilecki>
like +=0xa instead of |=0x2
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<karlp>
chsarper2005: do you really have lan and 2g with the same mac?
<chsarper2005>
karlp: Yes, I'm sure.
<karlp>
cute.
<karlp>
soundsd like a vendor script fuckup :)
<chsarper2005>
rmilecki: What would you suggest? 1. Fix possible mistake? 2. Keep original WAN MAC logic? 2а. Using set/unset bit. 2b. Add 0xa with new function.
Ansuel has joined #openwrt-devel
<Ansuel>
jow ping?
domon has quit []
<chsarper2005>
karlp: this is not the first such device in my practice :) with 2g MAC = LAN MAC
<Znevna>
OpenWrt guidelines suggest keeping the MACs how they were set in the vendor firmware
lipnitsk has quit [Quit: Client limit exceeded: 20000]
<chsarper2005>
Znevna: set/unset bits will be the easiest way...
<Ryncewynd>
the guideline should say "unless the vendor fucks up" :-)
<Ryncewynd>
2.a is the cleanest approach
MatMaul[m] has quit [Quit: Client limit exceeded: 20000]
<Ryncewynd>
I mean its 1 by implementing the set/unset bit
<rmilecki>
csharper2005: i don't know... my personal choice would to to look for other owners of that device model
<rmilecki>
see how MACs are handled in other units
<rmilecki>
maybe find some pattern that way
<Ryncewynd>
true, the 72 might be a mistake and actually they should all be 68, my device does not apply local/global logic
<Ryncewynd>
I have a different model though (tp-link archer c7 v2)
<stintel>
hmmm, anyone noticed any performance regressions in cake recently? steam was stuck at ~38MB/s, stop qosigy and now it's doing 106MB/s
<Ansuel>
this is on wifi or ethernet ?
<stintel>
ethernet
<stintel>
friends don't let friends game over wifi :P
<stintel>
perf top doesn't point to anything obvious
<stintel>
lots of .book3e_idle
<chsarper2005>
Ryncewynd: Now I have the another example. LAN: 50:xx:xx:xx:B7:DA, WAN: 54:xx:xx:xx:B7:DB. The only idea I have that TP-Link fw is handling 50->54, 68->72 as decimal numbers. +4. lol
<Backhand4630>
i have to do that on every start. where is the correct place to put it?
<Borromin1>
/etc/rc.local
<Backhand4630>
really? i had hoped to do it very early in boot, so my modem is ready when interfaces are initializing etc.... i wanted to put it in /etc/board.d
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
<Borromin1>
that sounds even more hacky to me since those files will be overwritten upon upgrade
<Borromin1>
if you want to make it persistent, wouldn't the DTS be a more logical place? Which means recompiling of course.
csharper2005 has quit [Remote host closed the connection]
<f00b4r0>
as he explained, overshooting is better than underestimating
<f00b4r0>
i don't know what kind of tunnel overhead you're facing
<stintel>
so overhead 44 mpu 84 noatm
<f00b4r0>
i guess so
<f00b4r0>
i find cake "no knob" to be not so "no knob" after all. And quite confusing, to the point that I've not been through with my plan to improve the documentation
<f00b4r0>
and i also noticed recently that fq_codel _actually no knob_ config performed outrageously well for my needs on the underpowered hap-ac2 that I use here :)
<Znevna>
aiyion: I don't know how backporting usualy works
<aiyion>
How it usually works I do know; I'm just not sure about how or even whether mt76 patches can land in 22.03 domain.
<f00b4r0>
then can, if there is a compelling reason
<f00b4r0>
(compelling reason = fixing a bug, not adding a feature)
<stintel>
hmmz
<Znevna>
aiyion: the power led and usb led deserve to be fixed in 22.03 too anyway
<Znevna>
those don't depend on anything from master
<aiyion>
Not sure whether that goes for the radio LEDs as well.
<f00b4r0>
I'm also not quite clear what kind of upstream contribution freifunk provides, so I didn't want to go down that road. But did I hate the tone of that message.
<slh>
it's particularly ridiculous, as freifunk is a disjunct group of regional projects with their different code bases - and for many of those, IPv6 is a necessary core feature for their own routing
<stintel>
Adrian did a lot of contrib
<stintel>
with a freifunk@ alias
<f00b4r0>
slh: interesting. That makes this even more retarded than I first thought then ;P
<aiyion>
We're not all like that, promised.
<slh>
f00b4r0: the problem for many of these is that they're sitting on mountains of 4/32 tl-wr841n routers deployed in the field - as it was easy to recommend them as under-20-EUR solutions
<Habbie>
hah, i have five of those
<Habbie>
one runs openwrt
<Habbie>
18.xx or something
<Habbie>
(terrible)
<f00b4r0>
slh: heh. well I think these are way past their due date. And certainly largely economically amortised by now.
<dwfreed>
18.06 is the 18 version, yeah
<stintel>
lol 4/32 people are really still running that now ?
<f00b4r0>
i have a couple of these types of devices, it would never cross my mind to /demand/ they be supported forever. That's beyond absurd.
<stintel>
I can barely fit my minimal requirements in 8MB
<f00b4r0>
stintel: I am :D
<Habbie>
stintel, i am!
<Habbie>
but i missed the conversation
<f00b4r0>
as dumb AP
<stintel>
actually I can barely fit my dumbAP in 16MB
<Habbie>
i would definitely not demand support
<Habbie>
f00b4r0, dumb client here
<f00b4r0>
stintel: then you dumbAP is not so dumb ;)
<slh>
f00b4r0: still very hard to replace, as they're owned/ paid by their individual operators, with very little means of contact or other ways to plan forward
<f00b4r0>
slh: I'm afraid that's *their* problem
<stintel>
f00b4r0: snmp and lldp is non-negotiable :)
<f00b4r0>
stintel: lol
<slh>
it is, I'm just mentioning it to explain the thinking behind it
<f00b4r0>
*nod*
Slimey_ has joined #openwrt-devel
Slimey has quit [Ping timeout: 480 seconds]
Slimey_ is now known as Slimey
<dwfreed>
probably a load of microscopic gl.inet devices that would be better than that
<f00b4r0>
i should take a closer look at gl.inet, seems people like it.
<f00b4r0>
client of mine is asking what should be their next hw investment for openwrt use ;)
<Habbie>
gl.inet comes up a lot in conversations i have with people on wide ranging subjects
<Habbie>
both "travel routers" and "we develop on these"
<Habbie>
(these two don't overlap much)
<slh>
f00b4r0: the interesting/ recent gl.inet devices are typically not supported by OpenWrt anymore (new SOCs)
<f00b4r0>
ah damn
<Habbie>
the second group does mention "best i can do is 19.07" on lucky days
<slh>
still plenty of older designs (ath79/ mt7621) which are fully supported, but at least I wouldn't be interested in buying those anymore
<slh>
ipq60xx wouldn't be that far away from prime time, the others will have worse chances
<dwfreed>
slh: the original beryl is supported from 21.02 (but you need 22.03 for the wifi to work correctly)
<dwfreed>
that's mt1300
<dwfreed>
it's not AX, but do you really need AX for a travel router?
<slh>
dwfreed: well, beryl is a 'boring' mt7621a ;)
<f00b4r0>
but mt7621 is rock solid, and that's cool :)
<slh>
support for opal (SF19A28) looks grim (as in probably not going to happen), brume2 (MT7981B/ filogic 820) looks promising (underway, but apparently not ready, yet), slate should be supported as well (ipq4018)
<dwfreed>
I also have an old mt300n, pretty sure it's v1
<stintel>
yep, have a beryl here too, good stuff
<stintel>
and convexa-b
<aiyion>
I'm still looking forward to eventually get that brume2 running.
<stintel>
yes, that brume2 looks fun toy
<jow>
hmm, anyone know what's the deal with adding more and more hardcoded fdt-to-pci-id mappings to libiwinfo?
<dwfreed>
stintel: brume2 has a really weird port setup
<dwfreed>
1x 2500, 1x 1000, no wifi
<f00b4r0>
now that's rather weird indeed
<dwfreed>
and the 2500 port is labeled "WAN"
<f00b4r0>
i'm guessing that's all about ticking that "2.5GE" marketing checkbox
<slh>
jow: with everything relevant being mac80211 these days, there might be a point to drop any kind of detection in libiwinfo (respectively to outsource it to pciids/ usbids, if installed), both ipq8074 and qcnx0x4 are very common targets though (qcn9074 as third radio (6 GHz or second 5 GHz radio as wireless backhaul)
<aiyion>
two 2.5 ports would've been nice, but having that device as a router on a stick with still a gigabit of bandwidth is quite nice.
<slh>
jow: 7 devices using those are already part of the (upcoming) ipq807x target PR, another 2-3 are in-waiting, while relatively minor kinks are resolved - and quite a few more with as-of-yet-unported devices and ipq60xx to follow