<dangole>
rsalvaterra: lgtm. the manual rebase because of commit ff19d70b665d ("net: sfp: ignore disabled SFP node") makes sense.
<rsalvaterra>
dangole: Great, thanks a bunch!
<rsalvaterra>
And now I'm off to bed too. :)
<philipp64>
asterisk question... looking in the canned /etc/asterisk/logger.conf file, I see that "syslog" is commented out... yet /var/log/messages is still filling up with asterisk logging. why? It's already going to /var/log/asterisk/messages which is exactly where I want it.
philipp64 has left #openwrt-devel [#openwrt-devel]
philipp64 has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
philipp64 has joined #openwrt-devel
<philipp64>
had to restart Colloquy so I don't know if this message made it out or not, so I'll ask again...
<philipp64>
The stock /etc/asterisk/logger.conf has "syslog" commented out, so no logging should be going to syslog. But it is anyway. I'm not sure why. Might it be throwing messages to stdout or stderr, and procd is deciding to log them instead? How do I turn this off? By default, asterisk logs to /var/log/asterisk/messages which is just fine by me.
<philipp64>
asked and answered... it was the line "option log_stdout '0'" in /etc/config/asterisk
<philipp64>
Not sure why this is enabled by default.
valku has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
Monkeh has joined #openwrt-devel
<neggles>
arnd: it is interesting that the CN7000 is still listed as a product, and I have heard some rumors that SDK 11 does still have support for MIPS Octeon III (and is kernel 5.4) + marvell have supposedly farmed out support/updates for the MIPS chips to a third party
<neggles>
probably because Amazon still have a *lot* of servers using Octeon III cards, and there are many, many firewall appliances / routers using CN7020s/7040s/etc which are still on the market + supported; keeping Octeon III support is probably a good idea
<neggles>
Octeon II (CN6xxx) can probably be made to work as well - but for older stuff like the ERLite-3, which was... not great even when it was new, well...
mitome has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
valku has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
minimal has quit []
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<wingman2>
so this pull request im working on. https://github.com/openwrt/luci/pull/5672 failed a test because one of the commits generated by github doesnt havr a signed off by line. is this deal breaker? should i edit my git history and clean everything up? or maybe just squash to a single commit and then force push?
<neggles>
wingman2: you should preferably squash everything into one commit
<neggles>
then force-push the branch
<neggles>
so there is only one commit in the PR
<dansan>
I've mostly rewritten https://openwrt.org/docs/techref/sysupgrade to reflect the current behaviour (v21.02) and add a few more intimate details about sources where the bits are implemented and the data / program flow.
<dansan>
Please feel free to review
<wingman2>
neggles: will do
lmore377_ has joined #openwrt-devel
GNUmoon2 has quit [Ping timeout: 480 seconds]
lmore377 has quit [Ping timeout: 480 seconds]
GNUmoon2 has joined #openwrt-devel
<wingman2>
neggles: Should I described the changes in the commit?
<wingman2>
luci-app-zerotier: add a new luci app to manage zerotier vpn
<wingman2>
- regenerated translation template from source
<wingman2>
- normalised translation files
<neggles>
wingman2: i would use 'luci-app-zerotier: add a new luci app to manage zerotier vpn' as your summary (first line of commit) then use the rest of the commit message to detail where it came from and what you did (ie the contents of the other commit messages basically)
<wingman2>
so remove "A simple luci app to manage the networks zerotier joins to."
Larhzu has quit [Remote host closed the connection]
Larhzu has joined #openwrt-devel
gladiac is now known as Guest1486
gladiac has joined #openwrt-devel
valku has quit [Quit: valku]
Guest1486 has quit [Ping timeout: 480 seconds]
nitroshift has joined #openwrt-devel
shibboleth has joined #openwrt-devel
goliath has joined #openwrt-devel
Tapper has joined #openwrt-devel
svanheule_ has quit [Quit: svanheule_]
svanheule has joined #openwrt-devel
srslypascal is now known as Guest1492
srslypascal has joined #openwrt-devel
Guest1492 has quit [Ping timeout: 480 seconds]
cmonroe has joined #openwrt-devel
danitool has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<aparcar>
nbd: would it make sense to have clang-12 as a default requirement? people start using bpf stuff and the CI doesn't like building for hours
<aparcar>
I could also add clang to the CI containers
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
aiyion has quit [Remote host closed the connection]
borek has joined #openwrt-devel
borek has left #openwrt-devel [#openwrt-devel]
<aparcar>
rsalvaterra: if you run make package/linux/refresh, does it touch kernel patches from all targets at one or do you have to switch target multiple times?
<rsalvaterra>
aparcar: It only refreshes the generic and *current* target/subtarget patches.
<aparcar>
excellent thank you
<aparcar>
that's what I thought
<nbd>
aparcar: for people that don't want to build llvm, they can simply grab the precompiled llvm toolchain and extract it into the openwrt dir
<nbd>
aparcar: i'm considering raising the requirement to clang-13 or even dropping support for host clang entirely
<rsalvaterra>
That's why we have the update-kernel script, to cycle through every target and refresh every patch on a kernel version bump. :)
<nbd>
because apparently on some hosts, clang-12 is generating some broken code
<nbd>
haven't fully debugged that yet
aiyion has joined #openwrt-devel
<aparcar>
nbd: all right I'll start using the pre-build stuff within CI testing
<aparcar>
nbd: does clang-13 bring any new features or why the bump?
<aparcar>
rsalvaterra: thanks for the clarification
<rsalvaterra>
Any time. ;)
<aparcar>
rsalvaterra: I thought of adding a CI test to verify that but if it's already done via your script I'll drop that
mattytap has quit [Quit: Leaving]
<rsalvaterra>
Oh, it's nbd's script, not mine. It's in the maintainer tools repo. :)
<nbd>
aparcar: i was hoping that clang-13 doesn't have the same issues that occurred with the clang-12 versions
<rsalvaterra>
Oops! Actually, it's not nbd's, it was written by Jonas Gorski (don't know his handle here).
<stintel>
Kanjimonster iirc
* russell--
is working on a program that wants to detect and act on usb plug/unplug events ... what's the best thing to use for that?
<russell-->
i want to notify a running program, so i realize that i can send a signal to the program, but is there anything better?
<PaulFertser>
If program is OpenWrt specific it can listen to a ubus signal I guess.
<russell-->
is something generating a ubus event?
<aparcar>
nbd: all right thanks, I'll look into downloading the bpf stuff into CI containers
<stintel>
you could send a ubus event from a hotplug script, that's what qosify does apparently
<aparcar>
what the more up to date samba thing called again? kmod-ef or something?
<PaulFertser>
I'm not now sure ubus has signals (like dbus broadcast signals), sorry.
<jow>
PaulFertser: it has
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<rsalvaterra>
OMG. I just received a call on my cell phone. A number from Germany. Some guy with an Indian accent saying that he was from Microsoft and that I had a problem with my Windows…! xD
<rsalvaterra>
I thought this only happened in the US. :P
<stintel>
I hope you trolled the hell out of him
<SwedeMike>
rsalvaterra: they call all countries. They stopped calling me, so now I just get crypto scammers
<nitroshift>
rsalvaterra, o/ it happened to me too, told him i don't use windows
<olmari>
Biggest issue with scamming the scammers is to remember never say "yes" or to that effect...
<olmari>
well.. even in general with scam callers
<rsalvaterra>
stintel: He hung up after a couple of minutes, unfortunately. :)
<olmari>
suddenly you're "proved" to order some k€ stuff, and they have recording of you saying "yes" =)
<rsalvaterra>
olmari: Ouch, that's nasty.
<rsalvaterra>
I think I may have said "yes" at a certain point. :/
<olmari>
Some scammers does such, tho usually they don't try to push such things as this particular example
<stintel>
I wouldn't worry too much, in Europe, as consumer, you are extremely well protected
<olmari>
They often start with something obvious like "is this <the entity just answered phone>"
<rsalvaterra>
Well, they didn't ask me that. Probably they got my number from some huge pile leaked from God knows where.
<olmari>
I once worked in Wärtsilä, globally acting company.. money deciding entities this was normal stuff
<olmari>
they developed habit of answering by (first)name, and if ever asked "is this him/her?" they just re-replied their name, never "yes" =)
<rsalvaterra>
olmari: Wärtsilä? The crazy marine engine manufacturer? :)
<rsalvaterra>
I'd be extremely sad if we had to drop the octeon target because of that leak, really.
<rsalvaterra>
Having a commit to point at will at least give us the possibility of a correct upstream fix.
<stintel>
I haven't looked at that commit in detail, but it touches cvm_oct_free_work which runs cvmx_fpa_free and it's pretty certain the leaks are in fpa as they're not accounted
<stintel>
that gave me the idea if we should track fpa alloc/free in /proc/meminfo
<stintel>
arch_report_meminfo could probably be implemented for that
* rsalvaterra
sometimes wonders if some patches are ever actually *run-tested*…
<f00b4r0>
heh
<neggles>
stintel: i did have the occasional error pop up that was triggered somewhere in this codepath
<stintel>
rsalvaterra: please elaborate - line 79 also returns 0 without free
<rsalvaterra>
I find those return 0 without cvm_oct_free_work(work) very fishy.
<aparcar>
I'm thinking of moving all this CI stuff to an external repo (i.e. ci.git) and let it download such scripts. Less noise in openwrt.git and we can use the same script across repos and CI provides. I know you started the work on gitlab, but are you okay to make it more generic?
<rsalvaterra>
stintel: Oh, missed that one,.
<stintel>
rsalvaterra: and look at the original code too
<stintel>
I *did* look in some detail :P
<ynezz>
aparcar: it's CI agnostic, it works on GitHub as well
<rsalvaterra>
stintel: I know you did. :)
<ynezz>
aparcar: you can take a look at ucode for example
<f00b4r0>
rsalvaterra: the comment seems explicit: if the function returns 0 the packet cannot be dropped?
<aparcar>
ynezz: does it contain the formal stuff to or mostly compiling?
<f00b4r0>
(and so presumably the wq is freed elsewhere)
<ynezz>
aparcar: no formal stuff yet, thinking about adding support for pre-commit as it allows to run the checks on the developer machines as well
<ynezz>
aparcar: it should be somehow configurable so it could be reused in various projects with different check needs
<rsalvaterra>
f00b4r0: Sure, but something's definitely amiss in that patch.
<aparcar>
ynezz: yea ideally. I'll have a look at your scripts again and add a GitHub wrapper + formal stuff
<aparcar>
should we mirror it to GitHub? gitlab.com seems somewhat out of the question for the near future
<ynezz>
aparcar: GH wrapper? in GH world, it should be some GH action probably which could be shared between repos
<ynezz>
since it doesn't allow includes, so one has to copy&paste a lot of things otherwise
<stintel>
+1 to move CI stuff out of main repo, it always bothered me that so many CI solutions don't support anything else
<aparcar>
only gitlab and sourcehut support that afaik
<ynezz>
I assume GH has actions for that purpose
Tapper1 has quit [Ping timeout: 480 seconds]
<ynezz>
anyway, even with GH actions one needs a lot of copy&pasta, in that ucode case it's 7 LOC for GL (because it has remote includes), 48 LOC for GH for same functionality
<neggles>
it's not that hard to support GH actions on other platforms, but also, ynezz GH actions can be called from other actions now, even cross-branch/cross-repo
<ynezz>
it wasn't available last time we've checked
<neggles>
it was switched on for everyone about 3 weeks ago
<stintel>
yeah the other thing that bothered me: why does it always have to be yaml :P
<f00b4r0>
rsalvaterra: I looked at both functions before/after, they're functionally identical, AFAICT. What would be interesting is to look at the disassembly on the target platform. I would hardly be surprised if the compiler generated the same assembly for both. Else, this may give a better clue to the problem
<neggles>
stintel: would you prefer JSON?
<neggles>
:P
<aparcar>
stintel: what's your current yaml alternative?
aiyion has quit [autokilled: This host has violated network policy. Mail support@oftc.net if you feel this is in error. (2022-02-02 11:29:50)]
dangole has quit [autokilled: This host has violated network policy. Mail support@oftc.net if you feel this is in error. (2022-02-02 11:29:50)]
<rsalvaterra>
f00b4r0: Compiler bug… it would be weird, but definitely not unheard of.
<neggles>
YAML's biggest crime is that whitespace encodes meaning, and going to a python-esque markup is *not better* in that respect...
aiyion has joined #openwrt-devel
<f00b4r0>
rsalvaterra: true
<f00b4r0>
which is why looking at disassembly might help :)
<neggles>
rsalvaterra: "works when you compile it with our hacked up SDK version of GCC 7" more like :P
<neggles>
ah crap
<neggles>
i forgot to replace the DTS after switching to stintel's branch
<neggles>
*CTRL-C*
<aparcar>
stintel: I agree with ynezz...
dangole has joined #openwrt-devel
<rsalvaterra>
f00b4r0: And as for the function being more readable with the patch, well… I disagree. I would make it more readable by using goto for the error handling.
<rsalvaterra>
Sprinkling returns in the middle of the function isn't exactly an improvement.
<f00b4r0>
rsalvaterra: I fully agree with you. That patch was uncalled for
<f00b4r0>
*nod*
<neggles>
btw, I do have a 90%-functional driver for the pcie console on the snic10e - it works for stdout, but when attempting to read from stdin i get an IRQ error, probably because I'm not really entirely sure how to write a console driver kernel module
<robimarko>
This is the SDIO version, its 99.99% the same code
<robimarko>
I think that even the version is the same
<jow>
okay, so that's the one. I understood it that way that this is just an older dump someone found somewhere
pmelange has quit [Ping timeout: 480 seconds]
<wingman2>
compile it with -O0 and -g then upload the binaries
<wingman2>
:p
<robimarko>
No, the company that published it keeps it up to date
<robimarko>
I wansnt really planning on upstreaming the support for this crap
<robimarko>
As its really crap
<jow>
imho you do have two choices
<robimarko>
So, its more of a hack for the 21.02 branch to keep the product alive
<jow>
1) do another driver integration backend in Openwrt (mostly userspace work)
<jow>
2) do serious changes to the driver (kernel level work in proprietary codebase)
<jow>
you'll likely find more support for 1)
<robimarko>
Yeah, 1 is the only option
<robimarko>
I already had to patch the USB driver to work at all since Globalscale provided a year older version for USB
<robimarko>
Then the PCIe one
<neggles>
I guess you could argue that the NDA applies to all the other bits and pieces wrapped around the driver / rest of the SDK? but not the actual driver source?
<robimarko>
Since NXP doesnt provide sources, docs or any kind of support for anything that isnt iMX
<neggles>
hey! layerscape ARM!
<jow>
I'd actually be somewhat interested in such an alternative backend
<jow>
it would serve as a blueprint for integrationg other proprietary drivers
robimarko_ has joined #openwrt-devel
<neggles>
LS1026/1046 <3
<neggles>
the _3 chips can come too
<robimarko_>
neggles: The thing is that there isnt anything else other than the driver and their weird module for WEXT
robimarko has quit [Remote host closed the connection]
<robimarko_>
But both are GPLv2
<neggles>
welp
<robimarko_>
But that does leave the USB/PCIe FW
<neggles>
from what i've downloaded from them, you have to click through a half-baked web prompt NDA to download much of anything, i don't think it has much teeth
<robimarko_>
neggles: But the NXP geniouses wont provide the driver sources directly
<robimarko_>
No, non
<robimarko_>
You have to go through the vendor
<robimarko_>
As NXP only supports the iMX line
<robimarko_>
And being that we are using Espressobin Ultras (Not my choice) you have to go through Globalscale
<neggles>
oh no, i mis-clicked and uploaded these sources to github without noticing! what a disaster!
<robimarko_>
Which is just a pain
<neggles>
ugh
<neggles>
i've not dealt with globalscale since the sheevaplug days
<robimarko_>
I cant explain how much I dislike this board
<neggles>
sad to hear they've not gotten any better
<robimarko_>
Its just a POS
<neggles>
(and glad I didn't buy one)
<robimarko_>
The biggest issue are WLAN cards
<robimarko_>
Which are random 88W8997
<robimarko_>
One PCIe and one USB based
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<robimarko_>
And then there is the Armada 3720 1.2GHz which still has broken scaling(As it doesnt work at all)
<neggles>
robimarko_: can't just yeet them out a window and install a nice mediatek?
<robimarko_>
Oh trust me, I tried
<robimarko_>
But nope, they got probably 5k+ of these
<robimarko_>
And they just keep on ordering
* neggles
screams
<robimarko_>
As only Globalscale constantly has stock
<neggles>
that explains the choice of wifi cards for mochabin then
<robimarko_>
So, I keep to have to maintain this shit
<robimarko_>
Yeah, they chose an NXP binary support only card
<robimarko_>
For Kickstarter/Indiegogo
<robimarko_>
Like WTF
<neggles>
welp
<neggles>
i hope they got them at a very steep discount
<robimarko_>
I am sure they paid rock bottom
<robimarko_>
Cause, they are just random unbranded cards
<neggles>
(still better than broadcom)
<robimarko_>
Well, thats not hard to achieve
<neggles>
they set a low bar, yes
<neggles>
are the cards not just the azurewave ones?
<robimarko_>
The PCIe one is
<robimarko_>
But the USB isnt
<robimarko_>
It has no marking at all
<neggles>
what chipset?
<robimarko_>
88W8997
<robimarko_>
Both use the same chipset
<neggles>
interesting
<robimarko_>
But one uses PCIe and one USB from the second PCI slot
<robimarko_>
PCIe one actually worked really good even with miwifiex/mwlwifi
<robimarko_>
But the USB one was constantly crashing
<karlp>
they're nice and small, but a little pricy
<robimarko_>
Nice module
<robimarko_>
Was the broadcom WLAN driver support type dropped?
<robimarko_>
I know it existed as non mac80211
<robimarko_>
Ahh, its part of broadcom-wl
<jow>
robimarko_: yes right, part of brcm-wl
<jow>
it was a little bit brittle and stale at the time it got dropped, I wouldn't be surprised if some fixes are required elsewhere in the machinery
<robimarko_>
Yeah, I am just looking at it for example
<robimarko_>
Which I am trying to avoid doing
<jow>
in any case it likely is a good idea to load the driver with 4 VAPs unconditionally
<jow>
thne have the script limit the number of UCI wifi-ifaces it can process to those 4
<jow>
unless the wifi driver reloading is functioning robustly (without crashes or OOMs) in this you might consider doing rmmod/insmod as needed when the VAP count changes
<robimarko_>
Number of VAP-s will be preset
<robimarko_>
As the USB one is flaky with reloading the FW
<jow>
I see, so "rocket technology"... once started it has to keep running as-is, attempts to change will cause it to explode :P
<robimarko_>
Yeah
<robimarko_>
Cause, though its supposed to work
<robimarko_>
It doesnt
<robimarko_>
So its once it works dont touch it
<jow>
Of course not. Any good appliance reboots itself to apply minor changes
<jow>
that's the fundamental principle of solid engineering
<robimarko_>
At least you can rename the interface without crashing
<jow>
... yet
<robimarko_>
Essentially, if I somehow hacked the mac80211 logic to register a "PHY" per interface it would just work as it is
<jow>
you'd probably need to do a lot of "proxying" behind the scenes then
<robimarko_>
Yeah
<jow>
well above my paygrade, maybe nbd can help with the relavnt mac80211 internals
<robimarko_>
Gotta love how they can break anything
<robimarko_>
Like, why couldnt you just support BSS-ese
<jow>
because it would be straightforward and sane
<robimarko_>
Or if hostapd supported multiple interfaces inside of one config
<robimarko_>
Cause that is easy to achieve
<jow>
but where's the value proposition if any fool can just use standard commands to configure the driver
<jow>
it needs to be something arcane you require proprietary logic and commercial support for. Because only then it is perceived to be enterprise grade
<robimarko_>
The stupid thing is that you can just copy/paste the same hostapd config into another file and change the interface name to attach to
<robimarko_>
And just pass both to hostapd and then it works
<robimarko_>
But that breaks the whole generation logic since hostapd requires separate config files per interface
<jow>
which multiple interfaces do you mean multiple BSSes or multiple phys?
<robimarko_>
Technically it ends up being PHY-s
<robimarko_>
Cause you use interface=
<jow>
hmm, so it boild down whether hostapd transfers the bss parameters as ... well ... bss or as phy config to the driver
<jow>
*boils
<robimarko_>
I think it tries to use BSS
<robimarko_>
And the driver will just reject that
<robimarko_>
Cause hostapd to fail dynamically creating the interface
<robimarko_>
The stupid driver preregisters interfaces like this:
<robimarko_>
And it will generate config by default for only one interface per PHY
<robimarko_>
But if you try to add the second one in UCI it will spit that out as a BSS which the driver rejects
xes__ has joined #openwrt-devel
<jow>
hmm, you could try something
xes has joined #openwrt-devel
<jow>
in the uci define 4 radios
rua has quit [Ping timeout: 480 seconds]
<jow>
instead of letting them match on option sysfs, try "option phy phy0" one two and "option phy phy1" on the other two
<PaulFertser>
robimarko_: you should be able to specify multiple hostapd config files to a single hostapd instance.
<robimarko_>
jow: good idea
<robimarko_>
PaulFertser
rua has joined #openwrt-devel
<jow>
then create 4 vaps and let them refer to four different radio-device sections each
<robimarko_>
Yeah, you can pass it multiple config files
<robimarko_>
But you cant have multiple interfaces per config file
<jow>
it'll likely fail because something somewhere in the stack will ensure that phy's are unique but try anyway
<jow>
maybe it can be achieved with a simple local patch
<PaulFertser>
I was commenting on "Or if hostapd supported multiple interfaces inside of one config" and I know OpenWrt currently doesn't allow to run single hostapd with multiple configs.
<PaulFertser>
But probably it would be nice to change, and that would provide rudimentary band streering support out of the box for all the OpenOCD users.
xes_ has quit [Ping timeout: 480 seconds]
<jow>
maybe it would even work without any patching if you register a new handler "mac80211_pseudophy" or something that simply sources the existing mac80211 shell logic but overrides they phy lookup routines
xes_ has joined #openwrt-devel
<jow>
you could then use "config wifi-device; option type mac80211_pseudophy; option phy usb-uap0" and the overridden logic will take care of resolving it
<jow>
with a bit of luck that can be achieved by simply placing additional files in the firmware
xes__ has quit [Ping timeout: 480 seconds]
xes has quit [Ping timeout: 480 seconds]
<robimarko_>
jow: yeah, if I register 2 radios with the same PHY NR then it just silently faisl
<robimarko_>
Not fails, but it will then just use the last radio
<robimarko_>
And broadcast the wifi iface under it
<robimarko_>
Gotta dig a bit to see whether the mac80211 phy logic can be patched
<rsalvaterra>
stintel: How's the RAM usage? Has the leak been plugged? :)
<Slimey>
heh
rsalvaterra has quit [Quit: rsalvaterra]
rsalvaterra has joined #openwrt-devel
<hurricos>
neggles: woah! I am having to actively stop myself from digging out the snic10e I brought with me to work.
<hurricos>
neggles: MX67 is LS1043 but has secure-boot enabled =_=
<hurricos>
and the combination of FPGA socketed SOIC16 + bootloader soldered SOIC16 from the FCC designs -> FPGA soldered SOIC8 + NAND for bootloader
<hurricos>
I have a dump of the FPGA's 16MB SOIC8 flash if anyone's interested, but it's gibberish to me.
<hurricos>
no `strings` and I have no idea where I'd start trying to decompile FPGA firmware
<Slimey>
you can find interesting strings in flash dumps, huh :P
<hurricos>
not if it's just an FPGA booting from the,.
<hurricos>
apparently
<Slimey>
oh then that blows
<hurricos>
sorry, it's 4MiB
<hurricos>
no way so far to interrupt the boot process on the MX67 in order to start chipping away and checking the e-fuses on the LS1043
<Slimey>
i can has rom?
<hurricos>
although fwiw there's no bootloader protection, the bootrom doesn't check what it boots, so the only thing you get out of putting your cert in the LS1043 is a secure boot verified gold star (yay)
<hurricos>
it occurs to me that one way into the board would be to
<hurricos>
.... use some sort of DMA attack from the FPGA
<hurricos>
whose bootrom can be chip clipped
<hurricos>
:coughs: but that's way too much work to get some silly layerscape board working when there are others out there
<Slimey>
heh microsemi we used to use a bunch of their poe injectors
<hurricos>
they're decent injectors as far as I'm aware
<Slimey>
what about interrupting the bootloader at a critical point at the flash
<Slimey>
say the power to chip was cut
<stintel>
rsalvaterra: I saw some memory usage increase but not near as much as before.. after work I will try booting 2 SNICs, 1 with the revert and 1 without
<hurricos>
Slimey: I'm guessing as soon as the bootrom hands over to U-boot, you're done for
<Slimey>
try stopping it before that :P
<hurricos>
So we need an LS1043 datasheet to find which capacitors need to be broken off to translate to a different boot mode
<Slimey>
it's not my favorite thing to do but i've had to do it a few times on some of these waps, for whatever reason i couldnt stop the boot process
<hurricos>
at which point the whole "porting OpenWrt" thing just plain dies
<wingman2>
Hey would someone be able to run the tests on my pull request? I kinda want to see if the Test Formalities test passes before i go to bed. https://github.com/openwrt/luci/pull/5668
<Habbie>
wingman2, i don't follow, it clearly failed, two days ago
<Habbie>
Commit subject line MUST start with '<package name>: ' (Translated using Weblate (Swedish))
<Habbie>
: Signed-off-by is missing or doesn't match author (should be 'Signed-off-by: Hosted Weblate <hosted@weblate.org>')
<hurricos>
you're using &hwinfo on L246 to point at that partition at L76 which is labeled
<hurricos>
in your case you'd probably end up with a partition labeled SENAO, but you'd have e.g. senao: partition@14ff0000 { ... label = "SENAO"; ... }
<hurricos>
the parent node of senao in this case must be a `partition {` which is `compatible = "fixed-partitions";`
dangole has quit [Remote host closed the connection]
<stintel>
so even if the code is supposed to be the same, it doesn't look like it behaves like that
Tapper has joined #openwrt-devel
<hurricos>
stintel: is that weird spike reproduceable?
<hurricos>
(on sr1)
<hurricos>
also, grafana? do you have a good workflow for establishing panes, or do you do the pointy clicky thing :^)
<hurricos>
I hate having to manually throw them together and I'm not a huge fan of how nasty and undiffable the JSON schema version of the Grafana panels is
<hurricos>
but I don't know any best-practices
<stintel>
pointy clicky in this case
<stintel>
sr0 is running with that single commit reverted, sr1 just openwrt 5.10
<stintel>
the spikes on sr1 is on iperf
<stintel>
I did iperf2 over sr0 and iperf3 over sr1, then reversed to make sure it's not due t o different behaviour of the tool
Borromini has quit [Quit: Lost terminal]
<stintel>
created an init script to boot OpenWrt initramfs on both SNIC10's in this box, and poked OpenWrt to mount mtdblock1 as overlay
<hurricos>
n e a t :D
* hurricos
puts on independent hardware consultant hat
<hurricos>
:bows politely: of course I'm glad to have given you the idea, that'll be five billion dollars please
<stintel>
man I looked at those mikrotik rb5009 again ... I was pretty close to ordering 2 + rackmount kit :P
<hurricos>
you really want that redundancy, don't you?
<hurricos>
wait, what's in the rb5009?
<stintel>
the PoE-PD interface is the 2.5 one, so could do an active/passive bond with 2.5+10 to my switch
<stintel>
but if I manage to get those to work I'll be retiring my M300s :P
<hurricos>
$219 O_O
<hurricos>
there has to be a drawback here ...
<hurricos>
oh found it. Marvell
<stintel>
:D
robimarko has joined #openwrt-devel
<robimarko>
On RB5009 the drawback is MikroTik
<hurricos>
call me when Cisco starts deploying LS1046 + sparx5 in their 100GbE ASA devices and then forgets to remove socketed flash from their board design
<robimarko>
At least if you want OpenWrt
<hurricos>
aiiich, yeah. I mean, I bought a bunch of sxt sq's for $50 apiece and I can't be happier but
<hurricos>
flashing them is really, 'head to desk' material
<robimarko>
Yeah, its nice HW for the price
<robimarko>
But getting a new platform supported is a pain
<hurricos>
yeah :(
<robimarko>
And on RB5009 they conviently/intentionally broke UART in RouterBoot
<hurricos>
T_T
<robimarko>
We managed to binary patch that after a while
<hurricos>
wait, SparX-5 can't even do 100G
<robimarko>
I think its 25G
<hurricos>
Yep.
<hurricos>
not that there's literally anything on the market using it right now.
<robimarko>
Yeah, we really want to use it for switches
<robimarko>
But nobody is making any HW
<robimarko>
And even the reference board is backordered
<hurricos>
you get cheap BCM43640 for that >1Gbps 11ac under brcmfmac, but it's broadcom. You get amazing 15W switch chips like the 98DX series, but you need CPSS
<robimarko>
Yeah, AC3X
<robimarko>
Nope
<robimarko>
AC3
<robimarko>
AC3X and AC5X have switchedv
<robimarko>
And we are using those
<robimarko>
But those have also skyrocketed in prrice
<hurricos>
robimarko: Oh, what's the application?
<robimarko>
Edge switching
<hurricos>
fwiw I have heard and seen good things about ONL support for older switches
<hurricos>
but it's older switches
<hurricos>
it's lab applications for a nerd who isn't carrying >10TB/hour
<hurricos>
it's funny, the situation we're in. The entire elevator car going up to "DSA support" has been packed with crabs by volunteers like svanheule (and we thank you for it)
<robimarko>
Ughh
<robimarko>
ONL
<robimarko>
These are techincally DENT
<robimarko>
But we dont run that on them
<robimarko>
We have our own Gentoo based distro and builder
robimarko has quit [Quit: Page closed]
<hurricos>
someone who knows about DENT o_o
minimal has quit []
robimarko has joined #openwrt-devel
<robimarko>
Well we are members
<robimarko>
And so I have to attend the TSC calls
<hurricos>
robimarko: I just went and looked into your website. Wow
<hurricos>
your company's, anyhow. Interesting stuff!
<robimarko>
Website is meh, its outdated
<hurricos>
I was mostly caught by the UCI2 blog article ;)
<neggles>
it’s not going to be a carbon copy, of course - and, is it “demand GPL dump from Meraki” time?
philipp64 has quit [Quit: philipp64]
<mangix>
rsalvaterra: reminds me of what gregkh said. Something like "We break userspace all the time and hope people don't notice"
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<hurricos>
neggles: Yeah. So why does the MX67C have a SOIC16?
<neggles>
hurricos: just to clarify: yours doesn’t? Only the one 8-pin SPI flash?
<neggles>
your -W I mean
<hurricos>
It does not! Just the 8-pin SPI flash.
<hurricos>
I checked both sides. It doesn't even have the white silkscreen clip pattern on the board
<hurricos>
in the center of which the SOIC16 would have been placed
FLD has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<rsalvaterra>
mangix: That's different. Sometimes there are interfaces which are deprecated and eventually removed, but the time scale for that usually extends for *decades*.