<Mangix> meaning it should go in prereq-build.mk
<Ansuel> should we add them to prereq
<Ansuel> yep....
<Ansuel> but i assume also bsd-compat-headers if we are in macos?
<Mangix> don't remember
<Mangix> should try without
<Mangix> bsd-compat-headers are specific to musl
<Mangix> note that OpenWrt's toolchain/musl includes them
<Ansuel> so we may require them ?
<Ansuel> and yep elfutils broken... god damn
<Mangix> well, for base OpenWrt they might be optional. But for certain host packages like libtirpc, they are needed
<Mangix> so, probably need a check in prereq-build.mk for them as well.
<Ansuel> any idea how to check if they are installed?
<Mangix> yeah
<Mangix> gcc -include sys/queue.h -x -c
<Mangix> that's one of them
<Mangix> the most important one actually
<Mangix> oh it's the only one toolchain/musl includes
<Ansuel> even better
<Ansuel> also lets add some comments just to give some context about it
<Mangix> this docker thing is quite convenient
<Mangix> better than my nspawn containers
<Ansuel> now i'm really curious if there is a way to fix elfutils...
<Mangix> Ansuel: you're in for some pain unfortunately
<Ansuel> oh no...
<Mangix> the first obstack error is easy to fix. The second libintl.h error is not
<Ansuel> btw wth we install all the manual for libressl...
<Mangix> ?
<Ansuel> just junk files in the host tool staging dir
<Mangix> oh
<Mangix> also as far as gettext is concerned, the selinux crap is also affected
goliath has quit [Quit: SIGSEGV]
<Mangix> adding musl-libintl to apk add is not enough to fix. they use custom makefiles with no proper checks for libc gettext or external
<Mangix> elfutils uses garbage automake stuff that can't deal with it either.
<dangole> anyone knows how to find the cause of cpu freeze? i'm trying to port ethernet driver for mt7981 soc and one of the two CPU cores just dies when eth0 is being brought up (eth1 works fine).
<Ansuel> sounds like a dead lock ?
<Ansuel> does it print cpu stall after a while?
<Ansuel> if it's a lock there are some debug config to bisect locking problem AFAIK
<Ansuel> configure: error: failed to find argp_parse LOVE IT
<Ansuel> this should be the easy problem to fix right?
<hauke> Ansuel: argp_parse is not supported by musl
<hauke> use argp-standalone
<hauke> dangole: activating all the lock debugging from the kernel is a good idea
<dangole> Ansuel: i also suspected locking first, and spend days verifying locking, using lock proving debug options, ...
<Mangix> oh yeah there's that too
<hauke> dangole: it could be that the system busg hangs
<hauke> *bus
<Ansuel> hauke if that's the case it's a PITA to debug
<Mangix> I blame stintel for these issues :)
<hauke> dangole: do you have jtag?
<dangole> hauke: no, the board may have jtag on test points, but i didn't wire it up yet
<dangole> hauke: but kgdb/kdb works fine over serial
<hauke> dangole: could you compare the clock and reset settings with a working driver
<hauke> with a working system
<dangole> hauke: thing is just that it won't help because when entering says "KGDB: Timed out waiting for secondary CPUs." and then what ever is happening on that CPU is invisible
<hauke> maybe you forgot to activate some clock and then something acceses this IP core and the system hangs
<dangole> hauke: yes, i suspect something like that
<Ansuel> it's probably that or the opposite
<Ansuel> aka some clock are disabled and the system goes crazy
<dangole> hauke: strange enough is that eth1 works fine, only eth0 has this problem
<dangole> hauke, Ansuel: ie. if i want to boot the system "normally" without any hangs i just deliberately break phylink in DTS for eth0 so it won't come up...
<Ansuel> eth1 is secondary and eth0 share some clock with the core or the entire system?
<Ansuel> just putting some idea on the table
<Ansuel> or a reset is doing something fancy?
<Ansuel> also worth to mention the problem may be in a clock driver and probing the eth driver just triggers it by enabling the clock?
<Ansuel> configure: error: failed to find fts_close OHHH FFS -.-
<Mangix> Ansuel: LOL. alpine has a musl-fts package
<hauke> dangole: If you have the vendor FW running too, please do a rgister dump of the clock and reset controller and compare it to your system
<dangole> hauke: i got working stock firmware, to have /dev/mem i will have to build mtk sdk from source, but it's doable.... was hoping to get around that...
<Ansuel> i'm compiling elfutils directly in docker build... extra lazy....
<Ansuel> musl-fts didn't fix the fts_close error
<Mangix> yes, because you need to add -lfts :P
<Ansuel> checking for library containing argp_parse... -largp
<Ansuel> checking for library containing fts_close... no
<Ansuel> FUN
<Mangix> oh that's surprising
<hauke> dangole: do you have the Gl int devices?
<Ansuel> Mangix it's not detected I guess
<Mangix> Ansuel: I think you should give up on Alpine honestly
<dangole> hauke: yes, it's mt3000 board, gl-inet provided a free sample some month ago, just didn't have much time to play with it earlier...
<hauke> nice, I just read about it
<hauke> does it really need the fan?
<dangole> hauke: i only got the bare board, also looks like an early pre-production version, has v0.1 printed on it...
<Mangix> Ansuel: wonder how easy it is to set up nix
<dangole> hauke: none of the ICs get hot at all, all below 40degC at ~ 19degC room temperature
<Ansuel> do you think we would have less problem with nix? ahahah
<Mangix> yes
<Mangix> nix uses glibc
<dangole> hauke: funny coincident :)
minimal has quit [Quit: Leaving]
<aiyion> hauke: brume2 (GL-MT2500A)
<Mangix> Ansuel: some fallout from your Wno-error commit: https://downloads.openwrt.org/snapshots/faillogs/arc_archs/packages/
<aiyion> dangole: Do you share your progress somewhere? I'd like to see whether my device freezes as well.
<Ansuel> Mangix this is from packages feeds right?
<Mangix> yep
<Mangix> glibc specifically
<Ansuel> well we were aware that some package would brake the priority was to have core packages working and fix everything on the feeds
<Mangix> OTOH it's only 5 packages. not too bad.
<Ansuel> btw the elfutils thing is incredible the web is full of report about not working with musl
<Ansuel> people provide patch and still here we are with no support
<Mangix> wouldn't doubt it
<Ansuel> problem is that report are from 2018
<dangole> aiyion: i have wip kernel tree here: https://github.com/dangowrt/linux/tree/wip
<Ansuel> and each link is dead
<Mangix> GNU people don't care about non-GNU
<Ansuel> there is this fun thing
<Ansuel> the fun thig is why autoconfig doesn't find the fts lib lol?
<aiyion> dangole: your tree adds mt7986 dts files, what do you use them for?
<dangole> aiyion: i'm also working on completing upstream support for mt7986...
<dangole> aiyion: most of that and also work on fitblk, ubi probing from dts, ... is of course not strictly needed for mt7981
<Mangix> package name is musl-fts-dev apparently
<[Pokey]> Good evening, is anyone able to point me to an example devices device tree with a working SD card in SPI mode please?
<Ansuel> should i care to also include musl-libintl ?
<Ansuel> 55 | #include <libintl.h>
<Ansuel> guess i got my answer ....
<Ansuel> oh wow it did actually compiled with no patch
<Ansuel> o.o
<Ansuel> well at least for ath79 every required tool got built
<Ansuel> also why we build findutils and we also have GNU find in prereq?
<Ansuel> something worth to investigate if find is used in the right place
Ansuel has quit [Ping timeout: 480 seconds]
<slh> I wouldn't be surprised if find might be an issue on MacOS or BSD
Ansuel has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
<stintel> ¯\_(ツ)_/¯
dangole has quit [Ping timeout: 480 seconds]
danitool has quit [Remote host closed the connection]
gch981213 has joined #openwrt-devel
valku has quit [Remote host closed the connection]
<rmilecki> hauke: thanks for refreshing patches after my changes...
<rmilecki> i was told to use GitHub to check my commits for that, i tried that but it didn't work: https://github.com/rmilecki/openwrt/actions
<rmilecki> Matrix: Check Kernel patches jobs failed with:
<rmilecki> Error response from daemon: manifest unknown
<rmilecki> Error: Docker pull failed with exit code 1
<rmilecki> anyone with idea why?
<jayk> ruh roh
goliath has joined #openwrt-devel
Tapper has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
cbeznea has joined #openwrt-devel
goliath has joined #openwrt-devel
<Znevna> is there a script that cleans just old stuff from the build_dir ?
<oliv3r[m]> rm -rf :D
<Znevna> :P
<Znevna> obviously
gch981214 has joined #openwrt-devel
gch981213 has quit [Ping timeout: 480 seconds]
hexagonwin has quit [Quit: [ Quitting client ]]
gch981214 has quit [Ping timeout: 480 seconds]
cbeznea has quit [Quit: Leaving.]
robimarko has joined #openwrt-devel
Ryncewynd has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
cbeznea has joined #openwrt-devel
<f00b4r0> ynezz: care to review my reply to Brian? I think you opened a can of worms here ;)
<robimarko> Like you pointed out, individually changing busybox options wont work
bbezak4 has quit []
bbezak has joined #openwrt-devel
<f00b4r0> robimarko: that's my understanding but the fact that ynezz (who knows a thing or two about our build infra) suggested differently made me doubt myself, tbh
<ynezz> you're correct f00b4r0, I was wrong, I'll reply to that mail later, thanks for catching this
<f00b4r0> ynezz: np, thanks for confirming. I think the AWK solution is the simplest. This doesn't even need to be packaged, it can be dropped in the subtarget files.
<ynezz> if its reliable, then yes
<ynezz> other option might be ubox/base64decode which would use bas64_decode from libubox/base64.c
<f00b4r0> awk is certainly reliable, and base64 is nothing complicated: if Brian can confirms that it works for him I think we should be golden :)
<ynezz> perhaps ucode could work as well
borek has joined #openwrt-devel
<f00b4r0> ynezz: btw since you're here, I'm still hoping that you can test buildbot monomaster ;)
* f00b4r0 runs
<ynezz> there is a progress, I've the ansible part prepared, need to deploy it and run test it
<f00b4r0> ah ha! excellent ;)
<f00b4r0> ynezz: fwiw I should be able to bring my machines back online no latter than Jan 22. At which point I should also be able to setup more machines.
goliath has quit [Quit: SIGSEGV]
goliath has joined #openwrt-devel
borek has quit [Quit: borek]
<hauke> rmilecki: for my gcc update I run tests on all targets also with testing kernel and saw these problems
<robimarko> f00b4r0: Have you used the check for initramfs in syuspgrade recently?
<f00b4r0> robimarko: nope. Is it broken again? ;P
<robimarko> Looks like it
<f00b4r0> *sigh*
<Znevna> x.x
<robimarko> I was adding ubiformat for Xiaomi devices on ipq807x to make sure its clean
<robimarko> And its happily running even when not initramfs
<robimarko> [ "$(rootfs_type)" = "tmpfs" ] && xiaomi_initramfs_prepare
<robimarko> That should work AFAIK
<robimarko> Interesting thing is that rootfs_type is empty
vicencb has joined #openwrt-devel
<robimarko> Well, its not empty
<f00b4r0> well that's what we had in older releases
<robimarko> But its always set to tmpfs
<f00b4r0> (empty rootfs)
borek has joined #openwrt-devel
<robimarko> upgrade: rootfs_type: tmpfs
<robimarko> My print was broken before
<robimarko> What is setting it?
<robimarko> I assume fstools
<robimarko> Oh, base-files
<f00b4r0> it'd be great if there was a definitive recipe to detect initramfs run
<robimarko> Well, this gets interesting
<robimarko> On running OpenWrt the base-files recipe of: /bin/mount | awk '($3 ~ /^\/$/) && ($5 !~ /rootfs/) { print $5 }'
<robimarko> Returns overlay
<robimarko> But the thing is that by the time platform_do_upgrade is invoked
<robimarko> We are already running from tmpfs
vicencb has left #openwrt-devel [#openwrt-devel]
<f00b4r0> neat
danitool has joined #openwrt-devel
<robimarko> No idea how are MTik devices working with a similar check
<f00b4r0> robimarko: technically it's not causing any particular harm tho? Only slowing down the process
<robimarko> f00b4r0: Actually its breaking sysupgrade
<f00b4r0> they're probably getting fully erased at every sysupgrade and we're none the wiser
<f00b4r0> is it?
<f00b4r0> how so
<robimarko> We are merging the rootfs on Xiaomi devices
<robimarko> As otherwise rootfs is crazy small on a 256 NAND
<robimarko> And their dual FW relies on the kernel itself to switch the rootfs thats used
<robimarko> So, currently we are relying on UBI attach failing on the new rootfs partition
<robimarko> That will trigger a ubiformat on it before anything else
<robimarko> However, I got pointed out that is a bit flimsy, so I wanted to run ubiformat on the kernel and rootfs
<robimarko> Whenever we are running from initramfs to make sure they are clean
<f00b4r0> ha, you were a bit greedy ;)
<robimarko> I mean, the fact that ubiformat on kernel fails doesnt make sysupgrade fail
<f00b4r0> if sysupgrade switches to tmpfs before do_upgrade runs, I'm not sure how we're supposed to distinguish initramfs from regular sysupgrade :(
<robimarko> But its damn wastefull to ubiformat 90% of the NAND every sysupgrade
<f00b4r0> yeah
<robimarko> I have no idea as well, cause it clearly switches to ramdisk first and only then platform_do_upgrade runs
<f00b4r0> although unless I'm mistaken, for areas that weren't written to, it's a NOOP
<robimarko> Actually no
<robimarko> ubiformat should wipe it clean
<f00b4r0> i don't know how ubifs works tbh. On SPI NOR it doesn't hurt since once the bits are set, they're set until written to. So there's no "wear", only wasted time.
<robimarko> Can we do something like add a /etc/image-type
<robimarko> And just store regular or sysupgrade
<robimarko> And then that can be copied to ramfs before sysupgrade
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
dangole has joined #openwrt-devel
Ansuel has joined #openwrt-devel
<Znevna> <dangole> Znevna: it's the other way around: all devices with switch ICs (or SoC-integrated switches like MT7621) are capable of bridge offloading. [...]
<Znevna> no, I was talking about the two exceptions from that commit
<Znevna> [ 0.420004] OF: /ethernet@1e100000/mac@0: could not get #nvmem-cell-cells for /nand@1e003000/partitions/partition@1e0000/macaddr@4
<Znevna> ok, this is new
<Znevna> x.x
<Ansuel> Mangix ping?
romany00 has joined #openwrt-devel
romany0 has quit [Remote host closed the connection]
romany00 is now known as romany0
<dangole> Znevna: the two exceptions are for devices which do not have ANY software-controlled LEDs other than the switch-port ones. in this case it is more important to have any indication (ie. blink at boot, fast blink at failsafe, sysupgrade, ...)
<Znevna> so it's just bad wording?
tom- has quit [Quit: upgrading weechat]
tom- has joined #openwrt-devel
<\x> robimarko: https://www.youtube.com/watch?v=4gQfdbuJZes think thats ipq957x? the 22000 meme robotic one
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
<\x> robimarko: https://www.youtube.com/watch?v=4gQfdbuJZes think thats ipq957x? the 22000 meme robotic one
<Ansuel> that thing is so stupid
<\x> yeaah
<\x> shouldve done this with those ASUS spider routers where it crawls under your bed, yeah man, router moves closer to the client bruh
<\x> none of that roomba shit, spider router is what the future will be
<robimarko> Pretty much everything BE should be IPQ957x for now
<robimarko> But yeah, the design as ugly AF
<\x> robotic wifi bro
<damex> mrnuke: i see that you did openwrt flashing on your switch. your bootloader version seem to be different from mine. i have had them on 2022 bootloader timestamp. maybe something did change? i am not sure that it is good idea to try updating on my last 3.20 switch without being able to revert back
<damex> i tested on previous switch and it didn't came back up with logs posted on openwrt forums.
borek has quit [Quit: borek]
borek has joined #openwrt-devel
<Ansuel> Mangix btw https://github.com/openwrt/openwrt/pull/11743 when you have time
<Ansuel> tested with the docker build file and works correctly with detecting missing header
<[Pokey]> I know this is a little bit generic and not too specific to OpenWRT right now, but when adding an SDHCI section to a device tree, how do you generally work out all of the options like reg and interrupts? I'm looking at datasheets and just... not having a good time, plus I'm getting sdhci@20060000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 2) warnings and generally not getting far with my basicaly
<[Pokey]> nonexistent experience
gch981213 has joined #openwrt-devel
gch981213 has quit []
gch981213 has joined #openwrt-devel
gch981213 has quit []
minimal has joined #openwrt-devel
gch981213 has joined #openwrt-devel
<gch981213> [Pokey]: According to that message you need to put 4 numbers in the reg property: 2 for address and 2 for size.
<robimarko> [Pokey]: Whats the platform?=
<[Pokey]> gch981213: I see
<[Pokey]> robimarko: A new one, BL808 from Bouffalo, RISC-V
<Znevna> so what can cause this? https://paste.debian.net/plainh/68f1da2b
<robimarko> If you have the full datasheet than its easy
<Znevna> I'm sure I haven't seen this with older builds
<robimarko> Even easier if has upstream driver with proper bindings
<[Pokey]> page 558 of RM
<[Pokey]> This thing has very minimal linux support, it is brand new and the upstream stuff hasn't even been accepted into kernel yet
<[Pokey]> Currently using a patched kernel
<[Pokey]> the hope is we can get basic peripherals working, and then get a buildroot working and then I hope OpenWRT can start working after a few more peripherals are working
<[Pokey]> Theres really not many people working on this as far as I'm aware. The manufacturer is focusing on their baremetal SDK
<gch981213> [Pokey]: It doesn't say where the SDHC is mapped to in the memory map section...
<[Pokey]> gch981213: Indeed. We're guessing, based on their SDK, 20060000
<gch981213> For 64 bit systems the memory address and size needs to be 64-bit while a number in the reg property is 32-bit, so it needs two numbers: <addr_high addr_low size_high size_low>
<[Pokey]> ahh
<gch981213> [Pokey]: e.g. A 0x1000 area starting from 0x11230000 is described as: reg = <0 0x11230000 0 0x1000>;
<[Pokey]> Right!
<jow> Ansuel: did you have a test to test the proposed iwinfo fdt compatible change?
<[Pokey]> Me and the others have something to try now, I'll report back, thanks
<jow> Ansuel: I lack suitable hw atm (could probably mock it, tough)
valku has joined #openwrt-devel
<Ansuel> jow was just about to test
<Ansuel> on a ipq4019 board
<Ansuel> actually now that i think about it I can totally test it on a ipq8074 board
<aiyion> dangole showed me a development branch for the linux kernel yesterday, I read through the most recent commits, but am unsure how one does build some sort of bleeding edge OpenWrt. Is there a better way, than backporting all relevant commits to 5.15 and apply them as patches?
<Ansuel> well using an external kernel tree is a way
<Ansuel> but you will have to manually patch it
<dangole> aiyion: use CONFIG_EXTERNAL_KERNEL_TREE and all you need is usually just very few openwrt-specific things on top of linux-next
<aiyion> Thank you both, I'll give it a shot when I'm back.
<dangole> Ansuel, aiyion, hauke: traced the hang down to first regmap access on the SGMII unit. now comparing clk registers to figure out why sgmii mmio range is unavailable...
<dangole> (eth1 works because is doesn't use SGMII but rather GMII to connect built-in GE phy)
Tapper has quit [Quit: Tapper]
Tapper has joined #openwrt-devel
<mrkiko> dangole: on what hw are you testing? brume2 like aiyion ?
<mrkiko> or is it a different hang / problem?
* aiyion is afk for a moment
<dangole> mrkiko: i'm trying to port mt7981 to mainline linux, using gl-inet mt3000 hardware for testing
<Ansuel> jow Hardware: 0000:0000 0000:0000 [Qualcomm Atheros IPQ8074]
<Ansuel> from iwinfo wlan1 info
<jow> Ansuel: seems to do what it is supposed to do, then
<Ansuel> wonder if it was 0000 also before the patch
<jow> no, before the patch it was initialized with fake IDs
<jow> the hardcoded switch/case created fake IDs, and those were looked up in the database as pci device then
<Ansuel> on luci it's always exposed with the name right?
<Ansuel> from ubus ubus call iwinfo info '{"device":"wlan1"}'
<Ansuel> "hardware": {
<Ansuel> "id": [
<Ansuel> 0,
<Ansuel> 0,
<Ansuel> 0,
<Ansuel> 0
<Ansuel> ],
<Ansuel> "name": "Qualcomm Atheros IPQ8074"
<Ansuel> }
<jow> yeah, LuCI just dispalys the name
<Ansuel> if we really want we can save the vendor and subsystem vedor is it would be the only real value... but subsystem_device_id and device_id is all fake
<Ansuel> for me the suggested patch is good as is
<Ansuel> (just needs to add the missing entry for ipq8074)
<jow> could you take care of it? Feel free to push it either with my Suggested-by and your S-o-b or my S-o-b and your Test-by or something
<jow> + the missing entry
rua has quit [Ping timeout: 480 seconds]
<Ansuel> sure will send on the mailing list so you can check if the added tag are ok
goliath has quit [Quit: SIGSEGV]
rua has joined #openwrt-devel
<stintel> aiyion: karlp: did you try 5.15 on sunxi ?
<karlp> yeah, I've got 5.15 in my own tree.
<karlp> anything in particular you were looking for?
<ukleinek> jow: Is there anything I can do to get forward with https://github.com/openwrt/luci/pull/6155 (apart from debugging that myself)?
<stintel> karlp: nope, just considering switching sunxi to 5.15 by default
<karlp> I want even newer, for something, that I can't remmeber right now, but will come back to me...
<stintel> karlp: there is no newer than 5.15 in OpenWrt ;)
<stintel> karlp: so I assume 5.15 ran fine for you?
<stintel> if I can add a tested-by or 2 to the commit I'd just do it today :)
<karlp> you can have mine :)
<stintel> tha
<karlp> Karl Palsson <karlp@etactica.com>
<stintel> etactica ?
<stintel> k ;)
<karlp> was just double checking I did have 5.15 in my local tree :)
<stintel> cheers
<karlp> where's this commit?
<stintel> ah not pushed yet
<karlp> right, just saw it :)
<karlp> if you're removing 5.10, shouldn't you be removing the files and stuff too?
<stintel> next I'll have a look at ramips to see what's wrong there still with 5.15
<stintel> good point
<karlp> it might be worth pointing out that I'm testing 5.15 with a board that's not upstreamed
<karlp> so some of those board support aptches that may or may not have been upstreamed, I'v
<karlp> e not tested.
<karlp> but sunxi is pretty close to upstream in general, so looks like it should be fine... :)
<stintel> should be fine, it's still master
<stintel> but people using snapshot images can't use testing kernel, so ideally we get everything switched to 5.15 by default asap to expose it to more testing
<karlp> :+1:
<stintel> I'm also testing ramips with 5.15, seems there is some kernel panic that needs fixing before we can switch
<robimarko> Ansuel: nice to see the fake PCI id gone
<aiyion> stintel: My commits were based on 5.15 I think, yes. But My concern was more of the device booting reiably and having a stable mac.
<stintel> aiyion:
<stintel> oops
<stintel> aiyion: but that means you've also successfully booted and run 5.15 on sunxi - can I add your tested-by also ?
<aiyion> But let me fire up the device for an hour and shove some trafficd, than I'll have it tested as well.
<stintel> alright :)
<stintel> thanks
<aiyion> I'll get right to it, but building always takes a moment.
<Ansuel> robimarko almost there tho... trying to understand why luci-rpc die after ubus call luci-rpc getWirelessDevices
<jow> ukleinek: right, so my idea was to fix it in a generic manner by making the calling code ignore returned graph definitions that refer to types not present in the rrd being rendered
<jow> Ansuel: abi breakage between rpcd iwinfo.so and libiwinfo.so ?
<Ansuel> in theory i should have updated all the libs
<Ansuel> that should be libiwinfo rpcd and rpcd-mod-luci
<jow> ukleinek: can you pastebin me the output of `find /tmp/rrd -name '*.rrd'` ?
<Ansuel> jow the strange thing is that the command correctly finish the first time and then luci-rpc die
<Slimey> speaking of testing.
<f00b4r0> stintel: i have a bunch of nanopis lying around, I could give it a shot later but right now my build horse is unavailable
<jow> ukleinek: *facepalm* ... it's been too long that I worked with the code, solution seems rather simple actually
<jow> ukleinek: the `graph` variable received as first arg by the `rrdargs()` function is a class instance providing a whole bunch of introspection methods
<Ansuel> compiling a full image.... no point in wasting time with searching what lib is broken....
<jow> ukleinek: among them, a `graph.dataTypes(host, plugin, plugin_instance)` which will return an array of `types` belonging to the given plugin instance
<jow> ukleinek: in your sensors case this should be either `[ "temperature" ]` or `[ "temperature", "humidity" ]`, depending on which sensor instance the rrdargs function is invoked for
goliath has joined #openwrt-devel
<ukleinek> jow: that "rather simple" part is what I expected. Not being fluent in js however ....
<ukleinek> jow: so the idea is to only return the configurations for the types returned by graph.dataTypes, right?
<ukleinek> jow: does it do the right thing then if my sensor yields (say) 2 temperatures and humidity?
<ukleinek> jow: or is the filtering better be done by the code calling rrdargs()?
<jow> ukleinek: so the solution would be something like this: http://sprunge.us/X81Qnq
<jow> yeah, the calling code could probably be smarter and check the .types array of the returned graph descriptions for intersections with the known datatypes of the plugin being rendered, but well
<jow> need to run. if the pasted version works for you, could you amend the PR? I'll merge it later then
<ukleinek> jow: Assume I test and massage that code, should I just update the PR with "Co-Authored-by:" or something similar?
* ukleinek lets jow run
<ukleinek> ... and schedules testing later today
Ansuel has quit [Read error: Connection reset by peer]
<jow> ukleinek: suggested-by is fine
Ansuel has joined #openwrt-devel
gch981213 has quit [Ping timeout: 480 seconds]
<Znevna> can't figure out which commit introduced those errors x.x
gch981213 has joined #openwrt-devel
<Ansuel> jow was thinking since we are adding compatible to the iwinfo struct
<Ansuel> is it necessary to bump ABI?
<Ansuel> ok tested on a full image an all works correctly
srslypascal is now known as Guest838
gch981213 has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
<damex> https://svanheule.net/switches/tl-st1008f interesting to try to get up. i guess it has to run something
Guest838 has quit [Ping timeout: 480 seconds]
<Habbie> i recently opened up https://wikidevi.wi-cat.ru/TP-LINK_LS1005G_V1 - also a much more capable device than "as sold", if you can control it :)
<Habbie> oh, yours has a nice mips cpu, i have 1kbyte of RAM on an 8051 ;)
dansan has quit [Quit: The C preprocessor is a pathway to many abilities some consider to be unnatural.]
<damex> Habbie: yeah, that tl-st1008f seem to have rtl9303 mips cpu inside (up to 800mhz) + 32mb nor + 512mb ddr3 ram :)
<Habbie> that is very nice
<Ansuel> Habbie what is that?
<Habbie> Ansuel, 5xgbit, dumb, 10 EUR
<Habbie> Ansuel, but with a small controller next to it, it can do vlans etc.
<Habbie> in fact by just rewriting that small flash chip you could maybe do vlans - just would have to rewrite it for every change
<Habbie> it can load config -or- code from it i believe
<Habbie> but the code goes into a very poor 8051 cpu with very little ram
<Ansuel> i can see crab
<Ansuel> realtek ?
<Habbie> yes
<Habbie> see sidebar, RTL8367S
<Ansuel> oh i was confused by the asin
<Ansuel> with that b my brain autoflaged it with broadcom
<Habbie> heh
<Habbie> this somewhat related device https://wikidevi.wi-cat.ru/TP-LINK_TL-SG1005D_v3.22 page links to hacks people did
<Habbie> add an arduino to get vlans
<damex> Habbie: i have tl-sf1008d v12 here ;) no idea who thought it is a good idea to buy 100mbit switch in 2022
<Habbie> anyway, no openwrt on mine, but damex - does linux run on 9303?
<Habbie> damex, lol
<damex> there is some support present
<Habbie> ah, nice
<damex> i wonder if there is photos/info about what is inside TL-ST5008F
<damex> looks like managed tl-st1008f with management capabilities ;)
<Habbie> for "my" switch, i get why there's a chip in there that can do a little more than be dumb
<Habbie> but 512MiB RAM in a switch sold as unmanaged, why
<damex> Habbie: probably has to run some crapware
<Habbie> hmm, no RTL9xxx at all on http://openrrcp.org.ru/hardware.html
<damex> tl-st1008f is like 98$ + 17$ shipping while TL-ST5008F is 132$ + 36$ shipping
<Habbie> ok
<Habbie> yes, makes you wonder if the difference is 2 chips or one bit somewhere :)
<f00b4r0> reading that RRCP stuff. Looks like an amazing attack vector.
<Habbie> f00b4r0, yes
<Habbie> f00b4r0, i guess mostly because people might not know they have it
<damex> Habbie: well, atleast they soldered actual serial console, added 'management port' and seem to have internal PSU
<Habbie> oh, neat
<damex> st1008f has external 12v 2a power adapter which is kinda low for 8x sfp+ ports
<Ansuel> jow sent the patch to mailing list as a last review... I added an extra thing in iwinfo_cli as I didn't liked the 0000:0000 thing
<robimarko> f00b4r0: I have seen PCIe based register acess, but this is just begging for doing bad stuff
<f00b4r0> robimarko: yeah, my thoughts exactly. Typical case of good idea on paper, very bad idea in practice.
<robimarko> This isnt good even on paper
<f00b4r0> ;)
<Ansuel> robimarko i sent the patch to mailing list wonder if you can test if you have time
dansan has joined #openwrt-devel
<robimarko> Ansuel: Sure, I am tweaking the sysupgrade for Xiaomi devices
<robimarko> After that is done
borek has quit [Ping timeout: 480 seconds]
<robimarko> f00b4r0: ok, so using platform_pre_upgrade works for detecting initramfs
<robimarko> As its called before moving to ramdisk
<f00b4r0> ah good catch!
<robimarko> Wish I was the one to figure that out
<f00b4r0> ;)
<robimarko> Found it in Filogic target as Redmi AX6000 is doing something really close to what I want
<robimarko> Ansuel: I presume I need to update iwinfo to latest version first?
<Ansuel> yes
<Ansuel> + creating a patches directory and putting the patch from the mailing list
<robimarko> Ugh, patchwork is down
<robimarko> Thanks
<aiyion> stintel: Here's the screenlog of the sysupgrade from 5.10, boot of 5.15, and basic checking of networking. Maybe you spot something I didn't, but so far it looks good.
<aiyion> Tested-by: Jan-Niklas Burfeind <openwrt@aiyionpri.me>
<robimarko> Ansuel: Works for me
cbeznea has quit [Quit: Leaving.]
<Ansuel> nice to hear i'm waiting jow approval and then i will merge and bump iwinfo in master
Borromini has joined #openwrt-devel
philipp64 has quit [Ping timeout: 480 seconds]
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 99.6% packages reproducible in our current test framework.)
<Ansuel> btw i think gcc 12 somehow
<Ansuel> broke elfutils package compilation
<Ansuel> checking whether the C compiler works... no
<Ansuel> configure: error: in `/__w/openwrt/openwrt/openwrt/build_dir/target-mips-openwrt-linux-musl_musl/elfutils-0.188':
<Ansuel> configure: error: C compiler cannot create executables
<Ansuel> wtf ?
<Ansuel> cc1: error: '-Wno-error=use-after-free': no option '-Wuse-after-free' probably this is the cause?
<robimarko> Is that on the host or?
<hauke> Ansuel: everything was buidling for me
<hauke> I thing it still picks up an old toolchain
<Ansuel> for ci probably the new toolchain needs to be generated?
<hauke> the build bot is still busy
<Ansuel> for my local testing let me try clean my toolchain
<hauke> the armvirt/64 is ready
<Ansuel> but anyway we missed this
<Ansuel> that in theory should handle the false-positive
<hauke> I tried it yetserday and build x86 with glibc and musl with gcc 12 and gcc11
<hauke> and elfutils build for me
<robimarko> On ipq807x everything builds fine with GCC12 localy
<Ansuel> then it's 100% my dirty buildbot
<mrnuke> damex: have you checked that your serail cable/adapter is working with 3.3V? You can short TX and RX on the cable and see it it echoes things back. I fried several USB adapters bu connecting them to the TP-Link. Reason: the GND can be at 50V potential from earth due to the way the PoW works. Last night when I was testing, I fried another USB-serial adapter :p
<Ansuel> hauke if that patch works should we care to have that instead of disabling the warning?
<hauke> I think we should retry tomorrow when the x86/64 and malta/be builds are done
<Ansuel> sure but it will totally work... just toolchain needs to be refreshed.
<dhewg> those two targets fail with the same errors on PRs I pushed to today
<damex> mrnuke: yeah, it works fine. i have many different usb ttl adapters and i confirmed that they work fine. one of them is ch343p (usb-c, designed/made by weact studio and schematics somehwere on github), some generic ch341a and some other stuff like pl2303 or something that i no longer use but they still work. i constantly debug esp32 chips using them through and i can definitely confirm that they work fine.
<hauke> dangole: the gl-mt3000 is for sale for 69$, does it make sense to buy it?
<damex> i have some other ttl adapters if that does matter and they still should work or i can repurpose one of the development boards to become a serial adapter :)
<robimarko> hauke: I really hoped for dual core A53 to die finally
<Ansuel> robimarko in theory your ipq807x pr should complete fine since every toolchain is locally built
<robimarko> Ansuel: Yes, it compiles fine as there is no prebuilt toolchain so its build in the workflow itself
<damex> mrnuke: maybe it would matter - 3.20.4 stock was unstable and constantly froze with stp on and under other circumstances. upgrading to 3.20.7 solved almost all concurrent problems. all switches boot with LEDS OFF when i plug 10gtek sfp->rj45 copper module on 9th port. works fine if i keep it plugged in to the 10th port.
<damex> i tried downgrading past that and it refused to accept it from gui or tftp+cli.
<Ansuel> any idea how to refresh gcc patches? totally forgot
<damex> hauke: i have been deciding on new device with filogic and did pick banana pi r3 instead of mt3000 for what it offers. quad core, 4 times more ram, more ports, more wireless channels, m2 nvme and etc :) mt3000 is not supported yet though while banana thingy got official support
<damex> but banana board does cost more :)
<stintel> aiyion: thanks!
<dangole> hauke: US$69 for a device with 2.5G Ethernet is quite nice, and my feeling is that MT7981 will be the new IPQ4019 in terms of popularity.
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
<SwedeMike> looking at https://img-blog.csdnimg.cn/3ab8a95592d743b4be758e2c4910576f.png what's the speed of that SGMII that goes from Panther to the MT7531 (?) switch?
<dangole> SwedeMike: MT7531 is connected to MT7986 with 2.5GBit/s
<dangole> SwedeMike: looks a bit like this fact was deliberately omitted in the image...
<SwedeMike> looks promising!
bluew has joined #openwrt-devel
<dangole> hauke: btw: I managed that eth0 on MT7981 no longer hangs on link-up, I figured the bus hang was due to a necessary clock ('sgmii_reg') not being enabled. now DMA still hangs for eth0, probably data path is not setup correctly...
<damex> https://forums.servethehome.com/index.php?threads/cheap-8-ports-sfp-low-noise.28243/post-265363 oh my, tplink removed serial port on v2 of that tl-st1008f. so i guess gotta pop them them out of soc :)
<damex> ah no, it is other way around. pins are present on v2 o-O
<Slimey> oh remind me i need to bring my multimeter home
<Slimey> s
<Borromini> dangole: are you talking about the 802.11ax TP-Link you are porting?
<hauke> Borromini: Is the TP link MT7981 avalibale in the EU?
<Borromini> hauke: i have no idea, sorry. It looks like everyone is ordering those XDR-6086 off AliExpress
<Borromini> i joined mid-convo so I don't know if that's what dangole was talking about, hence my asking
<Ansuel> well nice... gcc version selection is broken....
<dangole> Borromini: no, i don't have that XDR608x hardware, was only hacking on it via remote access. the mt7981 is gl-inet mt3000
<mrnuke> damex: The only other idea is to check the UART and clock likes with an oscilloscope or logic analyzer to see if the SoC is dead.
<robimarko> hauke: Other than GL-Inet stuff, you are gonna need to get the Filogic stuff from china
<robimarko> TP-Link has plenty of models, but its all CN only
torv has quit [Remote host closed the connection]
<Ansuel> hauke https://github.com/openwrt/openwrt/pull/11750 magic stuff i discovered...
<hauke> Ansuel: lloks good
<hauke> damex: banana pi r3 is more expensive and has no casing
torv has joined #openwrt-devel
<robimarko> There is optional case
<robimarko> But everything is paid extra, antennas, case, etc
<damex> hauke: they sell a metal casing for it for like 10 bucks :)
<damex> but yes, it is more expensive
<Borromini> dangole: ah ok :)
<robimarko> Well, my M300 lowballs failed on ebay
<f00b4r0> robimarko: if it werent so bloody expensive to ship to you, I'd offer to get the 2-pack and ship you one: I want one more ;)
<robimarko> Yeah, if you are not a frequent shipper they are too expensive
<f00b4r0> *nod*
<robimarko> BTW, Was there ever a sucessor with maybe an SFP port?
<Ansuel> hope the staging_dir_host rework won't cause buildbot to explode....
<robimarko> Ansuel: Once ipq807x is merged, we really gotta make that mini NSS-DRV
<robimarko> Cause, that alone was like 2x perf improvement
<Ansuel> does that also affect wifi ?
<Ansuel> like less load = more wifi bandwidth ?
<robimarko> Indirectly yes
<Ansuel> cause currently i have gigabit connection but with wifi i can only get 600mbps
<robimarko> In theory you can offload pretty much anything to NSS FW
<Ansuel> well yes with wifi offload and correct
<robimarko> If I ever figure out how upstream offloading works
<Ansuel> option (that other user didn't figure out *wink* *wink*)
<Ansuel> you can reach 3gbps with wifi
<Ansuel> it was very lol
<Ansuel> seing that on a router that has 1gig port ahahah
<robimarko> Well, if you offloading basic stuff like bridgeing, VLAN-s etc
<robimarko> That leaves a lot of room for WLAN
<Ansuel> adding offload api to nss cores would be power point meeting level at some hacking convention with the amount of work required LOL
<robimarko> The thing is that they already offer an API
<robimarko> Its just that they use that abomination called ECM on top
<robimarko> NSS-DRV itself is the "API"
<robimarko> But like I said, just pushing the traffic via NSS cores doubles the throughput
<robimarko> And you are not offloading anything technically
<Ansuel> you are doubling the rings
<Ansuel> nss have 4
<robimarko> Yes
<robimarko> And more importantly, all of the basic offloads
<robimarko> Like GRO, TSO, checksum etc are present
<Ansuel> still a mistery if the switch have tso or it's for real done by nss
<robimarko> Ansuel: QCA released SPF11.5.5
<robimarko> Looks like they were forced to not EOL support for IPQ4019 and IPQ8064
<Ansuel> i understand ipq4019
<Ansuel> but ipq8064... wow...
<robimarko> Well, if they are gonna support one ARM32 platform its free to support the second one
<robimarko> M440 looks nice
srslypascal is now known as Guest869
srslypascal has joined #openwrt-devel
<f00b4r0> robimarko: I see M400s going for 90USD. But only in the US
matoro has quit [Quit: ZNC 1.8.2 - https://znc.in]
<Ansuel> btw starting to hate the fact that many thing are us only and no reseller in eu
<f00b4r0> i suspect the m440 is not yet EOL'd
matoro has joined #openwrt-devel
* f00b4r0 adds an eBay alert for M400 :)
Guest869 has quit [Ping timeout: 480 seconds]
<robimarko> f00b4r0: They are all not being sold anymore
<robimarko> M400 personally isnt that atractive
<robimarko> But used stuff in EU is always crazy expensive compared to US
<f00b4r0> robimarko: what's better on M440 for you?
<robimarko> 25x1Gb (8 with PoE), 2x10Gb SFP+ fiber
<f00b4r0> yeah that's a tad overkill for me ;)
matoro has quit [Quit: ZNC 1.8.2 - https://znc.in]
<dhewg> that already sounds noisy just by roughly guessing the power consumption
matoro has joined #openwrt-devel
Ryncewynd has quit [Quit: Leaving]
Borromini has quit [Quit: Lost terminal]
matoro has quit [Quit: ZNC 1.8.2 - https://znc.in]
<robimarko> Its not gonna be quiet
<Ansuel> any help with this?
<robimarko> I am not getting what does he want to do with that
<Ansuel> probably a device enforce a specific bootargs and he wants to find a way to use that?
<robimarko> root=PARTUUID is nothing special
<robimarko> A lot of devices use it
<Ansuel> yep i remember that and we fix that with hardcoding the bootargs or appending to them if i'm not wrong
<robimarko> Not really
<robimarko> We activelly use that for mvebu and other targets that generate SD card/eMMC images
<robimarko> My point is, what would be the side-effect for boards that rely on that being correct
<Ansuel> guess i will ask more info about it
robimarko has quit [Quit: Leaving]
<jow> Ansuel: patch looks legit
<Ansuel> jow what about the ABI problem?
<jow> Ansuel: it simply makes fstools ignore root=xxx parameters it can't handle
<jow> the rootdevname() function the value gets passed to expects a block device path
<Ansuel> (oh ok the fstool thing)
<jow> and in case there's multiple root=, e.g. a root=UUID=foo prepended by the bootloader and another root=/dev/blah, the patch would make fstools skipe the former
<jow> *skip
<jow> or rather; the intent of the patch is to force looking up the requested partition name in *all* block devices in case the kernel cmdline root= does not refer to a /dev/ path
<jow> if it does refer to a /dev/ path, only devices belonging to the same block device as the root= parameter are considered
<jow> currently this logic does not account for root=UUID=...
<jow> in this case, fstools tries to find stuff in /sys/class/block/UUID=.../*/uevent
<jow> which is wrong
<Ansuel> considering rootdevname expect a /dev/ path... what is the output in the case PARTUUID=<xxx> is passed?
dangole has quit [Remote host closed the connection]
<jow> in case the uuid happens to end with decimal digits, they'll get stripped off
dangole has joined #openwrt-devel
<jow> otherwise the input value is returned back verbatim
<jow> e.g. 67a4b35c-02 => 67a4b35c-
<jow> basename("67a4b35c-") => "67a4b35c-"
<jow> or rather "PARTUUID=67a4b35c-02" => "67a4b35c-"
<jow> and basename("67a4b35c-") => "67a4b35c-"
<jow> erm "PARTUUID=67a4b35c-02" => "PARTUUID=67a4b35c-"; basename("PARTUUID=67a4b35c-") => "PARTUUID=67a4b35c-"
<jow> well, you get the idea
jennie has joined #openwrt-devel
<jennie> hello
<jow> this results in /sys/class/block/PARTUUID=67a4b35c-/*/uevent being globbed
<jow> however in this case we want to look at /sys/class/block/*/uevent instead
<jennie> any leads on this?I just did the measurement
<Ansuel> jow yep the patch looks good and it really seems current code assume things without actually checking
<jennie> Hi Ansuel
<jow> Ansuel: also abi issue, so the "compatible" addition to the id struct ended up breaking abi?
<Ansuel> we add stuff to struct iwinfo_hardware_id and struct iwinfo_hardware_entry
<Ansuel> the compatible char array
<jow> yeah, I know, it's expected
<jow> just was hoping that current users load that into a larger buffer, like all the other getter ops
<jow> but it's nto the case: https://git.openwrt.org/?p=project/rpcd.git;a=blob;f=iwinfo.c#l116
<jow> rpcd-mod-iwinfo is passing an exactly sizeof(struct iwinfo_hardware_ids) sized buffer
<jow> so obviously it'll fail without recompilation
<jow> but given that dhewg has other abi breaking changes pending as well, let's just go ahead, slap dhewg's changes on top and eventually bump iwinfo in master with a ABI_VERSION change
<Ansuel> i guess RIP cleanup
<Ansuel> think I will merge the current patch in iwinfo and move on the rest of the pr with the ABI change
<jow> but please don't bump the iwinfo package yet, at least not before the other cleanups here are merged: https://github.com/openwrt/openwrt/pull/11280
<Ansuel> yep that was the idea... add everything in iwinfo but only bump when we are finished
<jow> given that 22.03.3 is out now and we backported the most important fixes I'm fine with breaking the abi now
<Ansuel> btw about the fstools patch.... i'm checking and we are full of target with something like: setenv bootargs "console=ttyS2,1500000 earlycon=uart8250,mmio32,0xff1a0000 root=PARTUUID=${uuid} rw rootwait"
<jow> I can only say that the patch as such makes sense, but I do not know about the wider implications
<jow> how fstools is used in this context, whether anything is actually broken or will start working after the proposed change
<Ansuel> need to check it more since we have many target using PARTUUID... the patch makes sense... so everything is wroking by luck? it's strange
matoro has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
<jow> it will fix volume_find("rootfs") and volume_find("rootfs_data") in mount_root for example
dangole has joined #openwrt-devel
<jow> the jffs2reset applet performs a volume_find("rootfs_data") as well
<jow> as does fstools/snapshot (iirc nowhere used by default) and fstools/ubi
<jow> nvm about fstools/ubi, it declares an entirely different volume_find() locally, so it seems it'll affect mount_root and jffs2reset
dangole has quit [Remote host closed the connection]
<jow> likely neither works as intended if kernel is booted with root=PARTUUID=... or root=UUID=...
<Ansuel> https://git.openwrt.org/?p=project/fstools.git;a=blob;f=libfstools/partname.c;h=f59c52eb8f3c6da0e8ee6c4080abd7cdac3db715;hb=HEAD#l98 the interesting thing is this
<Ansuel> wonder if the strip part is doing some magic
<jow> no, it is not
<jow> it's simply nuking digit characters from the end of the string until the first non-digit character
<jow> if the last character after that happens to be a "p", it is nuked too
<jow> (some blockdevs use an foo0p1 notation)
dangole has joined #openwrt-devel
<Ansuel> so the glob is /sys/class/block/PARTUUID=.../*/uevent
<jow> yes
<Ansuel> how the hell this thing is working
<jow> it is not
<jow> I suppose affected devices end up using alternative code paths
<Ansuel> probably since by the looks of it the partname is never found
<jennie> sorry, i dont want to interrupt important stuff you are doing, what should i do next with this https://forum.openwrt.org/t/adding-openwrt-support-for-aruba-ap-315/145174
<jow> Ansuel: the entire code looks brittle
<jow> Ansuel: there's several places that never chick if volume_find() actually found something
<jow> the various accessor functions are null safe and will return -1 then
<jow> but the case switches don't handle -1
dangole has quit [Remote host closed the connection]
<jow> so the applets should end up doing nothing
<jow> for example in line 104 of https://git.openwrt.org/?p=project/fstools.git;a=blob;f=mount_root.c
dangole has joined #openwrt-devel
<Ansuel> i'm getting even more confused o.O how this thing even works
<jow> let's wait for the submitter to provide more context
<Ansuel> well yep mount_root is ancient code... 2016 stuff
<jow> isn't x86_64 using partuuid too?
<Ansuel> yep in ./target/linux/x86/base-files/lib/upgrade/platform.sh
<jow> hm, I could imagine that it's working because the kernel understands PARTUUID=... too
<Ansuel> ok not for root=PARTUUID
<jow> so maybe it is mounting stuff by itself already
<Ansuel> so mount_root.c is never reached probably
<jow> at least on targets using traditional partition tables and less-carzy filesystems
<Ansuel> btw the user answered and gave more info
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
gch981213 has joined #openwrt-devel
<jow> Ansuel: yep, explanation makes total sense
<Ansuel> i'm curious to check where mount_root is used in our base files
<jow> Ansuel: package/base-files/files/etc/init.d/boot and package/base-files/files/etc/init.d/done for example
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (14.2% images and 98.8% packages reproducible in our current test framework.)
<Ansuel> yep the fun thing is that by the looks of it mount_root done
<Ansuel> fails in almost all the case considering we use rootfs now instead of rootfs_data
<Ansuel> the UUID part is probably working as partname is failing but something else is working in volume_find
<Ansuel> i'm curious to test my theory about the broken done function
cmonroe has quit [Ping timeout: 480 seconds]
jennie has quit [Quit: Going offline, see ya! (www.adiirc.com)]
torv has quit [Quit: torv]
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
cmonroe has joined #openwrt-devel