**** BEGIN LOGGING AT Tue Jul 10 03:00:01 2018
Jul 10 03:00:57 <Westislander> Anyone here using 18.06.0-rc1 release?
Jul 10 03:01:38 <DonkeyHotei> i'm using an 18.06 snapshot on a couple of "dumb ap" devices
Jul 10 03:02:05 <DonkeyHotei> snapshot after rc1, though
Jul 10 03:03:15 <Westislander> Glad you reminded me to check latest builds/
Jul 10 03:04:18 <DonkeyHotei> what target?
Jul 10 03:04:57 <Westislander> TP-Link TL-WDR3600 is my spare/test device
Jul 10 03:05:11 <DonkeyHotei> ar71xx?
Jul 10 03:05:19 <Westislander> Yes.
Jul 10 03:05:31 <DonkeyHotei> i'm running it on archer c7 v2
Jul 10 03:05:52 <Westislander> I have a number of different non-current tp-link models
Jul 10 03:06:04 <Westislander> 741, 841, 3600, and 4300
Jul 10 03:07:34 <Westislander> Found any problems?
Jul 10 03:08:48 <Westislander> I did find a problem with RC1 which only accepts limited amount of characters in startup, scheduled tasks, and iptables uploads via luci.
Jul 10 03:09:09 <Westislander> Do you know if anyone is penetration testing openwrt?
Jul 10 03:14:40 <DonkeyHotei> idk
Jul 10 05:10:51 <russell--> looks like 4.14.x is responsible for the memory leak i'm seeing on mt7621
Jul 10 05:11:23 <russell--> didn't see it on the commit prior to the transition
Jul 10 05:12:07 <russell--> https://bugs.openwrt.org/index.php?do=details&task_id=1638
Jul 10 06:55:19 <mangix> russell--: I have an mt7621 device with no wireless. I mainly see OOM when running transmission
Jul 10 06:55:56 <mangix> my solution is to use swap
Jul 10 06:57:23 <russell--> that's not my problem, i don't think
Jul 10 06:57:53 <russell--> this device has no load on it, no clients on the wifi, just sitting in my testbed
Jul 10 06:59:31 <russell--> mangix: which mt7621?  i have an ubnt-erx that doesn't show the leak.
Jul 10 07:29:05 <russell--> leak is about 800k/minute
Jul 10 07:29:40 <russell--> according to /usr/bin/free
Jul 10 07:33:40 <russell--> nothing stands out in /proc/slabinfo
Jul 10 07:42:02 <Tapper> morning people
Jul 10 07:55:09 <mangix> russell--: so it's not a problem here then
Jul 10 07:58:55 <mangix> my unit has 512MB RAM. still not enough for transmission
Jul 10 08:03:30 <ds_shadof> here is transmission with 128mb ram
Jul 10 08:03:32 <ds_shadof> 2228 root      20   0 21380  12m 1856 S  0.0 10.4  10:58.63 /usr/bin/transmission-daemon -g /mnt/usb-2tb/transmission -f
Jul 10 08:06:00 <russell--> in my case, the userspace processes don't explain the usage
Jul 10 08:07:33 <russell--> nothing in slabinfo is going crazy, just 800k a minute is disappearing from /usr/bin/free
Jul 10 08:08:59 <ds_shadof> russell--, btw you scares me. I'm going to use ZBT WG3526 wich is  MediaTek MT7621AT based
Jul 10 08:13:10 <russell--> ds_shadof: do you have one?
Jul 10 08:17:30 <ds_shadof> russell--, yes. Will poweron it later today with latest trunk
Jul 10 08:20:03 <russell--> ds_shadof: i've been running 'while true ; do echo $(date) $(cat /proc/uptime) $(free) ; sleep 60 ; done'
Jul 10 08:20:11 <russell--> and watching the free number descend
Jul 10 08:26:38 <jow> russell--: did you try disabling flow offloading?
Jul 10 08:29:32 <russell--> jow: how do you do that?
Jul 10 08:29:46 <muhaha> ldir: ping
Jul 10 08:30:11 <muhaha> ola guys, any plan to bump lxc to 3.0 lts?
Jul 10 08:36:15 <russell--> ah, i found it in menuconfig
Jul 10 08:38:48 <ds_shadof> russell--, you can disable it in luci web in firewall menu
Jul 10 08:39:49 <russell--> i'm not using the stock firewall, fwiw
Jul 10 08:45:48 <dedeckeh> jow:ping
Jul 10 09:00:19 <russell--> jow: still seeing it with CONFIG_PACKAGE_kmod-ipt-offload and CONFIG_PACKAGE_kmod-nf-flow unset
Jul 10 09:02:51 <ldir> muhaha: pong
Jul 10 09:04:48 <muhaha> ldir: I can not find your changes for APU boardname changes in kernel for leds and gpio (https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=summary). Or did you get answer from package maintainers ? .. to remove completely boardname checking? Thanks
Jul 10 09:05:35 <ldir> It all got bikeshedded to death, and since I don't have a board anyway it puts me in a position where I'm unconfortable fighting for it.
Jul 10 09:05:55 <ldir> so it ain't gonna happen from me at least.
Jul 10 09:07:04 <muhaha> yaiks.. Seems that nobody is using this board :D
Jul 10 09:12:07 <muhaha> ldir: you removed this https://github.com/openwrt/openwrt/blob/master/package/kernel/leds-apu2/src/leds-apu2.c#L335-L344 and https://github.com/openwrt/openwrt/blob/master/package/kernel/gpio-nct5104d/src/gpio-nct5104d.c#L438-L440 , right ?
Jul 10 09:13:10 <ldir> My commits no longer exist.
Jul 10 09:13:41 <ldir> Whatever work I did no longer exists, I have made zero changes.
Jul 10 09:14:52 <muhaha> I know, but this was you intention, right? To remove boardname checking...
Jul 10 09:16:15 <ldir> The board checking still exists upstream so no.  The upstream stuff will break depending on dodgy bios.  I gave up.  I don't have the board.
Jul 10 09:22:48 <muhaha> ldir: but https://github.com/openwrt/openwrt/blob/master/package/kernel/leds-apu2/src/leds-apu2.c#L335-L344 is working and its in upstream so why to not do it also for https://github.com/openwrt/openwrt/blob/master/package/kernel/gpio-nct5104d/src/gpio-nct5104d.c ???
Jul 10 09:28:41 <ldir> I don't know.
Jul 10 09:33:24 <ldir> In essence I got bikeshedded on a patch for a board that I neither have nor maintain, by the board/patch maintainers and here on IRC. I'm not in a position to argue one way or the other and I no longer wish to be involved with it.
Jul 10 09:39:08 <muhaha> jesus
Jul 10 09:39:10 <muhaha> ok
Jul 10 09:40:14 <m4t>  /mode #openwrt-devel +b SpaceRat!*@*
Jul 10 09:40:16 <m4t> :(
Jul 10 10:00:04 <jow> dedeckeh: pong
Jul 10 10:04:08 <dedeckeh> jow:possible to set http://patchwork.ozlabs.org/patch/937167/ and http://patchwork.ozlabs.org/patch/936573/ as accepted ? Both patches have been applied to netifd
Jul 10 10:04:34 <dedeckeh> jow:could you have a look at http://patchwork.ozlabs.org/patch/938000/ ?
Jul 10 10:08:08 <jow> dedeckeh: I am not overly happy with the fw3 patch
Jul 10 10:09:17 <jow> dedeckeh: I'd rather introduce two global options "tcp_reject_code" and "any_reject_code" which default to tcp-reset and port-unreach respectively
Jul 10 10:09:40 <jow> I'd rather like to avoid single-purpose options
Jul 10 10:11:33 <jow> and if we implement it, we should extend it to config rule sections (e.g. config rule; option name "Reject stuff"; option src wan; option proto tcp; option src_ip 1.2.3.4; option target REJECT; option reject_code adm-prohibited)
Jul 10 10:14:10 <dedeckeh> so the idea is to allow per rule override the global configured behavior ?
Jul 10 10:37:24 <jow> dedeckeh: maybe, at a later stage, not as a requirement of the current patch
Jul 10 10:37:42 <jow> need to think some more about it
Jul 10 11:22:49 <muhaha> I am building 18.06 with error... output https://pastebin.com/v0yxL8xj Where can be a problem?
Jul 10 11:23:44 <jwh> not in that small snippet
Jul 10 11:30:06 <muhaha> ok, iam getting exit code 2 so I guess its sometghing with my build system
Jul 10 12:31:32 <DonkeyHotei> muhaha: this was my error with lxc 2.1.1 https://pastebin.com/zLq75P0k
Jul 10 12:32:47 <DonkeyHotei> muhaha: you said you were able to build 18.06 before and did not keep the build tree, but you never showed me /proc/version from that running build
Jul 10 12:33:42 <muhaha> ah, maybe its uses a cache or I dont know...
Jul 10 12:34:30 <muhaha> DonkeyHotei: Is there any issue to track it?
Jul 10 12:35:47 <DonkeyHotei> all i know is that the last person to touch lxc was rmilecki, who is aware that there is a problem with gcc7 of some sort, but hasn't looked into it
Jul 10 12:37:08 <DonkeyHotei> but if that 18.06 build of yours with lxc is still running, please paste /proc/version from it
Jul 10 12:37:25 <DonkeyHotei> muhaha: ^
Jul 10 12:38:02 <muhaha> I have no access to it right now, but I will be able to tell it to you in evening
Jul 10 12:38:33 <muhaha> Maybe its a time to bump from lxc 2.1.1 to lxc 3.0.1 .. its LTS...
Jul 10 12:39:57 <muhaha> DonkeyHotei
Jul 10 12:41:02 <DonkeyHotei> maybe, or maybe that may break other things
Jul 10 12:42:04 <DonkeyHotei> it's definitely broken as is in the release branch, but bumping a major version there after it's already at the rc stage sounds to me like asking for trouble
Jul 10 12:42:38 <muhaha> so fragile ... Shame that does not exist a router solution with proper gui for major distros :d
Jul 10 12:43:28 <DonkeyHotei> i don't think the overall status of lxc is anyone here's fault
Jul 10 12:45:56 <muhaha> https://github.com/openwrt/packages/issues/6409
Jul 10 12:46:50 <muhaha> I am not a developer, otherwise I will try to bump it to newer version, but seems its very hard, or there is noone who have a time to do it...
Jul 10 12:47:03 <DonkeyHotei> i know you reported that before, but i'm not getting even that far
Jul 10 12:47:55 <DonkeyHotei> and i'd rather not go down the rabbit hole of digging through all the lxc sources for gcc compliance if i can help it
Jul 10 12:49:06 <muhaha> But changing a PKG_HASH is easy to start with lxc bumping :D
Jul 10 12:49:46 <DonkeyHotei> it would need to be tested on all gcc versions still in use, at least
Jul 10 12:50:07 <muhaha> Yesterday I found a major bug in 2.1.1 , seems its impossible to run unprivileged container afaik
Jul 10 12:50:25 <DonkeyHotei> that may be related to the kernel version
Jul 10 12:50:39 <DonkeyHotei> something changed in 4.18, at least
Jul 10 12:51:32 <muhaha> I have to go, i will let you know about procversion later...
Jul 10 13:18:28 <allotrope94> could anyone here help with these questions? https://www.reddit.com/r/openwrt/comments/8xp09u/first_steps_after_flashing_a_ravpower_filehub_plus/
Jul 10 13:18:29 <allotrope94> Thanks!
Jul 10 13:18:59 <allotrope94> Essentially I need recommendations for connecting to wifi while accessing my router over ethernet and for mounting sd cards in the machine
Jul 10 13:23:02 <DonkeyHotei> sounds like a question for #openwrt rather than #openwrt-devel
Jul 10 13:23:21 <jwh> yup
Jul 10 13:25:06 <DonkeyHotei> but if your openwrt includes the luci web interface, it can set up a client interface for you
Jul 10 13:25:15 <allotrope94> DonkeyHotei - thanks. I will join that channel
Jul 10 13:25:18 <allotrope94> Oops
Jul 10 13:25:31 <allotrope94> I don't have luci in my OpenWRT (it's a snapshot)
Jul 10 14:56:08 <jwh> bleh
Jul 10 14:56:16 <jwh> this is fun, now have routeros to manage
Jul 10 14:57:19 <jwh> don't really have a choice unless someone can confirm a single target has working sfp :(
Jul 10 15:20:50 <Monkeh> jwh: Put SFP equipped targets in my hands, will confirm or try to fix. :P
Jul 10 15:21:09 <jwh> I don't have one to send, but I can give you console to an rb2011 :D
Jul 10 15:21:25 <jwh> used last spare one for this customer with routeros
Jul 10 15:21:28 <jwh> utterly horrible
Jul 10 15:21:31 <Monkeh> Not that helpful :P
Jul 10 15:21:33 <jwh> they really don't get switch config
Jul 10 15:22:05 <jwh> well, it will be plugged in, can see if the interface comes up on it and the box its plugged into :D
Jul 10 15:23:03 <jwh> ugh this is hideous
Jul 10 15:23:17 <jwh> I can tag cpu ports, switch ports etc
Jul 10 15:23:23 <jwh> but can't just add a tagged interface on the cpu port
Jul 10 15:23:27 * jwh rollseyes
Jul 10 15:23:31 <jwh> come back uci
Jul 10 15:26:57 <KanjiMonster> jwh: so far I had no issues with the sfp port of the clearfog pro (apart from the g.fast sfp that didn't want to work)
Jul 10 15:27:49 <jwh> ah finally, a confirmation! :D
Jul 10 15:28:02 <jwh> vdsl sfps require loads of power, well over spec
Jul 10 15:28:05 <jwh> so not unexpected
Jul 10 15:28:22 <jwh> they don't work in a lot of equipment, especially low power stuff
Jul 10 15:32:00 <KanjiMonster> I tested both fiber and copper modules, both worked (although I needed to patch the sfp driver as the copper module took longer to come up than the code expected)
Jul 10 15:32:51 <KanjiMonster> jwh: the main issue of the clearfog boards is that they come without any assigned mac addresses, you are supposed to use some of your own pool
Jul 10 15:33:05 <jwh> ah, thats ok
Jul 10 15:33:51 <jwh> can use local mac addresses, or just get a pool from the IEEE or w/e
Jul 10 15:34:18 <jwh> already use local mac addresses for devices that connect to carriers
Jul 10 15:34:26 <jwh> rather than the real oneos
Jul 10 15:34:27 <jwh> ones
Jul 10 15:44:52 <jwh> argh pile of shit
Jul 10 15:45:04 <jwh> add vlan on entirely different switch chip, other one breaks
Jul 10 15:45:04 <jwh> ..
Jul 10 15:52:21 <muhaha> DonkeyHotei: ping
Jul 10 15:52:31 <muhaha> root@OpenWrt:~# cat /proc/version ...
Jul 10 15:52:31 <muhaha> Linux version 4.14.50 (root@3f06fd643fe1) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r7074-b72bced2d7)) #0 SMP Thu Jun 21 09:22:05 2018
Jul 10 16:44:25 <ultito> morning
Jul 10 17:20:02 <micmac1> Hi jow you here?
Jul 10 17:45:55 <DonkeyHotei> muhaha: odd that you were able to have it compile with 7.3 and i was not
Jul 10 17:56:30 <muhaha> DonkeyHotei: that was with 17.10 ubuntu, now with 18.04 i getting this weird error... iam currently building it with 17.10 again...
Jul 10 17:57:28 <DonkeyHotei> that should not make a difference, because openwrt builds its own toolchain
Jul 10 17:57:34 <DonkeyHotei> i'm on 14.04 still
Jul 10 18:04:22 <muhaha> DonkeyHotei: we will see, i took ~55 min to compile ...
Jul 10 18:04:25 <muhaha> *it
Jul 10 18:17:41 <DonkeyHotei> muhaha: so you were able to compile it?
Jul 10 18:48:46 <neoraider> jow: I think I briefly talked to you about the distfeeds.conf generation shortly before the 17.01 release... any comments on http://patchwork.ozlabs.org/project/openwrt/list/?series=54570 ? (hmm, is the cover letter not available in patchwork?)
Jul 10 18:52:00 <muhaha> DonkeyHotei: no.
Jul 10 18:52:07 <muhaha> :/
Jul 10 18:58:05 <Borromini> hi
Jul 10 20:12:53 <russell--> checking the snapshot for dir860l-b1
Jul 10 20:24:48 <Borromini> russell--: bisecting?
Jul 10 20:34:55 <russell--> Borromini: i found the starting commit already
Jul 10 20:35:45 <Borromini> ok :)
Jul 10 20:35:48 <russell--> i'm just trying to take any of my local changes out of the picture
Jul 10 20:36:01 <Borromini> i haven't experienced any issues on my 18.06 builds
Jul 10 20:36:24 <russell--> i've only found it on mt7621 on 4.14.x
Jul 10 20:37:05 <Borromini> ok
Jul 10 21:57:21 <russell--> just added a comment to https://bugs.openwrt.org/index.php?do=details&task_id=1638 with evidence from a current snapshot
Jul 10 22:08:44 <mamarley> It looks like 18.06-rc1 soft-bricks after a reboot on the Linksys E3000.  I opened a bug report here: https://bugs.openwrt.org/index.php?do=details&task_id=1647
Jul 10 22:10:31 <Monkeh> russell--: Will attempt to reproduce on my RE350 later
Jul 10 22:12:19 <russell--> openvpn has a weird protective effect, which might be a clue
Jul 10 22:12:40 <russell--> ... but doesn't make any sense to me
Jul 10 22:12:44 <Monkeh> No OVPN on mine presently and it's been up.. 21 days
Jul 10 22:13:13 <russell--> with wifi?
Jul 10 22:13:29 <Monkeh> Not currently but it's been up with very recent builds for a while with wifi enabled
Jul 10 22:13:54 <Monkeh> It's in something of a state of disarray having been used for some hackery
Jul 10 22:14:26 <DonkeyHotei> my r3g is running without ovpn and in dumb ap mode
Jul 10 22:15:31 <DonkeyHotei>              total       used       free     shared    buffers     cached
Jul 10 22:15:31 <DonkeyHotei> Mem:        253668      45940     207728        940       2760      12872
Jul 10 22:15:31 <DonkeyHotei> -/+ buffers/cache:      30308     223360
Jul 10 22:15:40 <russell--> could be something else has a similar protective effect, i'd try a snapshot for vanilla comparison
Jul 10 22:15:43 <DonkeyHotei> after 3 days
Jul 10 22:15:59 <DonkeyHotei> running an 18.06 snapshot
Jul 10 22:16:03 <russell--> and that's a mt7621?
Jul 10 22:16:11 <DonkeyHotei> yes
Jul 10 22:16:34 <DonkeyHotei> 4.14 kernel
Jul 10 22:16:35 <russell--> any extra packages?
Jul 10 22:17:52 <DonkeyHotei> nothing special running
Jul 10 22:18:40 <DonkeyHotei> but i have 2.4GHz turned off
Jul 10 22:19:40 <russell--> cat /etc/openwrt_version ?
Jul 10 22:21:02 <DonkeyHotei> r6907+213-7e15e21
Jul 10 22:21:52 <DonkeyHotei> using a git remote, but it's straight 18.06
Jul 10 22:21:57 <DonkeyHotei> no mods
Jul 10 22:22:06 * russell-- wonders how that differs from snapshot
Jul 10 22:22:24 <DonkeyHotei> only in that i removed the firewall, etc.
Jul 10 22:22:37 <russell--> https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/
Jul 10 22:22:48 <DonkeyHotei> oh, you mean from master
Jul 10 22:23:03 <russell--> yeah, that's what i'm testing
Jul 10 22:23:35 <DonkeyHotei> if you bisected it back to the switch from 4.9 then it should be the same in that regard
Jul 10 22:23:59 <russell--> unless something in 18.06 branch fixed it
Jul 10 22:24:15 <russell--> i'm trying with 2.4GHz radio off
Jul 10 22:25:52 <russell--> first few minutes suggest that the rate of leakage is cut in half with one radio ... too soon to be sure
Jul 10 22:28:15 <russell--> oh, my radios are encryption none too.
Jul 10 22:30:09 <russell--> and no one is connected, also perhaps different
Jul 10 22:40:21 <DonkeyHotei> psk2+ccmp here
Jul 10 22:40:44 <DonkeyHotei> and i am connected to this channel through it atm
Jul 10 23:48:46 <russell--> interesting. at some point with a client connected (near some messages: "Tue Jul 10 23:07:19 2018 daemon.warn odhcpd[1022]: A default route is present but there is no public prefix on br-lan thus we don't announce a default route!") the leaking memory was recovered
Jul 10 23:55:49 <DonkeyHotei> i'm obviously not running odhcpd in dumb ap mode
Jul 10 23:57:02 <DonkeyHotei> can you check per-thread memory usage with top?
Jul 11 00:11:15 <russell--> the version of top in the snapshot is rather limited
Jul 11 00:11:59 <jwh> yeah busybox top is pretty basic
Jul 11 00:12:15 <jwh> probably want coreutils/util-linux, forget which one has fancy top
Jul 11 00:19:17 <russell--> psutils, iirc
Jul 11 00:20:02 <russell--> my theory is that some system call is tickling something that recovers the memory, it's not about the specific userspace program
Jul 11 00:20:19 <russell--> it's not showing up in a userspace process
Jul 11 00:20:30 <russell--> the consumed memory, that is
Jul 11 02:05:45 <russell--> yeah, looks like just being associated and maybe passing traffic is the tickle required
Jul 11 02:51:52 <russell--> if nothing is associated, memory leaks, oom's
Jul 11 02:54:05 <Monkeh> russell--: Will test that tomorrow, should be easy to verify
Jul 11 02:54:39 <Monkeh> Got distracted trying to figure out KiCad..
Jul 11 02:54:52 <DonkeyHotei> i could test it by simply enabling 2.4ghz
Jul 11 02:55:12 <Monkeh> Hop to it then
**** ENDING LOGGING AT Wed Jul 11 03:00:02 2018