**** BEGIN LOGGING AT Thu May 20 03:00:43 2021 May 20 05:02:59 i got an extra router they can have... May 20 05:04:09 it gets lonely out there in the wilderness May 20 05:06:56 slack actually took the first real blow to freenode May 20 05:08:23 people do get quicker responses on stackoverflow than on irc May 20 05:09:41 Take a look at this writeup on drupal: "this page provides a few details about using IRC with the Drupal community, for historical interest. If you want to communicate with the Drupal community on real-time chat, try blah blah instead." https://www.drupal.org/community/contributor-guide/reference-information/talk/tools/irc-historical May 20 05:13:16 if your opensource advocate you have a presence here... people outside freenode are like gpl3+$ exploiters May 20 05:14:14 with this client i can easily connect to multiple networks but a lot of people still connect to one or maybe two networks at a given time because of interface May 20 05:16:25 decentralized #curl like this: irc.curl.net/#curl i support May 20 05:18:16 that would be cool for a project to run there own irc server and still connect the server here May 20 05:18:32 i dont know if its needed though May 20 05:54:55 To all devs. If there is a need I would be willing to hand over the creds to the OpenWrt Discord server. If IRC gets messed up. May 20 05:55:20 https://discord.gg/AapGHjrD May 20 05:55:42 Tapper: There are already #openwrt and #openwrt-devel created on Libera, whether they decide to leave Freenode is another issue May 20 05:55:53 OK May 20 05:55:54 Tapper: Also, G'morning to you, sir ;) May 20 05:56:09 Grommish and to you my friend. May 20 05:56:30 Want to jump on to the VC on discord for 10 mins? May 20 05:56:37 Sure May 20 06:01:53 haha @ the irony May 20 06:03:18 all irc client devs have to do is modulerize the feature (api) set of discord/slack May 20 06:03:45 we can connect to those servers but cant join channels or are devoiced May 20 06:04:55 probably take someone a good three modes for something stable May 20 06:06:13 months* May 20 06:13:38 well i just got banned on ##science with topic change of moved to libreirc.net/we May 20 06:15:33 and another channel redirected me to ##moved_to_libera_omaha May 20 06:19:18 jow: nbd: sorry, I got offline, please let me know what do you think about changing "lan" to "br-lan" to avoid conflicint with DSA "lan" interfaces May 20 06:22:19 br-lan = bridge lan May 20 06:22:25 bridged lan* May 20 06:23:00 the BSSID May 20 06:24:30 your the first person ive met who uses dsa because they wanted to May 20 07:22:53 rmilecki: Aren't those settings usually defined in preinit/01_network for the target? May 20 07:23:15 rmilecki: I know I had to change the lanX to ethX for my uci_default_lan_wan or whatever it is May 20 07:24:29 rmilecki: Or is it in the tree? I'm still fumbling around the device tree stuff May 20 07:28:26 Grommish: 01_network / 02_network is used for billing board.json May 20 07:28:47 Grommish: network subnodes in board.json are logical names for interfaces May 20 07:29:10 rmilecki: Ahhh May 20 07:29:15 rmilecki: Thank you :) May 20 07:29:18 Grommish: np May 20 07:34:32 rmilecki: just the first: "is Linux kernel subsystem", either an "a" or "'s" is missing May 20 07:35:09 dhewg: thank you, i don't think i'll ever learn that stuff at not native :/ May 20 07:40:28 rmilecki: personally I'd prefer "switch" or "switch0" May 20 07:40:48 hub! May 20 07:41:23 ynezz: please clarify "hub" meaning for me :P May 20 07:41:36 jow: how to translate that though? May 20 07:41:51 jow: using logical name as part of device name give me unique name May 20 07:41:56 jow: like switch-lan May 20 07:42:30 jow: should we add some global counted in config_generate? May 20 07:42:46 so whenever we see logical network interface with "ports" we use "switch$n"? May 20 07:42:54 n=((n + 1)) then May 20 07:44:13 rmilecki: afair at some point the idea was not to have separate wan + a bridge containing the lan ports May 20 07:44:32 rmilecki: but to have one single global defualt bridge containing all dsa ports, then differentiate using vlans May 20 07:44:43 at least for devices where wan is no dedicated nic May 20 07:45:02 the reasoning was that in theory that should be the most widely supported configuration May 20 07:45:16 we don't have enough info in board.json (or 02_network) to do that May 20 07:45:38 and it makes adding vlans simpler May 20 07:45:41 we don't know if "wan" interface is separated device or switch port May 20 07:45:43 why not? we generate swconfig from the same info May 20 07:46:17 maybe previously existing info got dropped during the migration to dsa because nobody thought about future requirements, but should be easy to ressurrect that info May 20 07:46:20 i think 02_network contain more info for non-DSA switches May 20 07:46:25 right May 20 07:46:48 i also don't like idea of duplicating what is already in .dts May 20 07:46:49 but actually I think it is possible to programmatically figure it out: May 20 07:47:07 - resolve the ifname of wan from board.json / 02_network May 20 07:48:02 - test /sys/class/net/$ifname/uevent May 20 07:48:27 - check for DEVTYPE=dsa May 20 07:48:43 i'm still thinkig about the whole idea of one bridge May 20 07:49:21 having a dedicated lan bridge has its appeal as well, I suppose it is even more intuitive to users than some weird vlan indirection May 20 07:50:33 in the end there is no need to reinvent every single wheel, going back to your initial question, why not simply call it br-lan again May 20 07:50:49 will probably also increase compatibility with various custom scripting and solutions in the field May 20 07:51:11 simplicity is my point, i think having bridge without VLANs for LAN ports is much simpler solution for users May 20 07:51:32 also adding another bridge for grouping selected ports is simpler than having VLANs May 20 07:51:37 and you can have nice bridge names May 20 07:51:53 so you can use "home" and "office" instead of "lan.1" and "lan.2" May 20 07:52:23 and honestly I think VLANs are used by quite few people May 20 07:52:28 (tagging) May 20 07:53:02 likely, yes May 20 07:53:27 the single most common use case "isolate one or more ports from the switch" May 20 07:53:51 i agree May 20 07:54:08 ok, I'll just get back to br- for now May 20 07:54:53 yep, that's sensible May 20 07:55:42 jow: there is one thing, i should probably announce rather than just do it silently May 20 07:55:51 jow: i would REALLY like to backport those recent changes to the 21.02 May 20 07:56:23 21.02 is the first real release with DSA support and I'd like to get users used to one config that will be also used later May 20 07:56:45 i know, it's it a bit risky, sure May 20 07:57:05 but I still think it's worrth for the sake of consistent knowledge & documentation May 20 07:57:55 I don't want all those wiki pages & articles having /etc/config/network & LuCI info split into 21.02 and later releases May 20 08:09:41 they would need to be slit between 19.07 and later release though May 20 08:11:37 zorun: i think DSA was close to unsupported in the 19.07 May 20 08:11:56 ah, right May 20 08:11:56 zorun: no LuCI, no those recent netifd changes May 20 08:12:09 (not mine) May 20 08:12:26 (nbd's netifd changes for DSA from few months ago) May 20 09:20:18 jow: Oh, look, it's firewall5! ;) https://marc.info/?l=linux-netdev&m=162129200229057&w=4 May 20 09:21:31 (Actually, the idea is for the syntax to be the exact same as for iptables, so firewall3 should sufice.) May 20 09:41:49 xback: please see this https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=0e459668c5b3b158991803204f628b1b7dce9034 May 20 09:43:00 blocktrr1: ^^ May 20 09:43:21 ("base-files: generate bridge device sections with br- name prefix") May 20 09:43:30 rmilecki: btw. did you test your ifname->ports rename patch before pushing it? May 20 09:43:40 nbd: i'm quite sure i did May 20 09:44:00 it doesn't even work in dummy mode on a host in my test May 20 09:44:19 nbd: do you mean netifd change or uci-defaults script? May 20 09:44:23 the netifd change May 20 09:45:10 testing now May 20 09:45:49 nbd: i just verified, it works for me May 20 09:46:10 with a config that uses ifname, or with a config that uses ports? May 20 09:46:33 nbd: https://pastebin.com/6DGLSXwt May 20 09:46:57 okay, so you didn't test the actual compat fallback code May 20 09:47:13 nbd: please just show me your config May 20 09:47:32 i tested in dummy mode using the dummy config in the git tree May 20 09:47:40 ah, wait May 20 09:47:47 is dummy mode running on actual device? May 20 09:47:56 no, running on my macos host May 20 09:48:02 /etc/uci-defaults/11_network-migrate-bridges May 20 09:48:19 nbd: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=f716c30241d5fd9d821560f58d0af0c3ffe78600 May 20 09:48:50 but that should sitll work May 20 09:49:19 ah, so you didn't care that i strongly preferred to hold off on automatic migration for now May 20 09:49:42 nbd: wait a second, my brain was trying to work too fast for a moment May 20 09:49:59 nbd: so the old syntax should STILL work, let me verify that May 20 09:51:01 crap, it doesn't May 20 09:52:47 nbd: ok, i found it, "ifname" still works when used to list bridge ports in the "config interface" section May 20 09:52:57 nbd: "ifname" fails when used in "config device" section May 20 09:53:03 that is probably something i didn't test May 20 09:53:25 nbd: i'm appointment at 11:00, i've just run now, i'll be back in 20-30 minutes, i'll fix it then May 20 09:53:26 sorry for that May 20 09:53:40 i'm also a bit annyoed that you went ahead and added the automatic migration anyway after our discussion May 20 09:54:26 but let's discuss this later May 20 09:54:37 i'll fix up the breakage in netifd May 20 10:07:35 can somebody look into this? I'm missing the hardware https://github.com/openwrt/openwrt/pull/4190#issuecomment-844882749 May 20 10:22:28 nbd: i'm back fwiw May 20 10:24:13 nbd: this was expected to handle "config device": May 20 10:24:17 if (devtype && devtype->bridge_capability) { May 20 10:24:18 config_fixup_bridge_ports(s); May 20 10:30:28 i pushed a fix to netifd.git May 20 10:30:42 the fixup code you wrote looks up ifname as a string option May 20 10:30:45 but doesn't handle list May 20 10:30:51 so i changed it to use uci_rename instead May 20 10:30:54 which handles both May 20 10:35:10 i just found that out May 20 10:35:45 yeah, old code was working for option ifname 'lan1 lan2' May 20 10:35:51 it didn't for list May 20 10:37:41 nbd: as for the /annoying/ fixup, I pushed uci-defaults renaming ifname to ports only, what we were discussing (or I was discussing anyway) was implemented as LuCI migration, see https://git.openwrt.org/?p=project/luci.git;a=commitdiff;h=bca76a767316a689d59dfd4974dcb7bfb04db1e8 May 20 10:38:06 that handles old bridge syntax to new bridge syntax (L2 & L3 separated) May 20 10:38:16 and that is done on request only May 20 10:38:46 for automatic sections migration i prepared [PATCH] base-files: migrate old UCI network sections defining bridges https://patchwork.ozlabs.org/project/openwrt/patch/20210518214133.6622-1-zajec5@gmail.com/ May 20 10:39:15 and as I wrote: "I'm not planning to push this patch yet. We may give updated /etc/config/network few months to receive proper testing." May 20 10:42:14 nbd: do you want me to bump netifd? May 20 10:42:17 one side effect of any migration change to /etc/config/network is that it removes any comments May 20 10:42:42 so we shouldn't do this unless it's necessary May 20 10:43:01 i think the ifname->ports migration in the config is unnecessary at this point May 20 10:43:08 we can easily do it as part of the bigger migration later May 20 10:43:21 there's no need to rush this now, since we have the fallback code in netifd May 20 10:43:33 so i'd prefer a revert of that migration for now May 20 10:43:56 nbd: if you want & care about comments, add comments support May 20 10:44:32 I suspect this is a jow question, how can I run a git gc on my staging repo on git.openwrt.org please? May 20 10:44:39 i don't have any time for uci work at the moment May 20 10:44:53 and i don't think that's a valid response to my concern either May 20 10:45:46 and dealing with comments properly in libuci is very much non-trivial May 20 10:45:56 so many corner cases when sections are created/moved or deleted May 20 10:46:20 nbd: ok, so my point is, i'm one of few thinking about end users, their experience and documentation they can use May 20 10:46:47 nbd: if I document "ports", I don't want to care every time of documenting old syntax May 20 10:47:10 and I don't want to confuse users with "ports" if for some reason they see "ifname" May 20 10:47:43 and I believe that more users may need a proper & clear documentation than have any comments in their config files May 20 10:48:49 nbd: as for comments in libuci, handling random comments would be very tricky indeed, but we could add actual comments syntax May 20 10:49:31 i agree that configs should be clear. but since any migration has side effects and the potential to cause disruption, we should not do it very often May 20 10:49:49 since the ifname->ports rename is only the first step, i don't see why we should add migration now May 20 10:50:03 instead of deferring it until the cleanup is done and do the migration in a bigger step May 20 10:50:56 nbd: this is really rather straightforward, sure /string/ was a fail, but i hope there won't be more May 20 10:51:20 as for further steps, it won't really get any ore messy to add them cleanly May 20 10:51:59 nbd: consider checking https://forum.openwrt.org/t/request-for-testing-luci-on-dsa-devices/92126 and how many issues people had with network config May 20 10:52:02 you're completely ignoring that some people may want to test a newer build and then downgrade again May 20 10:52:28 right, you have a point here May 20 10:53:11 just suggest people to take a backup before testing? May 20 10:53:18 if they want to downgrade they can restore backup May 20 10:53:27 * ldir stintel types quicker than I can May 20 10:53:37 stintel: sure, people *can* do that May 20 10:53:52 but not everybody does May 20 10:54:06 stintel: i think i'm getting too tired for that May 20 10:54:41 i'm not saying that we should never break downgrades May 20 10:55:05 i'm wondering if anyone ever tests downgrades May 20 10:55:34 sometimes we might accidentally break it May 20 10:56:58 i just don't see why we should willfully break it for something where there really isn't a good reason to do it *now*, as opposed to postponing it to a later time where it will matter less May 20 11:04:01 ldir: good question, not sure if this is doable w/o shell access May 20 11:04:07 will research May 20 11:07:11 i give up, nbd feel free to revert that if you want to May 20 11:07:13 just personally I find it irritating that noone cares much about network cleanup (it takes me weeks to get some basic plan) May 20 11:07:14 even with some basic plan there is some disagreement that noone cares to sort our (like jow's idea for per-device uci sectinos) May 20 11:07:16 after finally getting it somewhere suddenly I hear how things got wrong May 20 11:07:17 some points may be valie - like downgrades - sure May 20 11:07:19 but with some arguments like the lost of comments in UCI files I feel like tiltint at windmills dealing with them May 20 11:07:25 that's not personal May 20 11:07:38 ldir: meh, the internet poses the counter question "why do you even want that?" May 20 11:08:00 ldir: will do it manually for you now, we might want to consideradding a cronjob May 20 11:08:02 nbd: Revert the migration? What about people who already have the L2 configuration in the new UCI format (e.g. me)? May 20 11:08:08 just an example how lack of proper discussion may end up irritating someone trying some changes May 20 11:08:23 rsalvaterra: nothing, new syntax will be still supported May 20 11:08:32 rsalvaterra: just old syntax users won't get migrated automatically May 20 11:08:53 rmilecki: I suspected that, thanks for clarifying. :) May 20 11:09:14 jow: cos I got "remote: warning: There are too many unreachable loose objects; run 'git prune' to remove them." May 20 11:09:19 rmilecki: don't get upset, your work on this is much appreciated. but to be fair, I did raise the comment aspect as well May 20 11:09:45 it is an unfortunate libuci/uci cli limitation May 20 11:10:03 my perspective is very limited by my own uci usage May 20 11:10:03 and one of the major arguments against it among those who don't like it May 20 11:10:11 but I didn't expect many to use comments in uci at all May 20 11:10:45 many people don't script uci (at least not in write mode) at all May 20 11:11:01 they had type the configs like they would do when e.g. placing apache configs on a centos server May 20 11:11:09 *hand type May 20 11:11:19 I think I've had comments disappear from config files before so I don't expect them to survive :-) May 20 11:11:20 undesratnd May 20 11:12:09 rmilecki: i also appreciate the work you're putting into this. the only reason i'm voicing my concerns is that i want to minimize disruptions caused by cleanup work May 20 11:12:10 I guess only gui users have no expectations about the exact config formatting May 20 11:12:19 the "weird" thing is that, by default, the firewall config has comments May 20 11:12:32 so when editing it, there is some expectation that they would remain May 20 11:12:43 right, things like that add to the confusion May 20 11:12:54 but as soon as you modify it through LuCI or UCI scripting, poof, all your comments disappear (which is indeed annoying) May 20 11:13:09 jow: rmilecki: nbd: Can I just say thank you to all for keeping things civil & cooperative - I can read that there's clearly some frustration both ways for you all and I was a bit worried at one point - thanks for working through it May 20 11:13:11 zorun: wow, i didn't realize that firewall thing May 20 11:14:03 nbd: ok, you're for reverting "base-files: migrate old UCI network bridge ports syntax" May 20 11:14:16 i'm truely neutral at this point May 20 11:14:36 anyone else with opinion? May 20 11:15:00 I'd prefer reverting this particular bit as well, but please keep all the rest May 20 11:15:07 btw I'm all for cleaning up the network config, thanks for tackling this, but it's a huge undertaking May 20 11:15:13 also related documentation May 20 11:15:30 rmilecki: I'm with jow, just reverting the automigration will sufice. May 20 11:15:44 right. i also want to keep all the rest May 20 11:15:56 i take it for settled then May 20 11:15:57 *the uci-defaults migration, the ui migration should stay May 20 11:16:03 jow: ack May 20 11:16:16 jow: i'll need to add ports migration *to the LuCI* then May 20 11:16:32 along with the bridge one, right? May 20 11:16:40 it's fine. I guess we can gradually expand it May 20 11:16:47 yes, but I'll need to check here now May 20 11:16:53 *two checks May 20 11:23:10 ldir: I gc'ed, can you check if the warning is gone? May 20 11:23:26 could also consider enabling autogc on all repos May 20 11:23:43 I'd go for the autogc May 20 11:25:40 looks like it's fixed - ty May 20 11:26:43 yay May 20 11:34:39 could someone look at https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=1e763bbcefa985d5a1a9021cf5112c9e97e4aa46 to make sure I'm not about to make a fool of myself May 20 11:42:00 is coverity now going to whinge "you discarded the return value from munmap"? May 20 11:44:52 (void) munmap(...) :) May 20 11:44:58 learn from the elders May 20 11:48:36 it's a bit daft anyway, if the close fails ultimately we're going exit anyway so worrying about a memory leak... still let's do the right thing. May 20 11:49:32 not sure if closing before unmapping is the right order anyway? May 20 11:49:39 I would likely simplify it into: May 20 11:49:45 (void) munmap(...); May 20 11:49:49 (void) close(fd); May 20 11:50:08 and do not care about adding yet more logic May 20 11:52:49 it's apparently legal to mmap a file, then close the FD. - this munmap only happens if the close fails May 20 11:55:41 it's basically the error path and coverity is saying 'you could still have the mmap stuff allocated after the close' May 20 12:07:59 ldir, shouldnt error handling in that part of code (return value mmap) use "MAP_FAILED" like man page or standard doc suggest ? May 20 12:17:30 plntyk: I wasn't planning on re-writing the whole thing. May 20 12:18:53 the original coders are relying on a non-null return pointer as being the pointer to the mapped file. NULL = failed in some way, non null = "there's your file data" May 20 12:21:20 The returned pointer is checked as "if (!input_file) " which tweaks my pendant mode/confusing over whether NULL really, always, equals 0 - and should the test more accurately written as if (input_file == NULL) May 20 12:24:19 but then I look at http://c-faq.com/null/ptrtest.html and decide to stop worrying May 20 12:26:53 Someone looked at if (input_file == NULL) and said, I bet I coud save a few bits there.. :D May 20 12:35:45 hehe May 20 12:41:37 jow: when editing "interface" in LuCi and changing "Protocol", input "Device" disappears until user confirms a new protocol May 20 12:41:54 jow: Device ("ifname" option) could stay there as its protocol independent May 20 12:42:07 can you help me change that behaviour? May 20 12:42:08 https://git.openwrt.org/?p=project/luci.git;a=blob;f=modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js;h=4eccc0beb5fcb7f29c533dced01200275c7df0c2;hb=HEAD#l459 May 20 12:49:49 o.modalonly = true; doesn't fix that May 20 13:05:30 jow: ok, i've fixed that 907b4222f70b3351d590d8a2e35c21a4ae07db8d ("luci-mod-network: don't hide "Device" on protocol change") May 20 14:12:43 Hey, is it known that downloads.openwrt.org is down? Its only nginx greeting May 20 14:13:09 works for me May 20 14:13:40 can you tell me which serverip you got? May 20 14:14:53 168.119.138.211 May 20 14:16:33 ok its a different one, i got mirror02 ... however https is working May 20 14:17:20 downloads.openwrt.org is an alias for mirror-02.infra.openwrt.org. May 20 14:17:20 mirror-02.infra.openwrt.org has address 168.119.138.211 May 20 14:17:20 mirror-02.infra.openwrt.org has IPv6 address 2a01:4f8:251:321::2 May 20 14:19:37 yeah, its working right now May 20 14:39:50 stintel: i just stumbled over a thread in which we (among others) discussed xbmc/kodi running on/in openwrt (raspberry pi back then) and i wonder how far you got? May 20 14:40:04 mirko: oh I had it running fine May 20 14:40:35 but it's outdated May 20 14:41:17 stintel: that's amazing! i used to play around with sunxi HW the past years and have kodi running fully opensource on Allwinner's H6 - incl. opensource opengles2 implementation as well as h264/h265 video decoding May 20 14:41:26 I should probably pick up my work on the meson target again and try to get kodi running on it with vanilla kernel May 20 14:41:37 figured it might be a good point in time to reconsider having kodi supported May 20 14:42:02 stintel: what was your graphical platform? gbm? May 20 14:42:10 I have no clue :D May 20 14:42:11 wait May 20 14:42:39 https://github.com/stintel/lede-wip/blob/master/kodi/Makefile May 20 14:42:45 should be visivle from the cmake flags.. May 20 14:42:46 ah May 20 14:44:15 hm, it doesn't say, not sure what the default is, but for AW I think there's nothing else than GBM anyway (despite Xorg which I won't fancy anyway) May 20 14:44:54 maybe 17.x was before gbm ? May 20 14:45:39 stintel: could be as well.. do you mind me using your base to level things up and make it running on AW-H6? i might break x86/rpi on the way, though.. May 20 14:46:06 not at all, just attribute me if you push it somewhere :) May 20 14:46:11 but i think from a fully vanilla and open source version it's better to deal with the quirks than the other way round May 20 14:46:41 stintel: cool, i'll see how far i get with the resource i have atm May 20 14:47:18 I'm on some ELEC build atm on my Khadas VIM3 and VIM3L May 20 14:47:35 last I tried vanilla kernel wasn't ready yet May 20 14:53:19 interesting, never heared of those SBCs May 20 14:53:30 i'm on an orangePi3 (AW-H6 as said) May 20 14:54:47 latest version (yet to be merged into linux/master) supports 4K and HDR May 20 14:58:00 VIM3 and VIM3L also do 4K + HDR May 20 15:05:07 ....was an issue with local dns.... May 20 15:30:35 rmilecki: ping May 20 15:30:46 xback: pong May 20 15:31:11 rmilecki: I just checked the latest master state from 30 minutes ago May 20 15:31:18 I can confirm that br-wan etc is now created again May 20 15:31:20 but .. May 20 15:31:36 testing on Mikrotik shows that custom MAC addresses are not written to /etc/config/network anymore May 20 15:31:41 https://pastebin.com/raw/jZdSRURg May 20 15:32:25 xback: does it really have 2 WAN ports and 1 LAN port? May 20 15:33:46 rmilecki: that is a custom change of mine where I shifted eth1 from LAN to WAN May 20 15:34:14 xback: ok, good to oknow May 20 15:34:24 xback: i'll fix mac addresses tomorrow May 20 15:34:30 LAN always gets created, even if you don't want one May 20 15:34:30 thanks for testing May 20 15:34:56 this part is missing on config May 20 15:35:01 config device 'wan_eth0_dev' May 20 15:35:02 option name 'eth0' May 20 15:35:03 option macaddr '74:4d:28:b9:14:8c' May 20 16:14:43 aparcar[m]: LOL! The nslookup change broke my DDNS update script. :P May 20 16:23:45 nbd: jow: do we need aliases (option ifname @foo) if we have devices (config device)? May 20 17:01:22 rsalvaterra: is this ddns-scripts or something else? May 20 17:05:01 ldir: It's my tiny custom ad-hoc update script, 100 % event-driven. :) May 20 17:05:38 * ldir feels less guilty May 20 17:05:42 ldir: No periodic execution at all. May 20 17:06:06 Hey, hence the "lol" part. I'd bite you guys if you reverted the change. :P May 20 17:09:24 nslookup-lede added numbering to the address lines ("Address 1:", "Address 2:", etc.), and I was parsing the output with awk '/^Address\ 1\:/' {print $2}'. May 20 17:10:41 Without numbers, to get the first address, I had to change to awk '/^Name:/ {getline; print $2; exit}'. No biggie. :) May 20 17:11:28 (And I just noticed I don't need to escape the colon.) May 20 17:16:08 * ldir needs to go to the dr about the escaped colon May 20 17:17:13 rsalvaterra: my own domain resulted in https://github.com/openwrt/packages/commit/8ae2b12d2b483c2fc710f0d474d74d5f4a5b29c8 May 20 17:18:00 of course it all happened around the same time as the nslookup change, so I naturally assumed that was the culprit May 20 17:29:43 ldir: This is my ad-hoc script… https://paste.debian.net/1198254/ May 20 17:33:06 that's remarkably straightforward. May 20 17:33:28 ldir: It better be. My shell-fu is weak. :P May 20 17:34:10 it's better than mine!!!! May 20 17:34:27 I just have to relearn everything anytime I want to do something. May 20 17:35:03 I feel you, believe me… :P May 20 17:38:27 didn't know about /etc/udhcpc.user.d or for that matter /etc/odhcp6c.user.d May 20 17:40:00 * ldir is constantly annoyed by ddns-scripts ipv6 support that always misses the ipv6 prefix delegation that happens on the same ISP facing interface so it never starts the ipv6 ddns address update May 20 17:45:23 I tried ddns-scripts, but I always had to fiddle with the configuration too much to get them to "work". May 20 17:47:25 But that was before I learned ddns-scripts does periodic checks/updates and does not rely on DHCP events, which is just stupid. May 20 17:48:48 * rsalvaterra wonders how much load could be alleviated from free DDNS services by only issuing updates when the IP address(es) actually change(s). May 20 18:06:15 think the ddns-scripts were written in very not mature days and needs an overhaul May 20 18:16:03 there are situations when you cant use DHCP events tho (and cannot determine your own external IP "locally") May 20 20:15:50 Hello, there is a new consortium of sorts for distros using musl, the point of which is to enable better collaboration to deal with upstreams. We'd like to invite openwrt to the channel -- #musl-distros on OFTC, and (which does or will shortly have a mailing list at "distros.musl.libc.org"). Participation is not required, but we'd love to have you. May 20 23:08:47 Hi, busybox can no longer compile with glibc since https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b36b8b6929c6d6b17edddfb4597cf6a26a991ed0 May 20 23:09:56 did you take a look at https://github.com/openwrt/openwrt/pull/4190 ? May 20 23:11:00 Thank you, did not see that May 21 01:07:16 for the ath79 target what is the etc/board./01_leds file for and how do i get these magic constants that sometimes are used? May 21 01:54:45 i've changed my mind about using nginx until i can cross compile nginx unit. uhttp is great especially with the LuCI interface May 21 02:20:08 from my experience last night uhttp was faster for LuCI than nginx anyway. nginx is great if you have a bigger purpose than LuCI. i think right now uhttpd i relatively secure out of the box and its probably compiled specifically for LuCI and LUA May 21 02:20:29 is that right... does LuCI use LUA? **** ENDING LOGGING AT Fri May 21 02:59:56 2021