<mangix>
musl was properly fixed upstream with version 1.33. incredible.
gch98121332894 has joined #openwrt-devel
gch9812133289 has quit [Ping timeout: 264 seconds]
gch98121332894 is now known as gch9812133289
peterM is now known as linmob
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<blocktrron>
nbd: i've seen the mt7915 rate-control is done via the MCU firmware - is this subject to change or is there no way around this (presumably MU-MIMO)?
madwoota has quit [Read error: Connection reset by peer]
Ycarus has quit [Remote host closed the connection]
CrazyLemon has joined #openwrt-devel
danitool has joined #openwrt-devel
Ycarus has joined #openwrt-devel
hbug___ has quit [Ping timeout: 240 seconds]
hbug___ has joined #openwrt-devel
<aparcar[m]>
jow: ping?
Ivan__83 has quit [Quit: Miranda NG]
Ivan__83 has joined #openwrt-devel
<nitroshift>
hey guys
<nitroshift>
trying to build, getting the following error:
<nitroshift>
grep: /home/nitroshift/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linux-5.10.4/modules.builtin: No such file or directory
<nitroshift>
any ideas?
<mangix>
dedeckeh: ping
Darkmatter66 has joined #openwrt-devel
<Borromini>
mangix: hey. seems breed reset my MAC addresses (I saved them before flashing though). can I just add them back in /etc/config/{network,wireless} etc. with option macaddr?
<stintel>
when I enable sqm with 300/300 -> 125Mbit down, 200 up
<Borromini>
stintel: on an APU2?
<stintel>
yes
<stintel>
it's downright horrible
<Borromini>
:-/
<Borromini>
really showing its age
<stintel>
1GHz is useless
<mangix>
what ethernet interface does it have?
<stintel>
even if you have 4 cores
<Borromini>
i have only 100 Mbps down so far, and sqm isn't really taxing my octeon :P
<stintel>
I210
<mangix>
Borromini: you have octeon?
<Borromini>
mangix: yeah. edgerouter 4
<Borromini>
and a lite on the way as a testing device
* Borromini
has been on a second-hand shopping spree
<stintel>
:p
<Borromini>
well the 4 was new :P
<stintel>
ERL is my backup router here
<Borromini>
missus said okay :P
Grommish has quit [Ping timeout: 260 seconds]
<rsalvaterra>
stintel: Something's not right, there… I have an APU2 managing two WAN connections and have no problems with SQM (250/50 and 130/10 Mb/s).
<stintel>
and have a 2nd one for testing before I update the production one
<Borromini>
stintel: yeah that's why i have been shopping around.
<stintel>
Borromini: but you really should have gotten a 2nd er4 :P
<mangix>
er4
<mangix>
is that a serial connection i see?
<mangix>
nvm, SFP
<Borromini>
mangix: it has serial as well, rj45
<mangix>
oh it's on the other side
<Borromini>
yeah.
<Borromini>
stintel: it's expensive enough :-/
<Borromini>
got an erl for 40 € :)
Grommish has joined #openwrt-devel
<mangix>
1ghz mips. interesting
<mangix>
wait, this is a new router?
<Borromini>
mips64
<stintel>
ERL is ancient
<Borromini>
mangix: 40 € second hand if that's what you mean
<stintel>
but also mips64
<stintel>
but at 1GHz I doubt it's going to be much faster than the apu2
<mangix>
hmm if memory server me correct, some octeon driver is in staging at kernel.org
<mangix>
or did it get removed
<Borromini>
stintel: i think damex ran some tests after he added support but not sure what kind of pipe he has
<stintel>
mangix: it was removed and later that removal was reverted
<Borromini>
but yes, erl is old. point was to have another octeon for testing though
<rsalvaterra>
stintel: Are you doing your own builds for the APU?
<stintel>
rsalvaterra: I do my own builds for all my devices
* mangix
is reading tc-cake man page
<rsalvaterra>
Yeah, I thought so. :)
<mangix>
seems over engineered
<damex>
Borromini: i have 0.5GbE at home. gpon.
<Borromini>
damex: cool :)
<damex>
actually 500Mbit that bursts to 550~600 from time to time
<stintel>
I have 1000/600 but there's a bottleneck somewhere on ISP side that limits me at ~350/350
<stintel>
I still have to give them a call about it but it's usually not easy to get someone competent on the phone, nor someone who speaks/understands English properly
<stintel>
and as long as I don't have this sqm issue sorted ...
<mangix>
australian internet is known as oceanic
<mangix>
didn't know that
<damex>
stintel: it could be. what saves apu2 is intel nic's that can offload some queues
<damex>
octeon does not have that (yet)
<mangix>
cake supports interplanetary traffic
<mangix>
amazing
<Borromini>
stintel: from PC Engines or from your ISP?
<stintel>
Borromini: the 350/350 bottleneck? pretty sure it's on the ISP side
<stintel>
Borromini: inter-VLAN does > 900Mbps
<stintel>
although there is no NAT involved there
<stintel>
but I doubt that alone will divide speed by 3
<ldir>
rsalvaterra: Doesn't adding '-march=btver2' to 'CONFIG_TARGET_OPTIMIZATION' in .config do the same thing?
<stintel>
that makes your {build,staging}_dir incompatible with intel CPUs
<rsalvaterra>
ldir: I *think* the kernel is a separate thing, I'm not entirely sure.
<rsalvaterra>
stintel: Sounds like a feature, then. :P
<stintel>
so you'd have to completely wipe them every time you do a build for a btver2 device vs any intel device
<stintel>
I've been thinking of a nice way to solve that
<ldir>
as I'm only building for the apu I don't mind.
<mangix>
ldir: given you worked on cake, what happens with sysctl -w net.core.default_qdisc = fq_codel
<mangix>
sorry, = cake
<rsalvaterra>
I'm only building for the APU2C4, so I don't have that problem yet…
Darkmatter66 has joined #openwrt-devel
<stintel>
that we can have more optimized variants with proper suffixed dirs in {build,staging}_dir to make people happy, but buildbots/official images just keep doing _generic_
<stintel>
but so many things to do, such little time
xback has joined #openwrt-devel
<lemmi>
one cause of poor performance on ingress shaping is that all traffic as to pass through a loopback device. there is quite some performance to be had to just mark incomping wan traffic and then shape the marked packets on the lan interface
<xback>
nbd: Are the minstrel changes also valid for 19.07? I would backport them otherwise
<ldir>
mangix: I'd expect it to work, however it would be in 'unlimited' mode and so rely on interface back pressure to do the pacing... ie BQL.
<rsalvaterra>
ldir: According to this patch, https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/pending-5.4/201-extra_optimization.patch;h=c60648799277c84b59089531ee68823f041d4156;hb=HEAD…
<lemmi>
if the router doesn't pass any lan traffic, all outgoing traffic on the lan port can be shaped
<lemmi>
makes it quite a bit easier to setup
<rsalvaterra>
… I guess you could add -mtune=btver2 to the CONFIG_EXTRA_OPTIMIZATION, yes.
<nbd>
xback: i'd prefer to let them sit in master for a bit of time before the backport
<nbd>
since the changes are quite intrusive
<nbd>
just to make sure there are no critical regressions
<nbd>
but afterwards, a backport would be a good idea
<xback>
nbd: thanks for the fast rerply. I'll backport it to my staging 19.07 and give it a thorough spin on a few dozen devices
<xback>
it can be cherrypicked to main 19.07 later on then at a convenient time
dwmw2_gone has quit [Read error: Connection reset by peer]
dwmw2_gone has joined #openwrt-devel
* ldir
dammit - have typed make dirclean instead of make clean - guess I'll be rebuilding the toolchain first then
<rsalvaterra>
stintel: Speaking of the APU, I'm getting a GPIO error when I build the pcengines-apu2 driver monolithically. If it's built as a module, the error goes away. Have you noticed this?
<nbd>
zorun: no, that patch fixes a regression in changes that have not been backported to 19.07
<zorun>
ah, thanks
<stintel>
rsalvaterra: I haven't, I just enabled the kmod in my .config but I'm don't even think I am using it
<rsalvaterra>
stintel: You need it for LED support.
<stintel>
rsalvaterra: I never really cared about that
<rsalvaterra>
stintel: But, but… them blinkenlights…!
<stintel>
I have enough of those on my switch and fileserver :P
<stintel>
it's my permanent christmas tree
<stintel>
(my rack)
<rsalvaterra>
XD
nitroshift has quit [Quit: Gone that way --->]
<Borromini>
demblinkenlights <3
<rsalvaterra>
Yeah, they're nice during the day… no so much at night, when you have networking equipment in your bedroom. :P
<stintel>
I believe I had a switch that supported scheduled disabling of all LEDs
<rsalvaterra>
The problem is my sleep schedule is… flexible. :P
<stintel>
sounds familiar
<stintel>
only "network" hardware in my bedroom are some z-wave and zigbee devices
<rsalvaterra>
Goes with the territory, I guess. :P
gch9812133289 has quit [Read error: Connection reset by peer]
gch9812133289 has joined #openwrt-devel
gch98121332894 has joined #openwrt-devel
gch9812133289 has quit [Ping timeout: 246 seconds]
gch98121332894 is now known as gch9812133289
victhor has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
gch9812133289 has quit [Ping timeout: 240 seconds]
gch98121332894 has joined #openwrt-devel
kbeflo has quit [Quit: Leaving]
goliath has joined #openwrt-devel
victhor has quit [Read error: Connection reset by peer]
victhor has joined #openwrt-devel
<ldir>
rsalvaterra: as an FYI your apu kernel arch patch is required... or when I looked through my build log the kernel didn't get built with march=btver2 unless I had your patch. So I was building all the packages with btver2 but not the kernel. I wonder how much difference it really makes.
_whitelogger has quit [Ping timeout: 260 seconds]
_whitelogger_ has joined #openwrt-devel
valku has joined #openwrt-devel
<rsalvaterra>
ldir: Actually you don't need the kernel patch, I just tested. But what you need is no less hacky, in my opinion. :P
<rsalvaterra>
You need to add -mtune=btver2 to CONFIG_EXTRA_OPTIMIZATION.
adrianschmutzler has joined #openwrt-devel
<ldir>
Oh, does it also get applied to the packages ?
<ldir>
if so, then to be honest, it's perfect for me :-)
<rsalvaterra>
ldir: For packages, it's CONFIG_TARGET_OPTIMIZATION. :)
<ldir>
So if I do both then great, and it's stored in the .config so changeable via envs
shibboleth has joined #openwrt-devel
veonik is now known as veonik[m]
<reiffert>
Hello - I'm trying to get openwrt onto mikrotik hex aka rb750gr3, the openwrt-19.07.5-ramips-mt7621-mikrotik_rb750gr3-initramfs-kernel.bin is booted via tftp, the booted OS requests an IP via dhcp, it gets one.
<reiffert>
I can ping the new IP, but telnet, ssh, http, https are closed. I can see the device make ntp queries with the world.
<reiffert>
it would explain that the mgmt ports are closed.
<reiffert>
yep - that's it. Thanks for solving my problem :)
gch9812133289 has joined #openwrt-devel
repulse has joined #openwrt-devel
gch98121332894 has quit [Ping timeout: 265 seconds]
Acinonyx_ has quit [Ping timeout: 246 seconds]
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
ivanich has quit [Read error: Connection reset by peer]
ivanich has joined #openwrt-devel
dangole has joined #openwrt-devel
danitool has quit [Ping timeout: 246 seconds]
danitool has joined #openwrt-devel
<enyc>
Hrrm ... particular dev version note! on Lantiq HHv5a -- console to 'failsafe' and then doing "firstboot" to reset config (then "reboot"), does not work -- same config still there after 'reboot'.
<enyc>
[ 25.342753] jffs2reset: /dev/ubi0_2 is not mounted
<enyc>
[ 25.346379] jffs2reset: /dev/ubi0_2 will be erased on next mount
<enyc>
[ 25.352609] jffs2reset: writing /dev/ubi0_2 failed: Operation not permitted
Tost has quit [Ping timeout: 256 seconds]
shibboleth has quit [Quit: shibboleth]
hbug___ has quit [Ping timeout: 240 seconds]
hbug___ has joined #openwrt-devel
gch98121332890 has joined #openwrt-devel
gch9812133289 has quit [Read error: Connection reset by peer]
gch98121332890 is now known as gch9812133289
hsp has quit [Quit: WeeChat 3.0]
danitool has quit [Read error: No route to host]
danitool has joined #openwrt-devel
<dangole>
enyc: yeah, that can't work in the way it is done now... jffs2_mark is called in jffs2reset.c and doesn't check anywhere if we are dealing with a UBI volume. shouldn't be hard to fix though
<dangole>
enyc: ie. the way to go for now would be to call 'mount_root' before calling 'firstboot'
[florian1 is now known as [florian]
[florian] has quit [Changing host]
[florian] has joined #openwrt-devel
Borromini has quit [Ping timeout: 260 seconds]
hsp has joined #openwrt-devel
hsp has quit [Client Quit]
<enyc>
dangole: ok, should I or you report a bug somewhere [where is best in this devel stage???]
<dangole>
enyc: i'm looking into it and will fix it, i have UBI hardware to try at hand. what we want is doing `int b=0; ioctl(fd, UBI_IOCVOLUP, &b);` or something like that in case of ubi overlay
<enyc>
dangole: thankyou! plesaed my feedback helpful.
<enyc>
I was just literally solderig up some ttl-serial 3-wire-header extenders... will have console on my next HHv5a so can have logging if any crashing persists .......
dana44 has joined #openwrt-devel
hsp has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
hsp has quit [Ping timeout: 264 seconds]
<enyc>
dangole: any $clue if i can/should set debug-level-4 automatically on serial console, rather than manually typing '4' on boot...
hsp has joined #openwrt-devel
Borromini has joined #openwrt-devel
danitool has joined #openwrt-devel
<aparcar[m]>
jow: are you okay with the findrev Patch? It would affect luci package names
muhaha has quit [Quit: Connection closed]
blb4393 has joined #openwrt-devel
Tost has joined #openwrt-devel
blb4393 has quit [Quit: ChatZilla 0.9.93 [Waterfox 56.3/MOZ_BUILDID]]
repulse has quit [Quit: repulse]
dana44 has quit [Ping timeout: 245 seconds]
reiffert has quit [Remote host closed the connection]
<dangole>
enyc: fstools patch for firstboot on UBI is ready for testing. in case you were running your own build, it'd be great if you can test with the patch.
dangole has quit [Ping timeout: 272 seconds]
valku has quit [Quit: valku]
valku has joined #openwrt-devel
<Hauke>
xdarklight: as far as I remomber the AHB bus is only used to conenct the PCIe controller to the central corssbar
<xdarklight>
Hauke: thanks, that will make updating the alias in sysctrl.c easier (needed for getting the mainline PCIe driver to work)
<Hauke>
and USB
shibboleth has joined #openwrt-devel
<shibboleth>
PaulFertser, so far, so good
<xdarklight>
Hauke: is USB connected to "AHBM" or "AHBS"? so far we only describe the USB connection to AHBM, but not AHBM
<xdarklight>
sorry, we for USB we describe the connection to the AHBM clock but not the ABH*S* clock
<Hauke>
bit 13 in PMU_PWDCR and PMU_SR is reserved in the VR9
<Hauke>
AHBS gibt es nur als bit 3 im CGU_CLKGCR0
dangole has joined #openwrt-devel
<dangole>
enyc: i've pushed a fix for the problem with firstboot on UBI you reported. tested on oxnas and did the trick. thanks for reporting!
gch98121332892 has joined #openwrt-devel
gch9812133289 has quit [Read error: Connection reset by peer]
gch98121332892 is now known as gch9812133289
<Hauke>
dangole: the commit message does not match the code any more: https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commitdiff;h=b7f0e92203e7d01dd11cb61426f615bf5c67abab
reiffert has joined #openwrt-devel
<aparcar[m]>
jow: this rsync docker container in buildbot.git drives me nuts. It prints "can't set permisison: file not found" while it still creates the file. This error message seems unknown to the internet
<dangole>
Hauke: true, I'll remove the no longer relevant parts
Borromini has quit [Quit: leaving]
dedeckeh has quit [Remote host closed the connection]
<PaulFertser>
shibboleth: you got lucky, thanks to dangole ! See, every individual package needed its own commit, plus REV bump (sorry for missing that).
<shibboleth>
hey, the more the merrier :P
<shibboleth>
seems robimarko also is also pushing for it
<PaulFertser>
shibboleth: it really makes sense for the maintainers, it's not an arbitrary out-of-the-blue thing.
<shibboleth>
is also...
<dangole>
Hauke: was wondering if we should add logic to netifd's netifd-wireless.sh to default to GCMP on 802.11ad. But I'm not even sure if that's a sensible thing to do, maybe other (?) 802.11ad hardware does support CCMP (?) or it's written in the standard that it should be GCMP for 11ad and that's it?
Slimey__ is now known as Slimey
<dangole>
shibboleth, PaulFertser: I was merely collecting the already split-out patches from lynxis staging tree. robimarko published them long ago on github in a series to support mikrotik 60ghz dish
<shibboleth>
yeah, robi was told to go refactor
<shibboleth>
the v2 reuses the mac80211.sh logic for ac as opposed to his v1
<shibboleth>
well, a/an/ac
<lynxis>
adrianschmutzler: merged the edma. so now it's possible to take a look onto the 60ghz
<shibboleth>
adrianschmutzler, the proposes ad7200 dts is, by choice, as similar as the long-since-approved dts for c2600 to make maintenance less of a hassle
<shibboleth>
since the devices are in essence identical
<shibboleth>
the thinking is that if the c2600/ad7200 dts veer of in different directions maintenance is no longer a matter of maintaining one, updating the other
<shibboleth>
veer off even. do you disagree?
<Hauke>
dangole: I do not know much about ad
<Hauke>
If the QCA device sdo not supprot CCMP is assume this is not so common
<Hauke>
I would make GCMP the default on 802.11ad
<dangole>
Hauke: i'm not even aware any other 11ad hardware being available...
<shibboleth>
i'm happy to change the patch, but then we suddenly have two identical devices with different "formatting"
<Hauke>
I think there is some Intel hardware
<Hauke>
but I am not sure
<shibboleth>
the mikrotok wap60g(x3), lhgg-60ad, ad7200, etc
<rsalvaterra>
pkgadd: Are you sure it's in hardware? Because iw list doesn't always make a distinction… :/
<pkgadd>
rsalvaterra: sorry, I'm not ;)
<rsalvaterra>
:)
<shibboleth>
the lhgg60ad and wap60g are especially interesting devices (long-distance links) but have som hw/fw-kinks, whereas the ad7200 is essentially a c2600. if the 11ad stuff could finally be merged those devs will only have to focus on the mikrotik kinks
<rsalvaterra>
For example, it says my RT2790 supports GCMP-256… :P
<shibboleth>
owrt 11ad-support has been "caught up in committee" for years at this point and that's pretty much it
Acinonyx has quit [Ping timeout: 246 seconds]
<rsalvaterra>
dangole: ping
<dangole>
rsalvaterra: pong
Acinonyx has joined #openwrt-devel
<rsalvaterra>
dangole: No opinion on the x86 gc-sections patch? :)
<dangole>
rsalvaterra: imho it should go to target/linux/x86/... 'x86' is our only 'x86' target, so no need to carry it in generic
<rsalvaterra>
Right, but we already have a similar patch for ARM in generic/hack-5.4, that's why I asked… :P
<adrianschmutzler>
shibboleth: I'm quite sick of this "we cannot do obvious improvements because the new device has to be like the ancient support of some other device" thing
<adrianschmutzler>
particularly since you prove that this is not working, as you keep stuff that makes no sense for a new device like BOARD_NAME and SUPPORTED_DEVICES
<shibboleth>
that's not what i said :). i simply stated that the current formatting/thinking was to stay as true to c2600 as possible to avoid maintenance overhead.
<shibboleth>
and the c2600 has a much larger userbase. any change to the c2600 dts should be safe-to-clone to the ad7200
<adrianschmutzler>
well, if you are convinced by that, please create a shared DTSI because that is actually reducing maintenance overhead
<dangole>
rsalvaterra: yes, but that one is actually also used by more than one target
<adrianschmutzler>
and by that, you have a chance to improve the support for both devices
<xdarklight>
Hauke: haha, thanks. seems like an old bug in sysctrl.c then. then only AHBM is relevant, but that's important for us :)
<aparcar[m]>
adrianschmutzler: for base-files, would you prefer versioning with just a number (204, 205, etc) or the luci style (year.day.second-revision)
<shibboleth>
not working? i'm... perturbed?
<adrianschmutzler>
aparcar[m]: I don't really know the luci style, but if nobody objects and you think it's a good idea, go for it
ivanich has joined #openwrt-devel
<adrianschmutzler>
essentially, the PKG_RELEASE bumping is a pain
<rsalvaterra>
dangole: I see. So in x86, it means the patch is only applied for x86(-64) kernel builds, right?
<aparcar[m]>
luci style is longer but better to put into context, it's e.g. 21.2 which means the wesion is 2 days old. a number is shorter which may look better :p
<adrianschmutzler>
aparcar[m]: and if that proves to be a good idea, please also apply it to uboot-envtools
<Hauke>
xdarklight: I checked multiple versions of the document and all say it is reserved
<shibboleth>
adrianschmutzler, they're not identical. three leds have diff pins, spi4/spi5
<xdarklight>
Hauke: I'm not questioning it - I just find it interesting to stumble across such an old bug in sysctrl.c :)
<adrianschmutzler>
shibboleth: that's the idea of a DTSI: have the shared stuff in the DTSI, and the specific stuff in the DTS
<Hauke>
xdarklight: changing this bit probably does nothing
<Hauke>
but I am suprised where this is comming from
<xdarklight>
Hauke: yep. at least we have tested for years that it doesn't make devices explode :)
<adrianschmutzler>
but I still don't see the reason for not improving the DTS ...
gch98121332898 has joined #openwrt-devel
gch9812133289 has quit [Read error: Connection reset by peer]
gch98121332898 is now known as gch9812133289
<dangole>
rsalvaterra: exactly. I understood right that it only affects x86?
<adrianschmutzler>
shibboleth: just see it from the opposite side: every new similar device added is a chance to improve the existing codebase
<rsalvaterra>
dangole: Yes, only x86 and x86-64.
<rsalvaterra>
I'd like to cook something for arm64, but I don't have the hardware to test… :/
<rsalvaterra>
It's the only missing "big" platform, I guess.
<shibboleth>
i have. the thinking was that since the c2600 has a much larger userbase any changes to the conventions/formatting is easier to test
<shibboleth>
for/with that device
<adrianschmutzler>
hmm, I just looked at my e-mail again and did not find any changes that require specific testing
<adrianschmutzler>
just stuff like labels etc. where pain only comes from changing them once they are established
<adrianschmutzler>
i.e. it pays off to have them right from the beginning
<shibboleth>
afaik there is a v2-variant (only supported by the updated/second stock fw) wlan0/phy0tpt was due to cfg/nl80211 and not mac80211
<shibboleth>
but i'll try it out
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
ivanich has quit [Client Quit]
ivanich has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
<adrianschmutzler>
well, phy0tpt instead of wlan0 would be the biggest gain to get there
finsternis has joined #openwrt-devel
gch98121332891 has joined #openwrt-devel
gch9812133289 has quit [Read error: Connection reset by peer]
gch98121332891 is now known as gch9812133289
mangix has quit [Quit: leaving]
mangix has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
<enyc>
dangole: I'm best to test next master build when I reflash another new HHv5a soon!
dangole has joined #openwrt-devel
<enyc>
dangole: was just asying ... thankyou, when I get another HHv5a soon/shortly i'll install next master build, test the config resetting then .............
<enyc>
more heisenbugs ;p
<enyc>
now I've set config with ipv6-only explicitly (rather than ipv4 addr and no route, or so) openwrt *is* updating NTP over ipv6 without separate ntp build install!
gch98121332894 has joined #openwrt-devel
<enyc>
got serial log and syslog being saved, so if I get any more rebooting-itself I'll have (some) log to show for it
gch9812133289 has quit [Read error: Connection reset by peer]