**** BEGIN LOGGING AT Fri Oct 02 02:59:57 2020 Oct 02 03:17:54 there is no AR9xx *SOC*, the wireless chipsets are usually called AR9xxx. you are probably looking for AR71xx/ ath79 instead Oct 02 03:18:59 (o.k., there is AR9132 as the exception to the rule, but that's covered by ar71xx/ ath79 as well) Oct 02 05:24:34 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.) Oct 02 06:42:55 is there a doc on how the require directive works in LuCI JS API? Oct 02 06:43:10 i couldn't find it in luci's github wiki Oct 02 07:21:10 i recently noticed /tmp/overlay is that some kind of replacement for/equivalent of /tmp/root? Oct 02 07:26:38 build #461 of ipq40xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ipq40xx%2Fgeneric/builds/461 Oct 02 07:41:05 hgl: no dedicated doc for it, but I can answer any question you might have Oct 02 07:42:17 'morns! Oct 02 07:42:55 jow: thanks. my first question is how does it actually work ๐Ÿ˜‚. does the js file have to be compiled for the require directive to work? Oct 02 07:43:33 <_lore_> hi all, is there anyone running OpenWrt on netgear r6260 recently? Oct 02 07:44:20 any script might help me understand how it works? Oct 02 07:44:32 hgl: no, luci.js require() function downloads the .js file via xhr, scans its source for the magic 'require ...' tokens, creates a function, compiles it and evaluates the resulting code. There is no need for compilation Oct 02 07:44:36 yes, sec Oct 02 07:45:52 hgl: https://github.com/openwrt/luci/blob/master/modules/luci-base/htdocs/luci-static/resources/luci.js#L2436 Oct 02 07:46:08 thanks. checking Oct 02 07:46:23 pretty neat trick from your description Oct 02 07:55:36 makes sense. ideally, luci could use a interpreter that supports es module Oct 02 07:57:03 but current implementation is pretty straightforward Oct 02 07:58:35 so far I tried hard to avoid any extra frameworks or precompilation tools Oct 02 07:58:54 only node stuff is for the jsdoc handling and this comletely optional Oct 02 07:59:02 *this is completely Oct 02 08:02:50 i mean the ecma2016 stuff like `require network from "network"`, v8 directly supports it. not sure if it's easy to bring to the luci js interpreter though. Oct 02 08:03:14 ah you mean supporting the ES6 *syntax* for module imports? Oct 02 08:03:18 yes Oct 02 08:03:35 like somehow arrange for the stuff to be loaded in the background before feeding it to eval() Oct 02 08:03:50 oh `import network from "network"` Oct 02 08:04:09 how is the class loading in ES6 in the browser? Oct 02 08:04:24 or must the script file providing "network" be preloaded (e.g. by webpack etc.) Oct 02 08:04:27 ? Oct 02 08:04:33 the interpreter is supposed to download the script and eval it, it should just work directly in the script Oct 02 08:04:41 damn, bad typing today. How is the class loading working Oct 02 08:05:10 ah okay. Might be worth a consideration when we move to ES6. Right now the codebase is strictly ES5 to retain IE compat Oct 02 08:06:02 yeah, it's pretty new stuff. makes sense to make IE compat Oct 02 08:07:27 i'm trying to write a protocol handler, but the program that is supposed to configure it insists it creates the interface itself, and the ifname is not customizable. should i use no_device=1 in the netifd/proto script? Oct 02 08:09:39 yep Oct 02 08:09:58 i currently use no_device=1, and also wrote a luci proto script copying from ppp.js. the interface is not stoppable in the page, and the interface name is currently [proto]-[config name], which doesn't match the created interface name. any way to solve that? Oct 02 08:10:22 not sure if ppp.js is the best role model Oct 02 08:11:04 https://github.com/openwrt/luci/blob/master/protocols/luci-proto-vpnc/htdocs/luci-static/resources/protocol/vpnc.js Oct 02 08:11:26 oh, thanks. taking a look Oct 02 08:12:07 these $proto-$name ifname format is an old relict where most openwrt proto handlers used to produce predictable names Oct 02 08:12:38 if the ifname is managed externally then simply set the fallback value to something sensible (e.g. tun0 or whatever happens to be the most common name) Oct 02 08:12:48 seems still similar to ppp.js, which sets floating and virtual to true, and getDevices to null? Oct 02 08:13:03 it is only displayed as greyed out hint in the ui if the actual ifname cannot be resolved (e.g. due to the iface being down) Oct 02 08:13:37 (iirc) been a few months since I actually touched this stuff Oct 02 08:13:38 sorry, i don't quite follow. where to specify the fallback value? Oct 02 08:14:02 I mean the `|| 'vpn-%s'.format(this.sid)` in line 13 Oct 02 08:15:01 ah, yes, i have hard-coded that line actually, `return 'utun'`, but in the page it still displays $proto-$name Oct 02 08:15:35 where exactly? Oct 02 08:16:29 could it be that the value comes from ubus? Oct 02 08:16:43 check "ifstatus yourlogicalname" Oct 02 08:16:51 and see what is reported in l3_device Oct 02 08:16:52 network -> interfaces. I have `config interface vpn\n\toption proto 'proto'` in config/network Oct 02 08:19:35 it returns a json object, but without any key called `l3_device`, i guess it's because i only specified option proto ? Oct 02 08:21:46 hgl: ah wait, its the default implementation of LuCI's getDevice() which makes up a $proto-$name device if the protocol is virtual Oct 02 08:22:10 so i should return the interface name in getDevice? Oct 02 08:23:20 sec Oct 02 08:25:06 try this implementation: https://pastebin.com/iBYdqKRA Oct 02 08:25:24 in any case this is only cosmetical and only affecting the state when the interface is not actually up Oct 02 08:26:01 since your "ifstatus vpn" is not reporting any l3_device, it means that the resulting netdev (utun?) is not being registered properly with netifd Oct 02 08:26:23 so it is considered "down" by the system Oct 02 08:26:35 great, with that line, it's now utun Oct 02 08:26:50 that makes sense Oct 02 08:26:59 how do i register it with netifd? Oct 02 08:27:13 should i call some ubus stuff? Oct 02 08:27:15 I assume you based your shell proto handler on ppp as well? Oct 02 08:27:43 no, it's a barebone one Oct 02 08:27:58 no_device=1 available=1 lasterror=1 in init_config Oct 02 08:28:07 and proto_run_command in setup Oct 02 08:28:09 that's it Oct 02 08:31:32 if i override getDevice, i guess there is no need to override getDevices? Oct 02 08:32:19 hgl: yeah, I guess you can ommit it Oct 02 08:33:36 cool Oct 02 08:36:31 for the ppp shell proto handler, the interface registration happens from an "up" script Oct 02 08:36:56 https://github.com/openwrt/openwrt/blob/master/package/network/services/ppp/files/lib/netifd/ppp-up#L5 Oct 02 08:37:15 IFNAME has been added as env variable to the pppd process and the IPPARAM refers to the logical network name, e.g. "wan" Oct 02 08:38:29 so in your case it would be proto_init_update utun 1 1; ... proto_add_$stuff ...; proto_send_update vpn Oct 02 08:38:32 i guess ppp-up is called by the ppd daemon? Oct 02 08:38:35 yes Oct 02 08:38:38 ppp Oct 02 08:38:45 once the connection has been negotiated Oct 02 08:39:06 I suppose your daemon process does not support/use callback scripts Oct 02 08:39:09 the program doesn't support up/down scripts ๐Ÿ˜‚ Oct 02 08:39:16 lol Oct 02 08:39:18 yep Oct 02 08:39:26 right, but it is a long-running process? Oct 02 08:39:30 yes Oct 02 08:39:41 so it more like vpnc or openconnect Oct 02 08:40:46 checking its package Oct 02 08:41:17 nvm, vpnc uses a callback script as well Oct 02 08:41:58 is it something detectable directly? Oct 02 08:42:29 i think at least the kernel has the knowledge when the interface is created and when it's up? Oct 02 08:44:25 can you share your current implementation? Oct 02 08:44:39 sure, sec Oct 02 08:48:57 hgl: I think what you need to do is first invoking proto_run_command() to invoke your vpn daemon Oct 02 08:49:12 netifd will consider the interface "alive" as long as this daemon process uis running Oct 02 08:49:56 then you need to supply netifd with state information about the interface. Usually this is done from a vpn-daemon specific callback script which supplies all the required info (ip, peer-ip, etc.) once connected Oct 02 08:50:16 since you do not have this facility in your case, you can simply provide the info manually directly after proto_run_command Oct 02 08:52:40 how to run command after proto_run_command? i think it's asynchronous? Oct 02 08:52:48 my implementation: https://gist.github.com/hgl/4d742d30286a209cef43a456715a3aab Oct 02 08:54:01 https://pastebin.com/hBgVsUKi Oct 02 08:54:06 it should look like this Oct 02 08:54:51 i'll give it a shot Oct 02 08:55:00 the example I pasted would tell netifd that there's a p-t-p interface $tundev with local ip 1.2.3.4, peer 5.6.7.8 Oct 02 08:55:13 and that it should add a default route 0.0.0.0/0 via 5.6.7.8 to it Oct 02 08:55:33 this obviously needs to be adjusted to whatever your vpn protocl actually provides Oct 02 08:57:19 yes, this program actually connects to multiple points and automatically load-balances. i was hoping netifd could offer me an hook to do ifupdown, and I'll set up iptables and ip rule then Oct 02 08:57:51 let me try proto_init_update first. i think it can at least tell netifd the interface is up? Oct 02 08:58:07 yeah Oct 02 08:58:14 awesome Oct 02 08:58:15 you probably also need proto_set_keep 1 Oct 02 08:58:31 otherwise netifd will attempt to recreate the interface itself from the supplied info Oct 02 08:59:37 so proto_run_command vpn /usr/sbin/....; proto_init_update utun 1 1; proto_set_keep 1; ...potential ip config details...; proto_send_update vpn Oct 02 09:00:20 where "vpn" refers to the uci section (logicial network) name Oct 02 09:00:26 and "utun" to the linux netdev name Oct 02 09:01:44 you should be able to execute proto_init_update ... proto_send_update at any point in time to update the interface runtime state Oct 02 09:01:56 could happen from e.g. a hypothetical monitor process Oct 02 09:02:19 sorry, every time i do `service network restart`, i cut myself off ๐Ÿ˜‚ Oct 02 09:02:50 ok, so you mean i should execute them later, and not directly after proto_run_command? Oct 02 09:03:14 no I mean you could potentially execute them multiple times later if the runtime state of the device happens to hcange and you want to reflect that in netifd Oct 02 09:03:37 executing it once right after run_command is likely fine Oct 02 09:03:41 ah, i see Oct 02 09:03:50 however I think it could result in a race condition Oct 02 09:04:14 I suppose your vpn daemon needs some initialization time, so the "utun" netdev will not be available immediately Oct 02 09:04:54 i agree. hmm, how could i delay executing them? Oct 02 09:05:13 you might need something like while [ ! -e /sys/class/net/utun ]; do sleep 1; done between proto_run_command and proto_init_update Oct 02 09:05:45 good idea Oct 02 09:06:39 maybe with some additional abort condition (e.g. fail after 10 seconds and invoke proto_notify_error vpn CONNECT_FAILED instead) Oct 02 09:07:18 you are the man! it's now stoppable and RX/TX starts to show counts. Oct 02 09:08:00 are these proto_init_update proto_notify_error commends documented anywhere? Oct 02 09:09:16 and stopping it works correctly too! Oct 02 09:10:11 should i directly call my custom ifupdown scripts after proto_send_update or use more proper mechanism like hotplug? Oct 02 09:10:42 unfortunately not but you cna find a reference of them in the source here: https://lxr.openwrt.org/source/netifd/scripts/netifd-proto.sh Oct 02 09:11:22 essentially these shell functions are convenience wrappers which format appropriate json messages which are then sent via ubus call network.interface notify_proto ... Oct 02 09:11:43 netifd then receives these json messages and acts accordingly Oct 02 09:12:05 e.g. for a run_command message it will spawn and monitor the specified command line Oct 02 09:12:19 ah, the dots start to connect Oct 02 09:12:27 for an init_update message it will extract the embedded ip config details and add them to its runtime state Oct 02 09:13:07 and there's two fundamental styles of proto handlers Oct 02 09:13:49 1) proto handlers that spawn the interfaces directly through netifd, e.g. for tunnel interfaces like ipip, 6in4 etc. Oct 02 09:14:24 2) proto handlers that launch a process that eventually spawns a netdev (openconnect, vpnc, openvpn, pppd) and which later update the runtime state of that external netdev Oct 02 09:14:38 your proto handler falls in the latter category Oct 02 09:14:43 right Oct 02 09:15:04 so the relevant calls for your are proto_run_command, proto_kill_command, proto_init_update, proto_send_update, proto_notify_error Oct 02 09:15:33 yes, makes perfect sense Oct 02 09:16:21 and i assumed the two styles are controlled by no_device? Oct 02 09:16:25 *assume Oct 02 09:17:07 I forgot about the actual implications of no_device but iirc it essentially tells netifd that this proto handler is spawning its own netdevs nad not operating on top of existing ones Oct 02 09:17:18 like e.g. dhcp, that assumes an existing ethernet netdev Oct 02 09:19:18 which is the second style you were saying? or is there a difference i missed? Oct 02 09:20:16 pppoe is a special case for example Oct 02 09:20:29 it requires a lower netdev but spawns an additional one on top Oct 02 09:21:53 i think my vpn also falls under this special case? Oct 02 09:21:57 so no_device is not strictly related to fact whether a proto handler spawns its netdev through netifd or an external process Oct 02 09:22:12 it requires a wan to bring up a new interface Oct 02 09:22:17 I don't know, depends on how your vpn is operating Oct 02 09:22:34 if it just requires layer 3 routing, then it is no_device 1 Oct 02 09:22:55 if it somehow binds to netdevs on layer 2 then it is no_device 0 Oct 02 09:23:03 oh, i see Oct 02 09:23:39 it can still creates the interface without wan, just offers no connections on its own created interface Oct 02 09:23:40 and in the latter case those lower netdevs it binds to would be usually configurable by the user Oct 02 09:24:14 e.g. in the case of pppoe, through "option ifname" Oct 02 09:24:29 i see Oct 02 09:24:39 so it'll run on top of eth0, but spawn an pppoe-wan tundev Oct 02 09:25:05 https://gist.github.com/jow-/0774c09f12df8e587d141a8c6aff8bd7 Oct 02 09:25:17 this is how I'd implement error handling in your proto handler Oct 02 09:26:01 wait, so if eth0 is not available, pppoe daemon won't be able to even bring the interface up? Oct 02 09:26:12 yep Oct 02 09:27:02 why couldn't it create the interface, but wait for eth0 to be up to actually forward connections? Oct 02 09:27:15 because it has not been implemented this way Oct 02 09:27:21 ah Oct 02 09:27:38 many unix services have similar ... weaknesses or design decicions Oct 02 09:28:55 thanks for letting me stealing your code :) Oct 02 09:29:13 (I forgot a sleep 1 in the initial revision) Oct 02 09:30:24 I'd imagine it is easier to code such way that an existing device is assumed Oct 02 09:30:37 hence we see such Oct 02 09:30:56 in principal less checks and so on Oct 02 09:31:12 not that it is best approach, but was thinking of the "why" :) Oct 02 09:34:54 i guess i will at least find some time to expand this doc: https://openwrt.org/docs/guide-developer/network-scripting Oct 02 09:36:41 jow, i still have one puzzle left: how do i call ifupdown scripts? i think i can directly call one after proto_send_update, and after proto_kill_command? Oct 02 09:37:12 but that doesn't feel like the proper way to call them, should i use hotplug scripts? Oct 02 09:39:08 Hi guys, please may I get some feedback/thoughts on https://patchwork.ozlabs.org/project/openwrt/patch/20200926150623.42441-1-nick.lowe@gmail.com/ Oct 02 09:40:26 hgl: what do you mean with ifupdown scripts exactly? Do you mean the interface hotplug in /etc7Hotplug.d/iface/ ? Oct 02 09:41:41 yes Oct 02 09:41:58 those should be invoked automatically now that the state tracking ios fixed Oct 02 09:42:12 oh right Oct 02 09:42:25 i'll add a script to try Oct 02 09:42:53 oh, another small issue Oct 02 09:44:21 since the daemon controls the interface, and it's not possible to customize the name, that means it can only have one such interface. i guess it's not possible to enforce such uniqueness in the LuCI web interface? Oct 02 09:44:47 actually we added validation hooks a while back Oct 02 09:44:55 which you could use or that Oct 02 09:45:16 sec Oct 02 09:45:16 nice! are they available in 19.07 or snapshot? Oct 02 09:46:17 https://github.com/openwrt/luci/blob/master/protocols/luci-proto-bonding/htdocs/luci-static/resources/protocol/bonding.js#L138 Oct 02 09:46:41 return null = allow to continue, return string = ui error Oct 02 09:48:19 ok, but how do I check if there already exists an interface in js? Oct 02 09:50:15 https://pastebin.com/VnT9d8G9 Oct 02 09:51:14 thank you! Oct 02 09:51:52 i probably should have known this, since LuCI has an API doc Oct 02 09:53:39 btw, i just remembered it's possible to run es6 code in old IE with a loader like this: https://github.com/ModuleLoader/es-module-loader Oct 02 09:54:36 not sure why the repo is archived, probably the author is focusing on systemjs instead, which uses this loader Oct 02 09:55:37 but it could bring in babel transpiler and stuff into the runtime, might not be suitable for space constrained routers Oct 02 10:01:22 jow: is isCreatable available in snapshot only? not seem to take effect in my 19.07.4. Oct 02 10:02:29 seems to be the case, there is no isCreatable in my network.js Oct 02 10:03:39 yeah, could be that we didn't backport it Oct 02 10:05:24 jow, thanks for the hand holding, I learned a lot today Oct 02 10:05:54 yw Oct 02 10:13:42 if ifname is hard-coded, is network.registerPatternVirtual needed? from networks it seems it's ultimately used by isVirtualIfname to set some tunnel flag Oct 02 10:14:19 you could use network.registerPatternVirtual('^utun$') Oct 02 10:14:37 iirc in the end it causes the device to be shown with a little tunnel icon instead of an ethernet plug icon Oct 02 10:15:09 and it will be filtered out in various places, e.g. bridge config dialogs, where "virtual" ifaces are considered not be eligible for ethernet bridges Oct 02 10:15:46 ah, i see Oct 02 10:16:04 yes, i current do have it. was wondering if it's really needed Oct 02 10:16:21 it also is an old relict Oct 02 10:16:31 nowadays luci asks the kernel for the device type Oct 02 10:16:39 but that only works if the device is present Oct 02 10:17:00 as a fallback, the type is guessed based on the name Oct 02 10:17:24 yeah, probably should still be provided by the package Oct 02 10:17:31 it knows better Oct 02 10:26:10 once the vpn is up, i'd like to change dnamasq's upstream DNS. i initially tried just using uci to change it and then reload dnsmasq, and restore it once vpn is down, but when i found out if the router was shutdown ungracefully, once it's powered up again, the DNS is incorrect. any way to temporarily change the setting? Oct 02 10:26:33 i guess i have to directly manipulate the generated dnsmasq.conf? Oct 02 10:30:26 you can push upstream dns servers through your proto handler Oct 02 10:30:41 but you cannot really replace them as this would be a user decision Oct 02 10:30:52 not replace them through a proto handler that is Oct 02 10:31:13 uci could uci set without uci commit and restart dnsmasq Oct 02 10:32:11 oh right, i don't have to commit it Oct 02 10:34:02 the daemon also comes with its own dns relay that does some additional translation, ideally i could let user configure DNS in the package i'm creating, and point dnsmasq to this relay. User specified ones are used in the relay. Oct 02 10:37:11 i do have to wipe out user's previous DNS settings. is there a canonical way to stow them away temporarily so I could restore them once the vpn is down? Oct 02 10:37:42 oh, since i didn't commit i could just reset? Oct 02 10:38:09 yes Oct 02 10:38:17 great! Oct 02 10:38:19 theoretically you could simpyl reset and invoke "ubus call network reload" Oct 02 10:38:53 what "ubus call network reload" is for? Oct 02 10:39:05 you mean dnsmasq reload? Oct 02 10:39:25 it globally reloads all network settings and only executes the bare minimum to reach the desired state Oct 02 10:39:43 as a side-effect that should restore /tmp/resolv.conf.auto which is then picked up by dnsmasq Oct 02 10:41:12 i want to make sure the vpn is not leaky, so i'll actually uci set dnsmasq's noresolv Oct 02 10:41:53 to make the relay the sole upstream server Oct 02 10:42:12 i guess in that case i should do dnsmasq reload? Oct 02 10:42:15 maybe some kind of iptables based itnerception would be more rleiable Oct 02 10:42:22 *reliable Oct 02 10:42:35 oh Oct 02 10:43:53 uhh, not seems to be easy. because i don't want to affect router's own traffic Oct 02 10:44:04 only those from dnsmasq Oct 02 10:45:21 dnsmasq blends in with router's own dns requests Oct 02 10:49:22 FW rule from an zone what steers all port 53 queries to certain IP? This is how I once did ssid honeypot when someone(s) tried to hack in too much Oct 02 10:49:46 (well was part of it) Oct 02 10:52:11 the problem is that i end to differentiate port 53 queries via dnsmasq from those from router itself, like opkg download request for example. Oct 02 10:52:26 I gave em easy access ssid that only showed kitten pics Oct 02 10:52:47 lol cute Oct 02 10:53:11 *need Oct 02 10:54:05 Router should request those from wan zone.. lan is your target there (or wharever zone you name) Oct 02 10:55:57 In my case I targeted honeypot zone.. lan and wan etc was not affected Oct 02 10:56:33 aren't dnsmasq requests to upstreams also from wan zone? Oct 02 10:57:12 hgl: iirc dnsmasq has an option to mark its own dns requests with a connection mark Oct 02 10:57:25 not sure if its baked in by default Oct 02 10:57:40 oh that's cool Oct 02 10:57:51 let me check Oct 02 10:59:11 With FW rule one can target indeed exactly an zone or even single IP (irrelevant of dnsmasq), but ofcourse propably plenty methods exists Oct 02 12:32:27 so after playing with nft for a bit I must say I am not overly impressed Oct 02 12:32:51 so you cna nest stuff with curly braces now, but apart from that it feels extremely verbose Oct 02 12:33:01 and declaring chains via the cli is a major pita Oct 02 12:55:15 it seems they really want you to write rules in a file Oct 02 13:00:53 i heard eBPF is supposed to replace nft? but i never found its cli Oct 02 13:06:27 jow: I'm waiting for bpfilter, but not holding my breathโ€ฆ nftables is only slightly more performant than iptables, I don't believe it's worth the learning effort. Besides, bpfilter is supposed tu use iptables syntax. Oct 02 13:06:40 *supposed to Oct 02 13:13:02 what I do like about nft is the anonymous sets Oct 02 13:13:25 nft add rule ip filter output tcp dport { 22, 23 } ... Oct 02 13:13:34 so no more chain indirection to target multiple things Oct 02 13:27:27 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.) Oct 02 13:51:28 is it possible to view the stdout & stderr of the command executed by proto_run_command? Oct 02 13:53:40 nvm, found it. procd_set_param stderr 1 Oct 02 13:54:14 wait, that's not for netifd Oct 02 14:01:44 i end up using sh -c to redirect stdout & stderr to files Oct 02 14:06:56 jow: with the previous discussed protocol handler script, does netifd change the interface's IP? Currently when I bring up the interface in LuCI web, the interface created by the daemon lacks ipv4, only ipv6 exists. But if I start the daemon normally, ipv4 is configured. From daemon's stdout when it was started by netifd, it showed it configured ipv4 correctly, and there were no errors. Oct 02 14:07:23 seems ipv4 were removed after the interface was brought up Oct 02 14:12:53 hgl it is probably stripped by netifd Oct 02 14:13:10 you need to send the effective ipv4 along with the update Oct 02 14:13:43 oh, the ipv4 option you previously mentioned Oct 02 14:14:16 is it possible to get it from the interface and let netifd know? Oct 02 14:14:35 or ask netifd to directly read from the interface? Oct 02 14:14:53 netifd oes not support externally managed ip config Oct 02 14:15:10 you could read it using ifconfig or "ip addr" in your shell handler, then send it to netifd Oct 02 14:15:26 ah, right Oct 02 14:18:12 proto_add_ipv4_address seems to expect a ptp address Oct 02 14:18:24 which the interface does not have Oct 02 14:18:36 is it ok to leave it? Oct 02 14:22:26 seems to be the case, it's ultimately passed as an array to netifd, which i guess netifd would just ignore it if it's empty? Oct 02 15:13:42 * enyc meows Oct 02 15:19:24 hgl: yes, iirc the arguments are ipaddr, prefix, broadcast, ptp Oct 02 15:19:29 hgl: the last two are esclusive Oct 02 15:19:34 *exclusive Oct 02 15:20:13 and if you omit both broadcast and ptp, netifd should assume non-ptp and calculate the broadcast addr automatically Oct 02 15:20:22 but I didn't verify Oct 02 16:16:07 since we were just discussing whether a switch should have dhcp enabled by default or not, I wondered: Oct 02 16:16:47 could we provide a set of simple "setups" like e.g. router, switch and "dump ap" that will allow to enable/disable services at runtime Oct 02 16:18:35 i.e. en/disable dhcp, firewall, etc. altogether ... Oct 02 16:20:39 or is this too specific for the general approach of OpenWrt Oct 02 16:56:05 adrianschmutzler I would like to have this to. Like a switch to change from router to dumb Ap or plane switch moad. Oct 02 16:57:19 but since this is an obvious feature, I suspect there is a reason why we don't have it Oct 02 16:58:28 I also think disabling services is not update-safe either ... Oct 02 16:58:39 update->upgrade Oct 02 17:03:12 adrianschmutzler I think it's just that there is not the time / manpower to do it and make it work. Oct 02 17:04:33 Or a safety thing, if you install openwrt on a device without dhcp enabled it becomes signifcantly more difficult to talk to it out of the box. Oct 02 17:05:51 pgwipeout[m]: Yes, I'm mainly interested in the ability to change that at runtime here Oct 02 17:06:12 changing the default is actually quite easy by just not installing the relevant packages ... Oct 02 17:09:25 One can always compile own with own settings.. or use imagebuilder :) Oct 02 17:20:19 Yes, this is merely about convenience, particularly for a non-educated user Oct 02 17:20:45 adrianschmutzler: imho this is a slippery slope Oct 02 17:20:58 soon enough people want to implement all kinds of highly specific corner cases Oct 02 17:21:31 I think OpenWrt could need some generic default config templating Oct 02 17:24:12 I do see that problem; next would be NAS, repeater, ... Oct 02 17:24:55 but actually I'm still thinking how one would implement something like that cleanly at all Oct 02 17:25:57 since what I have in mind is essentially disabling whole services, so it should not affect "config" at all (at least directly) Oct 02 17:26:51 of course I can just put /etc/init.d/dnsmasq stop into a uci-defaults script ... Oct 02 17:28:10 right Oct 02 17:29:03 however I wonder whether we should start storing the init script enabled status in a configuration file Oct 02 17:29:16 or rather the disabled status, for safety reasons (corrupted config etc.) Oct 02 17:29:22 something like that is what I'm looking for Oct 02 17:29:33 that would also solve the sysupgrade problem Oct 02 17:30:09 indeed. actually, I'm in a very early stage and just sorting/organization thoughts in my brain right now Oct 02 17:32:32 such a file might become a seek-and-replace nightmare though Oct 02 17:33:04 I was thinking about using a further section in /etc/config/system Oct 02 17:33:34 config init-scripts; list disabled dnsmasq; list disabled uhttpd; ... Oct 02 17:34:18 is there an uci del-list or similar command to remove a single specific entry? Oct 02 17:34:34 yes Oct 02 17:34:50 Well here's an unexpected side effect of the opkg change to https, the certificates package needs to be installed by default now or opkg doesn't work at all on new installs. Oct 02 17:34:51 uci del_list system.@init-scripts[0].disabled=uhttpd Oct 02 17:35:23 ah, wasn't aware of that, that's quite helpful Oct 02 17:35:41 there are a few usability quirks though Oct 02 17:35:52 I'm not sure yet whether uci is the right place, but that could work relatively cleanly Oct 02 17:36:12 jow: did you see https://github.com/openwrt/openwrt/pull/3477 ? Oct 02 17:36:25 aparcar[m]: I've seen the title, yes Oct 02 17:36:48 so, would you hook this to /etc/init.d/* disable then or just leave it for the user? Oct 02 17:37:22 adrianschmutzler: in a first step I'd probably make procd aware of that new "killswitch" and make it emit a log message if an init script is symlinked but disabled in uci Oct 02 17:37:27 so far, we just delete the rc.d file/link? Oct 02 17:38:04 adrianschmutzler: later we can think about extending the service command (service foo enable/disable) and forwarding /etc/init.d/foo enable/disable there Oct 02 17:39:03 though it should probably be done in one go to avoid inconsistencies from a user pov Oct 02 17:39:29 yes. but thanks, that's a good starting point to play around with this idea Oct 02 17:39:49 might still prove to be overcomplicated after all Oct 02 17:43:10 by that, one could also make a quick switch between router/switch/dump-ap a mere LuCI option just setting these disabled options Oct 02 19:05:09 If a package needs openssl host support, do I just do the +libopenssl in the depends or do I have to call it elsewhere? Oct 02 19:09:32 Grommish: i am a package newbie but i think something like: PKG_BUILD_DEPENDS:=libopenssl/host Oct 02 19:10:33 that package doens't have a host section though Oct 02 19:10:47 which is what I was asking.. it might just be having to try and point it at the lib dir Oct 02 19:14:18 I have a feeling it's just rust being difficult again Oct 02 19:28:36 this is not up my ally i am afraid Oct 02 19:28:43 jow: is gpio-export exposed to LuCI? Oct 02 19:28:48 adrianschmutzler: no Oct 02 19:29:54 so, if I want to remove devicename-prefix from line-name there like I did with the LEDs, it probably won't hurt anyone since the value isn't stored anywhere anyway ... Oct 02 19:30:45 tp-link:usb:power -> usb:power ... Oct 02 19:31:23 Are the 03_gpio_switches definitions exposed to LuCI? Oct 02 19:36:11 does not look like it does either Oct 02 19:36:15 Hi guys, I've submitted a PR to add board support and have received feedback, I'm wondering if the preferred ettiqutte is for me to resolve the comments as I fix the issues, or to leave that up to the maintainer Oct 02 19:36:33 I think it's you, actually, adrianschmutzler haha Oct 02 19:36:57 Well, if I said remove "x" and you removed x, just resolve it Oct 02 19:37:19 Perfect, thanks. Oct 02 19:37:44 What I personally don't like is if something is marked as resolved when there is still ongoing discussion Oct 02 19:38:15 E.g. you have a different opinion than I have, you decide that your opinion is "better" and close it Oct 02 19:38:38 In cases like this, I prefer to keep stuff open so others can share their views Oct 02 19:39:04 Of course, I understand that - Didn't want to go through marking things like "drop x" as resolved if the maintainer wanted to do this themselves though Oct 02 19:39:10 Trying to avoid toe-stepping, always :) Oct 02 19:40:26 In your case, I'd e.g. keep stuff like the wifi-led or the MAC address discussion open Oct 02 19:41:37 or for the size of the firmware partition, I actually asked a question, so an answer would be nice :-) Oct 02 19:43:21 don't want to sound too pedantic, but 1. I am pedantic and 2. you asked ;-) Oct 02 19:48:56 Ok.. I did actually laugh at that adrianschmutzler Oct 02 19:53:23 Why, did I say anything funny? Oct 02 20:00:20 adrianschmutzler: You.. pedantic? never Oct 02 20:01:05 I just call it attentive to detail Oct 02 20:01:11 Space, Space, Tab Oct 02 20:01:23 formalities Oct 02 20:01:54 actually, I was pissy about it as anyone else I suppose.. in the end, i realized it was the correct way to do things Oct 02 20:25:07 anyone here developing the target oxnas? Oct 02 20:25:26 It's the only target that has UBIFS_FS_SECURITY enabled per default. Oct 02 20:25:32 Why? Oct 02 20:26:45 daniel did the last kernel bump and a few other changes there ... Oct 02 20:27:07 ^ aparcar[m] Oct 02 20:27:27 have you tried to git blame it to a specific commit already? Oct 02 20:27:29 curious I'll ping him Oct 02 20:28:34 Oh 2018, that's long before selinux Oct 02 20:28:43 but from target history he is definitely the right person to ask Oct 02 20:28:57 Will do thanks Oct 02 21:14:46 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.) Oct 02 21:37:57 build #644 of oxnas/ox820 is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/644 blamelist: Adrian Schmutzler , Jo-Philipp Wich , John Audia , Pawel Dembicki Oct 02 21:40:54 Hauke: here is the 18.06 patch to support newer minor revisions of mikrotik hardware: https://patchwork.ozlabs.org/project/openwrt/patch/20201002213705.1189117-1-baptiste@bitsofnetworks.org/ Oct 02 21:41:55 it's already been backported to 19.07 as https://git.openwrt.org/3fecb06fb1b0 Oct 03 00:01:49 jow: is there a list of the openwrt GNU target triples anywhere by chance? Oct 03 00:02:28 ala mips64_openwrt_linux_muslabi64 Oct 03 00:45:03 aparcar[m]: why package apk? Oct 03 00:49:18 mangix: because opkg gives me a hard time Oct 03 00:49:57 i see. anyway, musl does not support ARC. Oct 03 00:50:17 thus alpine linux does not either Oct 03 00:52:14 Yea but it's C, shouldn't that somehow run on ARC? Oct 03 00:53:02 i mean you could do it but what's the point? Oct 03 00:53:39 there are no installable packages Oct 03 00:55:24 mangix: http://sprunge.us/PlcsCv Oct 03 00:55:26 i believe gcc defines __arc for ARC Oct 03 00:57:03 I could also add a target depends Oct 03 00:57:41 to prevent it from building, !CONFIG_arc should be enough Oct 03 00:58:22 erm, sorry, @!arc Oct 03 01:00:55 I should maybe do the opposite and only enable specific targets Oct 03 01:05:34 mangix: maybe we should add those fancy colours to the default entrypoint.sh? https://github.com/openwrt/packages/pull/13540/files Oct 03 01:08:46 up to you Oct 03 01:09:11 replace those echoes with printf Oct 03 02:17:34 mangix: will do, thanks Oct 03 02:41:05 aparcar[m]: wrong order of @!arc Oct 03 02:42:10 Ty **** ENDING LOGGING AT Sat Oct 03 02:59:57 2020