danitool has quit [Remote host closed the connection]
ccole has joined #openwrt-devel
ccole has quit [Quit: leaving]
minimal has quit [Quit: Leaving]
fakuivan_ has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
kenny has quit [Quit: WeeChat 3.8]
kenny has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
dangole has quit [Ping timeout: 480 seconds]
<gch981213> Znevna: "Here are some iptables modules from unknown sources, why not take it?" :P
<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.
hanetzer2 has joined #openwrt-devel
hanetzer1 has quit [Ping timeout: 480 seconds]
tlj_ is now known as tlj
<owrt-snap-builds> Build [#795](https://buildbot.openwrt.org/master/images/#builders/23/builds/795) of `mpc85xx/p2020` failed.
<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
<Znevna> anyway, morning
<gch981213> Znevna: Morning :)
<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
KGB-2 has quit [Remote host closed the connection]
KGB-2 has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
torv has quit [Remote host closed the connection]
torv_ has joined #openwrt-devel
valku has quit [Quit: valku]
goliath has joined #openwrt-devel
krch_ has joined #openwrt-devel
krch_ has quit [Remote host closed the connection]
danitool has joined #openwrt-devel
<neggles> > Not addressing self-hostingness here [snip]. I'm addressing limited official support for within-OpenWrt development.
<neggles> buddy that's self-hosting
<neggles> (or at least it's a slippery slope to that)
<neggles> yeesh, "full-cone NAT" or "how to completely destroy the passive security benefit you get from NAT"
robimarko has joined #openwrt-devel
<neggles> just go enable UPnP if you want shit on the internet to be able to directly hit your systems so bad
<stintel> =)
<robimarko> neggles: But UPnP makes gaming go wroom
<neggles> yeah and it's *less* bad than That One Kind Of NAT
<neggles> at least it only exposes *some* things
<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
<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.
<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
<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
<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).
<oliv3r[m]> I'm so supprised nobody else is having this... My host is arch linux, but for docker that shouldn't matter?
<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 :)
<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
<neggles> way too easy for someone to get pwned, then blame the existence of said checkbox for them getting pwned
<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
<oliv3r[m]> why would you have to resize anything?
<Znevna> that's the point of the PR
<oliv3r[m]> i think all you do is take the partition phandles and concat them :)
<oliv3r[m]> but I'll admit, I know nothing of context, just offered some options :D
<Znevna> almost half of the nand size is unused
<Znevna> and since the device was added as that from the start it's pretty hard to resize it along the way :P
<robimarko> neggles: I agree fully
<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
<oliv3r[m]> could be that the unused flash is used for wear leveling, but that only works for eMMC i suppose ...
<Znevna> the 2nd partition is used as a backup by the bootloader, but it doesn't boot from it
<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
<Znevna> so pretty much wasted space
<gch981213> Znevna: Are you brave enough to make a ubootmod for it?
<Znevna> for personal use, sure, but what are we modding? :P
<gch981213> Er..Maybe not "brave enough" but "have the right equipment and skill to recover from a brick" :P
<gch981213> Znevna: That Asus router you are talking about
<Znevna> I don't have a nand flasher
<Znevna> so if I brick it I'm screwed :P
<Znevna> the bootloader is decent tho
SherlockDomes has quit [Quit: Nettalk6 - www.ntalk.de]
robimarko has quit [Read error: Connection reset by peer]
<Znevna> it doesn't have ubi support :P but decent otherwise
robimarko has joined #openwrt-devel
<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'
<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
<Znevna> that's completely automated without user intervention
srslypascal has quit [Ping timeout: 480 seconds]
bluew has quit [Ping timeout: 480 seconds]
<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
<damex> so i want to update 'backup' that is installed on NOR and NAND while i booted from EMMC (and everything works)
Ryncewynd has joined #openwrt-devel
dangole has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
<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
<oliv3r[m]> but what makes you suspect the openwrt upgrade touches the nand/nor? (I expect that the nor holds the bootloader only?)
minimal has joined #openwrt-devel
aiyion_ has joined #openwrt-devel
aiyion has quit [Ping timeout: 480 seconds]
gtk2 has quit [Ping timeout: 480 seconds]
<nbd> dhewg:
<nbd> ping
<nbd> could you please test the mesh fast xmit patch that i just pushed to my staging tree
<dhewg> nbd: sure, will do
<dhewg> just the last one on top?
valku has joined #openwrt-devel
<nbd> yes
gtk2 has joined #openwrt-devel
<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?
<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.
<damex> i am not using nand for anything beside 'reserved'/'spare' disk with bootable openwrt so maybe dd is fine...
goliath has quit [Quit: SIGSEGV]
gladiac has joined #openwrt-devel
Slimey_ has joined #openwrt-devel
Slimey has quit [Ping timeout: 480 seconds]
Slimey_ is now known as Slimey
<dhewg> nbd: both sides updated. works so far, I'll let you know if a wan reconnect breaks it again
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<barhom> Is it possible to convert an existing uci config to a list of "uci set" commands ?
<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.
<oliv3r[m]> barhom: uci show > file.txt; and then some sed magic? :)
<barhom> oliv3r: that would some nice magix ;)
Borromini has joined #openwrt-devel
<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.
valku has quit [Quit: valku]
<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.
<damex> oliv3r[m]: i won't be connecting programming header to a chip here - that's for sure.
minimal has quit [Quit: Leaving]
gladiac has quit [Quit: k thx bye]
Borromini has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
Borromini has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
Ryncewynd has quit [Quit: Leaving]
maciekb has quit [Quit: bye]
gch9812139 has joined #openwrt-devel
maciekb has joined #openwrt-devel
gch981213 has quit [Ping timeout: 480 seconds]
gch9812139 is now known as gch981213
bluew has joined #openwrt-devel
goliath has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
T-Bone has joined #openwrt-devel
f00b4r0 has quit [Ping timeout: 480 seconds]
fakuivan has quit [Remote host closed the connection]
aiyion_ has quit [Remote host closed the connection]
aiyion_ has joined #openwrt-devel
fakuivan has joined #openwrt-devel
gromero has quit [Remote host closed the connection]
gromero has joined #openwrt-devel
philipp64 has quit [Remote host closed the connection]
Tapper has quit [Ping timeout: 480 seconds]
madwoota has quit [Ping timeout: 480 seconds]
madwoota has joined #openwrt-devel
<owrt-snap-builds> Build [#796](https://buildbot.openwrt.org/master/images/#builders/23/builds/796) of `mpc85xx/p2020` completed successfully.