03:59 <gch981213> Znevna: "Here are some iptables modules from unknown sources, why not take it?" :P

04:02 <gch981213> Besides that I don't see how full-cone nat is useful nowadays. ISPs perform their own NAT on IPv4 anyway, which is something end-users can't control.

05:14 <owrt-snap-builds> Build [#795](https://buildbot.openwrt.org/master/images/#builders/23/builds/795) of `mpc85xx/p2020` failed.

05:39 <Znevna> gch981213: some gamers are crying over 'full cone nat', obviously :P and then some expert came with 'hey masquerade sucks, you have to use netmap problem solved' ... meh

05:39 <Znevna> anyway, morning

06:04 <gch981213> Znevna: Morning :)

06:14 <Znevna> I'm guessing that something that requires this or something similar will never get accepted, right? https://github.com/openwrt/openwrt/pull/11806#issuecomment-1437030658

09:35 <neggles> > Not addressing self-hostingness here [snip]. I'm addressing limited official support for within-OpenWrt development.

09:35 <neggles> buddy that's self-hosting

09:39 <neggles> (or at least it's a slippery slope to that)

09:41 <neggles> yeesh, "full-cone NAT" or "how to completely destroy the passive security benefit you get from NAT"

09:41 <neggles> just go enable UPnP if you want shit on the internet to be able to directly hit your systems so bad

09:52 <stintel> =)

09:59 <robimarko> neggles: But UPnP makes gaming go wroom

10:00 <neggles> yeah and it's *less* bad than That One Kind Of NAT

10:00 <neggles> at least it only exposes *some* things

10:01 <neggles> still blows my mind that in this day and age, the current year, the year 2023, sony/nintendo/microsoft/etc are too goddamn cheap to pay for some fkn relay hosts

10:03 <neggles> also. c'mon. if you're claiming to be smart enough to know about different NAT types, you also know how to add a custom outbound NAT rule for your $console/etc with a static port mapping.

10:05 <neggles> OpenWrt can't save you from making stupid decisions, but it *can* make sure that when you get #rekt you can't blame it :P

10:15 <robimarko> Well, there is a lot of expectations that its going to simplify things to a on/off tick and prevent you from doing stupid stuff

10:17 <oliv3r[m]> so I"ve built a new debian container (from scratch) into a new openwrt worktree (ergo, from scratch) (to test those 7z patches) and I still have 1 (sometimes 2) 100% CPU usage faked running. With the alpine container, I get 20 or so faked's. I'm sure my system is very magical, or docker is to blame, in which case the CI suffers as well? It all works, just build times are huge (which could affect the CI).

10:17 <oliv3r[m]> I'm so supprised nobody else is having this... My host is arch linux, but for docker that shouldn't matter?

10:31 <oliv3r[m]> ok so the debian container also creates multiple faked's, just not as many as alpine for some weird reason; but I'm not caring enough to find that part out :)

10:32 <neggles> robimarko: if you need it to be as simple as a checkbox, you don't understand the security implications, and IMO it's not in OpenWrt's best interests to let you shoot yourself in the foot like that

10:33 <neggles> way too easy for someone to get pwned, then blame the existence of said checkbox for them getting pwned

10:37 <Znevna> oliv3r[m]: regarding your comment on the ax53u PR above, using concat mtd will still require an ubi resize and we'll end up with the same bootloop unless I'm missing something

10:37 <oliv3r[m]> why would you have to resize anything?

10:38 <Znevna> that's the point of the PR

10:38 <oliv3r[m]> i think all you do is take the partition phandles and concat them :)

10:38 <oliv3r[m]> but I'll admit, I know nothing of context, just offered some options :D

10:38 <Znevna> almost half of the nand size is unused

10:39 <Znevna> and since the device was added as that from the start it's pretty hard to resize it along the way :P

10:40 <robimarko> neggles: I agree fully

10:44 <oliv3r[m]> then I'd go with my suggestion of having a 'vendor' dts, and a referred' dts :) which is what I did, but then I had the 'luxury' that the vendor DTS does define two firmware partitions that pretty much fill the nand, so the concattenated partitions solve that; anyway, just some food for thought

10:44 <oliv3r[m]> could be that the unused flash is used for wear leveling, but that only works for eMMC i suppose ...

10:46 <Znevna> the 2nd partition is used as a backup by the bootloader, but it doesn't boot from it

10:47 <Znevna> in case the first partition goes bad it check the data from the 2nd partition, and copies it to the first partition and tries to boot again from the first partition

10:47 <Znevna> so pretty much wasted space

10:49 <gch981213> Znevna: Are you brave enough to make a ubootmod for it?

10:50 <Znevna> for personal use, sure, but what are we modding? :P

10:50 <gch981213> Er..Maybe not "brave enough" but "have the right equipment and skill to recover from a brick" :P

10:50 <gch981213> Znevna: That Asus router you are talking about

10:50 <Znevna> I don't have a nand flasher

10:50 <Znevna> so if I brick it I'm screwed :P

10:50 <Znevna> the bootloader is decent tho

10:58 <Znevna> it doesn't have ubi support :P but decent otherwise

11:14 <oliv3r[m]> Znevna: I get your issue now, the UBI (or any partition) will need to be resized; I've been in initramfs land for 6 months now; so I didn't think of the upgrade scenario's :) I'd do a second image though; sometimes users like to have 'openwrt + backup image'

11:15 <oliv3r[m]> <Znevna> "in case the first partition goes..." <- btw, that's just stupid, just boot the second partition! but emphasises my point above; user can 'restore' factory image that way

11:16 <Znevna> that's completely automated without user intervention

12:16 <damex> any idea if i can update banana pi r3 openwrt media that already has openwrt copy from already booted system? it has 32mb NOR, 128mb NAND, 8gb EMMC. i boot from EMMC and keep NAND+NOR as a backup

12:17 <damex> so i want to update 'backup' that is installed on NOR and NAND while i booted from EMMC (and everything works)

13:19 <oliv3r[m]> automatically or manually? manually you can just dd those (nand might need some special way) and then after eMMC update; compare and restore if needed; otherwise, you can always 'dd' over the eMMC

13:19 <oliv3r[m]> but what makes you suspect the openwrt upgrade touches the nand/nor? (I expect that the nor holds the bootloader only?)

14:06 <nbd> dhewg:

14:06 <nbd> ping

14:06 <nbd> could you please test the mesh fast xmit patch that i just pushed to my staging tree

14:13 <dhewg> nbd: sure, will do

14:13 <dhewg> just the last one on top?

14:22 <nbd> yes

15:21 <damex> oliv3r[m]: i would expect to do it manually. NR has two step bootloader only and are you sure about dd? i am using emmc and upgrades could be done but nand could be just dd over nand and that's it? how about data?

15:21 <damex> not sure if i can do sysupgrade from emmcs to upgrade emmc but we will see. reboot and upgrade could be done for sure.

15:22 <damex> i am not using nand for anything beside 'reserved'/'spare' disk with bootable openwrt so maybe dd is fine...

17:50 <dhewg> nbd: both sides updated. works so far, I'll let you know if a wan reconnect breaks it again

18:09 <barhom> Is it possible to convert an existing uci config to a list of "uci set" commands ?

18:51 <oliv3r[m]> damex: what are these devices used for?what are they doing with NAND normally? What IS on the SPI-NOR? nand can't reliably be copied, because of the whole wearleveling, well you can copy it, but there's some do's and don't and gotcha's that I don't remember. dd on the nand block device should be fine, nand on the raw flash (like connecting a programming header to the chip) is not a good idea.

18:51 <oliv3r[m]> barhom: uci show > file.txt; and then some sed magic? :)

18:52 <barhom> oliv3r: that would some nice magix ;)

18:55 <tmn505> anyone having schematic for Unielec U7623? I want to enable the LTE slot. I guess it would be similar to BananaPi R2 but I'm not sure about GPIO number, so it would be really helpful before I ask Unielec or would start to poke at GPIOs.

18:59 <damex> oliv3r[m]: well, it is just a arm64 box doing some 'compute' with openwrt. i don't do anything with NAND except keeping a backup of openwrt for emergency. SPI-NOR is used for storing an emergency bootloader.

19:00 <damex> oliv3r[m]: i won't be connecting programming header to a chip here - that's for sure.

23:59 <owrt-snap-builds> Build [#796](https://buildbot.openwrt.org/master/images/#builders/23/builds/796) of `mpc85xx/p2020` completed successfully.