<nick[m]4>
slh: I believe I used "-n". however, now ftftpboot is again broken :/
<nick[m]4>
now I have to go to my vm use avm recovery tool and then I can reflash openwrt again
Rentong has quit [Ping timeout: 480 seconds]
KGB-0 has joined #openwrt-devel
<aparcar[m]>
rsalvaterra: ping
<rsalvaterra>
aparcar[m]: pong
<aparcar[m]>
nice
<aparcar[m]>
I'm happy with the zram stuff ich you tell me how to test it
<rsalvaterra>
You want to test it? Well, that's easy. Just install the zram-swap package (with my changes) and see if the swap device has a priority of 100.
<rsalvaterra>
When swap devices are added, with no priority specified, by default the kernel assigns a priority of -1 to the first device, -2 to the second and so on.
<aparcar[m]>
rsalvaterra: will do thank you
<rsalvaterra>
aparcar[m]: You're welcome, I thank you. :)
<aparcar[m]>
rsalvaterra: err how do I show the swaps?
<aparcar[m]>
nevermind /proc/swaps
<aparcar[m]>
rsalvaterra: ack thanks for the patches
<digitalcircuit>
I'll post a reply to the mailing list once I've gotten a successful test build (hopefully within the next few hours), then I'll redo testing as usual.
<digitalcircuit>
(Posting here just in case anyone following this issue saw the reply - I am still happy to try to help :)
<slh>
digitalcircuit: the problem with that is https://github.com/openwrt/openwrt/pull/4192 not being merged to master yet - as a consequence there isn't really anything to backport at this point
<slh>
from a purely technical point of view that wouldn't necessarily be a problem, however straying from the strict trickle down procedures of backporting from master is a recipe for desaster (in the sense that while openwrt-2021.02 would be fixed, master gets forgotten and remains broken --> and taking a random number out of the hat, openwrt-22.05 would be broken as well)
<digitalcircuit>
slh: Understood, that makes sense! I agree. I would not propose a new "backport" until that PR is merged into master, ensuring it's trickle-down instead. I merely hoped that I could try to verify that if this PR was merged to "master" (as it seems necessary for the existing backport to not regress performance), it would go smoothly.
<digitalcircuit>
As it turns out, that pull request fails to build for me, so I'll have to dig into what's going on anyways.
<slh>
obviously test it now, make sure that it's fine
<digitalcircuit>
(I'll see if it fails to build on master + PR, ensuring it's not just 21.02 + PR that's broken)
* digitalcircuit
nods!
<slh>
and time is a bit scarce, as 21.02.0-final is imminent afaik no further rc)
<digitalcircuit>
Also understood. I wish I had gotten the mailing list reply sooner than today, but, ah well. If it can't happen, I've learned how to compile custom builds so I can live with that.
<slh>
there's always a 21.02.1 ;)
<slh>
and probably not that far away either, as many users skip testing -rcs and will only notice/ report issues after 21.02.0 is out of the door
<digitalcircuit>
That's good to hear - well, not the lack of testing (I personally almost didn't test the -rcs, glad I did), but good in that I likely won't be carrying a custom patch set for too long :)
<digitalcircuit>
Noted! In that case I can likely skip verifying that master+PR builds, and see how patch might need adapted to the 21.02 branch. I recall the wiki mentioning patch debugging; I'll work through that.
<slh>
(just for reference, currently running r16957-3d026d2425 including that PR, uptime 11 days)
<slh>
(with kernel 5.10.44 and the DSA PR)
<Tusker>
is the desire to get something into a particular release due to personal preference or because of company policy and roll out requirements ?
<Tusker>
Maybe I am abnormal, and don't care what the release number is...
<slh>
we're talking about a bugfix here, fixing a crash on ipq806x - not really a new feature (PR#4192 in isolation might not look that way, but it's a bugfix to the already merged-in-master crash-fix, so both need to go in)
<Tusker>
ah, got it
<digitalcircuit>
Do let me know if I should dial things back, I recognize most (all?) folks are volunteering their time and I don't mean any disrespect! As slh noted this is a bugfix, but I'm only managing two NBG6817s (one at home, one at family home). In the interim, I can compile custom images.
<Tusker>
no, I don't think so, I think push ahead with the desire to get it in, but just set your expectations so you don't get upset or get rude... :)
<slh>
then you're running one more than me (and I'm running master snapshots+pending patches anyways) ;)
<digitalcircuit>
Understood! I'll do my best, and feel free to call me out if I mess up :)
<digitalcircuit>
(This is actually progressing faster than some other open source projects I've contributed a bit to)
<slh>
I'm a little conservative in regards to testing at the moment (beyond merely updating my builds), as I've several changes coming ahead within the next 2-2.5 weeks (VDSL going away, having to move VoIP/ SIP from the VDSL line to ftth - and some AP changes) - so trying to minimize the number of moving parts a little, until the dust has settled
<digitalcircuit>
slh: Good luck with upcoming changes! Avoiding too many changes in that situation makes sense.
<digitalcircuit>
(Meanwhile, I've goofed up at backporting patches, but I think I /finally/ have a proper test compile that's appearing to work... This won't be submitted as a backport anyways until the PR is merged, but I want it to be generally sane.)
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Rentong has quit [Remote host closed the connection]
<digitalcircuit>
Woo! Custom build with ipq806x CPU-related backports appears to boot/work successfully. I'll run a backup test overnight (as I'm getting sleepy) and write my mailing list reply tomorrow.
<digitalcircuit>
...sigh. Reboot. Time to fetch the logs and see what happened...
Tapper has joined #openwrt-devel
<digitalcircuit>
I wonder if the 1.4 GHz cache freq is unstable in some way? I'll have to git bisect.
<digitalcircuit>
Or I'm missing other necessary changes/broke the backport, since the PR has been working well for others on master.
<digitalcircuit>
I'll try master + PR, see if that has issues by now, and if so, I'll try master without the PR. If not, I'll re-review my backport. Regardless, it's 2:30 am, time to wind down for the night. (Of course I'd get a failure RIGHT after responding on the mailing list...)
<digitalcircuit>
(Well, I'll start the build at least.)
feriman has quit [Quit: WeeChat 3.2]
nitroshift has quit [Quit: Gone that way --->]
nitroshift has joined #openwrt-devel
<digitalcircuit>
(Nothing in the serial console log, which happened sometimes with 21.02.0rcX releases - I'll look into this more tomorrow)
Tapper has quit [Ping timeout: 481 seconds]
jlsalvador has quit [Quit: jlsalvador]
Tapper has joined #openwrt-devel
CodeFetch has quit [Remote host closed the connection]
<ldir>
my understanding is that trying to register a namespace that is already taken is a non-transient error (unless the holding process releases)
<ldir>
in other words, trying to start multiple instances of dnsmasq with the same ubus ID is never going to work from a ubus perspective
Tapper has joined #openwrt-devel
owrt-1907-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-1907-builds_ has joined #openwrt-devel
owrt-snap-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-snap-builds has joined #openwrt-devel
owrt-2102-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-2102-builds has joined #openwrt-devel
owrt-2102-builds has quit [Remote host closed the connection]
owrt-1907-builds_ has quit [Remote host closed the connection]
owrt-snap-builds has quit [Remote host closed the connection]
owrt-1907-builds has joined #openwrt-devel
owrt-2102-builds has joined #openwrt-devel
owrt-snap-builds has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
owrt-1907-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-1907-builds has joined #openwrt-devel
owrt-snap-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-snap-builds has joined #openwrt-devel
owrt-2102-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-2102-builds has joined #openwrt-devel
Rentong has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
<rsalvaterra>
ldir: Maybe it would be better for dnsmasq to just implement the missing features which require us to run multiple instances in the first place…?
Tapper has joined #openwrt-devel
<russell-->
WARNING: Not overriding core package 'dante'; use -f to force
Tapper has quit [Ping timeout: 480 seconds]
<rsalvaterra>
russell--: It was moved to the packages feed, -f should be fine.
<russell-->
rm -rf tmp fixed it
<rsalvaterra>
That too. :)
decke has joined #openwrt-devel
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<ldir>
rsalvaterra: you know what I'm gonna say?
<rsalvaterra>
ldir: Not really… I don't read minds. Yet. :)
<rsalvaterra>
blogic_: Great! Looking forward to it. About the per network (or even per host) forwardings, is such a feature on the table?
<blogic_>
yes
<blogic_>
also per tld
jlsalvador has joined #openwrt-devel
<rsalvaterra>
blogic_: Exactly! I'd like to be able express something like "For this host, when targeting this domain, resolve thought this resolver. Otherwise, resolve through this default one."
<rsalvaterra>
blogic_: I felt this need when configuring an IPTV service from an ISP, whose set-top box needs to connect both to the internet and to the internal ISP network.
Guest769 has quit [Read error: Connection reset by peer]
rejoicetreat has joined #openwrt-devel
rsalvaterra_ has joined #openwrt-devel
rejoicetreat has quit [Remote host closed the connection]
<rsalvaterra_>
blogic_: Another extremely important feature (which dnsmasq has): populating ipsets with resolved addresses.
rejoicetreat has joined #openwrt-devel
<aparcar[m]>
rsalvaterra_: you should start talking blogic into patreon
<rsalvaterra_>
aparcar[m]: Aren't Patreon's commissions a bit… excessive…?
rsalvaterra has quit [Ping timeout: 480 seconds]
rejoicetreat has quit [Remote host closed the connection]
rsalvaterra_ is now known as rsalvaterra
rejoicetreat has joined #openwrt-devel
rejoicetreat has quit [Remote host closed the connection]
<blogic_>
2what is patreon ?
rejoicetreat has joined #openwrt-devel
rejoicetreat has quit [Remote host closed the connection]
rejoicetreat has joined #openwrt-devel
<aparcar[m]>
blogic_: it's something where fans pay you to do things, usually do art, teach guitar or replace core infrastructure of OpenWrt
rejoicetreat has quit [Remote host closed the connection]
<blogic_>
huh ?!
<blogic_>
why would i want that ?
<aparcar[m]>
/joke
<blogic_>
not a good one
rejoicetreat has joined #openwrt-devel
rejoicetreat has quit [Remote host closed the connection]
<aparcar[m]>
I've just been amused by rsalvaterra excitement and him starting a catalog of features
<blogic_>
well that is why I am talking to him
rejoicetreat has joined #openwrt-devel
<blogic_>
I have been collecting feature requests all over the place
rejoicetreat has quit [Remote host closed the connection]
rejoicetreat has joined #openwrt-devel
<aparcar[m]>
okay no quality content from me tonight, I'm off
<rsalvaterra>
blogic_: I can imagine, given the limitations of dnsmasq regarding DNS forwarding and the lack of alternatives… :)
<rsalvaterra>
aparcar[m]: Sleep well!
<blogic_>
rsalvaterra: it all started with me wanting to add dhcp-relay option82
<blogic_>
and we already have all the dns logic inside mdnsd
* rsalvaterra
needs to look that up…
<blogic_>
so its just a matter of adapting that and addind an application layer
<blogic_>
dhp-relay is a way where you have an upstream dhcp server on wan
<blogic_>
when you geta dhcp on lan you forward it to the wan side dhcp that handles a larger pool
<blogic_>
for that upstream to know where the request comes from option 82 is added
<blogic_>
enterprise switches support this aswell
<blogic_>
this allow mitigating rogue dhcp server and so on
<blogic_>
and you can server the same dhcp to a client independent of its broadcast domain
<rsalvaterra>
I see (I was reading a Juniper page about it).
<blogic_>
inside the circuti id you can then encode stuff like the switch port or the wifi bssid or whatever
<blogic_>
anyhow, i realized that we are sitting on a ticking time bomb with dnsmasq while trying to add that feature to it
<blogic_>
and we can safely assume that in 90%+ of deploys people will use the isp routers dns anyhow
<blogic_>
and if you really want a local dna, you can put a unbound in front of dnsfwd
<blogic_>
the main reason i see why we still use it is because of dhcpv4 and being able to resolve $hostanme.openwrt
<blogic_>
but odhcpd can do that awell and dnsfwd can just grab leases from that daemon
Tapper has quit [Ping timeout: 480 seconds]
rejoicetreat has quit [Remote host closed the connection]
aleasto has joined #openwrt-devel
rejoicetreat has joined #openwrt-devel
rejoicetreat has quit [Remote host closed the connection]
rejoicetreat has joined #openwrt-devel
rejoicetreat has quit [Remote host closed the connection]
rejoicetreat has joined #openwrt-devel
rejoicetreat has quit []
Rentong has joined #openwrt-devel
Tapper has joined #openwrt-devel
Rentong has quit [Ping timeout: 480 seconds]
<zorun>
aparcar[m]: it seems that $(AUTORELEASE) is costly in some cases: with package/boot/uboot-layerscape, the git logic is called again for each variant
rejoicetreat has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
aleasto has quit [Read error: Connection reset by peer]
aleasto has joined #openwrt-devel
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
rejoicetreat has quit [Remote host closed the connection]
rejoicetreat has joined #openwrt-devel
rejoicetreat has quit [Remote host closed the connection]
rejoicetreat has joined #openwrt-devel
Tapper has joined #openwrt-devel
rejoicetreat has quit [Remote host closed the connection]
<ldir>
my router/testing is in lockdown due to my imminent travel and I'm not allowed to touch anything networking whilst I'm away.
felix has quit [Read error: No route to host]
felix has joined #openwrt-devel
<rsalvaterra>
ldir: How should I test it and what should I look for?
<rsalvaterra>
ldir: I'm assuming I should "revert the reverts" first, right?
<ldir>
rsalvaterra: no, etan has 3 patches in the series, 1 to fix our dnsmasq init script (ie not fire up instances with same name) one to bump dnsmasq to implement his desired dns filtering by conntrack and one to allow said filtering to be configure via uci
<rsalvaterra>
ldir: I see, no need for 2.86 yet, right?
<ldir>
'ubus list' should show you dnsmasq instances with individual names, the primary (probably non-named instance in /e/c/dhcp) should be called 'dnsmasq' the others 'dnsmasq.$instancename'
<ldir>
etan is trying to push for 2.86 'cos of the conntrack based filtering.
<rsalvaterra>
ldir: Is there anything relying on the original 'dnsmasq' instance name?
<ldir>
the 2.86 (attempted) bump exposed our lack unique ubus instance name
<ldir>
I think so but I don't know how it's really supposed to work - that was my git log "
<ldir>
git log | grep "ubus.*dnsmasq"
<ldir>
I think there's stuff using hotplug events via ubus expecting to find 'dnsmasq'
<ldir>
multiple instances of dnsmasq and ubus was fundamentally broken AFAICT
<nick[m]4>
blocktrron: PaulFertser I connected now serial port
owrt-1907-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-1907-builds has joined #openwrt-devel
owrt-snap-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-snap-builds has joined #openwrt-devel
Rentong has joined #openwrt-devel
owrt-2102-builds has quit [Quit: buildmaster reconfigured: bot disconnecting]
owrt-2102-builds has joined #openwrt-devel
<rsalvaterra>
ldir: Patch series applied. Will build soon.
<ldir>
I would do it but I'm not going to be around enough to deal with any fallout
Rentong has quit [Ping timeout: 480 seconds]
rmilecki has quit [Ping timeout: 480 seconds]
<rsalvaterra>
ldir: Ok, I've got two dnsmasq ubus services. Working as intended?
<ldir>
more than 1 = very good
<ldir>
what are the instances called? dnsmasq and dnsmasq.??????
<rsalvaterra>
ldir: Yep! Although I'd like both of them to be called dnsmasq.$instancename, but it would probably break something, as you suggested.
<ldir>
your task is to find what talks/listesn to dnsmasq via ubus and check it handles multiple/different instance names.
<rsalvaterra>
ldir: How about making the change and see what breaks? ;)
<ldir>
hopefully someone annoying like rsalvaterra doesn't turn up and whinge "dnsmasq doesn't start anymore" :-P
<rsalvaterra>
ldir: I try to only annoy the right people… ;)
<nick[m]4>
blocktrron PaulFertser For the not working fritz!box the caldata is at 0x3C000 at urlader1: 3AVM7530V_CAL0_V4, For the working wifi fritz!box it is at 0x3C800 at urlader1 : 3AVM7530V_CAL0_V5
fx159 has joined #openwrt-devel
<fx159>
Hi, someone here with some experience in building ubinized images?
<fx159>
Got a device that names the mtd partition which contains the UBI "rootfs", that clashes with openwrt's UBI vol also named "rootfs"
<fx159>
Would it be feasible to extend ubinize-image.sh so that an alternative name for the rootfs vol can be provided?
<fx159>
In the stock FW the UBI vol is named ubi_rootfs
Weasel___ has quit [Ping timeout: 480 seconds]
aleasto has joined #openwrt-devel
rejoicetreat has quit [Remote host closed the connection]
nitroshift has quit [Quit: Gone that way --->]
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Tapper has quit [Ping timeout: 481 seconds]
<ldir>
Today's challenge - If you were presented with this "Take the tests day 4, 3, 2 before departure" and your departure was say July 10th, would your 'day 2 before departure' be July 8th or July 9th ?
<Tusker>
whatever calendar date falls on 48 hours prior to departure
<mirko>
hm, how to ensure the kernel has upped the device's (switch)PHY(s) before calling respective switch config scripts in /lib/network?
<Tusker>
which is 8th
<EqUaTe>
8th, 9th would be day before departure.
<mirko>
my PHY is coming up afterwards and i'm not sure how to ensure that's happening before /etc/rc.d/S20network is being called
<EqUaTe>
essentially, day of departure = 0
Rentong has joined #openwrt-devel
Rentong has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
<ldir>
you're all in agreement with my interpretation - D-Day = 0. Except I've now seen an email which if true makes D-Day = 1! Who writes this stuff? Not only that, who writes it AND puts it in a FAQ AND gets it wrong... in a FAQ?!!!
<Tusker>
well, because of the word within 24 hours makes it tricky
<Tusker>
so, if you depart at 10am, then 11am on the previous day is possible
<ldir>
If they were any bloody good they'd show a worked example.
Rentong has quit [Remote host closed the connection]
<digitalcircuit>
In attempting to test https://github.com/openwrt/openwrt/pull/4192 on master, now stress-ng is failing to build for some reason. Working on figuring that out, and if nothing else, I might have to drop that testing package.
<digitalcircuit>
Given io-uring.h contains lines like "#define #define HAVE_IORING_OP_NOP 0", it might just be the "sed 's/IORING_OP_/#define HAVE_IORING_OP_/'" from the Makefile adding an unnecessary extra #define?
aleasto has quit [Remote host closed the connection]
<digitalcircuit>
(I'm just trying to debug ipq806x master + Ansuel's cache PR... Ah well)
<digitalcircuit>
I haven't even (yet!) managed to recreate the issue with stress-ng (instead of the OpenSSH SFTP bursty upload test via Deja Dup), so for now I'm just gonna skip that package.
<digitalcircuit>
I'm starting to wonder if I'm running into instability with 1.4 GHz cache, hence why the new governor (that had removed that frequency) worked. I'll have to see if master + PR #4192 works.
Tapper has quit [Ping timeout: 480 seconds]
dedeckeh has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
rmilecki has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
_lore_- has joined #openwrt-devel
_lore_ has quit [Ping timeout: 480 seconds]
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
minimalist has joined #openwrt-devel
minimal has quit [Read error: Network is unreachable]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
minimal has joined #openwrt-devel
minimalist has quit [Read error: Network is unreachable]