<mangix>
also sounds like a new uboot is needed. my omnia is the original
pine127 has quit [Remote host closed the connection]
swex has quit [Ping timeout: 246 seconds]
<rsalvaterra>
Well, it's basically a patch generated from a squashed commit of all changes after the hardware buffer management enablement, up until 5.11-rc7.
<rsalvaterra>
Yeah, I'm looking forward to that u-boot update… My Omnia is also the model from the Indiegogo campaign.
pine127 has joined #openwrt-devel
<rsalvaterra>
But that Archer C7 v2 LED patch is nice, I wonder if I could do something similar on my TL-WDR3600…? The switch LEDs can't be controlled with sysctl…
jlanda has quit [Remote host closed the connection]
<rsalvaterra>
… and turns out I can! https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi;h=21fd079e1a06225d985f08de5853344bc908b740;hb=HEAD
<guidosarducci>
rmilecki: appreciate if you have a chance to look, we're trying to get it done for 21.xx
<rmilecki>
guidosarducci: oh, some hacky mtd code
<rmilecki>
i'll try to check tha
<guidosarducci>
rmilecki: originally, but it's been updated the "right way" since then. Thanks!
noltari has quit [Quit: Bye ~ Happy Hacking!]
plntyk2 has left #openwrt-devel ["Leaving"]
plntyk has joined #openwrt-devel
noltari has joined #openwrt-devel
noltari has quit [Read error: Connection reset by peer]
noltari has joined #openwrt-devel
Dracos-Carazza_ is now known as Dracos-Carazza
f00b4r0 has joined #openwrt-devel
valku has quit [Quit: valku]
f00b4r0 has quit [Quit: This computer has gone to sleep]
dedeckeh has joined #openwrt-devel
nitroshift has joined #openwrt-devel
Ivan__83 has quit [Quit: Miranda NG]
Ivan__83 has joined #openwrt-devel
slh64 has quit [Quit: gone]
slh64 has joined #openwrt-devel
lipnitsk has quit [Quit: Leaving.]
HeMan has joined #openwrt-devel
Red_M_ has quit [Quit: |]
Red_M has joined #openwrt-devel
Red_M has quit [Changing host]
Red_M has joined #openwrt-devel
Net147 has quit [Quit: Quit]
hsp has quit [Quit: WeeChat 3.0.1]
Net147 has joined #openwrt-devel
ivanich has joined #openwrt-devel
hsp has joined #openwrt-devel
<ldir>
nbd: ping - I've got that build problem on another mac - https://pastebin.com/wAmFqM4K - I'm confused to say the least!
LoopHoldYoaBrown has joined #openwrt-devel
Tost has joined #openwrt-devel
goliath has joined #openwrt-devel
Borromini has joined #openwrt-devel
nast has quit [Remote host closed the connection]
<aparcar[m]>
mangix: ping
f00b4r0 has joined #openwrt-devel
LoopHoldYoaRed has joined #openwrt-devel
LoopHoldYoaRed has quit [Remote host closed the connection]
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
LoopHoldYoaRed has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
mangix has quit [Ping timeout: 268 seconds]
<nitroshift>
rsalvaterra, ping
<nitroshift>
morning guys
<nitroshift>
<yawn>
<rsalvaterra>
nitroshift: pong o/
<nitroshift>
pm please?
<Borromini>
morning
mangix has joined #openwrt-devel
<rsalvaterra>
Sure, go ahead. :)
LoopHoldYoaBrown has quit [Quit: ZNC - http://znc.in]
danitool has joined #openwrt-devel
<Grommish>
I'm bleary eyed and tired, but can anyone think of a reason the build system would refuse to use the .xz package it created in ./dl/ on download but instead goes out every step and downloads trhe git source over and over?
<Grommish>
It's 550mb each time, and I'm not sure why
<zorun>
wrong PKG_MIRROR_HASH?
<Grommish>
the Makefile has the HASH which I did manually from the pack it did during a make package/xxx/download, because I wondered if it was freakout because of the skip
<Grommish>
PKG_MIRROR_HASH isn't even defined at this point
<Grommish>
The package is only avail as source, so it had to go out and get it to tarball it, but it's doing it each step.. prepare, configure, compile, etc
<russell-->
looks like linux-mips.org is off the air
dedeckeh has quit [Ping timeout: 240 seconds]
MichaelOF has quit [Quit: Konversation terminated!]
nast has joined #openwrt-devel
<nast>
quick question: 19.07.7 ath79 target is missing most of the packages e.g. luci-app-aria2 missing which makes it imossible to use imagebuilder with this target. Is this a known problem?
<Grommish>
russell-- Not only gone, but really gone.. I can't even do a historical IP pull on it
<zorun>
nast: this would be a problem, but the packages seem to be there. what is your error?
<nast>
sorry, you're right.
<nast>
I was wrong about it.
<nast>
it was couple of hours ago I was building mt7621, x86 and ath79 images, and only last one failed. but it should be ok now.
<zorun>
ok
<russell-->
Grommish: seems like a dns problem, maybe their server is in texas
<Grommish>
My domain can be tracked by historical IP back to 2011.. linux-mips.org I can't even find a single historical one
<Grommish>
and it is registared out of india
<Grommish>
It was also renewed in 2020
<Grommish>
I wonder if someone stole it on expiration
dedeckeh has joined #openwrt-devel
mangix has joined #openwrt-devel
<rsalvaterra>
mangix: ping
<mangix>
rsalvaterra: pong
<mangix>
my docker setup blew up
<mangix>
i have no idea how to debug this
<rsalvaterra>
mangix: I'm now chasing the IRQ problem on the Omnia… you told me you have a couple of Omnias, right?
<mangix>
just one
Darkmatter66 has joined #openwrt-devel
<rsalvaterra>
Ok, one is enough. :)
<russell-->
Grommish: i only noticed because i set up a git remote to their tree some time ago and a fetch wasn't connecting
<rsalvaterra>
What version of OpenWrt is it running?
<mangix>
it isnt
Darkmatter66_ has quit [Ping timeout: 260 seconds]
<rsalvaterra>
Oh… /o\
<Grommish>
russell-- Yeah, I tried to find some patches there a while back and couldn't ocnnect, but didn't think about it.. viewdns.info is a tool I use that can give interestring info.. https://viewdns.info/iphistory/?domain=openwrt.org
<Grommish>
Don't do google.com :D Takes forever
<Grommish>
I want to go to bed but I want to see if zorun has saved me from my own idiocy first
<mangix>
docker...how amazing. the only error it's giving me is that something went wrong
<Grommish>
Next it'll be all about the kubers :)
dedeckeh has quit [Ping timeout: 240 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
mangix has quit [Quit: leaving]
zatwai has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
mangix has joined #openwrt-devel
zatwai has joined #openwrt-devel
mangix has quit [Client Quit]
gnustomp has quit [Quit: yes]
mangix has joined #openwrt-devel
<mangix>
sigh. looks like i'll have to rebuild my NAS
* mangix
hates debian
* Borromini
loves debian
* rsalvaterra
loves Debian
<Borromini>
mangix: i thought you liked arch? why are you using debian on your NAS?
<rsalvaterra>
Borromini: It doesn't necessarily have to be pure Debian. OpenMediaVault is Debian-based, for example.
<Borromini>
true.
<olmari>
TrueNAS is FBSD.. Besides the OS, truenas itself is actually awesome thing =)
<f00b4r0>
it is
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
* Borromini
doesn't mind plain debian with zfs on his x86_64
<Borromini>
have armbian on my odroid xu4 though.
<olmari>
I use ZFS on selected use computers w/ debian, but on NAS specifically, TrueNAS does rule (:
<stintel>
Borromini: what are you using the xu4 for?
<nitroshift>
anyone knows why samba-libs fails to build due to libncursesw6 dependency not found?
<nitroshift>
it isn't available in buildbot packages either
<f00b4r0>
nitroshift: jow was discussing that yesterday with nbd. Seems to be realated to ABI dependency changes
<nitroshift>
f00b4r0, thanks
<mangix>
Borromini: my NAS is ARM based
<mangix>
kinda have to use Armbian
<rsalvaterra>
mangix: It's the Helios, right?
<mangix>
yeah
<Borromini>
mangix: what's the state of arch linux arm?
<mangix>
none. lol
<Borromini>
you got the helios or the helios64?
<mangix>
4
<mangix>
meh it requires custom patches to work eight
<mangix>
right
<Borromini>
with 'none' are you talking in general or for your device in particular
<mangix>
device
<mangix>
ALARM supports mvebu
<mangix>
I installed ir on the Omnia at one point actually
<mangix>
everything was broken ao I didn't go further
<enyc>
rsalvaterra: hrrm I was considering putting some sort of mini-arm thing in an old scsi hdd cage ;p
<enyc>
rsalvaterra: make small nas box... already has small very nice quality 5/12v psu in itwith plenty spare 5v to run a PI/smmilar
<mangix>
beware of SATA performance
<enyc>
mangix: sure, and SATA breakout fun....
<enyc>
mangix: some but not all mini-ARMs can have a pci-e/nvme ssd attached.... I wonder!
<mangix>
yeah the hwlios64 has one
<enyc>
seems like owrt 21.02 forked already -- but not to stage of test images with new mac80211 yet?
<mangix>
probably too warly
<enyc>
I'm really wondering where to "watch" per-se
<enyc>
Borromini: nm, badly worded "whats that" -- I think I can see on openwrt git...
<Borromini>
enyc: i gathered that, my reply was aabout which statement you were asking about
<Borromini>
and yes, the UniFI 6 LR snuck in
<enyc>
Borromini: ok, what is the snuck_in backport -- just new device
<nitroshift>
ldir, i had the same question but for a different package, the answer i got was that they are related to ABI dependency changes
<Borromini>
enyc: yeah
<enyc>
hrrm upstream 5.10.17 has ath9k: fix build error with LEDS_CLASS=m .... When CONFIG_ATH9K is built-in but LED support is in a loadable module, both ath9k drivers fails to link .... doubt this is openwrt issue
<ldir>
nitroshift: it's all very confusing - I had this problem on one build system and it magically went away. The other build system is throwing this error however the ipkg files etc produced are identical.
<Borromini>
enyc: mac80211 is at 5.10.16 atm
<nitroshift>
ldir, same here
<Borromini>
ldir: it looks very random every time. i have had it with dmesg every single time
<Borromini>
sometimes cleaning tmp/ and bin/ helps
<enyc>
Borromini: yes i mean... this build error probably doesn't affect openwrt strongly expect led support built in default kernel
LoopHoldYoaBrown has joined #openwrt-devel
<Borromini>
mangix: mt7621 has no hardware crypto, does it?
<ldir>
Borromini: I've done that a couple of times - I'm thinking it's a bug in opkg
<Borromini>
ldir: yeah it always pops up at the image generation stage
<blogic>
blocktrron: ping
<blogic>
blocktrron: did you get one of the mt7622 unifis ?
LoopHoldYoaBrown has quit [Ping timeout: 260 seconds]
Darkmatter66 has quit [Ping timeout: 272 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<blocktrron>
blogic: yes, its here
<blocktrron>
Pre orderes beginning of dec 20
<blocktrron>
Their shipping estimations are a big lie. "In stock" can mean "8 weeks"
<Borromini>
blocktrron: i recently got a second hand mt7610 device to play with, is the "mt76: mt76x02: set bssi_idx in mt76x02_mac_wcid_set_key" in your mt7610-fix branch something one would want?
<mangix>
Borromini: yes it doea
<Borromini>
mangix: yeah, thanks
T-Bone has joined #openwrt-devel
<blocktrron>
Borromini: this patch is upstream and backported to 19.07
<mangix>
supposwdly an XOR engine too. no driver though
<Borromini>
blocktrron: ok thanks, will comb through mt76 commits, in pre-21.02 a well then probably
f00b4r0 has quit [Ping timeout: 272 seconds]
ivanich has quit [Read error: Connection reset by peer]
<blocktrron>
Well, ope
<blocktrron>
mt76 in 19.07 is pretty much 2 years old at this point. Not sure if i'd waste time on that
ivanich has joined #openwrt-devel
<blocktrron>
OTOH, there were not big changes for mt76x{023} i'm aware of
snh has quit [Read error: Connection reset by peer]
<Borromini>
(i remember there being talk of it being too young to include in the release)
<stintel>
I wanted something PoE-PD
<Borromini>
stintel: same here.
<stintel>
can't wait for a PoE-PD with PT
snh has joined #openwrt-devel
<Borromini>
PT?
<stintel>
and preferably NBaseT PoE-PD uplink :P
<stintel>
PassThrough
<Borromini>
ah ok.
<Borromini>
hehe
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
DirkS has quit [Ping timeout: 240 seconds]
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 272 seconds]
DirkS has joined #openwrt-devel
LoopHoldYoaBrown has joined #openwrt-devel
<blogic>
blocktrron: so you have one and it works ?
nitroshift has quit [Remote host closed the connection]
nitroshift has joined #openwrt-devel
danitool has quit [Remote host closed the connection]
T-Bone is now known as f00b4r0
<blocktrron>
blogic: yes
<blocktrron>
writing this message with it
* olmari
is glad that in very recent years the "active" PoE stuff entry-level has came well cheap
<olmari>
I hate the active word there, but can't fight windmills there =)
LoopHoldYoaBrown has quit [Ping timeout: 272 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
guidosarducci has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
<blogic>
blocktrron: ok, found 1 on ebay
<blogic>
ordered it
<blocktrron>
:)
decke has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 264 seconds]
Acinonyx has joined #openwrt-devel
<blogic>
blocktrron: what radio is used for 2,4g ?
<blogic>
and does the pcb have jtag /
<blogic>
?
<blocktrron>
it's the mt7615 of the mt7622
<blogic>
hmmmz
<blocktrron>
I haven't seen jtag on the PCB, i can do some pictures if you'd like
<blocktrron>
although i'm not able to get the cans of, as they are either glued together or require different tools than the ghetto screwdriver i have here
<stintel>
maybe I should have another go at getting OpenWrt on my 8x8 ax AP with 10GbE PoE-PD uplink :P
DirkS has joined #openwrt-devel
<stintel>
that EAP245 is disappointingly slow still
<plntyk>
ha
<karlp>
bah, your speedtest result reminded me that I need to replace a gig switch,I'm on 100Monly at themoment.
<Borromini>
stintel: which one is that 8x8?
<plntyk>
i have the "fdisk" incompatible with the architectures configured bug
<plntyk>
lucky me -.-
<Borromini>
plntyk: queue at the back :P
<Borromini>
stintel: are you renting out your pipe to the rest of the building?
<rsalvaterra>
stintel: 1000/600…? o_O
<Borromini>
could make some money :P
* rsalvaterra
cries in 200/20…
* Borromini
hides his 100/40
<blogic>
100/50 altough i pay for 250/100
* plntyk
hits his 32/4
<rsalvaterra>
Borromini: I'd happily trade my 200/20 for your 100/40. :P
<stintel>
wait till you hear the price :P
<blogic>
i was on 6/2 until 4 months ago ;)
<stintel>
blogic: I remember something like that, must be a huge improvement nonetheless
<SwedeMike>
blogic: ouch, ADSL?
<rsalvaterra>
blogic: Uhh…? What, ADSL?
ivanich has quit [Quit: Konversation terminated!]
<Borromini>
rsalvaterra: you need the upload? :)
<stintel>
paying 35lv/month
<Borromini>
stintel: that's why i am saying you should re-sell :P
<olmari>
Who doesn't need the upload too?
<stintel>
Borromini: so ~EUR18/mo
<Borromini>
stintel: oh. you said it because it was effing low :(
<Borromini>
yes. lv is BGN
<Borromini>
ddg doesn't like two letter currencies :P
<stintel>
ddg ?
<rsalvaterra>
Borromini: Who doesn't need the upload? :)
<Borromini>
stintel: duckduckgo has a currency converter
<Borromini>
rsalvaterra: true.
<stintel>
ahhh
<Borromini>
especially with the asynchronous part
<stintel>
I gave up on duckduckgo
<Borromini>
i fall back to google if it doesn't work
<stintel>
I was type !g foo all the time
<Borromini>
but most of the time it does
<Borromini>
hehehe
<rsalvaterra>
Connection asymmetry is a cancer.
<stintel>
well I can live with 1000/600, but in Belgium they now offer 1000/40
<stintel>
😂
<rsalvaterra>
Even dial-up was symmetric up until V.90. :P
<Borromini>
s/asynchronous/asymetric/
lipnitsk has joined #openwrt-devel
<Borromini>
so so two m's anyway, lovely
<SwedeMike>
rsalvaterra: well, it started off at 1200/75, then it was symmetric for a while until HST 9600/300 etc
<Borromini>
i need me an irssi spellchecker :P
<rsalvaterra>
1000/40…? That needs SQM with aggressive ack filtering. :P
csrf has quit [Ping timeout: 240 seconds]
<stintel>
rsalvaterra: it's full retard :(
<SwedeMike>
I actually de-bloat my 1000/1000 down to 900/900 with FQ_CODEL
<rsalvaterra>
SwedeMike: Well, your 1000/1000 is probably already about 950/950 accounting for the overhead… :)
<ldir>
right, there HAS to be a word in German for this - what is it when you're both pleased but also quite cross at the same thing?
<SwedeMike>
rsalvaterra: all depends on how one counts the overhead, indeed.
<stintel>
and now I'm really going to have to replace the APU2. it just isn't strong enough
<SwedeMike>
stintel: my APU2 can't do 900/900 with CAKE, but it seems fairly ok at FQ_CODEL
<rsalvaterra>
SwedeMike: I usually count the goodput. :)
<SwedeMike>
I have an odroid h2+ I'm waiting for openwrt to gain native support for
<stintel>
SwedeMike: you have a command handy for that fq_codel thing ?
<ldir>
'macbot' has ridded itself of the 'can't find fdisk incompatible arch' problem - but I have no definitive reason as to how/why - grrrr
<SwedeMike>
stintel: I just use the built in luci-sqm-apps or whatever it's called
<stintel>
SwedeMike: I was looking into it but meh those realtek NICs :(
xes_ has joined #openwrt-devel
<stintel>
SwedeMike: ah, ok. I'll have a look
<Borromini>
stintel: they even have an expansion board with i think 4 extra 2,5 Gbit NICs
<stintel>
yeah
<stintel>
it looks super fancy
<stintel>
but maybe I should try again to get a Macchiatobin
xes has quit [Ping timeout: 240 seconds]
<stintel>
with layer_cake my speed drops below 200Mbps :/
<SwedeMike>
stintel: sqm-scripts-extra and luci-app-sqm
<SwedeMike>
yeah, CAKE doesn't work well at high speeds, I had to stop doing that. I reported it to the people who made it and they started talking about irq load etc
<stintel>
I see, so it's not just me
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
<stintel>
what do I need to do to get luci-app-sqm in luci after installing it? it's not in the menuys
<Borromini>
under admin > network?
<Borromini>
well just under network
* Borromini
was looking at the URL
<SwedeMike>
it's in network->SQM QoS for me
<SwedeMike>
and I didn't have to do anything
<SwedeMike>
stintel: I install luci-app-sqm sqm-scripts and sqm-scripts-extra , did it do all of those for you based on dependencies?
<stintel>
SwedeMike: I already had the latter 2
<Borromini>
stintel: maybe a forced reload of your web interface?
<stintel>
nope. also remove /tmp/luci*
<stintel>
still not visible
<Borromini>
there was also some purge thing to append at the end if it kept showing stale data but i forgot the exact wording
<Borromini>
or ?nocache
LoopHoldYoaBrown has joined #openwrt-devel
csrf has joined #openwrt-devel
<ldir>
cake is a bit of a cpu beast but then it's potentially doing quite a bit - shaping the link to a rate (unless in unlimited mode) - host fairness (by default) - nat lookups (not default for the host fairness) - diffserv fairness and finally an fq-codel/blue hybrid queue management thing.
<blogic>
ldir: so cake even works if i do not know the correct rate, right ?
<ldir>
it can use the 'back pressure' from the network interface driver...which hopefully implements byte queue limits.
<ldir>
if the back-pressure doesn't exist as is the case for adsl/vdsl drivers then your only option is to shape what you send into that driver.
<blogic>
ok
<blogic>
i need to look into the cfg
<blogic>
do you have a working uci cfg at hand ?
<blogic>
the wealth of options always confused me
<ldir>
no, not really - I have to shape the link to my vdsl modem 'cos it has a bufferbloat problem... my 100Mbit eth link to modem will overwhelm the 80/20 vdsl link
LoopHoldYoaBrown has quit [Ping timeout: 246 seconds]
<ldir>
I'll have a think/test with how to select 'unlimited' rather than 'bandwidth 'n'' mode within the sqm-scripts paradigm, 'cos it isn't obvious to me either!
LoopHoldYoaBrown has joined #openwrt-devel
linzst has joined #openwrt-devel
linzst has quit [Remote host closed the connection]
decke has quit [Quit: Leaving.]
eduardas has joined #openwrt-devel
<ldir>
does anyone here have a feel for how fast the apple m1 macbooks are for building openwrt with respect to say a 2017 intel based box?
<rsalvaterra>
ldir: It should be fast, especially with Linux, but that will take some time.
lipnitsk has quit [Quit: Leaving.]
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
adrianschmutzler has joined #openwrt-devel
guidosarducci_ has joined #openwrt-devel
guidosarducci has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
guidosarducci_ is now known as guidosarducci
LoopHoldYoaBrown has joined #openwrt-devel
mattsm has joined #openwrt-devel
csrf has quit [Ping timeout: 272 seconds]
Darkmatter66 has quit [Ping timeout: 256 seconds]
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<stintel>
yeah my ssh connection definitely starts lagging without SQM
csrf has joined #openwrt-devel
<rsalvaterra>
I know this is probably the wrong channel to ask this, but… how do you guys debug multicast connectivity problems? :/
Night-Shade has joined #openwrt-devel
<blogic>
stintel: can you send me your sqm uci ?
<stintel>
blogic: sure
Night-Shade has quit [Client Quit]
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
Night-Shade has joined #openwrt-devel
Tapper1 has joined #openwrt-devel
Tapper has quit [Ping timeout: 272 seconds]
Tapper1 is now known as Tapper
LoopHoldYoaBrown has joined #openwrt-devel
<SwedeMike>
rsalvaterra: what kind of multicast? I've debugged some multicast in my life...
<rsalvaterra>
SwedeMike: basically, a triple-play service. IPTV.
<SwedeMike>
rsalvaterra: so this is for an HGW point of view? How much do you know multicast?
<rsalvaterra>
I still can't get (surprise!) the TV box streaming without stopping after about 5 minutes.
<SwedeMike>
rsalvaterra: start by tcpdumping IGMP/MLD on wan and see if it's sending periodic updates
<SwedeMike>
correlate with IGMP/MLD on LAN and see what's going on there, then if that looks fine, check if stream still comes in on wan and not out to lan (indicating the actual routing is the problem)
<rsalvaterra>
SwedeMike: I'm running igmpproxy at verbosity level 2 and it seems to be working. Receives requests from the lan, repeats them upstream in the wan.
<rsalvaterra>
The network is IPv4 only, so it's only IGMP, not MLD.
koniu has quit [Remote host closed the connection]
<SwedeMike>
rsalvaterra: I have less experience fault-finding linux bridges etc, I mostly deployed multicast in ISP network so it was more PIM/MLD/IGMP/MSDP etc
<rsalvaterra>
The lan side is a single interface, not a bridge, so I suppose IGMP snooping won't buy my anything. Is my reasoning correct?
<SwedeMike>
yeah, if it's not a bridge then I guess that's out of the question
<SwedeMike>
but again, I'd verify if the ISP stops sending you the stream (tcpdump on wan) and that's the problem, or if it's the actual forwarding on your device that is the problem
<rsalvaterra>
I hate these new-fangled boxes which require both IPTV and internet access. :P
koniu has joined #openwrt-devel
<rsalvaterra>
Yeah, I've done a fair bit of tcpdump and I see the stream stopping, of course. But that's the symptom, I'm trying to find the cause…
<SwedeMike>
stream stopping where?
<SwedeMike>
does it stop coming in on wan or does it stop being forwarded?
ivanich has joined #openwrt-devel
<rsalvaterra>
Good question, I'll have to recheck that.
<rsalvaterra>
I need forwading from the lantv to both wantv and wan (these are the actual zone names).
<rsalvaterra>
Both wantv and wan are masqueraded.
<rsalvaterra>
Both wantv and wan input is dropped by default, but from what I seen, igmpproxy does the right thing with the firewall rules.
<SwedeMike>
good fault isolation is to see if your ISP is still sending you the stream or not, before you know that there is little reason to start poking at other places
<rsalvaterra>
Ok, tcpdump on the wantv side it is. :P
<rsalvaterra>
Thanks for the hints! :)
enyc has quit [Ping timeout: 265 seconds]
Olipro has quit [Read error: Connection reset by peer]
Olipro has joined #openwrt-devel
Olipro has joined #openwrt-devel
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
guidosarducci has quit [Ping timeout: 268 seconds]
guidosarducci_ is now known as guidosarducci
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<hurricos>
Any recommendations on an 8+ port SFP+ managed switch?
<ldir>
Hmm, kernel patch refreshing is so slow. Or the standard script has to do it in a slow way at least. For every target the generic kernel patches are refreshed. Ideally the generic stuff would be refreshed once and then the target specific patches refreshed on top of that.
<ldir>
It's not a task that lends itself to parallelism either - hmmm.
mattsm has quit [Read error: Connection reset by peer]
mattsm has joined #openwrt-devel
<hurricos>
ldir: what's the current order of patch application?
<ldir>
thought out loud - download new kernel archive from upstream, apply/refresh patches to it and produce a local 'patched generic kernel' tar archive. Then use that 'openwrt localised generic patched kernel' archive for everything else, refreshing the target patches on it.
<hurricos>
Sounds like a good job for overlayfs/docker
<ldir>
hurricos: get vanilla kernel archive. Apply openwrt generic patches to it. Apply openwrt target specific patches on top of that.
<hurricos>
but if I had to guess, a good reason against changing it is that the patching process already leaks internal logic
<ldir>
thus a refresh of all 'n' targets also refreshes the generic patches 'n' times, where 'n-1' runs will (or should) result in no changes to the generic patches.
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
<adrianschmutzler>
ldir: I also asked myself that question a few times, but I did have an idea how to improve that
<adrianschmutzler>
at least applying the generic patches is necessary on every target ...
<adrianschmutzler>
so, one could only save updating the patch files afterwards, i.e. half of the job
<adrianschmutzler>
and making that possible would make the whole thing more ugly and error-prone
<ldir>
another potential thought - instead of a full patched kernel archive, just have the generic differences in an archive that is restored over the kernel
<adrianschmutzler>
yes, but the problem is when and how this kernel+generic would be created
<adrianschmutzler>
unless we make refreshing a two-step process and hand this over to the user
<adrianschmutzler>
but given the saved time, one should actually consider ugly options if they are sufficiently "safe"
<ldir>
it should be something like 'make target/generic/refresh' - I don't know really but the current situation is very slow and seems to be wasting a lot of time.
LoopHoldYoaBrown has joined #openwrt-devel
<adrianschmutzler>
yes, no argument about the latter
<ldir>
unless you can parallel at target level it's a lot of sequential 'quilt foo'
<hurricos>
I'm sure you have some kind of low-level architecture to verify bkd radiation isn't messing up your hardware
<hurricos>
but vxworks *software* also plays a part in that stack
<blogic>
that suprises me
<hurricos>
I'm sure they run vxworks on the aforementioned synthesized hardware
<blogic>
but at the end of the day in a few days, weeks we might know if live exist beyon earth
<blogic>
lets hope the unit survives the "7 minutes of terror" and we get "touchdown confirmed"
<hurricos>
it's powerpc. it'll survive B)
<hurricos>
or, well ... I guess only on convenience would it be powerpc
<blogic>
the can even run this on win7, if the results deliver its cool imho
<blogic>
i was not born when the moon landing happened, been religiously watch all landing I was able to
<blogic>
hale-bopp tickled me, we had an abservatory at my uni at the time and seeing it and 2 weeks later the rings of saturn with my own eyes got me addicted
LoopHoldYoaBrown has quit [Ping timeout: 256 seconds]
<hurricos>
NAND usually doesn't get accessed via MTD, does it? I was under the impression one used mostly ubifs with NAND.
<hurricos>
Oh, not usually *partitioned* under mtd, but I checked my mx60w and it's definitely there.
<blogic>
hah you'd be suprised how vendors mis-use nand
<blogic>
we just spent 1 whole week to make mtk usage sane
<blogic>
they have all kinds of weird hacks to make jffs2 work on it
<hurricos>
all vendors should submit to the glory of OpenWrt
<blogic>
hurricos: working on it ... ;)
Darkmatter66 has quit [Read error: Connection reset by peer]
<hurricos>
Doing It The Right And Maintainable Way Ever Since Time Ended / Reality Nonced
<hurricos>
ditramwestern (?????)
<blogic>
huh ?
<blogic>
-EPARSE
<hurricos>
^
<hurricos>
^~~~~~
LoopHoldYoaBrown has joined #openwrt-devel
Darkmatter66 has joined #openwrt-devel
<Borromini>
welcome to the multiverse eh ;)
<aparcar[m]>
mangix: ping
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<aparcar[m]>
anyone experiencing any gettext issues?
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<aparcar[m]>
lipnitsk: ping
<enyc>
hrrrrrrrm... I see **snapshot** images on downloads.openwrt.org ,but not sure if these are master or 21.02-fork based... I'd like to help/test 21.02 in a way that can be upgraded into release eventually.
<plntyk>
aparcar: a patch for gettext is on the mailing list
<plntyk>
contains the include/autotools.mk sed fixup
<aparcar[m]>
Borromini: thanks you've been faster ;)
<Borromini>
have that in my paste buffer half of the day by now :P
<aparcar[m]>
plntyk: Yea I think I caused the issue by merging mangix patch :)
<aparcar[m]>
So the issue is still active...
<plntyk>
dunno i locally have sed -ne '1s/.*\([0-9]\.[0-9]\{2\}\(\.[0-9]\)*\).*/\1/p'
<plntyk>
maybe try that ?
<plntyk>
is wpa3 working with wpad-openssl ? i cannot seem to get it to work
<Borromini>
plntyk: sure?
<plntyk>
i flashed a glinet ar750s nor-nand unit (ath10k qca9887) , and in luci selected only the wpa3 setting
<plntyk>
current (todays) trunk
<plntyk>
connecting from win10 in a VM (rtl8812au stick) no connection possible
<pkgadd>
Hauke: I've been running your ppp update on a Deutsche Telekom VDSL2 line (lantiq/ bthub5) for the last two days, seems to work nicely
LoopHoldYoaBrown has quit [Ping timeout: 260 seconds]
<Borromini>
plntyk: i've been running WPA3 for ages with Intel AC clients and what i think are QCA mobile clients (no idea what wifi the smartphones here have)
<Borromini>
should check my wife's laptop hardware but i think it's some cheapo bottom range intel card as well.
<Borromini>
plntyk: what i can say is i haven't got a single W10 client that works on that WPA3 network
<Borromini>
so yeah.
<Borromini>
but those same cards all work fine with their linux drivers
<svanheule>
Borromini: Intel doesn't update it's drivers to do WPA3 on older cards :-(
<Borromini>
my wife's phone is android 9, and that doesn't work, i have the same but with Android 11
<svanheule>
s/it's/its
<Borromini>
svanheule: no, and why would they eh :-/
<plntyk>
if i try to connect with mt76x2u stick (avm fritz wlan) - fails with reason 3 in linux xfce debian sid
<Borromini>
svanheule: thing is i have a rather recent laptop from work that i'd expect would support wpa3 on win10 (very recent win10 but hey those drivers eh)
<Borromini>
but it doesn't
<svanheule>
which card?
<Borromini>
should check, no idea
<plntyk>
the other mt76 usb stick (single stream) doesnt work in a VM with usb host
<Borromini>
it's their business line and a rather recent i5 combo, laptop is a few years old, small bezels already like the XPS line (but not XPS)
<PaulFertser>
plntyk: on my Debian I had to add pmf=1 to wpa_supplicant config
<Borromini>
PaulFertser: ok. by the time i switched to WPA3 my laptop was already Debian Testing (pre-Bullseye)
<Borromini>
WPA3 worked just fine, so might be wpa-supplicant had already been adapted by then
<svanheule>
Borromini: Intel stopped making mini-pcie card with the 7260, but those drivers are terrible! Disconnects after a while, and won't automatically reconnect :-/
<PaulFertser>
pmf=1 seems to be not default
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
<PaulFertser>
Borromini: are you using any software to configure wpa_supplicant?
<svanheule>
Borromini: in any case, the bios of that HP laptop had to be modified to put the newer card in it's whitelist of allowed cards (who ever came up with that idea deserves an eternity in hell)
<svanheule>
again s/it's/its
<pkgadd>
Borromini: a lot of WPA3 (well, 802.11w, to be exact) bugs have been solved (as in transparently falling back to mac80211 based software crypto) in the mainline kernel between october and november last year, so you need a rather recent kernel to be on the safe side
<pkgadd>
ath9k for the old draft-n chipsets (up to ar9160), b43, rt2x00, ...
<Borromini>
PaulFertser: i am relying on NetworkManager
<Borromini>
(the Gnome frontend that is)
<Borromini>
svanheule: intel can be pesky, and that with all that money they're sitting on. so you hacked that bios huh? :) i'm glad my dell didn't have a whitelist (swapped out the single supported Broadcom card under Linux for an Intel AC8260)
<pkgadd>
aside from ipw2200, all my (actually used-) linux systems can now do wpa3 just fine, android is another topic (older devices, kernels 3.4 and older)
<Borromini>
pkgadd: i was happy to see my phone do it with android 10, wasn't sure about the drivers, since the kernel is still the 4.4 one from OEM Android 8 afaik
<pkgadd>
sadly a lot of devices don't like to work with APs running in mixed mode (even if they can do WPA3-only)
<Borromini>
pkgadd: i ended up settting up a WPA3 only AP and a WPA2 only one on the same radio
<pkgadd>
yep, that's a better solution
<Borromini>
so the wife's phone (and our work laptops, which are windows) can still get on the network
<Borromini>
once everything is stabilised here i plan on just having a guest network for the WPA2 stuff.
LoopHoldYoaBrown has quit [Ping timeout: 240 seconds]
<hurricos>
Is it practical on machines with an IOMMU/PCIe WLAN card to stick OpenWrt in a VM with macvtap on an eth port and full passthrough of the wlan?
LoopHoldYoaBrown has joined #openwrt-devel
<hurricos>
Seems it'd be an interesting / easy way to combine your desktop and router.
<hurricos>
s/rouer/wap/
<hurricos>
Though probably easier to find spare OpenWrt devices than to do sth like that.
<pkgadd>
hurricos: I've tried passing through USB wlan cards to a kvm VM a couple of years ago, that didn't work at all (well, very badly). PCI(e) should be better
LoopHoldYoaBrown has quit [Ping timeout: 260 seconds]
LoopHoldYoaBrown has joined #openwrt-devel
<plntyk>
my issue seems to be with ac mode and wpa3 - wpa3 with "n" on same hardware seems to work (with ath9k-htc as client)
<blogic>
"touchdown confirmed" ... wow
<blogic>
thx NASA
<blogic>
Perseverance is alive and sending a strong signal
<Borromini>
:)
<hurricos>
pkgadd: Sounds about right for USB.
<blogic>
totally mind blowing
<blogic>
lets hope we find microbes
LoopHoldYoaBrown has quit [Ping timeout: 265 seconds]
dedeckeh has quit [Quit: Connection closed]
LoopHoldYoaBrown has joined #openwrt-devel
SibrenVasse_ has joined #openwrt-devel
valku has quit [Quit: valku]
philipp64 has joined #openwrt-devel
SibrenVasse_ has quit [Ping timeout: 264 seconds]
LoopHoldYoaBrown has quit [Ping timeout: 264 seconds]
HeMan has quit [Quit: Connection closed for inactivity]
ivanich has quit [Quit: Konversation terminated!]
LoopHoldYoaBrown has joined #openwrt-devel
<rsalvaterra>
Hmm… is quilt smart enough to delete upstreamed patches when refreshing?
<ldir>
rsalvaterra: if a patch can be reverse-applied then it will warn & stop, allowing you to manually run 'quilt delete -n'
<rsalvaterra>
ldir: Nice, didn't know that (never happened to me). :)
<ldir>
so an upstreamed patch, when it returns back down to us from upstream, will either 'reverse-apply' or if there have been upstream changes to said patch apply with conflicts that have to be resolved manually
<Borromini>
pkgadd: thanks for the hint about uboot-envtools. sent a patch in for the gs1900-8hp v1/2
<rsalvaterra>
ldir: Telling the user the patch can be "reverse-applied" is a bit cryptic, though. Git is more sensible in that regard ("contents already upstream").
<Borromini>
rsalvaterra: i always double check, because of the 'can'
<Borromini>
but after a few of those you get a bit more confident
<pkgadd>
Borromini: yep, I would have been surprised if those two would diverge from ZyXEL's usual partitioning scheme, I just hope https://github.com/openwrt/openwrt/pull/3860 gets merged as well ;)
LoopHoldYoaBrown has quit [Ping timeout: 272 seconds]
<Borromini>
pkgadd: i checked my 10HP and my 8HP v1, identical settings
<Borromini>
yes, i think some PRs are getting lost in the release frenzy =)
<Borromini>
Hauke: fwiw, that uboot-envtools issue, i'm not seeing it here either and i've done nothing but run clean master/21.02 builds in the past few days
rmilecki has quit [Ping timeout: 265 seconds]
<Borromini>
crap :(
LoopHoldYoaBrown has joined #openwrt-devel
<Hauke>
pkgadd: thanks for the update
<Hauke>
rsalvaterra: is the hardware bufefr support for the mvebu device stable?