**** BEGIN LOGGING AT Mon Dec 23 03:00:01 2019 Dec 23 07:58:48 I need a little implementation suggestion for haproxy. I am using procd to do the process-management. I configured procd to only reload the process if the config-file has changed. However, I now need a method of reloading the process without touching the config-file. I would like something like "force-reload". Dec 23 08:00:16 I could add another dummy-config in /tmp and touch that whenever I want to do a force-reload. But it feels a little wrong to me. Dec 23 08:17:11 I could also fetch the PID via pidof(8) but that does not always work because haproxy in master-worker mode spawns at least 2 processes and determining the master-process is not trivial Dec 23 08:30:17 Another option would be to implement "force-reload" to procd which would implement the same logic as "reload" without the checking of the configuration file timestamps **** BEGIN LOGGING AT Mon Dec 23 08:30:38 2019 Dec 23 09:18:19 ynezz: no, i deployed an updated firmware on a four devices (three production and one test) about three weeks ago, and my uptime has maxed out at about 2 days since. averages a reboot after about 12 hours Dec 23 09:18:42 so, i thought maybe the test device would give me a nice panic or something Dec 23 09:18:53 just a silent reboot Dec 23 09:19:07 ubnt-bullet-m Dec 23 09:20:04 no clues why they are rebooting yet Dec 23 11:20:41 mangix: I applied your fix thanks Dec 23 12:32:16 ynezz: I've tweaked the CVE a little Dec 23 12:33:46 I'm slightly concerned that the fix doesn't do any bounds checking so 2^33 would be truncated to a positive 2^31 type number, the the provided length vs the parsed/interpreted length would be wildly different. Dec 23 13:35:45 Suggestion: as nowadays freenode and matrixorg are somewhat peeibg on eachothers cereals, I suggest we do new matrix-room for this and plumb irc channel to it (effectively same endresult as this room is now), but then we have powers to tame the appservice bit from arbitarily kicking people out Dec 23 13:35:56 ldir: thanks, it was just a copy&paste of the jow's commit description :] Dec 23 13:37:56 * olmari uploaded an image: 20191223_153738.jpg (456KB) < https://matrix.org/_matrix/media/r0/download/hacklab.fi/yXEeKVsRANzTVjgyVmmOHbjd > Dec 23 13:38:26 Talking about this :) I know most of you here don't propably car3 Dec 23 13:40:21 I mean I can help with that too :) Dec 23 13:45:36 ynezz: this https://paste.ubuntu.com/p/H8TFN2Wp57/ scratches the OCD itch I have about it (not actually tested yet) Dec 23 13:52:30 olmari: what's appservice and why is it kicking anybody? Dec 23 13:53:46 In a car, brb in about hour Dec 23 13:59:03 ldir: I dont know the surrounding code, so hard to comment, but that `INT_MAX >> 1` looks strange (why half the possible length?) Dec 23 14:00:15 because we're only capable of accepting 2^31 - we can't have anything that sets a sign bit. Dec 23 14:01:01 perhaps something like 'MAX_POSITIVE_INT' exists Dec 23 14:02:24 as jow pointed out ustream_consume() expects an int (which is a signed type) even though only positive values make sense. Dec 23 14:05:20 ldir: INT_MAX is already only 2^31, 2^32 would be UINT_MAX Dec 23 14:05:40 Ahh! Excellent Dec 23 14:07:55 ideally we should fuzz the functions in uhttpd/ustream which are getting inputs from possibly malicious sources and fix them appropriately, otherwise it just all looks like bandaid to me :] Dec 23 14:07:58 better https://paste.ubuntu.com/p/rrwxsGXbM4/ Dec 23 14:09:05 I don't think so Dec 23 14:09:27 it's a stream, so you don't know the length of the incoming data in advance Dec 23 14:11:00 so it's just another version of len < 0 check Dec 23 14:11:57 and looking in the ustream_consume, there is `s->r.data_bytes -= len; if (s->r.data_bytes < 0)` Dec 23 14:12:42 ldir: in other words, you're still able to crash uhttpd with some crafted input even with the jow's fix? Dec 23 14:15:00 I'm concerned that long int is bigger than int - so you could craft a decimal number that when it is truncated from say 64bit int to 32 bit signed int it represents a positive value Dec 23 14:15:28 right, but it's still valid content length Dec 23 14:16:21 but the underlying code shouldn't trust it anyway and use the allocated/available buffer len for safety checks Dec 23 14:16:59 the value 4294967296 for example is the first valid 33 bit value, but if truncated to 32 bit works out as zero Dec 23 14:17:22 so the text content-length would say 4294967296 but we would think they said '0' Dec 23 14:17:37 KanjiMonster: seems your tip about power supply did the trick! Dec 23 14:17:59 I didnt expect poor power to affect only the wifi, the router itself was fine (continous uptime) Dec 23 14:18:12 only the wifi was dropping.. changed power adapter and problem gone Dec 23 14:18:34 ldir: does it make sense to read 0 length content? Dec 23 14:18:50 ok, 4294967297 would say '1' Dec 23 14:21:12 I honestly don't know the answers, but it bothers me that we're taking a text value 'long' into a signed int without range checking. Dec 23 14:21:57 and simply checking for 'negative' in the end result signed int I don't think is quite good enough. Dec 23 14:23:07 there should really be a 'strtoint' Dec 23 14:24:54 abenz: haha, very nice. I wonder why you attribute my advice to him though :) Dec 23 14:26:14 PaulFertser: ops, indeed it was you. sorry about that, and thank you for the tip :) Dec 23 14:27:32 abenz: I'm glad it was surprisingly helpful. I just know that the most common problem with APs that worked for years is power supply capacitors degrading, and I can imagine how ripple can lead to all kinds of strange issues. Dec 23 14:31:17 PaulFertser: you know I was on the fence, thinking of buying a few aruba 303s (recently supported on OpenWrt trunk), I figured enterprise grade gear would last a long time, but once I checked ebay they are still quite pricey.. then replaced the power adapter following your tip (replaced it with a heavy transformer-type adapter, not switching like the factory) and the old tplink still seems to have juice left Dec 23 14:32:49 this particular box (4300) has been in continuous operation for many years Dec 23 14:33:30 abenz: I've already replaced a capacitor in a 50 Hz transformer adapter of my dlink, but it was more obvious, the device just started rebooting every now and then. Dec 23 14:34:59 abenz: the PSUs that come with most routers are horse dung! Dec 23 14:36:12 I see Dec 23 14:36:14 If you ever get reboots or strange issues that you think could be hardwair then PSU is first thing to check. It's the same with desktops. Dec 23 14:37:18 ynezz: next you'll get a bug report for failing to upload empty files ;) Dec 23 14:37:33 yup, in my particular case though the router itself was very stable (no reboots, lockups or oopses), the wifi would simply drop to an unbearable point.. that is why I didnt think of PSU at first, figured it would affect the whole unit Dec 23 14:38:01 I build computers for people and I will let them scrimp on most parts by the cheepest parts you can find, but I will never never put cheep power supplies in them. Dec 23 14:38:02 maybe not enough juice was flowing to enable the radios to transmit at full power or something Dec 23 14:39:29 yup, likewise, only seasonics :) Dec 23 14:42:33 A bloke came to me about 3 months ago and said his PC would not turn on. I looked at it and psu was nackered I said you need a new power supply. How mutch will that be he asked I said £65 for a good one. He said that he could get one from Overclockers for £20 I said that I did not think it a good thing to do. He did not listen! So about 2 weeks ago he rings me up and says my PC is not turning on again! Dec 23 14:44:07 So I go around to see the PC and he is not happy when I tell him that the PSU has gon again and this time it has taken your motherboard with it. Dec 23 14:44:17 ouch Dec 23 14:44:21 lesson learned? Dec 23 14:44:33 did he cough out the 65? Dec 23 14:44:58 He had to build a hole new PC because he was on a old AMD Dec 23 14:45:25 He could save his 3 drives and GTX970 Dec 23 14:45:31 O and case Dec 23 14:46:32 I could of got him a mobo of ebay, but he did not want to wate for shipping Dec 23 14:47:24 how old? bulldozer or phenom? and yes the recent jump in performance renders all prev gens obsolete Dec 23 14:47:31 It was good for me tho because I put £40 on top of the build price. Dec 23 14:47:37 * Tapper grins Dec 23 14:47:56 It was a FX6300 Dec 23 14:48:04 dozer Dec 23 14:48:39 heh not exactly, but if you see a linux install finish in literally a minute (complete with DE and assorted apps) then yup, prev gen looks slow Dec 23 14:48:52 I see Dec 23 14:50:44 he got the Ryzen 5 Six Core 2600 and a Gigabyte B450 AORUS M Dec 23 14:51:17 Which is way ahead of his old PC Dec 23 14:51:33 So worked out for the best in the end. Dec 23 14:51:48 Plus I got payed! Dec 23 14:56:45 Btw if you cant get a seasonic for a OK price super-flower- do good ones to. Dec 23 15:12:29 I see, will keep that in mind. cheers Dec 23 16:12:38 PaulFertser and others interested... Appservice is matrix-side bridge handler or bot if you wish, that is needed to make matrix users possible to be bridged on irc... all fine and dandy, but later days FN and matrix.org (the provider for freenode bridge) has some (too) tightened deals and behaviours Dec 23 16:12:59 I don't know exactly who pisses on whose cereals, but methods doing now is not feasible in real life Dec 23 16:13:49 problem is then that when an matrix user comes to this channel (as in matrix side) and if nto having presence made up in freenode for himself, then appservice will jsut blatantly kick user out oif this channel, mitrix side ofcourse Dec 23 16:14:42 I could have mile long more detailed description about this, but this is the gist... there are ways to migitate and make "appservice" be powerless Dec 23 16:18:34 olmari: but what you propose will basically remove control of irc channel ops over what individual matrix users can do here, right? Dec 23 16:21:21 not sure actually, but good question.. I've never needed to think it that way around.. from matrix side on irc channels I still have all the power I need, but hm... needs some testing on trash channel I guess Dec 23 16:22:15 In broad general I personally hope that FN and matrix would jsut stop screwing around and be positive towards eachothers... Dec 23 16:22:54 this is totally man-made issue, not technical... only on FN (with matrix, ofcourse) Dec 23 16:26:30 olmari: do you mean freenode servers somehow throttle/rate-limit connections from the matrix appservice? Dec 23 16:28:04 PaulFertser: they do, but the most f**kfaced part is that irc-bridging in matrix is so good that at many occasions peoples doesn't even realise or know they are using irc.. especially if icr-channel is "plumbed" (their term) to existing matrix-channel Dec 23 16:29:03 but new rules from FN requires matrixorg to apparently have registered nicks and this and that... well an plain matrix user who has never seen FN nickserv suddenly can't join for example this channel within matrix Dec 23 16:29:30 this sis still "just irc channel" so to speak, and it shows even from it matrix-side address Dec 23 16:29:57 olmari: are you sure that affects just matrix users? If channel mode allows only registered nicks then it does that for all he users. I can't see the point yet. Dec 23 16:30:06 I mean I can understand some of the concerns in FN and matrixorg, but in broad general this is not sustainable way to do things Dec 23 16:30:22 olmari: I can't yet see how that's matrix-specific at all. Dec 23 16:31:35 PaulFertser: if _channel_ requires regged nick in irc, that is channel thing then, and understandable... but in broad general FN seems to kick everyone who has not regged their nick on FN... and in broad general otherwise seamless bridging this breaks lots of stuff Dec 23 16:31:59 for example other channel infoscree using telgram gets kicked out from hacklab channel, because it does not have irc =) Dec 23 16:32:44 for a channel where irc is just another method from 5 of em, this is crap =) Dec 23 16:32:48 olmari: are you sure freenode really does that? Is that documented somewhere? E.g. this very channel is not +r so anyone can join it with unregistered nick. Dec 23 16:33:25 PaulFertser: it is exactly matrix org appservice that does it, within the stated new rules they made up with FN and themselves Dec 23 16:34:18 so it is exactly the appservice-bot that does it, which is made to do so, because of whatever stupidities FN and matrixorg made up Dec 23 16:34:36 ..and also only FN, other networks that are available behaves way better :) Dec 23 16:34:44 olmari: were there many attacks on freenode performed via the matrix before that? Dec 23 16:35:43 not more than your average big provider... but there is still oident and generally means to control spammy individuals and ofcourse the more deeper networking rules for core admins Dec 23 16:36:32 so it's not like stuff has to be exactly all of matri users or nothing at all :) Dec 23 16:37:53 olmari: requiring all matrix users to run identd would be even more problematic I guess ;) Dec 23 16:39:15 identd resides on the bridge Dec 23 16:39:19 not on users computers Dec 23 16:39:52 bridge is the thing handling matrix<->irc stuff, from matrix user perspective this is just anothet matrix-room Dec 23 16:40:54 now... I could run own bridge to, say, for finnish hacklab members, but currentl tech stuff makes it impractical too... because of the one thing that makes current bridging cool... user puppeting :) Dec 23 16:41:13 aka me being as "irc user olmari" here, while I have only mine matrix-client to use Dec 23 16:41:55 olmari: but if freenode doesn't trust matrix bridge then it doesn't matter if it runs identd or not, that's my point. If it was agreed that the bridge would be checking ident of end-users then it could make a difference. Dec 23 16:42:52 for irc perspective endpoint is the matixorg server Dec 23 16:44:40 I know matrixorg is massive as shit also, because they're default matrix server, but also because of said tech reasons they are practically the only one bridge provider for FN, because anything other will cause more problems.. which is again aanother tech issue what could be resolved but so far no general will-power to want it Dec 23 16:45:07 (aka 2 or more bridges on same room/channel would handle own users instead blindly puppeting everything) Dec 23 18:02:08 build #177 of ath79/tiny is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Ftiny/builds/177 Dec 23 19:35:40 ? Dec 23 19:35:46 ?? Dec 23 19:42:24 ?? Dec 23 19:42:59 ??? + ? What did I win? :) Dec 23 19:48:07 * tmn505 announces that olmari wins ticket to Matrix Dec 23 19:49:12 hmm.. ticket to home... I'll take as money pls ;D Dec 23 19:59:41 :) Dec 23 20:00:41 money aint nothing next to upstream first Dec 23 20:01:06 hey guys, I am thinking about porting generic kernel patches to 5.4 Dec 23 20:01:09 would that be appreciated? Dec 23 20:01:44 its a tough job and require plenty of XP and will see alot of feedback Dec 23 20:02:03 i have xp with kernel Dec 23 20:02:15 little less with the openwrt hack patches Dec 23 20:02:30 but i looked at 4.19 Dec 23 20:02:36 hehe, that is the detail you'll need to look into Dec 23 20:02:45 and they do not seem compilated Dec 23 20:03:00 so I think the worst part is to just do the fucking work Dec 23 20:03:16 as usual ... Dec 23 20:03:51 upstream 5.4 has support for turris mox :) Dec 23 20:04:13 * tmn505 sends 01101101 01101111 01101110 01100101 01111001 to the Matrix Dec 23 20:05:39 tmn505: ''.join([chr(int(i,2)) for i in '01101101 01101111 01101110 01100101 01111001'.split(' ')]) Dec 23 20:06:53 kab-el: thanks that's better. BTW xback has WIP tree for 5.4, You can base it. https://git.openwrt.org/?p=openwrt/staging/xback.git;a=summary Dec 23 20:07:18 *base on it. Dec 23 20:09:37 hmm Dec 23 21:04:50 kab-el: blogic: there is 5.4 support already in xback's stging tree Dec 23 21:06:45 kab-el: https://git.openwrt.org/?p=openwrt/staging/xback.git;a=shortlog;h=refs/heads/master Dec 23 22:21:17 build #65 of ramips/rt305x is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt305x/builds/65 blamelist: Roman Yeryomin , Rafa? Mi?ecki , Yousong Zhou , Hauke Mehrtens , Jo-Philipp Wich **** ENDING LOGGING AT Tue Dec 24 02:59:57 2019