**** BEGIN LOGGING AT Mon Jan 27 02:59:58 2020 Jan 27 03:40:49 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Jan 27 05:41:39 morning Jan 27 07:36:56 morning Jan 27 09:02:09 morning Jan 27 09:02:57 * ldir feels very urgh - series of very late nights/mornings due to work Jan 27 09:04:01 is jow the firewall expert in the house? Jan 27 09:04:49 Question on syn flood protection option Jan 27 10:48:38 ynezz: I flashed an esphome firmware on the nodemcu I ordered for luftdaten.info instead. added that in my home-assistant (just add the IP of the nodemcu and it grabs everything configured in esphome automatically), and created a rest_command and automation in home-assistant that pushes the values to luftdaten.info Jan 27 10:49:24 I want that data in my home-assistant anyway, and esphome on the nodemcu gives much more flexibility (I'm already using a couple of esp32s like that too) Jan 27 10:49:45 think I like this better than having home-assistant grab the data from the nodemcu running luftdaten.info firmware Jan 27 10:56:03 jow: thanks for all your efforts on luci client side conversion Jan 27 11:03:01 ooooh "WARNING: Applying padding in /Users/kevin/wrt/bin/packages/x86_64/luci/Packages to workaround usign SHA-512 bug!" Jan 27 13:09:33 ldir: its a mitigation for an old bug in usign Jan 27 13:33:20 ldir: now I'm here Jan 27 13:40:03 You know the syn flood protection in firewall3 - is this intended to be syn flood protection for the router only or protection for internal hosts as well? Jan 27 13:42:25 blogic: ah ok, thanks Jan 27 13:42:27 ldir joh This something I would like to know to. Plus what is the Drop invalid packets fore? Jan 27 13:43:42 Does it drop packets with no TTL? Jan 27 13:45:37 it drops packets which are considered invalid by conntrack Jan 27 13:46:01 martians, asynchroneously routed ones etc. Jan 27 13:46:19 AFAIK the state referred to is the conntrack aka firewall state - which can be new, established, related or invalid. A packet associated with an invalid state in conntrack is a real 'huh?' type state...so best to throw them away Jan 27 13:46:19 ldir: afair it only evers was intended for the router itself Jan 27 13:46:41 Tapper: as ever jow says it better Jan 27 13:46:53 joh sho it should be checked? Jan 27 13:47:01 so* Jan 27 13:48:15 Tapper: out of 10 million packets I have a total of 200 'invalid state' related drops - I'm not worried Jan 27 13:48:52 o that's is not menny. Jan 27 13:49:01 that is* Jan 27 13:49:54 jow: ok, thanks. If I wanted to do so something like https://paste.ubuntu.com/p/ztJHYGsPRq/ should do I think? Jan 27 13:51:19 ldir: yeah, I guess so Jan 27 13:54:36 thank you Jan 27 13:56:15 hi, I was trying to build the openspot-19.07 branch from github with glibc enabled as opposed to the default musl libc but that fails in multiple spectacular ways. libpcap for tcpdump and libuhttpd refuse to build. Jan 27 13:58:22 we don't really support glibc for anything other then arc770 and archs38 Jan 27 13:59:28 hmm, I was building with it for the erx platform since that thing has plenty of flash memory and I'm using it with a go application Jan 27 14:00:46 Hello! Jan 27 14:01:36 I almost never worked adding a device with NAND flash Jan 27 14:02:07 How is Openwrt aware of using an ubi partition for rootfs data? Jan 27 14:02:33 using fixed partitions and an "ubi" partition is enough? Jan 27 14:04:33 on the "ubi" partition should I flash an ubinized rootfs , right? Jan 27 15:11:32 ok the "ubi" partition apparently it works ok Jan 27 15:11:47 but on every boot I get "[ 10.655134] UBIFS (ubi0:1): recovery needed" Jan 27 15:11:56 not sure if this is normal Jan 27 16:56:00 * enyc asks nicely if any -dev has clue, we were discussing Lantiq VDSL and PPPoE MTU's etc with jow before... Jan 27 16:56:28 I ab getting impression Lantiq X-way openwrt 19.07 is simply not retrying ppp properly once in a failed state, but not onsite to check Jan 27 16:56:49 would like to know what debugging to cellect before rebooting/replacing/etc BT HH v5 type A running OpenWRT 19.07 Jan 27 18:50:09 I would like to apply: https://patchwork.ozlabs.org/patch/1229467/ to 19.07 before the release Jan 27 18:50:15 Release date of 19.07 is 10.1.2019? Really? Not 2020? Jan 27 18:50:32 it is working fine on my device, but I will do some more testing Jan 27 18:50:38 rubberduck: yes it should be 2020 Jan 27 18:50:53 Maybe correcting on the website will be cool Jan 27 18:51:19 rubberduck: where did you find the wrong date? Jan 27 18:51:45 http://downloads.openwrt.org/ Jan 27 18:52:09 Hauke: I wonder whether it's really worth the effort to release 18.06.7? There haven't been to many changes ... Jan 27 18:52:55 to -> too Jan 27 18:53:04 adrianschmutzler: I would like to add these missing security fixes: https://patchwork.ozlabs.org/patch/1229386/ Jan 27 18:53:19 and there is a diffeernt security problem Jan 27 18:53:57 Hauke: Ah, I didn't realize this, never mind. Thanks for taking care! Jan 27 18:54:02 Same for 18.06.06. Same wrong Date Jan 27 18:54:28 jow: can you please fix the dates on http://downloads.openwrt.org/ Jan 27 18:54:34 it should be 2020 and not 2019 Jan 27 18:54:39 I do not have access to this page Jan 27 18:55:01 Who has? Will you contact the responsible, please? Jan 27 18:55:19 he already has (jow) Jan 27 18:56:06 Thx Jan 27 19:43:35 are there critical issues which need to be adressed? i'm wondering about the short time between the minor releases... **** ENDING LOGGING AT Tue Jan 28 02:59:57 2020