<hanetzer>
and is it 'option gateway' or 'option gatewayip'? forget.
<Tusker>
option gateway
<hanetzer>
danke
<Tusker>
bitte
minimal has quit []
<hanetzer>
I really hate these devices.
<hanetzer>
so. I can ssh into device b, from my machine. from device b I can ssh to device c. but I cannot ssh to b or c from a directly.
<hanetzer>
and from c I can go to d. but I can't reach d directly either. What could be causing this? b,c,d are all configured as 'dumb aps' so no firewall or dhcp servers.
<Tusker>
are there static routes configured? do you see each station in arp tables ?
Monkeh has quit [Quit: No Ping reply in 180 seconds.]
Monkeh has joined #openwrt-devel
drikus_ has quit [Ping timeout: 480 seconds]
drikus_ has joined #openwrt-devel
<Namidairo>
maybe your poe injector is broke
<hanetzer>
suppose it is possible.
<hanetzer>
Tusker: no. I used to when my primary router was a pfsense box.
<hanetzer>
anywho, 'the internet' says that this particular ubiquiti AP acts funky with some switches.
rsa9000 has quit [Remote host closed the connection]
<hanetzer>
gonna end up doing the same thing I did with the other side that made it work reliably. just insert some dumb netgear switch between
<Namidairo>
maybe chuck some load onto the AP and see if the measured voltage drops or something
<hanetzer>
well, as it currently stands I really can't do anything with the ap, without inserting something between its poe injector and the poe switch.
<Namidairo>
is this where we hear you were electrocuted in the news later
<hanetzer>
nah, that's happened a few times tho in other lines of work :P
<Namidairo>
or you could just get ubiq to replace the whole thing
<hanetzer>
to replace the switch? or the funky AP itself?
<Namidairo>
...yes
<hanetzer>
very helpful, o tear-colored one :)
<Tusker>
does the switch port lose sync and fails to renogotiate properly ? is it set to fixed in the DTS ? not sure exactly what is going on in your case
<hanetzer>
Tusker: doesn't seem like it. light is still blinking, the webui (its an aruba s2500-48p) shows it as active, nothing too funky in the logs.
goliath has quit [Quit: SIGSEGV]
snh_ has joined #openwrt-devel
snh has quit [Ping timeout: 480 seconds]
danitool has quit [Ping timeout: 480 seconds]
victhor has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<stintel>
hanetzer: which AP? I have a U6-Lite that did that, I believe it happened on radar event, have selected a non-DFS channel and not seen the problem since
<hanetzer>
stintel: nanobeam m5 or something of the like (I know there's like, two variants in openwrt). Done fucking with it for the night, too frustrated.
<stintel>
ok very different beast
<hanetzer>
izzn't the u6-lite/lr that one with wifi 6?
<stintel>
yes
<hanetzer>
thoughts on them? considering replacing our meraki mr24's with them.
<stintel>
it's 2.4ghz 11n with 5ghz 11ax
<stintel>
which is kind of stupid
<stintel>
TP-Link EAP615-Wall looks way more interesting
<stintel>
it's proper wifi6 in both bands at least
<hanetzer>
hrm. any work in that regard for owrt?
<stintel>
waiting for a shop that delivers to Bulgaria to have them
<hanetzer>
ah, that can be a problem... they look interesting, and relatively cheap.
<stintel>
there is this one shop in Poland but they require me to send VAT registration documents instead of just doing a vies check
<hanetzer>
blegh. yeh, seems like VAT-related stuff is a pain in the ass?
<stintel>
I don't feel like putting the effort in getting a recent doc, potentially have to get it translated as it's in cyrillic, etc
<stintel>
ah some shops are just ... :)
<stintel>
usually it's not too bad
<hanetzer>
indeed.
<stintel>
oh, I might have found one
<hanetzer>
pizza time
<stintel>
yep, ordered 2
<hanetzer>
always nice when vendors put their gpl code right on the product page
<Slimey>
;)
<Slimey>
booze is whats for dinner
<hanetzer>
Slimey: ey' slimeball, howya doin?
<Grommish>
Is there a $() shortcode for ./feeds/packages?
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Tusker has quit [Quit: Time wasted on IRC: 7 hours 50 minutes 48 seconds]
rua has quit [Quit: Leaving.]
nitroshift has joined #openwrt-devel
rua has joined #openwrt-devel
valku has quit [Quit: valku]
<hanetzer>
stintel: model = "MediaTek MT7621 RFB (802.11ax,SNOR)"; from the firmware dtb :)
<hanetzer>
spoke too soon. the GPL release they've given is incomplete. no kernel sources (just a symlink to /home/zys/sambaServer/test_git/sdn5/SMB_EAP/build/../sdk/build_dir/mt7621da/linux-4.4.198 )
<stintel>
it's incomplete as usual ;)
<stintel>
probably have to mail back and forth with them a few times before you'll get a proper one
<stintel>
pffft, advent of code is too hard already for only being day 3
<stintel>
wtf
<stintel>
I spent 2h for part1, maybe I'm just too dumb for this
<hanetzer>
w0t is advent of code?
<hanetzer>
someone mentioned it in the minecraftforge discord server as well.
<stintel>
programming puzzles for each day of the advent
<hanetzer>
ah, advent is that christmas thing innit?
dedeckeh has joined #openwrt-devel
<stintel>
yeah :P
<hanetzer>
figures. my christmas experience is just santa and gifts as a kid, and I no longer observe it.
<Slimey>
hanetzer just busy with work and life :P you?
<stintel>
same
<hanetzer>
Slimey: same. my boards from oshpark shipped on 12/2, which is nice :)
<Slimey>
sweet
<stintel>
but I do go back to hometown for the holidays usually as one of my nieces has her birthday around christmas and my dad a few days after new years
<hanetzer>
yeh. a bit nervous; it was a 10 board medium run. I'll be pissed if they'refucked up.
<stintel>
so far only skipped that once, last year, due to covid
<stintel>
with the new restrictions being imposed in Belgium it might be the 2nd year I skip it
<stintel>
although I would prefer to go, dad turning 70 doesn't happen very often
rua has quit [Quit: Leaving.]
<nitroshift>
stintel, o/
<nitroshift>
happy birthdays!
<stintel>
nitroshift: :P
<stintel>
too soon ;)
<stintel>
how are ya
<nitroshift>
yeah, don't know when / how long i will be online next days / weeks
<nitroshift>
i'm at work now, been arguing with my ceo lately
<nitroshift>
apart from that, we're good
<stintel>
any skying trips planned ?
<nitroshift>
yeah, up the mountains near my place :D
<nitroshift>
wanna come? :)
<stintel>
depends
<stintel>
if I'm not going to Belgium, that could be a good idea
<stintel>
hmmm snow cover 0cm
<stintel>
I guess no snowboarding this weekend
<hanetzer>
stintel: honestly, having the dts is *usually* enough to get moving these days :)
Tapper has joined #openwrt-devel
<stintel>
hanetzer: well depends on the hardware but in this case most likely yes
<hanetzer>
yee.
<stintel>
I got a text message from fedex informing me of a shipment that would arrive on monday, but that would be too soon :P
<stintel>
apparently it's some branding stuff from $client I forgot about
<hanetzer>
hell with it stintel, you convinced me. just ordered one of those off amazon.
<stintel>
:P
<stintel>
hmm?
<stintel>
ow, wrong window
<stintel>
hanetzer: the coolest part about these devices is the PoE PT
<hanetzer>
that is useful, yes. could add a POE ipcam near each one if wanted :)
<stintel>
I had just bought 2x Unifi Switch Flex, 1 for in my office, so I could power both the IP phone and 8-port switch via it, instead of just one and using an injector for the other
<stintel>
and another one for behind the TV, so I could power the 8-port switch AND install an AP on this floor
<stintel>
in the latter case I have simply replaced the flex by an EAP235-Wall (similar model, but AC)
<Namidairo>
lcd screen and it's not an ubiquiti for once
<hanetzer>
oh hey, its the tear-colored one :)
<mangix>
it's a newer version of the turris omnia
<mangix>
looks like no more duplexersx
<hanetzer>
stintel: yeah, this one goes under target/linux/ramips, neat. seems most of the guts should just work oob with proper dts stuff.
<Namidairo>
ralink has been gone for over 10 years now
rmilecki has joined #openwrt-devel
danitool has joined #openwrt-devel
<hanetzer>
perhaps, but the dts of the device we're talking about says its a `model = "MediaTek MT7621 RFB (802.11ax,SNOR)";` with `compatible = "mediatek,mt7621-rfb-nor\0mediatek,mt7621-soc";`, which is under ralink in our tree.
<rsalvaterra>
mangix: Oh, look, a dead spider!
<svanheule>
hanetzer: stintel: Maybe have a look at the EAP235-Wall support in OpenWrt. I suspect the EAP615-Wall may be quite similar.
<hanetzer>
svanheule: yeh, I eyeballed that one a bit.
<rsalvaterra>
mangix: I like the aluminium case, should help dissipate heat a lot better.
<rsalvaterra>
But if that thing is based on the same Armada 385 SoC, it's absolutely dead-on-arrival.
<mangix>
nope
<mangix>
mvebu64 this time
<rsalvaterra>
mangix: That's better. Probably still an in-order CPU, I'm not getting my hopes up. :P
<Namidairo>
wait who's sticking 11ax chipsets to mt7621 this time
<rsalvaterra>
Namidairo: Most of China? :)
<Namidairo>
I already cringed when ubiquiti did it
<mangix>
rsalvaterra: it's ARMv8 as is vulnerable to spectre. so not in order.
<rsalvaterra>
mangix: Hm… are the specs available anywhere?
<mangix>
of that unit probably not
<mangix>
but I did get confirmation it's armada 3700
<stintel>
Namidairo: mt7621 is more than capable enough for 11ax with <=1GbE uplink
<stintel>
what makes absolutely no sense is the U6-LR
<mangix>
Namidairo: my e7350 works fine
<rsalvaterra>
mangix: The Armada 3700 is based on the Cortex-A53. That's an in-order microarch.
<stintel>
mt7622 + 802.11n 2.4GHz radio + 802.11ax 5GHz 4x4 + 2.5GbE phy in 1GbE mode :/
<rsalvaterra>
stintel: Still no PHY magic bits from Marvell? :/
<mangix>
rsalvaterra: it *might* be based on 88F7040 which is cortex a72
<rsalvaterra>
That would be nicer, yes.
<Namidairo>
i was wondering why everyone was calling 7531 a 2.5gbit switch
<stintel>
rsalvaterra: have not spent any more time on it, and Daniel is also busy with other stuff
<rsalvaterra>
I can relate. Also a bit more busy than usual IRL. :)
<stintel>
rsalvaterra: I'm currently testing EAP235-Wall, as I heard there might be stability issues (there are), and the mt7613 in it is also in a device that we might potentially use in a project
<stintel>
so I had $client ship me 2 and my home network is now running on these 2 only
<rsalvaterra>
4 cores, 2 GHz… I doubt it's A53-based.
rsalvaterra has quit [Quit: rsalvaterra]
rsalvaterra has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
pmelange has joined #openwrt-devel
<Namidairo>
what if they overclocked a 807x like mad
pmelange has left #openwrt-devel [#openwrt-devel]
goliath has joined #openwrt-devel
<nbd>
stintel: i pushed another mt76 update that might help with mt7663
slingamn has quit [Ping timeout: 480 seconds]
<stintel>
nbd: ok, seems like I had another stall this morning, long enough for iperf to timeout, I'll do a new build right away
<stintel>
it didn't result in memory usage going near 100% but well if the stall happens around the time I'm walking upstairs and my phone roams ...
<stintel>
maybe I should make a test ssid that is only available on one of my 2 APs
snh_ has quit []
snh has joined #openwrt-devel
minimal has joined #openwrt-devel
<stintel>
wait, that stall might have been due to my main router shitting the bed
* stintel
checks timestamps
nlowe has joined #openwrt-devel
nlowe has quit []
<stintel>
actually looks like it. wonder what happened there. I wasn't properly awake yet, didn't realize after moving the console cable from a 9600 baud device to the m300 that I had to change to 115200, concluded the device was stuck and power-cycled it so no clue what was going one :(
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
<stintel>
it's the first time I was doing iperf3 -t0 --bidir, let's try that again and see if I can trigger it again :P
<rsa9000>
core devs do great job and a new board could be introduced with a single DTS
<Habbie>
yep
<Habbie>
that's awesome
<rsa9000>
i was fascinated how is this easy in nowadays in comparition to a time when you should write a bunch of arch kernel code
<Habbie>
device trees are a real win
<Habbie>
another system to learn, of course, but it appears to be worth it :)
Gaspare has joined #openwrt-devel
<SwedeMike>
autodiscovery was invented in the 90ties, I don't get why we have to have these dts files that describe hw
<rsa9000>
with such amount of examples in the repository the DTS learning curve becom almost flat :)
danitool has quit [Read error: Connection reset by peer]
<rsa9000>
but anyway dts is not without downsides
<rsa9000>
it is not someone fault, just sometime looks easier to configure some boards with code instead of static dts
danitool has joined #openwrt-devel
<rsa9000>
SwedeMike: just because PnP was not yet introduced for GPIO controlled LEDs :)
<SwedeMike>
rsa9000: it seems it hasn't been invented for anything running MIPS/ARM or any other arch
<rsa9000>
true
<Habbie>
SwedeMike, but the boot times!
<SwedeMike>
my slowest x86 boxes boot about the same time as my fastest ARM box
<SwedeMike>
x86 box does autodiscovery
<Habbie>
ack
<rsa9000>
lol
<SwedeMike>
it's not like my WRT1200AC boots magically quickly because of DTS :P
<\x>
isnt it like dsdt on acpi
<\x>
on x86 i mean
<rsa9000>
when dts provided by a bootloader, yes
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<stintel>
nbd: bad news, another stall, oom-killer, etc
slingamn has joined #openwrt-devel
Gaspare has quit [Ping timeout: 480 seconds]
<hanetzer>
SwedeMike: well, that's the thing about dts. its not any form of autodiscovery. there is no ability to autodiscover arm hardware (and most stuff)
<Habbie>
hanetzer, and it bafffles many people that that is so :)
<SwedeMike>
hanetzer: exactly, why isn't that a thing?
<hanetzer>
*anything to avoid acpi*
<SwedeMike>
hanetzer: I lived through the 90ties with dip switches, PnP was a "aha!" moment... and now we're here, 2021 with... DTS files.
<hanetzer>
SwedeMike: well, yeah. someone already wrote the 'dts file' for most commercial x86 hw. acpi and friends.
<SwedeMike>
hanetzer: I can boot a generic x86 kernel and it'll just autodiscover everything. With ARM/MIPS etc, I need to have device-specific DTS files
<SwedeMike>
hanetzer: I started doing networking before NAT/PAT was a thing, to me "oh, DTS is so much easier" is equally stupid to "oh, NAT is so much easier"
<hanetzer>
SwedeMike: yeah, because the generic x86 kernel sucks the acpi info out of memory.
<SwedeMike>
hanetzer: yes!
<hanetzer>
SwedeMike: in other words, a 'file' on the flash chip.
<SwedeMike>
why do we need to have lots of images instead of a single generic image?
<stintel>
limited flash size
<hanetzer>
because we have like no storage space
<stintel>
we're talking about embedded
<hanetzer>
and our images are, for the most part, generic. the kernel part, at least.
<hanetzer>
but, why carry a dts file for *every* supported board (this *is* doable), and inflate the size for something we'll get no benefit from?
<Habbie>
i think what SwedeMike means is that Debian also does not carry a 'dts' for every PC out there
<hanetzer>
yeah, because the flash carries it. debian arm *does* carry a dts for every machine (well, not really, but close enough)
<Habbie>
ack
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
<SwedeMike>
I don't see how it's more beneficial to use per-device image file vs generic file that'll read device-specifics at boot-time
<Habbie>
SwedeMike, well, then we get to the practical side - 'from where'
<SwedeMike>
that's up to the manufacturer to fix
<hanetzer>
SwedeMike: you already have that. its called your bios/uefi's acpi tables.
Borromini has joined #openwrt-devel
<hanetzer>
and its per-device.
<SwedeMike>
hanetzer: on typical ARM-devices?
<hanetzer>
no, because typical arm devices get all sorts of hackery done. "I don't wanna use u-boot, I wanna use oreboot!" and all combinations thereof.
<SwedeMike>
this is exactly my point
<hanetzer>
most people just accept that their x86 hardware will always run the firmware it came with, but if you wanted to port it to oreboot/etc, you'd have to write a 'dts file' for it.
<SwedeMike>
I don't see how this is a good thing, or even acceptable.
<hanetzer>
you're right, it is unacceptable to be stuck on the crappy bios/uefi vendors provide.
<hanetzer>
such is life, however.
<SwedeMike>
I like that Linus demanded that the ARM subsystems didn't have per-device trees completely, now I can only hope that they'll come together and create an autodiscovery standard as well... 10 years too late
<hanetzer>
you know what solved that issue? dts files. You do realize that the whole dts/dtb//fdt thing is hella old?
<SwedeMike>
hanetzer: I started using computers in the 80ties. We had dip switches on hw and had to manually enter the values into each application we used. You're somehow claiming this is superior to just having a generic autodiscovery mechanism, like PnP
<SwedeMike>
this is baffling to me
<hanetzer>
it *is* vastly superior to the alternative, and for 'normal' peripherals it is pretty much 'autodiscovery'
<hanetzer>
plug in a usb, pcie, whatever, it works.
<PaulFertser>
ARM servers are supposed to have ACPI now :/
<hanetzer>
PaulFertser: which is a huge failure.
<SwedeMike>
hanetzer: wat?
<hanetzer>
you seriously don't get that *ALL* modern computers have this type of setup, you just don't see it.
nlowe has joined #openwrt-devel
nlowe has quit []
Grommish has quit [Read error: Connection reset by peer]
<mangix>
rsalvaterra: jailbroken iOS devices have apt and typical linux packages
<PaulFertser>
hanetzer: yes, I can't understand why shouldn't ARM vendors just put proper DTB for the bootloader and the kernel to use.
<hanetzer>
PaulFertser: because the bootloader/kernel is frequently rewritten compared to x86 bioses.