<rsalvaterra>
In 1), they talk about recursive DNS. In point 12), they talk about lawful filtering. How are they going to achieve this without completely independent root servers, which would go totally against what DNS is?
<dwmw2_gone>
oh, I hadn't caught the filtering bit
<karlp>
I mena, I don't see what "transparent" filtering would be, but it's stricly opt in, and that's clearly there for appeasement, so what's the big deal with having a dns service?
<karlp>
oh, I was looking at filtering in point 6
<karlp>
point 12 looks crap, yeah :)
<Habbie>
rsalvaterra, what do root servers have to do with it?
<rsalvaterra>
Habbie: Root servers are supposed to be global, unless I have no clue of how DNS works.
<Habbie>
they are
<Habbie>
but i don't see how that is relevant to point 12
<rsalvaterra>
Habbie: How can you have two root servers returing different replies to the exact same query? That's what filtering implies.
<Habbie>
the document, as far as i know, is about recursive servers, not root servers
<Habbie>
if i could figure out how you're confusing the two i could probably help
<rsalvaterra>
Habbie: A recursive query could end up in a root server, no?
<Habbie>
a recursive query could cause a query to be sent to a root server, as part of the recursive process
<Habbie>
(not trying to be more pedantic than necessary here)
<rsalvaterra>
Right.
rua has quit [Quit: Leaving.]
<Habbie>
a query for a forbidden name would, presumably, not cause any queries to go out from the recursive resolver to the root servers or any other authoritative servers
<rsalvaterra>
Oh, I see. They'd be blocked before recursing, of course.
<Habbie>
yes, or in some cases, blocked because of a name encountered during recursing, in a CNAME or in some NS name
<Habbie>
but all of that happens in the recursive resolver
<rsalvaterra>
Anyway, censorship == bad.
<Habbie>
i have a slightly more nuanced view, but also this does not look like a service that will suddenly become mandatory for all Europeans
<rsalvaterra>
Were it mandatory, how would they enforce it? :)
<Habbie>
I wouldn't know :)
<Habbie>
most recursive resolvers do some filtering/censorship today
<Habbie>
and mostly that is considered good
<Habbie>
known malware sites, etc.
<Habbie>
(but there are always risks)
<Habbie>
quad9 recently blocked some pastebin because there was a bunch of bad stuff on it
<rsalvaterra>
I use filtering DNS servers (AdGuard), but that's my personal choice, nobody imposed it to me. :)
<Habbie>
yeah
<Habbie>
that fits my more nuanced view :)
<rsalvaterra>
Heh… Linux 5.10.93 is out. I'm doing the bump, but this release is kind of boring. :P
<rsalvaterra>
As for malware, assuming there are no remote exploits (big assumption, probably) and the umask isn't completely bonkers, I can't see how to easily infect a Linux machine.
champtar has joined #openwrt-devel
rsalvaterra has quit [Quit: rsalvaterra]
<champtar>
Hi all, who should I ping to check all the buildbot builder docker image version ? cryptodev-linux failure in openwrt/packages CI could be caused by outdated builder image not having libelf-dev
<neggles>
rsalvaterra / Habbie / karlp: australian ISPs are already forced to do this by the government, there's a list of banned domains that all either resolve to nothing or to a "hey sorry this is blocked by <link to piece of legislation> take it up with your local MP/senator"
<Habbie>
yes, various european countries have such lists too
<neggles>
everyone just uses google/cloudflare/quad9 DNS instead
<neggles>
at least 1) makes it sound like they know they can't possibly force people to use it & are hoping to make it good enough to be worth using
<neggles>
or rather, good enough that people will want to use it
* neggles
is still yet to see a reason to use any recursive DNS resolver other than one.one.one.one
<neggles>
point being, I doubt 12) intends to implement anything more than that - though presumably with every country's block list merged together, so ISPs don't have to manage/handle it themselves
<karlp>
neggles: it's more the "transparent" part of it that is curious, like, "what is the content of the list, how did it get there, what are the procedures for removal" for the "family content filtering" section 6, more than the "piracy" section 12
<Habbie>
quad9 is currently fighting a court order to block certain names in Germany
dangole has joined #openwrt-devel
<neggles>
karlp: ah yes, true - 5) probably plays into that as well, cloudflare already offers a similar service as a component of Cloudflare for Teams (formerly CloudFlare Access / CloudFlare Gateway)
<neggles>
custom block page, options to allow some or all users to click through, details of why it's blocked, etc
<rsalvaterra>
karlp: That's the problem. Here, for example, it's completely opaque. People only know a site has been blocked after the fact, when trying to access it. There's no official list of blocked hosts.
<neggles>
most "NGFW" appliances and their friends have been doing this for ages
<Habbie>
block pages are hard in the age of https, though
victhor has quit [Ping timeout: 480 seconds]
<rsalvaterra>
And the blocking is purely administrative. There are no courts involved.
<neggles>
rsalvaterra: ...that does present some interesting problems, yeah, it's not like you can have an official list of "sites that are blocked due to content involving exploitation of minors"
<Habbie>
those lists often even go pre-hashed to the ISPs
<neggles>
we do at least require a court order
<karlp>
neggles: sure, I've helped setup fortinet stuff for an ISP, but it's that "transparent" wording that's curious
<rsalvaterra>
neggles: You wouldn't have to be so specific… "illegal content" would suffice.
<neggles>
true, though IMO DNS blocking is a waste of time on that sort of website - shut the damn site down
<neggles>
easier said than done, sure
<rsalvaterra>
And DoH/DoT clients/servers should be running to implement ECH…
<neggles>
but in the context of 6) (parental controls) I imagine it'd be something like "install this root CA cert so our block pages work" + some sort of web portal for parents' to use to view logs / block reasons / add temporary exclusions
<rsalvaterra>
neggles: That worked great in Kazakhstan… :P
<neggles>
or perhaps "install this companion app of ours on your kid's PC so they get a popup instead of just an error"
<neggles>
rsalvaterra: I didn't say it was a good idea :P
<neggles>
we tried doing the "ISP-level content filtering" thing here circa 2008-2009
<neggles>
It Did Not Go Down Very Well And The Trial Deployment Was A Catastrophic Failure
<neggles>
turns out you need a *lot* of *very* expensive firewall appliance to filter an entire ISP customer base
<neggles>
gah! I had this APX530 booting from NAND, mounting the FIT image as a ubiblock, and attaching the rootfs part just fine late last night
<neggles>
...then I closed the vscode tab with the log & what cmdline/image generation params I used and didn't save it
victhor has joined #openwrt-devel
zatwai has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<nitroshift>
since stintel is still busy snorring, i'll just ask: is remote sysupgrading from fw3 to firewall4 safe?
zatwai has joined #openwrt-devel
<nitroshift>
i know they *should* be compatible, but better safe than sorry
<rsalvaterra>
nitroshift: I wouldn't risk it. It's a big change.
<nitroshift>
rsalvaterra, thought so
<nitroshift>
0/
<stintel>
it should be safe, but I would recommend initial attempt not remote :)
<rsalvaterra>
Especially if you have custom firewall rules.
<nitroshift>
good morning, stintel :p
<stintel>
but /etc/firewall.user doesn't work
<nitroshift>
rsalvaterra, i only have an accept rule
<nitroshift>
and it's not in firewall.user
<neggles>
is remote sysupgrading *ever* really safe?
<nitroshift>
my fingers are itchy :))
<rsalvaterra>
neggles: Is upgrading ever really safe? #yolo :P
<nitroshift>
neggles, i left myself without ssh tunnels before...
<neggles>
rsalvaterra: i'd say it's safe if you're upgrading a dual-image system you're right next to (and you have an appropriate console cable) :P but, yea
pmelange has joined #openwrt-devel
<neggles>
nitroshift: assume it goes horribly wrong and you're locked out of everything. how big of a problem would that be?
<stintel>
nitroshift: afternoon, had a meeting :)
<nitroshift>
neggles, lock myself out of my ssh tunnels / movie servers
<nitroshift>
so basically nothing left to do but play solitaire
<rsalvaterra>
Oh, no. Not the movies.
* nitroshift
pats rsalvaterra on the back
<neggles>
anything but the movies!
<neggles>
so... annoying but not really a big deal? not going to be down for days until you can get to the thing?
<nitroshift>
neggles, no
<neggles>
then, as rsalvaterra said, #yolo
<nitroshift>
rofl
<nitroshift>
here goes nothing. if i ain't coming back, you know why
<nitroshift>
:p
<stintel>
:P
<ldir>
nitro who?
<rsalvaterra>
Please, don't take that as an advice. I do horrible things in my builds, I'm a terrible example to follow. xD
<stintel>
there's a reason I run a HA setup :)
nitroshift has quit [Remote host closed the connection]
<stintel>
I should get some extra USB to serial adapters so I can plug the serial console of main into backup and vice versa
<stintel>
now that I have two routers with USB ports
<stintel>
that would allow me to recover remotely using serial and tftp
nitroshift has joined #openwrt-devel
<stintel>
:)
<neggles>
he returns!
<neggles>
(he?)
<stintel>
they! :P
<nitroshift>
neggles, yeah, he
<stintel>
to not offend anyone
<stintel>
in this snowflake world :P
<neggles>
I am getting better at defaulting to using they
<neggles>
lotta years of habit to break
<nitroshift>
stintel, come on, you know me, i can't be "they", i'm too thin
<neggles>
(but IMO if you flip out because someone uses the incorrect pronoun on you once or twice, you're the bigger asshole)
<neggles>
nitroshift: so it didn't explode then? :P
<nitroshift>
neggles, apparently not
* neggles
dances
<nitroshift>
stintel, in luci there's no more "enable software offload" under network / firewall
<nitroshift>
though the package is installed
<nitroshift>
(and its setting is present in /etc/config/firewall
<nitroshift>
)
<stintel>
no idea, I don't know much about luci, I followed jow's suggestions for basic firewall4 support
<nitroshift>
well, it seems to be working
<nitroshift>
brb, cigarette
<neggles>
(what does software offload actually do?)
<stintel>
iptables/nftables flow offloading
<neggles>
so what mikrotik calls 'fasttrack'
<neggles>
neat
<stintel>
noticeable performance improvement
<neggles>
but at the expense of bypassing several of the more advanced features, iirc?
<stintel>
I've been using it with sqm and now with qosify
<neggles>
features I recklessly abuse to do horrible things that should not be allowed
<neggles>
ooh, it doesn't bypass queueing? *nice*
<rsalvaterra>
stintel: Wait, SQM with NAT lookups is playing nice with flow offloading?
<rsalvaterra>
That would be news to me…
<stintel>
I've always used it like that ¯\_(ツ)_/¯
<rsalvaterra>
It's… not a good idea… :/
<stintel>
why not?
<rsalvaterra>
Speaking of SQM, we really need a way to configure pause frames in devices (netifd?). Ethernet flow control interferes with SQM, we should do SQM only.
<rsalvaterra>
stintel: Well, the point of flow offloading is to avoid doing NAT lookups… and SQM does NAT lookups in order to identify and isolate flows. :P
<rsalvaterra>
(Well, at least the SQM which matters the most, cake.)
<rsalvaterra>
I've been looking into how to implement support for enabling/disabling rx/tx pause frames in netifd, but it's a bit more than I can chew without help.
<stintel>
rsalvaterra: /etc/rc.local to the rescue :P
<dangole>
rsalvaterra: with openwrt becoming more common also on switch devices, we'll need to teach netifd more of the ethtool stuff, for exactly those things (flow control, speed, duplex, eee, ... settings)...
eduardo010174 has joined #openwrt-devel
nlowe has joined #openwrt-devel
<rsalvaterra>
stintel: Race conditions. Doesn't always work. Been there, since that. ;)
<stintel>
rsalvaterra: /etc/hotplug.d should be more reliable I guess
<rsalvaterra>
Still, having ethtool just to do that is a bit overkill. We need to teach netifd new (switch) tricks, like dangole said. :)
<stintel>
ethtool is part of my default packages :)
<neggles>
same
<neggles>
does netifd know how to turn EEE on/off?
<rsalvaterra>
Ditto. Begrudgingly. :P
<dangole>
rsalvaterra: i'm not saying to let netifd use the 'ethtool' executable, but rather teach it to use netlink or whatever kernel API is used for that directly.
<rsalvaterra>
dangole: Yes, of course, that's what I meant too when I said I'd been looking into it. :)
<rsalvaterra>
However, that's all still a bit mystery to me.
<rsalvaterra>
*git
<rsalvaterra>
*big
<rsalvaterra>
(WTF is wrong with my typing?)
<neggles>
third time's the charm :P
<neggles>
I still can't get the fit partition parser to trigger, sigh...
<dangole>
rsalvaterra: probably it really just went unnoticed as we lack pstore/ramoops on MT7621, so users didn't notice...
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<neggles>
`[ 11.922313] bl▒[ 11.928265] List of all partitions:`
<neggles>
it does not help troubleshooting that my kernel appears to eat its own output when the problem happens
<dwmw2_gone>
dangole: I can probably set you up with remote access to this board if it's useful. It's got remotely switchable power, and the serial port and USB flash are connected to a box under my desk
<dwmw2_gone>
In the meantime, want to do the uncontroversial parts first? The U-Boot update can go in as it is, right?
<dangole>
dwmw2_gone: it could, but would require some conflict-fixing as the commit modifies the patches on top of the release which are also modified by previous commits. and it did require some fixing-up of mtk patchset because things have changed upstream, so wasn't just a simple version bump...
Tapper has quit [Ping timeout: 480 seconds]
<dangole>
dwmw2_gone: if you can give me remote access to the board i believe it would take me less than a day to resolve the remaining issues. i would need serial line and also a way to use SP Flash Tool (via USB-over-IP? I got fiber here, so it could work...) or gretap to the ethernet port, so i can load stuff to U-Boot (without having the run the TFTP server on the open internet...).
<dwmw2_gone>
I can just let you SSH into the box under my desk. The serial port and the SP Flash tool can run on there. You can even build there (or not, as you see fit)
<dwmw2_gone>
The U7623 itself has public IPv6 and even Legacy IP on its WAN port.
<dangole>
dwmw2_gone: that sounds great, if easily doable. just worried i'm burning too much of your time for this
<dwmw2_gone>
well, I bought this box *specifically* to burn time on cleaning up the mt762x image build crap. Got part way through it and got distracted. You're finishing the job for me :)
<jow>
rsalvaterra: LuCI checks the availability of flow offloading via fs.access("/sys/module/xt_FLOWOFFLOAD/refcnt")
<jow>
rsalvaterra: this obviously won't work for nft. I wonder if we should simply assume its presence in case of fw4 support or whether there's an alternative to query
<neggles>
dangole: for reference, u-boot passing 'ubi.mtd=rootfs' in bootargs does indeed prevent the 'ubi' partition from automounting, even if 'rootfs' doesn't exist
<neggles>
and apparently passing `ubi.mtd=ubi` later in the same cmdline doesn't override/replace the earlier one u-boot put in there
<neggles>
s/automounting/autoattaching
Tapper has joined #openwrt-devel
<rsalvaterra>
jow: If that's a stable interface, sure.
eduardo010174 has quit [Quit: Leaving]
rua1 has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
<dangole>
neggles: sad. so we may have to change that, e.g. by checking if the device/partition name actually exists and use auto-attach in case it doesn't...
valku has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
rua1 has quit [Quit: Leaving.]
rua has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
<stintel>
how unlikely is it that the mt7621_nand simply doesn't properly handle bad blocks and we never found out because nobody encountered bad nand blocks before on ramips/mt7621 ?
mattytap has joined #openwrt-devel
<jow>
I wonder how to best visualize nftables in the LuCI status ui
<jow>
with iptables we broke down the rule listing into a tabular view
<jow>
with nftables that does not fit well
<jow>
maybe pull out some common properties like in-dev (iif, iifname), out-dev (oif, oifname) and counters, then have a large column that simply prints the entire rule as-is
<stintel>
why do whe sometimes have pad-to $$(KERNEL_SIZE) vs pad-to $$$$(KERNEL_SIZE) ?
<jow>
stintel: macro nesting depth I suppose
<jow>
e.g. if pad-to is part of another macro which again is included or not
<f00b4r0>
hmm. calling devstatus on vlan devices created via config/network show type "8021q", but for VLAN devices auto-created from device name inference (e.g. eth0.1) it says type "VLAN" (on 21.02): is this expected?
<rsalvaterra>
… sure, but we need the same for ip link in busybox.
<aparcar>
anyone working on dnsmasq 2.87?
<stintel>
anyone working on nftables support in dnsmasq? ;p
<rsalvaterra>
aparcar: ldir is, I think. At least he has it in his tree and I've been shamelessly stealing from him. :)
<aparcar>
stintel: I just posted that into openwrt-devel. did you try it?
<rsalvaterra>
stintel: Is anyone working on a decent DNS forwarder for replacing it? :P
<stintel>
udns? :P
<aparcar>
stintel: from my understand does dnsmasq 2.87 support that
<stintel>
oh
<rsalvaterra>
stintel: I only heard the rumours… is there code anywhere already?
<dangole>
rsalvaterra: the patch for iproute2 is kinda optional, you only need it if you want to **change** the preferred CPU port manually. defaults are assigned in DTS.
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rsalvaterra>
dangole: Yikes. That means changing all device trees…?
<fda->
dangole: e8450 +5ghz wlan works now great!! If someone else complains that wlan is crap, country settings should be the first hint :)
<dangole>
rsalvaterra: it means wiring up the 2nd CPU port (if existing and connected to the switch IC) in DTS, and that's anyway always needed to make this work on any board
<rsalvaterra>
Alright, but it's still a good idea to give users a bit more control. I think I can cook a patch for BusyBox in the next few days (weekend). ;)
<fda>
i have hijacked outbound DNS, but with nftables suboption the iptable syntac for redirect is no longer accepter as the ipv6 of my local dns is not an ip, in the error message is only the 1st char of ULA "fda0:..../64"
<dangole>
rsalvaterra: having a patch for busybox would of course be nice :)
<rsalvaterra>
dangole: Cloning… :P
<fda>
@jow firewall on luci: it would be nice if ipv4 and v6 are different pages! currently, if i search in the browser for a table the current ip version is highlighted AND the hidden tables of the not visible version
<ldir>
I try to keep up with the dnsmasq tree ready for when a release comes out that it's easy to do a bump - I have personally been bitten before by putting test releases into master so try to avoid it now. By all means feel free to copy/ignore/whatever any/all of my commits :-)
<fda>
ldir: isnt fw4 a "test-release"?
<ldir>
a failing dnsmasq tends to attract a lot of flack :-)
<fda>
when complete ipv6 /nat6 does not anymore, too
<rsalvaterra>
The price of ubiquity… ;)
rua has joined #openwrt-devel
<fda>
i thnk full nft support will take months...
<dangole>
fda: no. fw4 is an internal development and release-status goes together with OpenWrt, ie. since jow pushed it to the tree i'd consider it public beta test, once we have 22.xx release candidates and subsequent release, that also applies to fw4. NAT66 has never been an officially supported feature btw and should not be used by anyone.
<fda>
dangole: so you recommend only use ipv4?
<dangole>
fda: dnsmasq, however, is not developed by us, but it's an upstream project and pushing one of their test-releases into our tree is a bit of a different story
<dangole>
fda: which ISP in the world gives you only a single IPv6 address? this is wrong and you should complain at the ISP.
<fda>
german "telekom"
<dangole>
fda: IPv6 standard mandates that you get at least /64, recommended is /56 for private and /48 for business clients
nlowe has joined #openwrt-devel
<dangole>
fda: telekom gives you /56 if you just request it, i've seen it many times on german VDSL lines.
<fda>
i have a "hybrid" internet, which bundles (crap)dsl+lte
<fda>
there is only 1 device "speedport hybrid" which is not able to do DP, even it get itself a /56
<fda>
so -> nat6
<fda>
or throw openwrt away and use the speedport
<dangole>
fda: a right. that maybe a bit special, because then the openwrt router would not receive the prefix but only an address. but you can use ND-proxy and then again don't need NAT66
<fda>
the speedport gives to its LAN /64 ips
<fda>
nat6 or ipv4-only ...
<ldir>
the flip side of putting an upstream test release in our ecosystem is that any bugs can be fed back upstream early and indeed that has been done... but it requires someone on the openwrt side to wear the flack jacket.... and that cannot be me at the moment/foreseeable future
<dangole>
fda: read up about ND-proxy please, it's exactly for this situation
<fda>
which neighbours??
<dangole>
fda: ND is the equivalent of ARP in v6
<dangole>
fda: read the wiki please
<fda>
the speedport is a piece of crap! no functions, but is sold for 400euro!
<stintel>
and if you really can't figure it out, stick with fw3 for now
<fda>
it is even not able to allow icmpv6 or forware incomming ipv6 ports
<dangole>
fda: the speedport doesn't need to do anything special for that
<dangole>
fda: just switch on ndp on the openwrt router and it will pass-through the whole /64 to down-stream clients
<fda>
in case it works , only 1 of my 5 vlans gets ipv6
<dangole>
fda: they will just share all the same prefix
<fda>
so no routing anmyore between them?
<dangole>
fda: that's what ND-proxy is for then
<fda>
im currently use ULA and can do this. with nat6 all have internet access
<dangole>
fda: please read the wiki, i will not spam the channel going through this line by line
<hurricos>
neggles: vscode strikes again
<dangole>
fda: with nd-proxy also all will have internet. your situation is not uncommon (having only a single /64 and no sub-prefixes) and nobody is using NAT66 for that.
<fda>
dangole: openwrt-device has no /64 but only 1 singe ip from this /64
<dangole>
fda: READ THE GOD DAMN WIKI MAN
ldir has quit [Quit: +++Divide by cucumber error+++]
<dangole>
fda: it's really easy, you just have to set it up in /etc/config/dhcp and then OpenWrt will pass-through the very same v6 prefix it is living in itself
<hurricos>
neggles: bootargs-override chosen :o
<dangole>
fda: just give it a try, i'm positive it will work instantly.
<fda>
dangole: SPEEDPORT - OPENWRT - CLIENTS-IN-LAN -- in case CLIENTS are in the same subnet as OPENWRT, they have a wrong routing table - as SPEEDPORT is also in the same subnet
<fda>
same subnet (v6 or v4) means NO ROUTING -> does not work
<dangole>
fda: please, just give it a try, i've been using that myself many times with OpenWrt router behind an ISP router which doesn't do prefix-delegation. and it always worked very nicely.
<fda>
as CLIENTS and SPEEDPORT are on differen segments
<dangole>
fda: this is EXACTLY what nd-proxy is for, to proxy ND messages between these layer-2 domains and hence it looks like one transparent domain for v6
<dangole>
fda: and you can still firewall things, on layer-3, because it's not a really a bridge.
<fda>
dangole: no, NDP is for "on the same network but in different broadcast domains" - and diffrent BC domains different subnets - and i have only the /64
<fda>
so this does not work
<fda>
but anyway, the nat6 script does not work with NFT
<fda>
btw, my openwrt has a GUA + temp-ipv6, but it does not use the temporary ip. should this with with openwrt?
<stintel>
you're wrong
<stintel>
have you tried NDP?
<fda>
stintel: i have not found anything which describes that it could help me
<fda>
"With ND proxy, hosts in different broadcast domains can communicate with each other as they would on the same network."
<fda>
I DONT HAVE MORE THAN 1 BROADCAST DOMAIN
<stintel>
please do not yell
<dangole>
fda: just try enabling ND proxy in /etc/config/dhcp for the interfaces you like to have v6 being passed-through. afaik you can even do that with LuCI.
<fda>
so instead "you wrong" tell whats wrong
<fda>
[17:26:57] <dangole> fda: READ THE GOD DAMN WIKI MAN
<fda>
i thought this is how chat is here
<fda>
nd fills the cache wiht mac/ips. even you know it, ip needs a routing table
<fda>
you cant reach a>b>c without routing, except you use masquerading
<dangole>
fda: instead of insisting in your (factually wrong) truth, you could just go ahead and give it a try and if you don't manage, share your configuration and we will tell you if there is something wrong
pmelange has joined #openwrt-devel
<dangole>
fda: ND proxy will not stop working just because you don't believe it does
<stintel>
I actually have a setup like that, ISP-Home-Gateway - [wan]OpenWrt[lan] - clients
<stintel>
both wan and lan have the same /64, as does the ISP-HGW and as do the clients
<stintel>
don't tell me it doesn't work because I use it and it does
<fda>
stintel: i have ISP [wan]SPEEDPORT[lan] - [wan]OPENWRT[lan] - [lan]clients
<dangole>
fda: this is what stintel meant.
<fda>
speedort gets /56 but send to lan only /64
<dangole>
fda: ISP-Home-Gateway == Speedport
<fda>
so [wan]OPENWRT has 1 ip
<dangole>
fda: please just go ahead and try. you will not convince us
<stintel>
*facepalm*
<stintel>
I'm done
<stintel>
stick with fw3 if you don't want to listen
<fda>
stintel: why is fw3 now related?
<stintel>
because you're complaining that fw4 doesn't support your usecase
<fda>
dangol told me nat6 is bad, ndp is the solution
<stintel>
nat6 is bad
<fda>
stintel: i told NFT does not support NAT6 script, which should be updatd
<fda>
nothing else
<dangole>
nft will NEVER support NAT6 and i think we should eliminate all traces of it's existence to avoid situations like this now
<fda>
and that fw4 is a test release as it break ipv6 for users which use nat6
<dangole>
you are probably the only user in the world who made this very weird setup
<fda>
dangole: please stop chat with me for today, maybe you mood is tomorrow better
<dangole>
fda: if you would even just go ahead and try (to make me believe you did it would take 5-10 minutes) and then reply instead of insisting in something that may here know is just wrong, my mood would be much better
<fda>
im now writing since 30 minutes shit!
<fda>
send me a link which describbes what you "believe"
<hurricos>
Do we know whether Openwrt 21.02.2 will be based on kernel 5.4?
<hurricos>
or indeed, whether will be such a release?
Guest1180 has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
<hurricos>
I may just have to abandon the assisted HiveAP 330 sysupgrade process from PR 4897, if 21.02.2 doesn't come out based on 5.4
<minimal>
dangole: not wanting to raise people's blood pressure any more, but there are other reasons why people may want to use NAT6 such as for "privacy" reasons (i.e. to obscure internal network layout/devices aka masquerading)
<dangole>
minimal: sure, not all client devices support privacy extension (or use it properly)...
<dangole>
minimal: point there was also just that it really shouldn't be the default-way for situations where you have OpenWrt sitting behind an ISP-Gateway which only does RA on a single /64.
<minimal>
dangole: exactly! so its unfortunate that "NFT will NEVER support NAT6"
<minimal>
dangole: to be clear, I'm not referring to a single /64 situation.
<dangole>
minimal: what i do is blocking all EUI-64 based addresses using firewalling, so clients which don't do privacy extension just won't have connectivity
<dangole>
minimal: by matching the XXff:feXX
<Slimey>
hurricos networks are my carrier :P
<minimal>
dangole: in my situation I use a ULA internally divided into /64s for each VLAN/physical subnets. For some subnets I may want to do 1-1 GLA/ULA mapping, in other subnets I may want to do 1-N GLA/ULA mapping, for some other subnets I just don't want them to have external access at all
<dangole>
minimal: so that spares me the mess of NAT66 and clients still got real public addresses, i don't need the overhead of connection tracking. just a bit of ND-Proxy (ok, not so much less effort than ct if all clients to privacy extension properly...)
<dangole>
minimal: that's not a very minimal setup :P
<minimal>
dangole: its a very "minimal access to the outside world" setup :-)
<dangole>
minimal: but yes, I get the use-case for such things and we have to re-implement them for nft if we want that
<minimal>
dangole: its complicated more so as I have a DMZ with a 2nd router, so ISP gives /48 prefix, I use a /64 for DMZ, and 2nd router provides multiple /64s from a prefix delagated by WAN router
<dangole>
minimal: in my experience, many things didn't work well when using the ULA as global source address from client perspective. breaks things like SIP clients which assume that local v6 address == global v6 address.
<minimal>
dangole: the main reason for ULA is that all "servers" have static ULA and internal firewall rules (between vlans/interfaces) are ULA based.
<minimal>
so regardless of whether externally connection is up or down internal servers always use ULA between themselves rather than GLA
<dangole>
minimal: i'd just use more vlans and use that to match traffic. but that complicates things if you also have a lot of internal traffic which you don't want to go through the router.
<dangole>
minimal: ULA in addition to GLA is of course also possible :)
<dangole>
minimal: (and the default)
_Lechu is now known as Lechu
<hurricos>
Ok, this is torture
<hurricos>
I give up on 5.4 -> 5.10 for mpc85xx
<minimal>
dangole: yes for things like the SIP client example you mentioned I'd intend to give a device a (non-NAT6) GLA as well as a ULA. But for most devices with external connectivity I'd want to 1-N NAT6 them to a single GLA, and for internal servers they'd only have static ULA with no GLA (neither direct nor via NAT6) at all
<hurricos>
I have some thoughts of things that might make incompatible sysupgrades easier, if only they could be written:
<hurricos>
1) include/image-commands.mk::metadata_json should be able to encode executables
<hurricos>
(that inlcuding the process for actually executing them through sysupgrade)
<hurricos>
2) if not 1, then it should at least be able to encode arbitrary strings (\ns and $s are lost due to echo / variable interpolation)
<dangole>
minimal: sounds like you are going to contribute some patches soon ;)
<hurricos>
without 2), actually giving the user scripts to upgrade their devices with is impossible
<hurricos>
< a suggestion from a committer, obliterated by harsh reality that the tools aren't built to do that.
<hurricos>
(the usual fare is to accept that users should know how to find instructions or should accept that sysupgrade isn't always supported and sometimes you need to get your serial cable out.)
<hurricos>
3) (not a serious suggestion) Open up the policy for backports to fix devices which cannot be sysupgraded.
<jow>
hurricos: fixing 2) sounds like the way to go
<hurricos>
3) is the "modest proposal" option, of course ...
<jow>
can't put my finger on it but my intuition is that 1) will bite us, badly, eventually
<hurricos>
1) is like giving nukes to the Vacitan
<hurricos>
unnecessary and potentially disastrous
<hurricos>
I'll go and try to implement 2. Thankfully there are less than a dozen devices with DEVICE_COMPAT_MESSAGEs, so I should be able to find the gotchas.
<minimal>
dangole: as DMZ involves a 2nd non-OpenWRT router/firewall I've got 2 fronts to figure things out on
<hurricos>
Another change to 2 more *approaching* 1 would be to pass definitions by *file* rather than by string
<hurricos>
and that'd eliminate the need to handle Makefile parsing
<Habbie>
when i set syntax to JSON in Sublime Text it made all those red
<hurricos>
rather than escaping, I could just print the control characters I want. Still, the json won't want this
<hurricos>
though I could tweak sysupgrade to turn \ns into literal $'\x0a'
<hurricos>
that'd probably do it
champtar has quit [Quit: WeeChat 3.3]
<Habbie>
json indeed does not want that, outside of x0a and a few others
<hurricos>
OpenWrt's json can handle literal newlines?
<hurricos>
I don't believe it
<Habbie>
no no
<hurricos>
I misunderstood, sorry
<hurricos>
just the scape sequence yeah
<hurricos>
but does OpenWrt's JSON implementation care about \(, I wonder?
<Habbie>
ah, even a literal newline is invalid inside a string
<hurricos>
I'd prefer to act as though OpenWrt's using a subset of jq, but json canonicalization is a rough fight
<Habbie>
yes
<hurricos>
Hmm, this is tricky. v/vn exist for dealing with logging at the same time as one wants to spit out a message.
<hurricos>
I suppose a "ve()" would be OK to add?
<hurricos>
Let's try.
<hurricos>
oh.
<hurricos>
I guess the nice thing about OpenWrt using JSON is that one day
<hurricos>
in the far, far future
<hurricos>
when even ath79 is deprecated ... the community will be able to, without too much fuss, turn around and change tooling, because the format itself is one which has a lot of attention on it.
<Habbie>
people will stop being confused about what things conflict/duplicate each other in the uci config syntax?
<Habbie>
ah
<Habbie>
that too
<hurricos>
:^) Nice try, Habbie.
GNUmoon has quit [Ping timeout: 480 seconds]
nlowe has joined #openwrt-devel
<Habbie>
:D
<hurricos>
Hmm. So because fwtool uses v to echo out the compatmessage, it's actually never possible to put out newlines.
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<hurricos>
I *could* tweak that, so that it uses ve instead; and have ve call a helper _ve, then log the first line ... but that type of code-duplication appears to be strongly frowned upon
<hurricos>
for example, lib/upgrade/common.sh::vn was created <2y ago and dropped 12 months ago
<hurricos>
I *could* break the sysupgrade logging functionality for EVERYONE so I could have this functionality for myself ...
<hurricos>
Oh no
<hurricos>
wait
<hurricos>
I forgot
<hurricos>
This code doesn't actually exist
<hurricos>
except in master
<hurricos>
so I can't actually use it in this implementation
<hurricos>
and so we return to 1)
Borromini has left #openwrt-devel [#openwrt-devel]
<hurricos>
Oh!
<hurricos>
I'm pleasantly surprised
<hurricos>
jshn handles \n
<hurricos>
It does not handle *arbitrary* characters
<blocktrron>
We have multiple mpc85xx on our mesh framework for which we want to retain backwards compatibility
<hurricos>
ok.
<blocktrron>
notable wdr4900
<blocktrron>
We want to deliver unattended automatic upgrades for all platforms as far as possible
<hurricos>
I was thinking that might be i
<hurricos>
t
<blocktrron>
When i did this (prior covid *sigh*) it did work with the OpenWrt gcc toolchain (19.07)
<hurricos>
At least for AP330, the bootcmd cannot be modified, but the neat workaround might be putting u-boot where the kernel would be.
<hurricos>
I'm assuming you got it working against `bootm`
<blocktrron>
They just did not apply the base-address correctly from the configuration afair
<blocktrron>
It's the same as i already did for the ramips target
<hurricos>
Hmm. OK.
<hurricos>
Not sure I've heard of u-boot replacements for ramips. I dont pay attention to mtk stuff (I probably should).
<hurricos>
I did see lzma-loader stuff aplenty there.
<hurricos>
I'm not sure, you might be just talking about tweaking the base-address so that simple executables can just be jumped to.
<hurricos>
Send me whatever you have. If you lack hosting for big files, send me an id*.pub and I'll give you sftp access at sftpuser@home.laboratoryb.org:20000
<hurricos>
Thanks!
<blocktrron>
I'm not taking of replacing the bootloader
<blocktrron>
It's about crafting sysupgrade images, which contain an additional bootloader for the kernel, which allows reading from SPI / NAND
<blocktrron>
The loader used on many target only supports loading images in the systems memory map. The ramips example was for the RavPower WD009, where the kernel to load is not contained in the mapped flash space
philipp64 has quit [Quit: philipp64]
<hurricos>
But in general you load in and jump to a TPL (rambooted u-boot, or okli/lzma-loader, etc)
<hurricos>
I'm open to try and use what you have; let me know when you have time to work on it.
<hurricos>
The trick will be building that consistently for mpc85xx
<Slimey>
:)
<Slimey>
loading 2nd stage bootloader.....
<hurricos>
I just want to avoid "toolchain hell". Okli-loader is extremely simple, though daunting to write (some libraries and some assembly), ramips' RAM-based u-boot (I suspect) is better mainlined or potentially simpler than mpc85xx's
<hurricos>
but mpc85xx is older and has more different boards with (potentially) more different quirks
<neggles>
hurricos: it wasn't vscode's fault, it asked me if I wanted to save and I hit no before I realized I'd clicked close on the wrong tab :( and yeah, bootargs-override works, but I was hoping to avoid baking the cmdline into the image
<hurricos>
oh, it's been done
<mangix>
that dts section is questionable. I don't know if it even compiles
<neggles>
dangole: there's actually a hack in ipq806x to rename the "rootfs" partition to "ubi" at runtime if the qualcomm smem partition parser is used
<neggles>
unfortunately the smem partition table on this device is *completely wrong*
<mangix>
I just copy/pasted from the ath79 PR and adjusted some things
<slh>
neggles: you can hardcode the partions
<hurricos>
mangix: I can build and test (and tell you it doesn't work) at some point.
<slh>
only nbg6817, g10, ea7500 and ea8500 use smem based partition at all
<hurricos>
or, well, perhaps it does
<slh>
all other ipq806x devices hardcode the partition table
<mangix>
hurricos: my point is I don't have the hardware nor experience with the platform
<hurricos>
mangix: OK, understood. At the very least, I can test.
Lechu has joined #openwrt-devel
<neggles>
slh: yes, but the hack which renames 'rootfs' to 'ubi' only works on smem partitions, not hardcoded ones - and actually i'm not sure it'd help here anyway
<slh>
neggles: if you hardcode the partitions, you can name them as you like
<neggles>
yeah, my problem is that u-boot passes 'ubi.mtd=rootfs loglevel=8 console=ttyMSM0,115200' in bootargs
<neggles>
and if the boot sequence sees an mtdpart named rootfs, it won't try to do all the fun FIT-splitting etc, just tries to mount it as, well, rootfs
<slh>
neggles: then you can also overwrite bootargs, most devices do that
<neggles>
yeah, i'd just hoped to avoid that :(
<neggles>
though... wait a minute
<slh>
is there anythying valuable in the bootloader cmdline?
<slh>
so bootargs remains the same in both cases? then just overwrite bootargs in DTS, done
<neggles>
ubiboot loads 'image' ubivol to loadaddr and bootms it, ubiboot_backup does the same with image_backup and appends 'OLD_IMAGE_BOOTED' to bootargs