lemmi has quit [Read error: Connection reset by peer]
lemmi has joined #openwrt-devel
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #openwrt-devel
lemmi has quit [Remote host closed the connection]
lemmi has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
lemmi has quit [Remote host closed the connection]
lemmi has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
Strykar has quit [Quit: /quit]
Strykar has joined #openwrt-devel
schwicht has joined #openwrt-devel
<nbd>
Mangix: you mean trouble with ssh?
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
schwicht has quit []
valku has quit [Quit: valku]
xes has quit [Remote host closed the connection]
xes has joined #openwrt-devel
xes has quit [Remote host closed the connection]
csrf has joined #openwrt-devel
barhom has quit [Remote host closed the connection]
JuniorJPDJ has quit [Write error: connection closed]
t4h4[m] has quit [Write error: connection closed]
dfceaef[m] has quit [Write error: connection closed]
pavlix has quit [Write error: connection closed]
Kiste has quit [Write error: connection closed]
evils[m]1 has quit [Write error: connection closed]
fieryeagle954[m] has quit [Write error: connection closed]
decke[m] has quit [Write error: connection closed]
nick[m]11 has quit [Remote host closed the connection]
ctdvqgg445[m] has quit [Write error: connection closed]
lipnitsk has quit [Write error: connection closed]
znullptr[m] has quit [Write error: connection closed]
hexagonwin[m] has quit [Write error: connection closed]
schmars[m] has quit [Write error: connection closed]
whatevs111[m] has quit [Write error: connection closed]
oliv3r[m] has quit [Write error: connection closed]
mkg20001 has quit [Write error: connection closed]
olmari has quit [Write error: connection closed]
Movedtomkg20001mkg20001io[m] has quit [Write error: connection closed]
John[m]123456 has quit [Write error: connection closed]
will[m]1 has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
domon has quit [Write error: connection closed]
fpsusername[m] has quit [Write error: connection closed]
tohojo has quit [Write error: connection closed]
MatMaul[m] has quit [Write error: connection closed]
Jonny[m] has quit [Write error: connection closed]
bluse-blue[m] has quit [Write error: connection closed]
goliath has joined #openwrt-devel
xes has joined #openwrt-devel
<Mangix>
nbd: seems to be more than that. I reverted to around the ipq commits. Works now.
<nbd>
Mangix: can you try reverting da6b77215b995eb61edd84b2766930bc963b3331 + 590eaaeed59a9eb6637a1480587fc410de182523 to see if it makes a difference?
<nbd>
(on latest master)
srslypascal has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
aparcar[m] has joined #openwrt-devel
<Mangix>
nbd: will do so tomorrow. It's late here.
ptudor_ has quit [Read error: No route to host]
ptudor has joined #openwrt-devel
mrkiko has quit [Quit: leaving]
floof58 is now known as Guest3035
floof58 has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
Guest3035 has quit [Ping timeout: 480 seconds]
cbeznea has joined #openwrt-devel
ptudor has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
danitool has joined #openwrt-devel
robimarko has joined #openwrt-devel
csrf has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
xback has quit [Remote host closed the connection]
<jow>
nbd: what is MBSSID exactly?
<jow>
nbd: does it refer to the ability to do multiple BSSes at once or is it some kind of enhanced beacon feature?
<nbd>
announcing multiple BSSes (possibly also on different channels) with a single set of beacons
<jow>
ah so it's just some kind of optimization
<nbd>
it's mostly useful for wifi-6e
<jow>
if unavailable we just need to send more beacons
<nbd>
we're not using it by default
<nbd>
it needs to be configured explicitly
<jow>
okay, great
<nbd>
and not all clients support it
<nbd>
and i think 21.02 doesn't even have a way to configure it via uci
schmars[m] has joined #openwrt-devel
<schmars[m]>
cheers for the fast wifi fixes
dangole has joined #openwrt-devel
f0g has joined #openwrt-devel
<f0g>
Hi all. I am looking for the location where luci call 'reload_config' or something similar to restart a service after setting changed. Any suggestion?
<jow>
f0g: luci commits uci changes through rpcd which in turn emits an ubus "config.change" event for any comitted uci config
<jow>
f0g: that will get catched by the subscribed init scripts and issue a reload for them
<jow>
if you inspect the reload_config shell script you'll notice a similar logic
<jow>
it uses md5sums of all configs, compares them on each run and synthesizes a config.change event for each config with a changed md5sum
<f0g>
jow: so luci will not call reload_config, right?
<jow>
correct
<f0g>
fine
<jow>
it's rather reload_config emulating the luci/rpcd logic
Saladin has joined #openwrt-devel
Saladin has quit [Remote host closed the connection]
goliath has joined #openwrt-devel
<rua>
Hello. Isn't there still any multi-cpu-port improvement accepted in current available DSA?
<robimarko>
None that I have seen upstream
<robimarko>
Only work was done to be able to change the CPU dynamically
<\x>
hi robimarko, do any of you guys working on ipq60xx found a way to get proper boardfiles? i cant find the one for MR7350. I wonder if I have to live with that forever or just for now.
<rua>
What does this mean? If a hardware is designed with multiple cpu-ports, it is possible to choose which one acts as the working cpu-port at runtime?
<robimarko>
\x: Not want to be mean, but everybody is jumping way ahead
<robimarko>
IPQ60xx has way more important stuff than hacking up OpenWrt and calling it sucess
<robimarko>
rua: Yes, exactly that
<\x>
yeah Im testing too early, I tried mrnuke's stuff, wifi is so bad as Im using another board's boardfile
<rua>
robimarko: And in openwrt, if a hardware is designed with multiple cpu-ports, currently, are the cpu-ports other than the used one simply not defined in the switch block of device tree?
<robimarko>
rua: Yes, or defined and just commented out
<robimarko>
That was the upstream state as well until like a couple of weeks ago as well
<robimarko>
I think Vladimir Oltean did like 4 patch series to get this working
goliath has quit [Quit: SIGSEGV]
<rua>
But is it possible to just define them as DOWNSTREAM ports, but connecting to other ethernet ports of the host (soc)?
<nbd>
jow: btw. i managed to get the phy rename stuff working even for dbdc cards now
<robimarko>
rua: Yes, but what would that give you?
<\x>
I think the MT7621A 2Gbps patch did it that way, wan port goes to 1 cpu port, another one goes to the lan ports something llike that
<robimarko>
Only issues pretty much
<robimarko>
\x: MT7621A AFAIK has a mux so its not like you connected it to a second ethernet controller, but its internally muxed to the existing one
<\x>
but the issue with that 2Gbps patch, well not an issue but intended is that when you bridge wan port to the other lan ports, the packets from wan port to any lan port vice versa has to pass through the cpu
goliath has joined #openwrt-devel
<nbd>
jow: with my current code, two phys on the same device will be called wl0 and wl0.1
<rua>
For example, a router has DSA downstream ports lan1~4, wan under eth0, now there is another DSA downstream port "extcpu" connecting to eth1, if wan and extcpu are bridged, we could use eth1 for wan communication.
<robimarko>
I guess that could work
<rua>
In this way, we could make use of hardware multiple-cpu-port designs even without an acceptable upstream multi-cpu-port improvement.
<robimarko>
I dont know if bridging will be efficient
<robimarko>
I guess, speed of it would need to be tested
<rua>
Because both "extcpu" and "wan" are DSA downstream ports, their bridging should be handled and accelerated with the switch.
Saladin has joined #openwrt-devel
Saladin has left #openwrt-devel [#openwrt-devel]
schwicht has joined #openwrt-devel
schwicht has quit []
<jow>
nbd: great! maybe consider wl00 and wl01 ?
<nbd>
it would break if you have 10 wifi devices :)
<nbd>
and the logic would be more complex
<jow>
yeah true
<jow>
and 0a, 0b, 0c could be confused with bands
<jow>
the dot will cause confusion too, though
<nbd>
what kind of confusion?
<jow>
peopel will think VLAN
<jow>
*people
<nbd>
well, vifs will have -apX / -staX suffix
<jow>
yeah, so wl0.1-ap0
<jow>
not too bad
<nbd>
as requested, i kept the radioX names as section names
<nbd>
decoupled from wlX index
<jow>
great, that was my only pet peeve, really
LuDuoduo has joined #openwrt-devel
LuDuoduo has quit []
<nbd>
jow: so do you think i should push the changes now?
<jow>
nbd: sure. Now that we also more or less eliminated all non-mac80211 drivers I wonder if I should redo iwinfo as ucode script and git rid of the library
<jow>
*get rid
<\x>
ei jow about that ip6 nat thing rule with nftables, is that a single rule?
<nbd>
pushed
<nbd>
i only added board.json entries on mt7622 for now
<jow>
\x: what do you mean?
<\x>
you said some time ago that we got free ipv6 nat with nftables
ptudor has joined #openwrt-devel
schwicht has joined #openwrt-devel
mrkiko has joined #openwrt-devel
<aiyion>
I opened op the router, connected the serialport, extracted an oembootlog indicating some mediatek meshlink framework and have put it on a new wiki page for the device.
<aiyion>
tftp appears to be locked, the router claims ipaddr was not set, even though printenv begs to differ.
<aiyion>
once I used the mediatek loader (effectively writing the image to disk I run into an lzma compression error upon boot), so that's somewha progress I suppose.
<aiyion>
would it be possible though, they allow uploading firmware, but deny decompression if a signature is missing, or similar?
indy has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
valku has joined #openwrt-devel
KGB-2 has quit [Remote host closed the connection]
<jow>
\x: for zones there's a new option masq6 instead of masq to die IPv6 masquerading
<jow>
\x: for redirects (port forwards) the syntax is the same, just set "option family ipv6"
<jow>
s/die/do/
KGB-2 has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Borromini has quit [Ping timeout: 480 seconds]
schwicht_ has joined #openwrt-devel
schwicht has quit [Read error: Connection reset by peer]
barhom has joined #openwrt-devel
bluse-blue[m] has joined #openwrt-devel
ctdvqgg445[m] has joined #openwrt-devel
decke[m] has joined #openwrt-devel
dfceaef[m] has joined #openwrt-devel
domon has joined #openwrt-devel
evils[m]1 has joined #openwrt-devel
fieryeagle954[m] has joined #openwrt-devel
fpsusername[m] has joined #openwrt-devel
gnustomp[m] has joined #openwrt-devel
hexagonwin[m] has joined #openwrt-devel
John[m]123456 has joined #openwrt-devel
Jonny[m] has joined #openwrt-devel
JuniorJPDJ has joined #openwrt-devel
Kiste has joined #openwrt-devel
Q__ has joined #openwrt-devel
lipnitsk has joined #openwrt-devel
MatMaul[m] has joined #openwrt-devel
Movedtomkg20001mkg20001io[m] has joined #openwrt-devel
mkg20001 has joined #openwrt-devel
nick[m]12345 has joined #openwrt-devel
oliv3r[m] has joined #openwrt-devel
olmari has joined #openwrt-devel
pavlix 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
G10h4ck has joined #openwrt-devel
<G10h4ck>
hi all!
Gaspare has joined #openwrt-devel
<G10h4ck>
nbd I was diving into eBPF and found that linux have many helper functions like bpf_skb_vlan_push, i was wandering if it is powwible to manipulate wifi frames with similar helpers, in particular if there is a way to access and manypulate the 4 macaddress fields in the wifi data frames
<nbd>
you can insert headers, manipulate frame data, etc.
<nbd>
it's quite flexible
<G10h4ck>
I was wondering about forwarding L2 frames without need to encapsulate them, encapsulating L2 stuff have gine MTU quirks historically expecially when both cabled ethernet and wifi links are involved
<G10h4ck>
we managed to work around those hickups, but prevent them radically is tempting
<G10h4ck>
so if we can access the four macs fields in the wifi frame we gould use one for real source and one for real destination
Gaspare has quit [Ping timeout: 480 seconds]
<nbd>
G10h4ck: in unetd vxlan i had mtu issues as well, so i wrote a BPF program that fixes the TCP MSS option to deal with that
<G10h4ck>
yeah we have that sort of workaround in place in libremesh too
<G10h4ck>
but they always fix only part of the problem
<G10h4ck>
at some point we endup having reports from users the the app X that uses it's own UDP based transport protocol doesn't work as expected for example
<G10h4ck>
in the end we have all user facing network interfaces setted with MTU 1350
<G10h4ck>
we also telle the clients via DHCP that the mtu is 1350 and so on
<G10h4ck>
but there is always some quirks
<nbd>
you could bounce oversized packets to user space and let user space send back ICMP error packets to trigger path MTU discovery
<G10h4ck>
in our case it seems we can avoid it almost completely in most of the case by avoiding encapsulation unless it is strictly needed
<G10h4ck>
on cabled links we could just forward the frame as-is to the correct interface
<G10h4ck>
in wireless link we should set DST macaddress to the nextop, and save the real_DST somewhere, maybe in 4 mac address field
<nbd>
just make a real 4-address wireless link
<nbd>
then you can treat it as an ethernet link
<G10h4ck>
or we could encapsulate on wireless only which supports greater mtu, and then decapsulate when forwarding over cabled link
<nbd>
at some point i was thinking of making a mesh-like mode which runs on top of a regular AP interface and simply creates 4-addr peer station entries/interfaces for its neighbors
<nbd>
seems like it would fit nicely with what you're trying to do
<G10h4ck>
also it seems that newer radios doesn'T supports 802,11s that well
<nbd>
one useful property of this is that it doesn't require special addressing modes used for 802.11s
<nbd>
it would work with any chipset that has normal mac80211 4-addr support
<nbd>
and would work with the existing offload features
<nbd>
e.g. encap offload on mtk chipsets
<nbd>
with a bit of luck, it wouldn't even need user space changes
<nbd>
sorry, kernel space changes
<nbd>
it would work with a modified hostapd
<nbd>
since all you're doing is creating extra station entries and handling mgmt/auth in user space
<G10h4ck>
> it would work with any chipset that has normal mac80211 4-addr support< is this supported by most of the chips/drivers ?
<nbd>
most common ones yes
<nbd>
ath9k, ath10k, mt76
<nbd>
it would definitely be a lot faster than 802.11s
<G10h4ck>
do you think ath11k will be viable for this too ?
<G10h4ck>
San was investigating 802.11ax radios for librerouter 2
<nbd>
i think it could work, but i would definitely recommend going with mt7915 instead
<nbd>
for 802.11ax
<G10h4ck>
he has been playing with some mt7915e based radios
<nbd>
from what i hear, ath11k still has a lot of firmware bugs
<nbd>
and you can't really expect any reasonable support from qualcomm
<G10h4ck>
so this AP + 4-addr custom mode you suggests seems very interesting
<nbd>
with mt76, i can forward bug reports directly to mtk
<nbd>
and they typically have been very responsive when it comes to dealing with firmware issues
<G10h4ck>
so basically one should configure the radio in this mode on each router, and it would behave more or less like mesh node, but with better performances
<nbd>
of course somebody would have to write the code for hostapd to do this
<nbd>
one advantage is that you wouldn't even need a separate interface for meshing anymore. you could piggy-back on a normal ap interface with this
<G10h4ck>
that would be great
<G10h4ck>
from what I understand we will be also less dependant on driver support of "more exotic" features like virtual interfaces and 802.11s
<G10h4ck>
so any radio with good AP support should work well
<G10h4ck>
do I understand well?
<\x>
hi, just a hardware question, theres this new chip on the block, MT7981, 2xA53 and they commonly come with 256MB ram embeedded on them, are those viable for support or will the memory be too small for 64 bit mode?
<robimarko>
64bit does not use more RAM
<robimarko>
MT7981, that should be Filogic 630?
<\x>
seems its mtk's contender to 50xx
<robimarko>
I hoped that built-in RAM was dead, but nope
<robimarko>
QCA and MTK are both having models on the low end
<\x>
Filogic 820 robi
<robimarko>
Thats a new one for me
<robimarko>
I was aware of 630 and 830
<\x>
my bad for embedded wording, should be "comes with
<yolo>
schmars[m]: that's brave, but i did not know stash handles .gitignore
<schmars[m]>
yolo: you'd probably stage everything first (something like `git add -f .`) and then stash it
<schmars[m]>
-f to override gitignore
<schmars[m]>
and then after stash you can check that everything is gone using `git clean -fdx` - if it doesn't remove anything, then everything was already gone
<schmars[m]>
never tried it in the context of openwrt, but that's what i'd try
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
Borromini has quit [Quit: leaving]
csrf has joined #openwrt-devel
csrf1 has joined #openwrt-devel
jlsalvador has quit [Ping timeout: 480 seconds]
<T-Bone>
hmm, now logread throws me a segfault. That can't be good
T-Bone is now known as f00b4r0
<dwfreed>
oof
<f00b4r0>
oof?
<dwfreed>
"oof" is what you say when someone says something bad happened
<f00b4r0>
ha
<f00b4r0>
wasn't familiar with that particular idiom
<dwfreed>
it's like "yikes"
jlsalvador has joined #openwrt-devel
<f00b4r0>
committed to persistent storage :)
<dwfreed>
dangole: would it be possible to backport the new API for asu to auc in 19.07 ? It's currently not possible to use auc at all on 19.07 because of the asu API change
<f00b4r0>
why do i always have to notice these strange things just as I'm about to head to bed... I must be cursed ;P
<f00b4r0>
well now that's even weirder. Ran "logread -f" which didn't crash, got a message, and now logread works again
<matoro>
hey, I picked up a MT7915E mpcie card. it seems to work but strangely creates two interfaces. one of them gets renamed to wlp1s0 but the other gets left as either wlan0 or wlan1 (it's inconsistent across reboots). why two interfaces and what's the difference between them?
<dwfreed>
f00b4r0: buffer was empty and logread doesn't handle that correctly in non-f mode?
<f00b4r0>
dwfreed: buffer was quite full in fact
<dwfreed>
huh, weird then
<dwfreed>
matoro: the 7915e is simultaneous dual band
<dwfreed>
see the iw phy output :)
<matoro>
dwfreed: ah, so one is 2.4G and the other is 5G?
<matoro>
how do I know which is which? and also why is one of them getting renamed from wlan0 but wlan1 is not getting renamed?
<Mangix>
matoro: that's some udev thing
<Mangix>
I assume it needs upstream support
<matoro>
hmmm, so where should I be looking for this?