guifipedro_ has quit [Read error: Connection reset by peer]
KGB-0 has quit []
KGB-0 has joined #openwrt-devel
valku has joined #openwrt-devel
<neggles>
aw robimarko is away/asleep
<neggles>
i have acquired cambium XV3-8
<neggles>
and *holy balls this thing is fast*
<slh>
the NSS offloading is capable, but a nightmare from a long term maintenance point of view (and without NSS, it's not that fast anymore)
<slh>
(o.k., wireless itself is /less/ dependant on NSS offloading than routing, but still, the OEM firmware handles rather significant parts of the IRQ handling and more in the NSS cores)
<neggles>
slh: you can actually disable nss offloading in the oem firmware
<slh>
heh, that's interesting - first time I see that in an OEM firmware (admittedly, consumer gear has a different target audience)
<dwfreed>
nbg6817 doesn't do that simply because its A/B is in the eMMC flash instead
<dwfreed>
but I do have roughly half that quantity of partitions
<slh>
the nbg6817 has full a/b flashing (oem and openwrt), I just haven't found a way to failover to the other partition set in case of problems so far (without serial console access or reflashing the primary partition set via push-button tftp)
<slh>
and at least on the ax3600, the failover is handled via a kernel patch (oem-only so far)
<dwfreed>
slh: yeah, there's no auto failover back to the opposite partition afaik
<slh>
it 'should' be there, somehow - otherwise, why bother with the a/b flashing complexity in the first place
<dwfreed>
right
<slh>
but who said vendors need to be rational
<dwfreed>
lemme take a second look at env and see if there's anything
<neggles>
oh yeah i know it's normal
<dwfreed>
but I don't think there is
<neggles>
the unifi cloud key gen2 has 48 partitions on its emmc
<dwfreed>
neggles: christ that's excessive
<slh>
there isn't in uboot-env
<dwfreed>
neggles: even chromeos used to only have like 27
<neggles>
it's running an APQ8053, which is an android SoC
<neggles>
2/3 of the partitions are blank
<slh>
(I've written the nbg6817 a/b flashing support for OpenWrt)
<neggles>
(and <8MiB)
cmonroe has joined #openwrt-devel
<slh>
there are also some ZyXEL/ zloader specific u-boot commands for the nbg6817, those (modelled after hayes AT commands) are rather opaque
<slh>
including some to reflash/ repartition the eMMC from the (spi-nor based) bootloader
<slh>
it would have been interesting to dive more into those topics, but... I needed my router and didn't want to do more open heart surgery than necessary
<dwfreed>
slh: I have to imagine there's *something* in the a/b decider in uboot
<slh>
there should be, yes
<dwfreed>
as the decider itself is not in env, it's in uboot itself
<slh>
the deciders is a flag partition on the spi-nor flash
<slh>
mtd11: 00010000 00010000 "0:DUAL_FLAG"
<slh>
first byte of it either being 0x01 or 0xff
<dwfreed>
I mean the code that reads that partition and acts on it
<dwfreed>
there is nothing in env that decides whether to execute bootcmd or bootcmd_1
<slh>
I also contemplated crafting a very minimal initramfs rescue environment fitting into the reserved space of the spi-nor, but 2162688 bytes would be very limited
<dwfreed>
I mean, a full-featured busybox should fit in 2M
<dwfreed>
if you wanted to go crazy, you could repartition the eMMC for it
<slh>
I have the GPL tarball, if you're interested - it's rather difficult to get it from ZyXEL
<neggles>
dwfreed: they probably either hooked a lil binary into preinit
<dwfreed>
that's what I plan to do eventually anyway; I could totally throw in a rescue C env (though I don't have serial access)
<neggles>
or used an api app
<neggles>
slash bootmenu app
<dwfreed>
slh: yeah, would be neat to dig through
<neggles>
if you have a flash dump i can tell you which hook method they used (in case it's been hidden in the gpl dump)
<neggles>
they're probably not that devious though
<dwfreed>
I mean I can get one; spi-nor is fully readable
<slh>
dwfreed: would you mind a short /query? my webspace can't host the tarball for longer periods (nor take hundreds of downloads)
<dwfreed>
12 partitions on the spi-nor, including the reserved partition
<dwfreed>
slh: by all means
<neggles>
I can mirror it on a box with a 20G uplink if you like
<dwfreed>
nice
<neggles>
ive got all of hurricos's torrents running on there :P
<dwfreed>
slh: can you confirm md5sum of 6df6f4bd0ad32a984201eac9a18359e8
<dwfreed>
just to make sure I don't have a corrupted file
<slh>
dwfreed: yes
<dwfreed>
perfect
<dwfreed>
4 copies of uboot
<slh>
NBG6817_100ABCS7C0/package/uboot-ipq806x/ should be the one
<dwfreed>
that's just the packaging; there's 4 full copies of source in the tarball
<neggles>
dwfreed: sounds like it's one tarball for many devices :P
<dwfreed>
okay, looks like the packaging uses the qca/src/u-boot-ilq-3.0 source for 6817
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<dwfreed>
slh: the dualflag partition must be handled by zloader
<dwfreed>
there is nothing in the uboot sources about it
<slh>
yeah
<dwfreed>
and zloader is blackbox
rsalvaterra_ has joined #openwrt-devel
rsalvaterra_ is now known as rsalvaterra
<dwfreed>
the more I think about this, the more I should make sure I have working serial before trying to resize my emmc partitions
<neggles>
dwfreed: if you wanna upload an mtd dump somewhere and send me link (/query is fine if you like) i can throw it into ghidra and see what zloader is up to
<neggles>
back in several hours though :P
<dwfreed>
there's nothing sensitive in mtd, fortunately
<dwfreed>
I'll dump the uboot partition, sec
<dwfreed>
zloader is after uboot in the same partition
<slh>
only binaries, but there is ./NBG6817_100ABCS7C0/target/linux/ipq806x/nbg6817/boot_images/
<dwfreed>
and after a slight adjustment, those files match what's on my mtd0-7
<dwfreed>
sbl2 is nor_sbl2_sr_disable.mbn not nor_sbl2.mbn, but that's it
cmonroe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
srslypascal is now known as Guest3413
srslypascal has joined #openwrt-devel
csrf1 has joined #openwrt-devel
Guest3413 has quit [Ping timeout: 480 seconds]
csrf has quit [Ping timeout: 480 seconds]
valku has quit [Remote host closed the connection]
<Grommish>
rsalvaterra: ping
csrf1 has quit [Ping timeout: 480 seconds]
ekathva has joined #openwrt-devel
cbeznea has joined #openwrt-devel
ecloud_ has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
rmilecki has joined #openwrt-devel
<mrkiko>
ynezz: hauke: would you please pick up e3f9af4fb6e4ba8bf54cb4240f318ad32260a6fa so that it can be present in 22.x stable releases?
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
ecloud_ has joined #openwrt-devel
guidosarducci_ has joined #openwrt-devel
guidosarducci has quit [Ping timeout: 480 seconds]
<rmilecki>
mrkiko: wasn't that picked yesterday? https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=3a974b5bcd77a55f544448f63e27654cf9734cd6
<f00b4r0>
without it bridge-vlan is unusable on mt7915/21
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<rmilecki>
nbd: ^^ is that OK to backport? [PATCH] mt76: fix encap offload ethernet type check
borek has joined #openwrt-devel
<f00b4r0>
rmilecki: for context, i had asked nbd before sending this patch, I didn't submit the same for 22.03 as I assumed back then that the whole mt76 package would eventually be updated there, and the fix is already upstream.
<f00b4r0>
:) (i was looking to quote my logs, too slow :)
<rmilecki>
thanks, I'll pick it later if noone does
<f00b4r0>
thanks!
Tapper has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<f00b4r0>
hmm, so despite the device having markings that say "LAN0" and "LAN1" for each of its ports, the DTS for the TP-Link CPE210 (a wallmount AP with 2 ports) defines LAN0 as wan. *sigh*
<neggles>
f00b4r0: yeah openwrt seems to default to "first interface is WAN, any remaining are LAN" for devices with >1 ethernet port
<neggles>
which is, intensely frustrating
<neggles>
not quite as frustrating as defaulting to 192.168.1.1 with DHCP/IPv6 ND+PD enabled for LAN on single-ethernet AP devices mind you
<neggles>
should *really* be DHCP client with PD/etc disabled for a single-port device, that's the industry standard + what people expect, and doesn't lead to a freshly-flashed AP stealing DNS resolution duties (via ipv6 ND) despite not actually having any upstream connectivity...
bluew has quit [Quit: Leaving]
<f00b4r0>
neggles: it's also completely unnecessary. It's perfectly valid to have all interfaces in LAN
<neggles>
it's a hangover from when the overwhelming majority of supported devices were 1xWAN + 4xLAN routers
srslypascal has quit [Ping timeout: 480 seconds]
<f00b4r0>
*nod*
<neggles>
and for devices like that it makes sense, i.e. ones which are intended for use as a gateway
<neggles>
but IMO there should be a way to flag a device as 'Not A Gateway'
<neggles>
the defaults make it horrifically impractical to deploy a prebuilt image on any single-ethernet/AP-type device, since you can't factory reset without losing access
<f00b4r0>
well you can, but it needs a bit more work (custom files)
<neggles>
so i end up having to imagebuilder or SDK-build an image with a defconf script to wipe networking and set up 'bridge all ports, DHCP client on native vlan'
<neggles>
yeah exactly
<f00b4r0>
but in any case, on a device that labels both ports as "LANx", I think it's completely wrong to arbitrarily assign one to wan. Maybe I should send a patch :P
<neggles>
last time I looked it seemed like it was policy that anything with multiple ethernets gets either the WAN-marked port, or the lowest-numbered port, configured as WAN
<neggles>
just changing the assignment doesn't really fix the problem - you still end up with 192.168.1.1 / DHCP enabled / IPv6 PD enabled, so either you're making custom defconfig anyway, or you've gotta deal with that every reset
srslypascal has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
robimarko has quit [Ping timeout: 480 seconds]
<f00b4r0>
ok I'm going to ignore walterav1984 on gh. They apparently can't take no for an answer :P
<jow>
PR discussions quickly escalating on GitHub? Shocking! ;)
<f00b4r0>
;)
<f00b4r0>
that's one of the reasons why I normally go through the m-l. I already regret making an exception ;)
<jow>
"my personal problem is of the utmost priority to me, I demand that you urgently look into it! And you're a moron btw for providing such a shitty software free of charge!"
<f00b4r0>
lol
<f00b4r0>
pretty much yeah
<jow>
didn't even know what you referred to, just guessed
<f00b4r0>
typical GH pattern I guess :)
* enyc
meeps
<robimarko_>
Hehe, I would be shocked if people like those dissapeared from PR-s
<enyc>
Wondering what separate trello-board/ idea-pages / etc are used ?
<jow>
we have that secret jira where we discuss which bugs to introduce next to increase the annoyance for the userbase
<f00b4r0>
rofl
<enyc>
What jira !?!?!?!?
* enyc
Shakes jow side-to-side with repeated high-bandwidth bit-shifts !!!!!
valku has joined #openwrt-devel
<robimarko_>
f00b4r0: The dude is persistent I must say
<robimarko_>
And I love when they "give advice" while requesting something
<f00b4r0>
annoyingly so. Making noise for no valid reason.
<f00b4r0>
yeah.
ekathva has quit [Remote host closed the connection]
minimal has joined #openwrt-devel
csrf1 has joined #openwrt-devel
* enyc
meeps
Piraty has quit [Quit: --]
Piraty has joined #openwrt-devel
danitool has joined #openwrt-devel
<hurricos>
I'm really not a fan of unproductive board support PRs. It's a waste of everyone's time ....
<hurricos>
on the other hand I've had a few run-ins where I was trying to contribute garbage. I honestly wonder how frequently people are just misguided and how frequently they're just not ever going to be good contributors
csharper2005 has joined #openwrt-devel
<csharper2005>
hi guys! I'm going to send OpenWrt-related patch series to Linux. To whom should a cover letter be sent? To all maintainers of all files referenced in the patches?
<mrkiko>
eheh, if robimarko_ wasn't patient with me the other day, the situation would have been more difficult. That said, sometimes it happens that - if you don't try to fix something or get it better, no one will do it for you
<ynezz>
csharper2005: but have it added as sendemail.linux.tocmd, so with linux identity, so I can do `git send-email --identity linux *.patch` and it will do all the wonders
<f00b4r0>
i typically avoid cross-posting to lkml when there's a separate subsystem list
<f00b4r0>
iirc there is/was a patch to get_maintainer.pl to make that behavior the default
<ynezz>
so what it's not merged?
<ynezz>
s/what/why/
<f00b4r0>
i haven't followed tbh
<f00b4r0>
imho there really is no point in CC'ing the lkml for every possible patch. It severely degrades the SNR ratio there
<mrkiko>
nick[m]1234: hi!!
<nick[m]1234>
sihi
<nick[m]1234>
hi
<csharper2005>
ynezz: Thanks! I have хх patches. Should I send cover letter [PATCH 0/xx] to all maintainers from patch 1 + ... + all maintainers of patch xx?
<f00b4r0>
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html says " linux-kernel@vger.kernel.org functions as a list of last resort, but the volume on that list has caused a number of developers to tune it out. Look in the MAINTAINERS file for a subsystem-specific list; your patch will probably get more attention there."
* f00b4r0
notes the wording on latest is slightly different. v4.17 is what google gave me as first link :)
robimarko_ has quit [Remote host closed the connection]
robimarko_ has joined #openwrt-devel
<rmilecki>
f00b4r0: upstream use for "label" DT propert is that it should match what is printed on device
<rmilecki>
f00b4r0: please feel free to correct CPE210 DT
<f00b4r0>
incidentally in PR#9451 I've been having the exact same argument with the submitter, and it seems the "overwhelming" majority of (imo incorrect) lan/wan setup confuses people into thinking it's the de facto standard
<rmilecki>
understandable
<rmilecki>
make things right
<rmilecki>
and people will follow too :)
<f00b4r0>
to do it right I gotta have to check all of these devices *sigh* ;P
<f00b4r0>
i'll try to get around doing that. For the devices where there's no doubt, I'll submit a patch to m-l. I'll CC you, for good measure :)
<rmilecki>
cool :)
Tapper has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
<csharper2005>
ynezz: Your config drops "commit_signers" from the recipient lists. Is it ok? :)
Tapper has joined #openwrt-devel
<neggles>
f00b4r0: ugh that guy is the worst
<neggles>
i have a hAP AC Lite I could test with latest routeros but like
<neggles>
nobody's actually putting rOS v7 on them, the flash is too small and they don't have enough ram
<f00b4r0>
neggles: just ignore him. He's making noise.
<neggles>
oh i am ignoring him
<neggles>
"but what if people have problems with newer routerboot!!!" if mikrotik have actually updated routerboot on the hAP AC L meaningfully in the last 4 years i will eat my hat
<f00b4r0>
:P
<neggles>
i've just realized
<robimarko_>
I think they gave up on MIPS long time ago
<neggles>
that's why they went to the whole "routerboot version number equals routeros version number" thing, isn't it
<neggles>
to make it harder to tell when they actually *did* update it, and therefore harder to change out the OS
<f00b4r0>
honestly I care increasingly less about these devices. Mikrotik is going out of their way to make it a PITA to install OpenWRT, fine, nobody's forced to buy their stuff.
<robimarko_>
YAFFS FTW
<f00b4r0>
I'm keeping my devices working, the rest, I'm afraid I cba.
<f00b4r0>
robimarko_: *sigh* :P
<neggles>
the YAFFS shit is just so
<neggles>
*why*
<robimarko_>
And not the same old YAFFS2, a new custom version
<neggles>
why are you making more work for yourselves guys???
<neggles>
this is a solved problem! ubifs!
<f00b4r0>
neggles: NIH syndrome.
<robimarko_>
Stupid thing is that they moved to UBIFS on IPQ40xx NAND devices
<neggles>
and for that matter why are you still writing your own goddamn bootloader?!
<neggles>
you have limited resources! spend them on things that matter! implement netinstall as a u-boot app!
<robimarko_>
Well, that would make it too easy for installing open SW
<robimarko_>
I mean, we are talking about company that intentionally disables UART
<f00b4r0>
^
<robimarko_>
And on RB5009 you can toggle the bit in hard_config
<robimarko_>
And ROS will think that UART is enabled
<robimarko_>
But nope, RouterBoot function for putc/getc quite literaly just exits
<neggles>
doesn't it do the thing where you can plug in a usb uart and get access though?
<robimarko_>
Supposedly, but thats not really practical
<neggles>
ive been meaning to get one of their woobm-usb esp8266 sticks and rip the firmware off
<neggles>
just cause it's got a nice web terminal heh
<robimarko_>
Well, they actually have the FW for that downloadable on the product page
<robimarko_>
At this point they are just being d*cks then
<neggles>
it's just the application package bit, not the freertos underneath
<neggles>
i found references to someone having dumped the spi flash on a couple forums but nobody ever posted the file
<neggles>
on a site that's still up anyway
<neggles>
also, iperf3 from the XV3-8, single TCP stream, sending to a server on the far side from a 2x2 client: [ 5] 0.00-10.00 sec 1.08 GBytes 927 Mbits/sec
<robimarko_>
Perfect for Youtube
<neggles>
if i run to the AP itself it'll hit 1.08, need to plug this into a multigig port
<neggles>
...and find a 3x3 or 4x4 wifi 6 client...
<robimarko_>
BTW, you know of a small switch like CSS610 with a 2.5G port?
<neggles>
a couple yeah, depends on how much you wanna spend
<f00b4r0>
Zyxel has one iirc
<robimarko_>
Well, not too much as I use it for development
<robimarko_>
And beyond switching it doesnt do anything
<neggles>
sophos have an 8x2.5G + 4x10G which is a strataDNX and they'll have one of their beautiful GPL dumps for soon
<neggles>
not stratadnx sorry
<neggles>
marvell. it's marvell.
<robimarko_>
Thats overkill for me
<f00b4r0>
XGS1010-12
<f00b4r0>
unmanaged. XGS1210-12 for the managed one
<neggles>
these are pretty cheap, unmanaged, 8x2.5G but no PoE
<f00b4r0>
robimarko_: they tend to be that, and also reasonable price/value deal.
<neggles>
the zyxel is a better choice if you can get 'em
<neggles>
nobody in australia seems to stock their stuff :(
<robimarko_>
I am gonna need to spend some money
<f00b4r0>
:)
<robimarko_>
Cause, if I am getting a new switch then time to get a 802.3at one
<robimarko_>
Cause, this Mikrotiks fake "passive" PoE shit aint gonna cut it anymore
<f00b4r0>
oh yeah, that abomination
<robimarko_>
And its a good excuse to finally pull fiber from my networking cabinet down to desk
rua has quit [Ping timeout: 480 seconds]
<olmari>
I so hate anything "passive poe" :)
<olmari>
I tell because you didn't ask
<f00b4r0>
don't we all
* neggles
doesn't
<f00b4r0>
;)
<olmari>
well... suprisingly here and there used (by end users)
<olmari>
I mean each and anyone can do whatever they want obviously.. still abomination =)
<neggles>
it has its place
<neggles>
namely in devices where adding a proper PD controller etc. would double the price of the thing
<robimarko_>
Nah
<neggles>
i just look at it as 'integrated poe splitter'
<robimarko_>
4 port 802.3at TI IC is like under 5 EUR
<f00b4r0>
when you power from PoE switch and end up having to buy a separate PD->passive spliiter, it doesn't add up.
<neggles>
no i mean on the device side not the PSE side
<olmari>
I'd rather have then separate ejector than passive poe... but that's me
<robimarko_>
Well, client side PoE IC-s are even cheaper
<neggles>
yeah but they take up board space, and the transformer/power conversion
<robimarko_>
Though it means they have to to 48+V instead of whatever 24V crap they are pulling
<neggles>
f00b4r0: i mean, a 48V passive poe device works just fine hanging off a proper 802.3af PSE
<olmari>
chinesium surveillancecam mfg's have noted this long time ago
<f00b4r0>
the ic is cheap. The trafo usually slightly less so
<neggles>
but yeah most passive poe is 24v
<neggles>
cambium's old-style 28V passive poe can fuck off though
<f00b4r0>
but then again, a lot of implementations don't even bother with galvanic isolation :P
<neggles>
it's reverse from the 'standard' polarity
rua has joined #openwrt-devel
<neggles>
cambium 28V injectors blow up mikrotiks and ubiquiti airmax gear
<robimarko_>
Well, cause geniouses were skimping on a bridge rectifier
<f00b4r0>
neggles: none of my PSE are going to deliver 48V to a passive device that doesn't signal itself correctly
<olmari>
also problem with many too exact voltage passive poe is that it is indeed too exact
<olmari>
(damn what pandoras box I opened)
<neggles>
fortunately they quit using the 28V an amount of time ago, all their current stuff that supports it also supports 802.3af
<neggles>
f00b4r0: all that's required for a PSE to supply power is the classification resistance
<robimarko_>
Yeah
<f00b4r0>
which they typically don't implement
<robimarko_>
And worse case it will get identified as legacy/custom and still get 48V
<neggles>
i have not come across a mikrotik or ubiquiti passive poe device with 48V input capability that doesn't work with an 802.3af switch
<neggles>
only the 24V stuff
<robimarko_>
Thats cause they got burned on the "passive" 24V stuff
<robimarko_>
With the blowback as people fried their gear
<robimarko_>
Cause, they tended to be a bit vague with the type of PoE being advertised
<neggles>
i've also not fried anything other than by feeding 28V to something that has a 25V max input rating
<neggles>
there was that whole fiasco with the UAP-AC-Lite
<neggles>
but ubiquiti replaced those *shrug*
<robimarko_>
Yeah, thats what I am talking about
<robimarko_>
Cause, they forgot to mention it was not 802.3af/at
<neggles>
well except it *was*
<neggles>
but only on one pair of pairs
<neggles>
those only died because they tried to support both options
<robimarko_>
Thats the definition of not being per standard
<neggles>
and elected to put the 24V on the same pairs that cisco typically use for 802.3af
<neggles>
and they quit doing it
<neggles>
only first production run had the support, and they replaced all of them under wty 🤷
<f00b4r0>
well PD don't get to choose which pair carries power in 802.3af/at
<neggles>
yeah i am aware lol
<neggles>
but that wasn't passive 24 poe's fault, that was ubiquiti being dumbasses
<f00b4r0>
more like shaving a few cents off the bom ;)
<robimarko_>
Passive PoE-s fault is lack of standardization
<neggles>
no their goal was to support both their unifi 802.3af switches and their edgemax 24v switches with the same device
<robimarko_>
And then you get fun stuff like pair swapping per vendors
<f00b4r0>
well 802.3af/at makes passive poe completely irrelevant tbh
<neggles>
so you could hang a lite off the passthru port on an airmax radio
<f00b4r0>
*it* is the standardization
<olmari>
maybe because no one wants to standardize exactly that
<neggles>
(the AC-Lites were garbage anyway...)
<neggles>
24v passive poe *is* practically standardized, mikrotik and ubiquiti and cambium devices that use it all use the same setup, apart from cambium's 'special' choice of voltages etc. for their own injectors
<neggles>
which is a holdover from when they were canopy
<olmari>
de facto doesn't still make it standard... and I still don't get it why some OEMs want to push it that much
<olmari>
makes no effing sense :)
<neggles>
don't get me wrong, it's bad and given the choice always go for 802.3af
<neggles>
but
<f00b4r0>
because it's cheap ;P
<robimarko_>
Cause, you can do it with a couple of resistors
<f00b4r0>
^
<neggles>
the choice is usually not between passive poe and 802.3af
<neggles>
it's between passive poe and no poe
<neggles>
and i'll take passive in that case
<robimarko_>
Well, that is cause its free for them
<robimarko_>
Just use multipackage transistors for on/off and boom
<f00b4r0>
neggles: what makes absolutely no sense to me is that the cheapest and /smalles/ mikrotik device, namely the mAPlite, takes af/at/passive
<f00b4r0>
clearly, they can do that at this price point and this form factor, they can do it everywhere.
<neggles>
(it's actually purely passive it just has the classification resistance)
<robimarko_>
Well, they claim af/at on most of their stuff
<robimarko_>
But there is no logic
<f00b4r0>
ah
<robimarko_>
Its just the resistor for classification
<neggles>
but that's *totally fine*
<f00b4r0>
sweet
<robimarko_>
So not 802.3af/at per standard
<f00b4r0>
well at least it works on either set of pairs
<neggles>
all you need is the resistor and the bridge rectifier and it's compliant with 802.3af - bare minimum compliance
<neggles>
but it's enough
<robimarko_>
But they are usually smart enough to use a bridge rectifier
<robimarko_>
And thats fine for me
<neggles>
you don't get power class reporting, but that's not mandatory and plenty of cisco/hpe/etc gear doesn't support it
<neggles>
older stuff sure but
<f00b4r0>
then again, why not using that on all their devices. why sticking to stupid 24V
<neggles>
because 24V buck converter cheaper and smaller than 48V
<neggles>
and easier to certify
<robimarko_>
Cause, you then can save on a bridge rectifier and transformers
<f00b4r0>
robimarko_: again, device size and pricepoint
<f00b4r0>
it's the smallest/cheapest
<neggles>
they're still using poe magnetics and a bridge rectifier on the 24v stuff
<robimarko_>
I know
<robimarko_>
It makes no sense
<neggles>
f00b4r0: it is also very low current
<neggles>
er s/current/power
<f00b4r0>
robimarko_: there. Exactly my thoughts. They make no sense :)
<robimarko_>
On those you can get away with non PoE magnetics actually
<neggles>
it's got poe magnetics
<neggles>
i have mine open in front of me right now :)
<robimarko_>
Cause, we are talking ridiculously small currents
<neggles>
well not poe magnetics per se but ones with the center taps broken out
<robimarko_>
Yeah
<robimarko_>
But their segmenting sometimes makes no sense
<robimarko_>
They tend to cut something interesting from each product
<robimarko_>
No matter the price
<neggles>
yeah like refusing to put a microsd slot on the ccr2004-pcie
<neggles>
jackasses
<neggles>
has now been delayed until *september*, too
<robimarko_>
We are talking about geniouses which used I2C-GPIO on RB5009
<robimarko_>
And the thing has 2 HW I2C controllers that arent used
<neggles>
pinmux i guess?
<neggles>
or just easier routing
<robimarko_>
Well, thats the thing
<f00b4r0>
reminds me we still don't have the mAP supported in ath79
<f00b4r0>
I'll have to fix that
<robimarko_>
Like half of the pins can be used for I2C
<f00b4r0>
cause I have one :)
<robimarko_>
Its quite literaly 2 pins
<neggles>
f00b4r0: i was going to do that one cause i have one too
<f00b4r0>
lol
<neggles>
but eth0 on mine
<f00b4r0>
be my guest
<neggles>
is fucked
<f00b4r0>
ah
<neggles>
link comes up and packets flow for 2 seconds
<neggles>
then *freeze*
<robimarko_>
BTW, does UART work in ath79 on mAP?
<robimarko_>
Cause, it never did on mine when I tried
jlsalvador has quit [Ping timeout: 480 seconds]
<f00b4r0>
robimarko_: I'm lazy, I never bother with uart :)
<neggles>
dunno, uart works on mine
<neggles>
i haven't openwrt'd it
<neggles>
idk why eth0 would work for 2s then freeze the whole system
<f00b4r0>
in fact apart from the very mikrotik device I supported back in ar71xx days, I never bothered *opening* any of the ones I implemented afterwards
<neggles>
it shows link up but nothing flows and it screws with traffic on the switch it's plugged into
<f00b4r0>
thanks to (very convenient) tftp-boot reset-button procedure
<robimarko_>
I wont touch anything that doesnt have UART
<neggles>
maybe it's spamming pause frames?
<f00b4r0>
very first*
<neggles>
robimarko_: it has a functional 3.3v uart
<robimarko_>
I know
<robimarko_>
I am just saying its broken on mine
<neggles>
odd
<neggles>
mmio address mapping maybe?
<robimarko_>
No idea, it never worked
<f00b4r0>
i also have an sxtsq2 lite, but that one presumably works with the LHG2 image
<robimarko_>
Not even on ar71xx AFAIk
<f00b4r0>
so I'm going to be lazy there
<neggles>
my mAP Lite is one of the first batch ones
<neggles>
where if you use the magnets to stick it to something
<neggles>
mikrotik's production solution: ferrite sticky pad under pcb
<neggles>
it's quite useful when i'm at the datacenter, plug it into a mgmt vlan port with a 6" patch cable
<neggles>
but even the mAP-L is kneecapped, the mAP-2n/2nD has its usb-otg port wired up for data
<neggles>
the -L doesn't for no reason
<f00b4r0>
true. But for my use case, it never bothered me
<neggles>
it would be nice if it worked, put openwrt on it, usb gadget ethernet+serial
<neggles>
behold, universal "get access to the thing"
<neggles>
plug in OTG to UART/cisco console cable for serial via ttyd, switch to device mode with gadget for stuff that's expecting a usb uart adapter for console, ethernet-to-wifi and wifi-to-ethernet-or-usb... *so close, yet so far*
* neggles
has come to the conclusion that he's going to have to build this himself
<robimarko_>
f00b4r0: BTW, what are we gonna do about the Mikrotik BDF-s?
<robimarko_>
Upstream aint respnding
<neggles>
implement the loader in packages.git ? :P
<robimarko_>
No need for that, all that we require is for the driver to request BDF-s with a unique name per radio
<robimarko_>
And thats all that my patch does, brings that in line with caldata
jlsalvador has joined #openwrt-devel
<neggles>
right, so include the device path or dt node name or something in the first file it looks for
<robimarko_>
Yeah, it uses the same format as caldata
<robimarko_>
Basically, the DT node name
<robimarko_>
Cause, currently with API1 it just looks for board.bin
<neggles>
ath_k-caldata, ath_k-boarddata
<robimarko_>
There has been a PR open for months now
<neggles>
yeah there was a reason it couldn't just be nvmem wasn't there
<robimarko_>
Yeah, cause Mikrotik stores it like caldata
<robimarko_>
LZO-RLE compressed
<robimarko_>
And we have a platform driver that exposes the decompressed data via sysfs like caldata
<neggles>
ah yeah right
<neggles>
which is pretty much the way upstream says to do it
<neggles>
i remember now (heck i commented on the PR)
<f00b4r0>
robimarko_: I really wish openwrt would carry it regardless. It doesn't hurt. Maybe ping someone here about it? ISTR hauke wasn't hostile
<robimarko_>
Me as well
<f00b4r0>
robimarko_: meanwhile I would suggest resubmitting, to kale/linux-wireless. Omit lkml, less interference maybe?
<robimarko_>
I dont think anybody got involved except for chunkeey
<f00b4r0>
just rebase and resubmit. Mention it hasn't been going anywhere and this is needed. Of course having this in OpenWRT would add clout by showing it works here
<neggles>
it's a really tiny patch
<robimarko_>
Just sent a ping
<robimarko_>
If that doesnt work, will resend
<robimarko_>
Ahh
<robimarko_>
QCA and their codeaurora
<robimarko_>
Now they changed the emails
<neggles>
this upstream patch is literally just 'check for device-specific named file and load it if present, if not then check for generic one' right?
<robimarko_>
Yes
<robimarko_>
If it fails, it just uses the current path
<neggles>
why is this a big deal??? the drivers already do this for caldata???
<neggles>
???????
<robimarko_>
No idea
<robimarko_>
Cause, caldata is being requested with this naming
<f00b4r0>
robimarko_: let's see. Meanwhile I'm not sure what to do with john's minor erase patch. I rebased it and reworked to make it smaller and more efficient, but he seems AWOL
<robimarko_>
Yeah, he goes AWOL for a while then pops back
<robimarko_>
I mean, if it works and he doesnt reply
<robimarko_>
Just send it yourself
<neggles>
sorting out packing and unpacking bdfs is what's kept me from getting the yealink wf56 working on things that aren't yealink phones
<f00b4r0>
I might end up doing that. It's annoying that a half-assed version was already committed without even his consent/review in 8441a62. My first order of business is to revert that
<neggles>
i have the BDF files from their firmware but I cannot work out how to get it into the format ath10k is expecting
<robimarko_>
Thats super easy
<neggles>
ah wf50 not 56
<robimarko_>
You just wrap them using the ath10k-bdencoder
<neggles>
i worked that bit out
<neggles>
but the instructions are not clear on how to unpack/repack - it was a while ago that i last tried tbh
<robimarko_>
There is nothign to unpack
<robimarko_>
QSDK uses raw BDF-s
<robimarko_>
So you just need to wrap them so that variant matching can be done using DT property
<mrkiko>
How stable is considered to be ath10k on ipq4019 hw ? And on QCA9888v2 ?
<robimarko_>
Stable in what sense?
<mrkiko>
robimarko_: for me stable means - it doesn't crash the host system; and maybe work correctly or restart in case of failure without intervention
<robimarko_>
That really depends
<robimarko_>
For some it works great, for some not so
<robimarko_>
For me it works good
<robimarko_>
I have a VR2600v
<robimarko_>
Running for months without a reboot
<mrkiko>
robimarko_: thanks. Very stable here as well. On what does instability depend on your opinion?
<mrkiko>
I mean - apart from hardware ... ok. But wondering if different BDF files can impact on this
<neggles>
robimarko_: hmm maybe i dumped the files wrong, ath10k-bdencoder won't read them :/
mattytap has quit [Read error: Connection reset by peer]
<mrkiko>
neggles: you have the raw files from the QSDK and need to re-pack them?
mattytap has joined #openwrt-devel
<robimarko_>
I dont really know, it seems that clients used also impact things
<robimarko_>
neggles: You wrap the file, there is nothing for bdencoder to read
<neggles>
it should dump info though shouldn't it?
<robimarko_>
Unpack one of the exiting BDF-s in OpenWrt
<robimarko_>
No
<neggles>
oh.
<neggles>
well then.
<robimarko_>
It can only print info its already wrapped
<robimarko_>
So, you just need the board-2.json properly populated
<mrkiko>
robimarko_: what is contained in a BDF file actually?
<robimarko_>
Well, everything imaginable when it comes to configuring the radios
<neggles>
I ripped the firmware, board.bin, and board-2.bin out of a firmware update for the voip phones this is meant to work with
<neggles>
(theres stuff in here for pci ones on the phones with integrated wifi)
<neggles>
then got confused when the board.bin was not parseable
<neggles>
d'oh
srslypascal has quit [Ping timeout: 480 seconds]
csharper2005 has quit [Remote host closed the connection]
<neggles>
hmm
<neggles>
https://paste.neggles.dev/VamVf i think my problem is qca9377 usb support not really being a thing yet actually heh
mattytap_ has joined #openwrt-devel
mattytap has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
goliath has joined #openwrt-devel
<csrf1>
I'm looking at some dts files to use as examples. it seems that many (all?) of them have a section called "m25p80@0" which I'm assuming refers to the physical flash chip
<csrf1>
they all seem to refer to the same 'm25p80' chip even if they have a totally different brand/model of flash & flash size
<dwfreed>
99% sure it's just a label
<csrf1>
was this just done by convention, due to ppl copy-pasting an existing dts file to use as a template?
Tapper has joined #openwrt-devel
<csrf1>
dwfreed, so it can be called anything?
<dwfreed>
yeah, it's only used as a reference, so as long as it's internally consistent, what you call it doesn't matter
<dwfreed>
it's probably a convention just so people don't have to remember differences between devices
<csrf1>
cool
<csrf1>
if I'm going to be setting up a custom flash layout for an upgraded (larger-sized) flash chip, and if there's an existing 'radio'/'factory' config partition somewhere on the oem chip, I'm guessing I'll need to copy that raw partition onto my new, custom flash image, and then point my bootloader (kernel?) at that partition, correct?
<dwfreed>
you may need to put that partition in the exact same spot
<dwfreed>
radio firmware may not necessarily ask the device tree where the partition is
lynxis has joined #openwrt-devel
csrf1 has quit [Read error: Connection reset by peer]
csrf1 has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest3463
srslypascal has joined #openwrt-devel
csrf1 has quit [Read error: Connection reset by peer]
csrf1 has joined #openwrt-devel
srslypascal is now known as Guest3464
srslypascal has joined #openwrt-devel
Guest3463 has quit [Ping timeout: 480 seconds]
<csrf1>
dwfreed, by 'exact same spot', do u mean the exact same memory address, or just the same partition location relative to the other mtd partitions?
<dwfreed>
same memory address
<csrf1>
ughh
Borromini has quit [Quit: leaving]
<dwfreed>
mtd partitions aren't real
srslypascal is now known as Guest3465
srslypascal has joined #openwrt-devel
<csrf1>
is there anyway to figure out if this is the case?
<dwfreed>
move it and see if the radio still works
<csrf1>
this is for the MT7628 btw
<csrf1>
ok, i guess I can do that
srslypascal is now known as Guest3466
srslypascal has joined #openwrt-devel
Guest3464 has quit [Ping timeout: 480 seconds]
Guest3465 has quit [Ping timeout: 480 seconds]
borek has quit [Ping timeout: 480 seconds]
<robimarko_>
neggles: ath10k USB never really got finished
<robimarko_>
Though, you can try adding the ID to the supported list
mattytap_ has quit [Quit: Leaving]
<robimarko_>
csrf1: m25p80 in the nodes is a copy/paste leftover from a time when the driver for JEDEC SPI-NOR chips was called m25p80
<robimarko_>
Since that was the first chip it supported
<f00b4r0>
neggles: when you say "eth0 doesn't work" on your map2nd, do you mean that it's got no networking at all?
srslypascal is now known as Guest3467
srslypascal has joined #openwrt-devel
<f00b4r0>
because afaict in ar71xx, there is only eth0+switch
<csrf1>
robimarko_, ok, figured it might be something like that
<csrf1>
just wanted to make sure, thanx
Guest3466 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest3468
srslypascal has joined #openwrt-devel
Guest3467 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest3469
srslypascal has joined #openwrt-devel
<f00b4r0>
out of curiosity, what's the policy on LED namings when naming can "conflict" (look like) a linux interface name?
<f00b4r0>
specifically, this device has two LEDs with markings "ETH1" and "ETH2", but AIUI caps are frowned upon, so they would be "eth1" and "eth2"
<f00b4r0>
svanheule: interesting. Cross-flash possible then? :)
srslypascal is now known as Guest3470
srslypascal has joined #openwrt-devel
Guest3468 has quit [Ping timeout: 480 seconds]
<svanheule>
f00b4r0: probably. Not sure how much further that user went with that device.
Guest3469 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest3471
srslypascal has joined #openwrt-devel
<svanheule>
f00b4r0: reading the thread again, an OpenWrt build for XGS1210-12 worked on the 1010, so running stock 1210 FW should also be possible, I assume
<f00b4r0>
zorun: still willing to test hap-acl? Reading the old ar71xx code I see we addressed the SSR at 25MHz there, but my PR is set to 10. I'm curious if the faster setting would work, would you mind checking?
<f00b4r0>
more accurately: I don't see why the faster setting wouldn't work, but testing again requires going offline and not ideal for me now :)
rua has quit [Ping timeout: 480 seconds]
<mrkiko>
what happened to the PR for the FRITZ!BOX 7490 / 7491 and friends?
goliath has quit [Quit: SIGSEGV]
rua has joined #openwrt-devel
bkallus has quit [Remote host closed the connection]
shibboleth has joined #openwrt-devel
<f00b4r0>
zorun: don't bother. I just tested on the mAP which I'm currently preparing support for (same SSR), it works. I'll update the PR
Tapper has joined #openwrt-devel
goliath has joined #openwrt-devel
<f00b4r0>
grr I can never wrap my head around switch bypass options in DTS
robimarko_ has quit [Quit: Leaving]
rua has quit [Ping timeout: 480 seconds]
cbeznea has quit [Quit: Leaving.]
<f00b4r0>
can someone enlighten me about the difference between switch-phy-swap and switch-phy-addr-swap?
rua has joined #openwrt-devel
<slh>
mrkiko: given that the hardware is 'special', it needs someone very persistent (but at the same time not a perfectionist, as it's effectively impossible to build one single image with wireless support; you'll need two, lantiq soc, ath79 wireless) to push for it
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<f00b4r0>
neggles: map-2nd support done :) I'll git-email tomorrow
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
Tapper has quit [Ping timeout: 480 seconds]
bluew has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Tapper has joined #openwrt-devel
cmonroe has joined #openwrt-devel
cmonroe has quit [Read error: Connection reset by peer]