**** BEGIN LOGGING AT Wed Sep 25 02:59:57 2019 Sep 25 04:49:39 aparcar[m]: didn't think in detail yet - maybe by adding dummy signatures in buildroot and "patch" or replacing them using fwtool on the build master or repo server later Sep 25 04:49:59 jow: I send a patch to the mailing list Sep 25 04:50:20 thanks, will look later. Sep 25 05:00:03 jow: the script is rather a proof of concept, I guess it should be integrated into the build master directly Sep 25 06:00:38 build #337 of x86/generic is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/x86%2Fgeneric/builds/337 Sep 25 06:14:01 aparcar[m]: it looks well from a first glance Sep 25 06:30:50 sss Sep 25 06:30:53 soory Sep 25 07:40:26 are there any plans/wip to support device tree overlays? Sep 25 07:42:21 dhewg: On what systems? I think those are supported, like on ath79 etc, maybe plenty others I don't use :) Sep 25 07:42:41 only raspi, and only because of out-of-tree patches Sep 25 07:43:09 it's prolly only interesting to sbc's, like to enable spi on sunxi or omap Sep 25 07:43:51 uboot supports device tree overlays just fine, you just have to have a dtb with symbols and the overlay files Sep 25 08:12:15 from shell, how can I retrieve the local lan subnet ? Probably a magic uci incantation. Or point me at a web page. Sep 25 08:15:41 ldir: How do you identify your lan interface? Sep 25 08:17:25 I usually just run "ip -4 -j addr show dev br-lan" (for example) and then use json parsing tool of choice to extract the address/prefixlen Sep 25 08:18:14 "ip -4 -j ro" is another option Sep 25 08:18:19 "ubus call network.interface dump" would be the openwrt config as json Sep 25 08:18:41 # (. /lib/functions/network.sh ; network_get_subnet subnet lan; echo $s Sep 25 08:18:41 ubnet) Sep 25 08:18:43 10.11.12.13/24 Sep 25 08:19:40 also returns 0/1 so you can use it in conditions Sep 25 08:20:02 if network_get_subnet subnet "$some_interface_name"; then echo "$some_interface_name has subnet $subnet"; fi Sep 25 08:20:09 nice Sep 25 08:23:24 I have earlier used ipcalc to achieve something similar, but this is much better. And one less piece of software to worry about Sep 25 08:26:14 thanks all - helpful Sep 25 08:43:39 for bonus points - is there a way to translate a physical interface, say 'eth0' into relevant logical interface/s ? Sep 25 08:45:14 if interested...for backgroup - sqm-scripts deals in physical interfaces, but for iptables type purposes I need subnets / prefixes Sep 25 08:47:59 background - I can't type. Been up since 0330 Sep 25 08:48:12 # devname="eth0"; ubus call network.interface dump | jsonfilter -e "@.interface[@.device='$devname' || @.l3_device='$devname'].interface" Sep 25 08:48:19 this may result in multiple names Sep 25 08:49:59 err wow! Will give that a try Sep 25 08:50:04 to translate it into subnets right away, you can use this: Sep 25 08:50:06 devname="eth0"; eval $(ubus call network.interface dump | jsonfilter -F "/ " -e "SUBNETS=@.interface[@.device='$devname' || @.l3_device='$devname Sep 25 08:50:09 ']['ipv4-address'][*]['address','mask']"); echo $SUBNETS Sep 25 08:50:10 meh, moment Sep 25 08:50:46 https://pastebin.com/b6VprUX8 Sep 25 08:57:20 * ldir thinks it must be nice to get able to write that sort of thing off the top of your head Sep 25 09:02:30 repetition is key in general I'd say 🙂 You do a thing long enough you'll get the gist... for that particular usage area yo udo at the least and I think jow has that =) Sep 25 09:07:06 jow: fyi, i ported all relevant upstream changes from nft_flow_offload to xt_FLOWOFFLOAD, and now it seems to work well again on 4.19. i'm going to push the fix in a few minutes Sep 25 09:07:35 on an ath79 device it increased throughput from ~290 mbit/s to ~890 mbit/s Sep 25 09:10:50 nbd: that's.. shit ton :D Sep 25 09:11:57 yep :) Sep 25 09:14:47 nbd: any reason to keep the local patches compared to upstream? if yes, is it an option to send the local hacks upstream? Sep 25 09:20:50 when i wrote the xt_FLOWOFFLOAD target, i think it wasn't wanted upstream, because the main focus was developing nftables and not adding more features to legacy iptables Sep 25 09:21:16 however i think that changed over time and more features for legacy iptables were added Sep 25 09:21:26 but i don't have time to push it Sep 25 09:21:35 so it would be helpful if somebody else would attempt that Sep 25 09:21:49 regarding hw offload support, that requires at least one driver that's clean enough for upstream inclusion Sep 25 09:22:07 because i don't think they are going to merge the support code without a single in-tree user Sep 25 09:22:43 and the ethernet driver situation on mtk is a bit messy there Sep 25 09:24:47 ok. thanks for the insights :) Sep 25 09:25:24 build #350 of x86/64 is complete: Success [build successful] Build details are at http://release-builds.lede-project.org/17.01/images/builders/x86%2F64/builds/350 Sep 25 10:27:00 good morning! Sep 25 10:29:33 nbd: great - thank you! Sep 25 11:35:55 jow: i've problem with LuCI which incorrectly complains during flash with "It appears that you are trying to flash an image that does not fit into the flash memory, please verify the image file!" Sep 25 11:36:13 jow: the problem is findStorageSize() which finds "linux" partition size instead of "firmware" partition size Sep 25 11:37:22 jow: https://pastebin.com/jDeStt5v Sep 25 11:37:47 jow: on brcm47xx "firmware" mtd partition is where image gets flashed and "linux" mtd partition is just a kernel Sep 25 11:38:31 findStorageSize() first sets wholesize to my "firmware" partition size (good) but then it sets (overwrite) wholesize to my "kernel" partition size Sep 25 12:11:24 What do I need to do first in order to be able to use json_select? I am trying to test something on the shell directly before put it in the script... and I get this Sep 25 12:11:32 rmilecki: please try this: http://sprunge.us/w5KzvN Sep 25 12:11:39 root@OpenWrt:~# json_select systemWARNING: Variable 'system' does not exist or is not an array/object Sep 25 12:11:54 json_init or json_load Sep 25 12:11:59 to setup a working stack Sep 25 12:12:00 thanks Sep 25 12:12:34 by the way, do you think I should store in the board.json the oem wifi ssid and key? Sep 25 12:12:56 msgito: personally I'd be fine with it Sep 25 12:13:13 my point is, either dump into wireless directly from json, or dump it first to /etc/config/system Sep 25 12:13:42 I think it's better and clean directly from json Sep 25 12:13:55 yes, it'll also allow reset to defaults Sep 25 12:14:08 rmilecki: ping Sep 25 12:14:27 rmilecki: I have been playig around with 53xx in the last days Sep 25 12:14:47 I am seeing that when i do wifi->eth i am getting ~500mbit Sep 25 12:14:52 so openwrt/package/kernel/mac80211/files/lib/wifi/mac80211.sh would be loading it directly from board.json Sep 25 12:14:59 but when i do eth->eth it cpas around 250 Sep 25 12:15:21 rmilecki: and doing a perf i see that around 40% cpu load is consumed by cache ops Sep 25 12:15:33 rmilecki: is this normal ? or what numbers should i expect ? Sep 25 12:16:52 root@OpenWrt:~# json_init root@OpenWrt:~# json_select system WARNING: Variable 'system' does not exist or is not an array/object Sep 25 12:25:36 jow: this doesn't work: size = parseInt(match[1], 16); Sep 25 12:25:46 jow: match may be null/false/something Sep 25 12:26:17 flash.js?v=git-19.267.64604-66749b4:165 Uncaught (in promise) TypeError: Cannot read property '1' of null Sep 25 12:27:12 blogic: i started doing big NAT performance research months ago but didn't finish that Sep 25 12:27:22 blogic: i'm planning to get back to it in next month or two Sep 25 12:28:50 jow: other than that it works as expected (function returns 16449536 which is my "firmware" size) Sep 25 12:29:09 rmilecki: make it size = match ? parseInt(match[1], 16) : 0; Sep 25 12:29:18 that's what I tried Sep 25 12:29:20 and it works now Sep 25 12:29:51 rmilecki: so this is a known issue ? Sep 25 12:29:55 blogic: yes Sep 25 12:30:10 blogic: you can find my old e-mails about weird NAT performance results Sep 25 12:30:37 blogic: e.g. [PATCH RFC] kernel: drop -fno-reorder-blocks Sep 25 12:30:39 there were more Sep 25 12:30:41 jow after doing json_init or load still nothing Sep 25 12:34:38 msgito: define "still nothing", and provide more context Sep 25 12:42:31 I did json_init, and then json_select system, but I get error. Tried json_init, json_load $(cat /etc/board.json) but I get "failed to parse message data" Sep 25 12:53:05 Hello all, should patches be tagged with [PATCH] as documented or with [Openwrt-Devel] as I see almost all do? Sep 25 12:56:36 aliemjay: with [PATCH] as documented - [OpenWrt-Devel] will automatically added by the mailing list software Sep 25 13:01:05 [patch] will be added by things like git-send-email too... Sep 25 13:01:15 that as well Sep 25 13:04:28 ok, thanks Sep 25 13:23:58 msgito: "failed to parse message data" sounds like an ubus client error, not something emitted by any of the json_* functions Sep 25 13:54:21 msgito: quotes Sep 25 13:54:36 msgito: quote your $() argument Sep 25 13:56:57 thanks Sep 25 15:00:51 Do I need to do anything else when I do a commit to my PR with label "need changes"? How do people know that changes are applied? Sep 25 16:31:01 nbd, do you checking your FLOWOFFLOAD changes in browser before commit? Sep 25 16:32:12 I mean checking how router/network with those changes working after in any browser Sep 25 16:35:58 got built with commit b2c55d50f8aeb21ef4cd3948034a158f7dd743c2 and most of the websites couldnt do TLS handshake and return: PR_END_OF_FILE_ERROR Sep 25 16:39:10 didn't do a browser test, but ran a bunch of other tcp/udp tests Sep 25 16:39:19 thanks for letting me know, i will investigate Sep 25 16:39:25 MY-R: there are two additional commits after the one you mention Sep 25 16:39:42 including "kernel: port another missing upstream change to xt_FLOWOFFLOAD on 4.19" Sep 25 16:39:56 zer0def, ye noticed them but no time do build again Sep 25 16:40:05 sorry, zorun ^ Sep 25 16:40:38 nbd, well ye, https connection by wget/curl, pings etc was working but stuff in browser didnt Sep 25 17:39:08 MY-R: it seems i found the cause of this issue (a leftover patch incompatible with recent changes) Sep 25 17:39:17 going to push some fixes soon Sep 25 17:39:53 nbd, oh great :) Sep 25 17:43:04 is nice too see somebody working on it (FLOWOFFLOAD stuff) thanks nbd Sep 25 18:12:15 MY-R: fix pushed Sep 25 18:16:39 copy that! Sep 25 18:22:20 rmilecki: thanks for the luci patches, will look at them tomorrow Sep 25 18:22:58 rmilecki: without deeper review I can already tell that you will need to whitelist the new rpc procedure in modules/luci-base/root/usr/share/rpcd/acl.d/luci-base.json Sep 25 18:24:17 basically add "system": [ "validate_firmware_image" ] in the "write": { "ubus": { ... } } section of the file Sep 25 18:25:30 nbd: do you plan to backport the flow offload updates or can you tell if they're backportable to 4.14 without larger changes? Sep 25 18:29:08 yes Sep 25 18:30:36 going to wait for a bit more feedback Sep 25 18:30:43 maybe i'll push it tomorrow or the day after Sep 25 19:25:40 jow: ah, I did that locally & forgot about it afterwards! Sep 25 19:26:01 MY-R: please let me know when you've tested my changes Sep 25 19:32:48 nbd, sure, I will have image in few minutes and put in main router :P Sep 25 19:51:53 nbd, so far so good :) and flowoffload working! Sep 25 19:57:37 during 94 mbit speed test cpu usage is just 1% higher than on 4.14 so prety sure that would get without any problem at least 900 mbits on tp-link wdr3600 Sep 25 20:14:24 rmilecki: you see the umdns failure? Sep 25 20:31:32 MY-R: i easily got around 900 mbit/s on an archer c7 v4 Sep 25 20:36:27 :) **** ENDING LOGGING AT Thu Sep 26 02:59:57 2019