**** BEGIN LOGGING AT Fri Jun 01 03:00:10 2018 Jun 01 03:03:38 Is there a nodogsplash irc channel Jun 01 03:24:52 MrFantastik: ask in the github page Jun 01 03:25:25 people who have issues usually get answers there Jun 01 03:26:46 I don't have an issue, more of a implementation question, I feel like it would be inappropriate to open an issue for basically tech support Jun 01 03:29:12 It looks like they have a mailing no list but idk the etiquette for a mailing list Jun 01 04:16:53 MrFantastik: people are communicating from all over, just ask in a clear and direct way and some will probably help you out Jun 01 04:21:55 Okay I will, thanks I appreciate the guidance Jun 01 04:31:03 morning Jun 01 04:48:47 blogic: morning, is this one on your radar? https://patchwork.ozlabs.org/patch/921907/ Jun 01 04:58:40 Hi has any one had a look at 18.06 bug: Flow Offload Active Connections Jun 01 06:19:18 Tapper: link ? Jun 01 06:29:26 anyone have any feelings about the ath25 series ? Jun 01 06:29:46 its yet another sub target but it does debloat heavily and makes 4.14 usable on the units Jun 01 06:43:31 Hi blogic when I go to the email list I get a 404 Jun 01 06:43:50 The email said Jun 01 06:43:52 Dear all, Jun 01 06:43:52 Whenever flow offload is enabled (either software or hardware) I can Jun 01 06:43:52 see many many active connections on the Luci overview page. It can go Jun 01 06:43:52 up to thousands of active connections. Looking in the "connections" Jun 01 06:43:52 part of the "realtime graphs" in Luci shows me that even connections Jun 01 06:43:52 with devices that turned off hours ago are still active. So for some Jun 01 06:43:52 reasons old connections are not leaving the conntrack table. Turning Jun 01 06:43:53 off flow offload fixes these issues right away. I am currently running Jun 01 06:43:53 the latest 18.06 snapshot on a dir-860l. Hopefully this is useful Jun 01 06:43:54 information for debugging. Jun 01 06:43:54 Yours sincerely, Jun 01 06:43:55 Jaap Buurman Jun 01 06:44:24 ok Jun 01 06:44:27 nbd: ^ Jun 01 06:46:31 What do youmeen by the char ^ ? Jun 01 06:46:55 its an arrow pointing up Jun 01 06:47:04 as in nbd, read whats above this line Jun 01 06:47:21 Ok thanks :-) Jun 01 06:47:52 It makes my screen reader say the word carrot! Jun 01 06:48:09 ^^ Jun 01 06:57:00 🥕 Jun 01 07:33:28 blogic: I've replied on list, i'll be online for the next while if you wanted to discuss. Thanks for looking at it. Jun 01 07:45:06 hello, is anyone here tracking this bug? https://forum.lede-project.org/t/mt76-stopped-working-with-latest-updates/14623/70 Jun 01 08:08:39 mangix: not near my unit til next week sorry. Jun 01 08:18:11 * ldir chuckles at the carrot ^ caret screen reader interpretation - brilliant. Jun 01 08:19:38 hello gendlemen, and ladies, i'm very new but trying to learn and contribute. I'm trying to install kmod-mt76 on the latest kernel (4.14.44), but the package says the kernel version is too new. where do i modify the package so i can install it? Jun 01 08:19:49 Is it possible to speed up OpenWRT Luci WebUI by compiling lua files with luac ? Jun 01 08:20:49 Here is my console output: Jun 01 08:20:51 root@OpenWrt:~# opkg install kmod-mt76 Installing kmod-mt76 (4.14.44+2018-05-18-0b8d1dde-1) to root... Downloading http://downloads.lede-project.org/snapshots/targets/ramips/mt7621/packages/kmod-mt76_4.14.44%2b2018-05-18-0b8d1dde-1_mipsel_24kc.ipk Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-mt76: * kernel (= 4.14.44-1-cfa316e572ea7fa890feb6abb050c445) * kernel (= Jun 01 08:26:37 aside from just compiling it Jun 01 08:35:25 jow: ^^ isn't that biangbiangmian's problem something that was supposed to be fixed by your changes? Jun 01 08:35:46 jow: that change with keeping per-kernel-build kmod packages Jun 01 08:38:48 rmilecki: maybe his build isn't official Jun 01 08:39:00 kernel must be one of these: http://downloads.lede-project.org/snapshots/targets/ramips/mt7621/kmods/ Jun 01 08:39:12 biangbiangmian: where did you get that firmware from? Jun 01 08:39:34 pulled it from the master branch Jun 01 08:39:40 so selfbuilt Jun 01 08:39:45 yes Jun 01 08:39:52 biangbiangmian: you can't use kmod packages from our server for self built images Jun 01 08:39:54 selfbuilt images cannot use repo kmods Jun 01 08:40:03 biangbiangmian: copy kmod you need from your bin/ directory Jun 01 08:40:06 and install it locally Jun 01 08:40:12 opkg install /tmp/kmod-foo.ipk Jun 01 08:40:13 ah thanks Jun 01 08:40:29 easy Jun 01 08:40:31 :) Jun 01 08:40:46 but how about that wifi problem? it's a real head scratcher isn't it Jun 01 08:44:56 uh, that's a long thread with quite some offtopics Jun 01 08:46:43 biangbiangmian: according to the https://github.com/openwrt/mt76/issues/173 it's fixed by "ramips: Fix WiFi after 5f7396ebef09b224edf08b0bda113613a42f0928" Jun 01 08:46:47 biangbiangmian: can you confirm that? Jun 01 08:47:16 i tried it earlier and it is not working for me Jun 01 08:50:15 blogic: this commit seems to be causing regression: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=5f7396ebef09b224edf08b0bda113613a42f0928 Jun 01 08:50:44 blogic: reported in https://github.com/openwrt/mt76/issues/173 and also on forum (forum report mixed two separated issues and there is some noise there) Jun 01 08:51:39 rmilecki: it looks as if it came from upstream (at least I can't imagine that gregkh sends openwrt patches now) Jun 01 08:51:53 blogic: there are links to 3 out of tree commits that were supposed to fix this, don't know much about it Jun 01 08:51:53 rmilecki: so it'll come back with a future kernel bump and bite us again Jun 01 08:52:03 so either fix it now or tell upstream to clean up Jun 01 08:52:49 blogic: according to the https://github.com/openwrt/mt76/issues/173 it was supposed to be fixed by https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=02f815d1907cdd7e042415a2b4a749c819087168 Jun 01 08:52:56 according to biangbiangmian that doesn't really fix the problem Jun 01 08:53:27 rmilecki: some users reported that they had to remap irqs Jun 01 08:53:27 jow: right, i see Jun 01 08:53:43 so I think the fix you linked is correct, it jsut doesn ot cover all cases Jun 01 08:54:02 apparently some boards need nonstandard irq setup or something Jun 01 09:38:27 ok Jun 01 09:38:37 i will revert all recent mt7621 patches Jun 01 09:40:02 if my board needs non-standard irq's can i override that in my .dts file? Jun 01 09:40:52 rephrasing the question: can i override something in the .dtsi by using a .dts? Jun 01 09:43:39 i nuked the whole lot Jun 01 09:43:52 biangbiangmian: please test latest HEAD from 1 minute ago Jun 01 09:44:05 i will fix this properly once we rebase to that kernel version Jun 01 09:44:18 pulling master now Jun 01 09:44:25 i knew it was a bad idea to merge all these backports Jun 01 09:44:43 should hav listened to my gut feeling Jun 01 09:47:37 blogic: yeah. that's basically how dts works. for instance, in a dtsi, most stuff is status = "disabled", but you activate it in dts :) Jun 01 09:47:42 erm, biangbiangmian ^ Jun 01 09:47:51 ? Jun 01 09:48:31 ah ok i see Jun 01 09:50:32 * ldir searches for 'DTS for dummies' Jun 01 09:50:55 ldir: a good read, to be sure. think its called 'devicetree for dummies' however :) Jun 01 09:51:05 * ldir hopes it exists Jun 01 09:52:14 it does Jun 01 09:52:16 this is what i read https://saurabhsengarblog.wordpress.com/2015/11/28/device-tree-tutorial-arm/ Jun 01 09:52:47 https://events.static.linuxfound.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf Jun 01 09:53:47 ^ nice Jun 01 09:53:48 wow - thank you. maybe I'll even understand some of dts Jun 01 09:53:50 also, its honestly pretty easy to grok, if you understand kernelstuff already. best way I've found to learn is read existing dts/dtsi in upstream linux and u-boot and see how things are done :) Jun 01 09:54:31 "if you understand kernelstuff already" ha - there's the flaw right there :-) Jun 01 09:54:42 hehe. well, learn it! :D Jun 01 09:55:54 I've only been involved in linux since 2013 or so, and only really hardcore the past two years or so, and I grok it enough to have ported a chromebook (asus c201 4GiB [veyron speedy]) to u-boot and the glinet ar300m to dts in openwrt :) Jun 01 10:07:33 i bet everyone has their IRC clients set up to be pretty comfy, but has anyone brought up the idea of moving to something like Slack? Jun 01 10:07:46 begone! Jun 01 10:08:39 sorry if i double posted, my session got disconnected Jun 01 10:08:55 doesn't appear you did. Jun 01 10:09:18 Praise Bob, no double posting here... Jun 01 10:10:16 * ldir does not need yet another f*ing messaging platform. Jun 01 10:10:31 if it aint broke, dont' fix it. Jun 01 10:14:41 Christ, I can barely even log in to my Fonera any more Jun 01 10:14:44 no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 Jun 01 10:16:53 You can override that. The web will explain. Jun 01 10:16:59 yeah Jun 01 10:17:06 that DTS for dummies link is good! Wish i'd read that a few months ago Jun 01 10:17:14 but then I learn it's running a 2.6.11.7 kernel and I get even sadder Jun 01 10:17:30 really need to find a way to make the fon spot stuff actually work on an updated OpenWRT Jun 01 10:20:19 wifi is showing up properly for the kernel, now the moment of truth: enabling and connecting Jun 01 10:20:23 blogic: did you actually want changes with that mvebu patch? Jun 01 10:38:10 having a bit of trouble getting it to actually broadcast it seems Jun 01 10:38:30 i have wpad-mini installed, should i go with wpad? Jun 01 10:39:26 last time all i needed to get it working was the mt76 drivers, and wpad-mini Jun 01 10:50:28 blogic: if you're gonna revert the pci driver, revert my fix wifi commit too as it's no longer valid Jun 01 10:51:08 ah nvm i missed it Jun 01 11:00:52 pkgadd: what packages did you install in order to be able to mount the mmcblk0p10 partiton? Jun 01 11:06:41 build #891 of brcm2708/bcm2709 is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2709/builds/891 blamelist: John Crispin , Koen Vandeputte , Daniel Golle , Alex Maclean , Hans Dedecker Jun 01 11:06:41 , Kevin Darbyshire-Bryant , Mirko Parthey Jun 01 11:07:11 ERROR: "ipv6_push_frag_opts" [net/ipv6/ip6_tunnel.ko] undefined! Jun 01 11:07:13 ^^ Jun 01 11:07:48 that should be fixed since https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=daa73b63d5dc5eb264341336c0d7cd64d750664d Jun 01 11:08:01 dedeckeh: can you look at that? Jun 01 11:09:27 rmilecki:should be fixed now by https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b7735d8113ce57d2d1a9c720e2e62750705bd8f7 Jun 01 11:09:49 oh, great ,thanks! Jun 01 11:11:51 rmilecki:credits should go to dangole :) Jun 01 11:12:00 thanks for the info :) Jun 01 11:12:03 dangole thanks for the fix :) Jun 01 11:13:09 but it got reverted..... and in theory is no longer required since the kernel bump.... so talk about me being confused! Jun 01 11:17:46 Lantis: no, all ready to go an in my local tree Jun 01 11:18:42 mangix: i'll look at that lot again next week Jun 01 11:19:11 blogic: thanks :). appreciate you taking the time to look too, i wasn't meaning to give you a hurry up, just checking it was still on someones todo list Jun 01 11:19:54 Lantis: turns out the shitty code style problems were there before you touched the patch :-) Jun 01 11:20:02 otherwise i'd have asked for it to be fixed up Jun 01 11:20:05 :P Jun 01 11:25:21 blogic: lol! i wouldn't have blamed you Jun 01 11:26:08 lidr:hmmm you removed patch 095-v4.12-ipv6-Need-to-export-ipv6_push_frag_opts-for-tunnelin in the kernel upstep Jun 01 11:26:34 ldir:afaik this patch is only present since 4.12 Jun 01 11:26:52 yes cos it could be reverse applied Jun 01 11:27:08 ldir:which triggers the build issue again in the build bot Jun 01 11:27:32 ldir:are you sure ? Jun 01 11:29:37 when I did the bump it definitely could be reverse applied, hence being included for removal. But I think between the bump & committing the original apply commit was reverted. So I'm no longer sure what that means :-) Jun 01 11:31:18 revert the kernel bump. I'll have another go after the revert and seeing some buildbots go through. Jun 01 11:36:04 lidr:patch is still required as ipv6_push_frag_opts is not exported https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/net/ipv6/exthdrs.c?h=linux-4.9.y#n734 Jun 01 11:36:24 lidr:will fix it Jun 01 11:47:31 Can anyone help me out with this? I'm looking at what's on my netgear r7800 and I'm interested in this partition: Jun 01 11:47:33 cat /proc/mtd Jun 01 11:47:39 mtd7: 04480000 00020000 "netgear" Jun 01 11:48:08 block info produces: /dev/mtdblock7: UUID="0" VERSION="1" TYPE="ubi" Jun 01 11:48:20 how do I mount it to take a look inside? Jun 01 11:49:26 huaracheguarache: http://www.linux-mtd.infradead.org/faq/ubi.html#L_attachmtd Jun 01 11:49:51 dedeckeh: thanks - I genuinely don't understand what has gone on with that. Have locally reverted the kernel bump and re-doing to see if I get the same result. Jun 01 11:51:12 rmilecki: thanks! I'll have a look =) Jun 01 11:53:53 ha - my refresh happened after https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=daa73b63d5dc5eb264341336c0d7cd64d750664d and before the very next commit https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2087df1c6d38333aa1d8f87eb7b29a85b5863bd5 Jun 01 12:00:26 ldir:my fault Jun 01 12:03:22 he he - np - /me disables panic mode :-) Jun 01 12:22:36 blogic: i saw you reverted ramips patches on master, should it be merged to 18.06 as well? Jun 01 12:23:05 running 1806 on zbt1326 but no 2.4Ghz due to mt76 bug :( Jun 01 12:30:01 the reversion seemed to halfway fix (my) problem, the devices are now showing up, just can't broadcast Jun 01 12:31:42 blogic: no reverts on 18.06 for mt7621? Jun 01 12:33:24 the "fix wifi after ..." commit namely Jun 01 12:34:18 just noticed ausjke msg. I'm running on wg3526 Jun 01 12:34:47 seems most issues are on zbt devices, I see no complaints from eg DIR860 or xiaomi owners Jun 01 12:36:17 i'm reverting on 1806 branch and see it makes any difference Jun 01 12:47:54 can not revert cleanly anymore Jun 01 13:08:25 Hey all! Is there a way to build the latest openwrt, but using the 4.9 kernel, instead of the 4.14, due to some stability issues? Jun 01 13:35:43 build #875 of ixp4xx/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ixp4xx%2Fgeneric/builds/875 Jun 01 14:05:31 on zbt1326 after reverted NeilBrown's patches I can now see two wifi phy0 and phy1, but can not bring up wifi Jun 01 14:05:38 on 1806 branch that is Jun 01 14:19:57 I'm using the latest SDK and receive the following error when reloading feeds: Jun 01 14:19:58 `.xargs.bin: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.` Jun 01 14:19:59 Anyone ideas what happens? Jun 01 14:22:16 regarding the latest mt7621 changes, 2 of us are seeing the same message Jun 01 14:22:45 Fri Jun 1 13:08:46 2018 daemon.notice netifd: radio1 (1189): cat: can't open '/var/run/wifi-phy1.pid': No such file or directory Jun 01 14:22:45 Fri Jun 1 13:08:46 2018 daemon.notice netifd: radio0 (1188): cat: can't open '/var/run/wifi-phy0.pid': No such file or directory Jun 01 14:23:08 there is a hostapd-phyx.conf but no wifi-phyx.pid Jun 01 14:40:38 biangbia_: leleme is me on the forum Jun 01 14:57:05 blogic: based on forum discussions, it seems individual dts files will need to be fixed before staging driver is ever nerged. there's time :). Jun 01 15:06:49 does radio/phy/ifname have any relationship, on zbt1326 I now have "5Ghz is phy1-radio0-wlan1 while 2.4Ghz is phy0-radio1-wlan0", feel some mapping is messed up, will check later, need run Jun 01 15:07:15 https://forum.lede-project.org/t/mt7621-pcie-dts-issues-mt76-stopped-working-with-latest-updates/14623/88 Jun 01 15:07:39 wifi is all up, just can not connect 2.4Ghz, 5G is fine after reverting patches Jun 01 15:07:59 wifi-status, config/wireless, dmesg, logread all seem sane Jun 01 15:32:35 aparcar: on what host system do you attempt to run it? Jun 01 15:36:03 debian testing Jun 01 15:40:16 glibc probably found new ways to do nonesense Jun 01 15:45:11 build #878 of brcm63xx/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm63xx%2Fgeneric/builds/878 Jun 01 15:49:05 jow: I'll just wait until tomorrow :) Jun 01 15:50:35 Is it possible to compile packages of a selected repository but not it's dependencies if PKGARCH is set to all? Jun 01 15:54:43 no Jun 01 15:59:58 So tue only way is to remove the feeds which contain the dependencies... Jun 01 16:02:53 I think so, yeah Jun 01 16:04:46 If anyone else is using procd-ujail, please check https://bugs.openwrt.org/index.php?do=details&task_id=1559 Jun 01 16:30:58 build #893 of ar7/ac49x is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ar7%2Fac49x/builds/893 Jun 01 17:37:04 I attached a cisco usb-to-rj45 cable to the serial port of an EasyBox 803a. When opening serial console with 115200 8n1 I can read the output of the console. But it's all rubbish, confused letters. Is it maybe due to the cisco cable? Jun 01 17:38:51 You may have the wrong rate or a soldering issue, but I'd be concerned the cable is not the right voltage. Jun 01 17:41:17 You mean the usb-to-serial chip inside the usb-cable won't be the problem? Jun 01 17:42:26 No, it may very well be the problem Jun 01 17:42:41 I have no idea what voltage the Cisco port operates at Jun 01 17:47:37 I have no glue what's the doc of the usb-rs232-ic is all about: Jun 01 17:47:42 http://www.ftdichip.com/Documents/DataSheets/ICs/DS_FT232R.pdf Jun 01 17:48:10 Is it adapting it's voltage to the device? Jun 01 17:48:57 try change baudrate before anything else Jun 01 17:49:26 picocom -b 115200 /dev/ttyUSB0, then change 115200 to a few other popular values such as 57600 etc Jun 01 17:50:13 the wiki states 115200 8n1 Jun 01 17:50:19 https://wiki.openwrt.org/toh/astoria/arv752dpw22#serial_port Jun 01 17:50:24 ham5urg: It doesn't matter what chip is in there, it matters what voltage it's expecting and putting out. Jun 01 17:51:09 I've tried picocom -b 115200 /dev/ttyUSB2 Jun 01 17:51:25 and all other baudrates Jun 01 17:51:38 only 115200 shows something Jun 01 17:52:45 dmesg told me to use usb2 as inside the laptop I have a wwan-modem Jun 01 17:52:50 disconnect Vcc pin, just Tx/Rx/GND? Jun 01 17:52:56 yes Jun 01 17:53:02 no vcc Jun 01 17:53:13 What's the voltage on the TX pin from your adapter? Jun 01 17:54:55 i bet 3.3v Jun 01 17:55:07 Don't bet. Jun 01 17:56:15 5 Jun 01 17:56:20 Unplug that. Jun 01 17:56:21 Don't use that. Jun 01 17:56:21 5v Jun 01 17:56:27 ok Jun 01 17:56:49 Hope you haven't damaged it. Jun 01 17:56:56 And go buy a 3.3V adapter Jun 01 17:57:18 sorry guys to bother you with such a stupid failure Jun 01 17:58:21 This cable is for server use, maybe that's why it's on 5v Jun 01 18:03:20 A tiny little CPU is very unhappy right about now Jun 01 18:04:41 Eh, it may have survived. Jun 01 18:04:46 maybe Jun 01 18:04:58 I accidentally connected USB VBUS +5V to one of the boot_sel pins on my first Home Hub 5A when I started porting OpenWrt to it. RIP :( Jun 01 18:05:11 dunno how (older) lantiq CPUs like high voltage Jun 01 18:05:13 Usually they put some 1K resistors in series on the serial lines to give the poor diodes a chance at life Jun 01 18:05:50 xdarklight, and now you've got a Smokey Hub 5A :D Jun 01 18:06:12 Redfoxmoon: it's more of a Hot Hub 5A now - if you power it on the SoC gets *very* hot *very* quick ;) Jun 01 18:06:13 I've got a Crashy Hub 5A Jun 01 18:06:40 xdarklight, oh really, dang. Jun 01 18:06:51 Shorted clamping diodes Jun 01 18:06:58 dead Jun 01 18:07:03 Not enough guts in the regs to blow them open Jun 01 18:07:24 Desoldered a few chips that way Jun 01 18:07:41 xdarklight, at least you didn't start porting on a buggy unit :P Jun 01 18:07:47 build #881 of brcm2708/bcm2708 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2708/builds/881 Jun 01 18:07:55 *cough*crashy hub..*cough* Jun 01 18:08:06 Yeah yeah :P Jun 01 18:08:14 That thign ate too many hours Jun 01 18:08:42 The buggy HH5A I have ate a lot of my sanity ;-; Jun 01 18:10:43 amazing how and why u-boot doesn't bring up networking on the buggy unit I have :^) Jun 01 18:13:53 xdarklight, ah well, your Hot Hub 5A doesn't beat my *audibly clicking* HH2A :P Jun 01 18:14:10 (accidentally shorted JTAG pins together :P) Jun 01 18:15:16 i have a routerstation that use 48V while my brandnew linksys AC2600 had the connect connector, I mis-connected and saw the smoke and a little fire immediately, $130 was gone in 2 seconds Jun 01 18:15:31 s/the connect/the same/ Jun 01 18:16:17 ausjke: ouch. letting out the magic blue smoke is always painful. Jun 01 18:16:20 which triggered a journey on finding zbt1326, with a dead 2.4ghz which I now have to fight with :( Jun 01 18:20:57 snap. Jun 01 18:24:34 crackle. Jun 01 18:26:19 Boom! Jun 01 18:26:20 (darn, used too much explosives) Jun 01 18:33:30 build #26 of at91/sama5d4 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d4/builds/26 Jun 01 18:54:06 build #480 of at91/sama5d3 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d3/builds/480 Jun 01 18:59:33 any idea on how to get this one simpler? basename $(dirname $(readlink -f $0)) Jun 01 19:00:02 it shows the directory name of the script in which it is used Jun 01 19:00:45 (note: not the full path, only the last directory. and has to work in ash, not bash) Jun 01 19:12:13 build #26 of at91/sama5d2 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/26 Jun 01 19:50:49 After failing with a Cisco 5V USB-to-serial cable attached to a EasyBox 803A, I got an cheap USB-to-serial cable. I measured the voltage, both showing 5V. So both are unable to connect to the 3.3V PCB. What kind of resistor could I attach to get the 3.3V? Jun 01 19:51:35 build #866 of brcm63xx/smp is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm63xx%2Fsmp/builds/866 Jun 01 20:01:50 ham5urg2: you need a valtage divider, 1.5k/3.3k will do. But I'm not shure with the RX line of the adapter Jun 01 20:06:23 Or just get a suitable adapter Jun 01 20:10:02 I usually use 4pin PL2303 adapters off ebay, don't use (cut) the red wire Jun 01 20:12:48 Ugh, horrible things Jun 01 20:13:43 Any eBay link to suitable adapters? Jun 01 20:16:08 thanks, pl2303 can work Jun 01 20:23:41 ham5urg: https://www.ebay.com/itm/253127507805 Jun 01 20:26:17 ham5urg2: better this one https://www.ebay.com/itm/112974980011, I dislike devices without housing Jun 01 20:27:09 Prolific is never better Jun 01 20:29:35 Here, have a case: https://www.ebay.com/itm/181992762360 Jun 01 20:30:36 That's actually pretty nice, maybe I'll order a couple Jun 01 20:40:54 mh, but rather short cables on that one. Jun 01 20:41:03 So use longer ones Jun 01 20:41:18 Fixed cables make for disposable devices Jun 01 20:42:05 if you use them as flyswatters, sure. Jun 01 20:42:06 thank you guys. I'll buy some of your tips. Jun 01 20:42:45 by the way, I have a bricked wrt54gl. which jtag cable do you use for such? Jun 01 20:42:45 also, yeah, never prolific. Jun 01 20:43:10 For a WRT54GL? I use the bin. :) Jun 01 20:43:31 not because prolific is bad, but approximately 293% of the cheap prolific ones on ebay are fake. Jun 01 20:43:54 But they are bad Jun 01 20:44:31 genuine ones are acceptable. fake ones give you driver heartburn. Jun 01 20:44:42 Genuine ones give you driver heartburn too Jun 01 20:44:47 They dispose of support on a regular basis Jun 01 20:48:51 eh, no need to argue. silicon labs is an easy enough choice. Jun 01 20:48:56 * drmr pours shochu. Jun 01 20:49:09 Yep, I've yet to see a fake CP2102 Jun 01 20:49:49 how would you know? :) Jun 01 20:50:19 Well, every one I've encountered has had a unique serial number, consistent markings, and performed to spec Jun 01 20:50:31 I've yet to see any reports of definite fakes Jun 01 20:51:58 Certainly haven't had any fakes slip into the proper supply chains yet either, so there's that Jun 01 20:52:44 fair enough. Jun 01 20:53:26 they're probably cheap enough to begin with, not much margin to be had on fakes. Jun 01 20:53:49 Yeah, they're not nearly as expensive as FTDI and the Prolific fakes came from the dark past and just haven't stopped shipping Jun 01 20:55:00 it's been nice to see some competition in that functional space; my preference is cp2102 now. Jun 01 20:55:28 There's a good list of companies at it now Jun 01 20:56:37 Prolific, FTDI, Silabs, Cypress, Microchip (not that anybody bothers with theirs), WCH with those CH340 things (no thanks), to name the big players Jun 01 20:57:13 NXP and TI have some, rarely see them Jun 01 20:57:36 Holtek have some incredibly low cost 8-pin ones I've been meaning to try out for a while Jun 01 20:57:56 Monkeh: ive had cp210x all come with 0000001 as the serial Jun 01 20:58:09 Interesting Jun 01 20:58:11 bright side, uts reprogrammable via usb :) Jun 01 20:58:22 That could be that they've been programmed with a static serial Jun 01 20:58:38 iirc they do come with unique serials before programming Jun 01 20:58:56 Certainly the newer types do Jun 01 20:59:01 silabs is weird still, some with OTP, some with eeeprom, mixed features on each uary on the multi devixes Jun 01 20:59:17 also, 2102 vs 2q04 and 2101 vs 2109 stuff Jun 01 20:59:27 They've got a newer range I use anyway Jun 01 20:59:27 still. theyre mu go to :) Jun 01 20:59:58 Really must get to trying the HT42B532 though Jun 01 21:00:07 ceot for manufacturing, where our partner at leat gets the new ft230x series cheaper Jun 01 21:00:31 does silabs have a crystalfree part yet? Jun 01 21:01:07 Ahhh, that's right, the CP2102 is 0001 until programmed, the CP2109 is unique from the factory Jun 01 21:01:21 All the CP210x parts don't use crystals, afaik Jun 01 21:02:13 I've done CP2104, 2108, 2102N boards, certainly no crystals involved on those. Jun 01 21:02:38 jrm, was ut silabs who had the patent then? must have been Jun 01 21:03:26 we designed once with cp2104, ended up cheaper with ft230x, and no reprogramming modes during manuf Jun 01 21:03:47 Silabs, FTDI, Cypress, Prolific, and WCH all do chips with internal oscillators Jun 01 21:04:13 Look into the CP2102N, iirc they come out cheaper than the FT230X Jun 01 21:04:15 but silabshave alwasys been cheapest most reliable dongles to buy on [onlinestore] Jun 01 21:04:28 Plus they're nicer packages and you don't have to deal with FTDI. Jun 01 21:05:00 eh, its not our manufacturing. if manu says x, makes no differemce tl me :) Jun 01 21:05:29 i want a uart, with rs485 mode, and least worm possible. Jun 01 21:06:15 I really need to get some of these to try: https://lcsc.com/product-detail/USB_HT42B534-SOP-8_C94990.html Jun 01 21:06:20 Hard to argue with the price tag. Jun 01 21:08:27 karlp: I don't recall if the FT230X suffered from their 'oops, we bricked our own parts' debacle.. Jun 01 21:12:58 nah, that wsd before Jun 01 21:13:13 This definitely happened long after the X series came out Jun 01 21:13:28 yeah, but didnt affect them iirc Jun 01 21:13:30 They changed serial number format at some point and their driver choked Jun 01 21:13:33 Not sure if the X was affected Jun 01 21:13:56 they certainly behaved badly tjougj Jun 01 21:35:25 Hey guys, I have a legacy device with AA installed onto it by vendor. I've got a shell access, but I'm struggling to use the keys for passwordless logins. Did old dropbear not understand the openssl-generated keys? Jun 01 21:36:02 I've tried generating the key pair on device with dropbearkey, but my ssh client says that the privatekey is invalid. it is indeed some binary format. Jun 01 21:40:56 any ideas? Jun 01 21:42:50 there have been quite some new findings in regards to which key types are secure or not (e.g. DSA keys aren't trusted anymore), but plain rsa keys 'should' be accepted Jun 01 21:43:44 (but AA is really old, so at least I can't be 100% sure about what worked or didn't) Jun 01 21:44:42 back around Openwrt 8.09 times (kamikaze) dropbear did you use a differnt public key format. I don't remember when it started accepting openssh-format keys. Jun 01 22:09:53 pkgadd: ping Jun 01 22:12:30 huaracheguarache: pong Jun 01 22:12:50 pkgadd: sadly same key which I've been using since CC doesn't work for AA. Or maybe it's the KexAlgorithms. I'm using diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 -- should they work for AA? Jun 01 22:13:00 huaracheguarache: mmcblk0 is the system flash (eMMC), so I didn't have to install anything to mount it Jun 01 22:13:50 pkgadd: I eventually figured it out, and I tried removing the partition and flashing OEM afterwards. Jun 01 22:13:52 pkgadd: also, does the authorized_keys file go into /root/.ssh/authorized_keys on AA instead of /etc/dropbear/authorized_keys ? Jun 01 22:14:14 pkgadd: flashing OEM recreates the partition. Jun 01 22:16:19 pkgadd: but I haven't confirmed that the contents are the same as before. Jun 01 22:17:54 huaracheguarache: they don't really need to be the same, just good enough - that's a little hard to judge, but it doesn't sound too bad Jun 01 22:19:21 do you know whether APPSBL and APPSBLENV are OpenWrt related or also OEM stuff? Jun 01 22:19:31 partitions that is Jun 01 22:19:42 stangri: qualcomm's qsdk (which forked of 12.09-rc1)? because I see dropbear - 0.53.1-5 in the nbg6817 firmware, while the real OpenWrt 12.09 release shipped with dropbear 2011.54-2 (and a package called dropbearconvert) Jun 01 22:20:04 huaracheguarache: APPSBL == u-boot, APPSBLENV == uboot-env Jun 01 22:20:05 I'll confirm exact version and BB Jun 01 22:20:27 pkgadd: ah, better not touch that, hehe Jun 01 22:20:35 pkgadd: definitely no dropbearconvert on that machine, I checked Jun 01 22:21:19 does anyone know what could cause a sysupgrade failure? adding -v doesn't do much as ssh is terminated. The router simply reboots into current FW without any changes (I do upgrade with -n) Jun 01 22:21:55 pkgadd: what about the reserve partition? Jun 01 22:22:36 abenz: iirc there was a hickup in sysupgrade functionality 'recently', don't really ask me about the details - but you can replace the binaries (well, scripts) with the current version, if your old snapshot isn't tooo old Jun 01 22:22:58 huaracheguarache: I really don't know, unfortunately no r7800 is range ;) Jun 01 22:23:41 pkgadd: I'm sysupgrading from 18.06 of a couple of days only.. is this the right timeframe ? Jun 01 22:24:15 pkgadd: ok, I'll ask around. I think someone mentioned it in the r7800 exploration thread that it might be something that can be removed as well. Jun 01 22:24:26 huaracheguarache: btw. this https://github.com/pkgadd/nbg6817 is the partitioning on mine, the nbg6817 uses qcom-smem for getting the partition table from the hardware (that's why LEDE divides the partitions differently than the vendor firmware, which specifies them via cmdline) Jun 01 22:24:48 abenz: >2 weeks, iirc Jun 01 22:24:58 a couple of days should be fine Jun 01 22:25:27 huaracheguarache: I think the partition may be unused free space, but... Jun 01 22:25:57 pkgadd: any idea how I can troubleshoot? Jun 01 22:26:26 pkgadd: yeah, the name "reserve" doesn't sound as inviting for removal as "netgear" Jun 01 22:26:58 abenz: ideally with a serial console, as sysupgrade detaches from the console as early as possible Jun 01 22:27:33 abenz: if that isn't an option, you can only hack on the sysupgrade script to not detach Jun 01 22:28:25 pkgadd: dropbear - 2011.54-2, but no dropbearconvert binary. :( Jun 01 22:29:48 stangri: unfortunately an elf binary (and real 12.09 didn't know about ipq8064) Jun 01 22:30:28 pkgadd: that's not ipq8064 Jun 01 22:30:33 stangri: but this suggests that you may need it, Package: dropbearconvert Description: Utility for converting SSH keys Jun 01 22:31:07 stangri: on the other hand, you should be able to convert the keys on any architecture, including an x86 VM Jun 01 22:31:35 pkgadd: ty, installed it on mvebu Jun 01 22:33:46 will try the result and bb Jun 01 22:36:13 good luck Jun 01 22:47:24 huaracheguarache: OpenWrt doesn't touch netgear or reserved partitions at all, so only the vendor firmware might use it Jun 01 22:52:30 pkgadd: ok, I'll try removing that as well tomorrow Jun 01 23:00:01 pkgadd: I'll send you a PM with the paste Jun 01 23:10:11 I am having some pretty strange issues running ipq40xx and ath10k driver. My wifi is giving me some pretty strange latencies of 100+ms Jun 01 23:10:17 anyone else experiencing that? Jun 01 23:15:51 I have a platform that is ipq40xx/ath10k, how are you seeing the latencies? I can run things locally to see if I can repro Jun 01 23:19:11 dedomraz: is it periodic? Jun 01 23:19:53 Once it happens - it stays there Jun 01 23:20:13 Right now I am getting over 300ms, and its progressivly getting worse Jun 01 23:20:21 dedomraz: hmm Jun 01 23:20:27 dedomraz: doesn't sound good Jun 01 23:20:40 Not at all, specially when I have over 30 devices, that have that same issue Jun 01 23:20:56 I tried kernel 4.14 - bad, 4.9 - seems bad too Jun 01 23:21:05 dedomraz: I was going to suggest: http://blog.cerowrt.org/post/disabling_channel_scans/ Jun 01 23:21:33 dedomraz: but since 30 devices are experiencing it at the same time it's not what's causing it Jun 01 23:21:34 if I ping the router from my laptop - I get max 5ms ping, but if I ping the laptop from the router - i get over 300ms Jun 01 23:22:08 wish I could help you out, but I'm going to sleep now Jun 01 23:22:11 good luck Jun 01 23:22:54 huaracheguarache: have a good night :-) Jun 01 23:23:35 Oh wow. When I go to interfaces - that happens now - /usr/lib/lua/luci/dispatcher.lua:487: Failed to execute function dispatcher target for entry '/admin/network/wireless'. The called action terminated with an exception: Jun 01 23:30:49 dedomraz: afaik ath10k, especially on ipq40xx, can be problematic if you don't supply the correct board-2.bin, which is model specific for that target Jun 01 23:31:41 I use the board-2.bin provided by gl-inet (the maker of the device) Jun 01 23:31:52 that should be fine Jun 01 23:33:23 [ 16.359568] ath10k_ahb a800000.wifi: Direct firmware load for ath10k/QCA4019/hw1.0/firmware-6.bin failed with error -2 Jun 01 23:33:28 Could this be in any way related? Jun 01 23:33:39 found that in the dmesg log Jun 01 23:33:55 nope, that's no issue at all (and expecetd) Jun 01 23:34:36 some chipsets (not yours) can make use of firmware-6.bin, ath10k just tries to load everything it knows about Jun 01 23:34:44 Ah cool. I am still puzzled then. And it seems that as it failed - I can no longer open admin/network/wirelesss via luci Jun 01 23:35:03 but firmware-6.bin doesn't exist for most chipsets supported by ath10k so far - it transparently falls back to firmware-5.bin Jun 01 23:35:20 It was working fine for about almost a day. But this is definitely not the only unit with this issue, and sometimes occurs earlier. Jun 01 23:40:41 pkgadd: i has a patch for that Jun 01 23:41:18 only thing left is to test Jun 01 23:42:22 brb Jun 01 23:44:29 pkgadd: relevant to the 4.14 ar71xx effort: https://github.com/torvalds/linux/commit/648ea0134069cda7d4940f397bcc6901fb88752a#diff-5f9a24651de47015444ea712bc0ad805 Jun 01 23:50:15 patch up at: https://github.com/neheb/source/commit/99827d32d584a24a6e7ea96713469c7fdbb76a58 Jun 01 23:53:42 oh wow, nice! Jun 01 23:54:39 that's only for kernel 4.14 Jun 01 23:54:49 i didn't bother to port to 4.9 Jun 01 23:55:53 is there any log that I can see whats going on with my wifi and if it is throwing out errors? Aside from dmesg Jun 01 23:56:45 logread Jun 02 00:00:38 mangix: its not normal to have such high latency over wifi, specially when i am basically a fart away from it, correct? Like over 100ms Jun 02 00:01:33 specially when I ping it from the router - I get no such issues, usually around 5ms. Only when pinging from router to laptop Jun 02 00:05:45 so I'm missing quite a bit of context Jun 02 00:05:48 I just joined Jun 02 00:05:58 Oh, my bad :-) Jun 02 00:06:54 with ath10k, it may be useful to enable debug output if you can Jun 02 00:06:55 I have the b1300, and I am getting some really bad latency. When pinging from router to any device - I get between 2ms and 300ms, mostly on the upper end. When pinging from device to router - I get max 5ms. Jun 02 00:07:48 so it's an rx problem Jun 02 00:08:58 Likely yes. And when doing speed tests, etc - it gives me around 1.5Mb upload (I get 30 from my isp and other routers) and around 50Mbps download (I get 300+ from other routers and my isp). Jun 02 00:09:37 what kind of wireless chipset is it using? Jun 02 00:09:49 I have tested 4.9 and 4.14 kernel - both have the same issue. Jun 02 00:09:55 umm give me a quick second Jun 02 00:10:19 its the ipq4028 Jun 02 00:10:23 ls -Rl /lib/firmware should tell you Jun 02 00:11:37 https://pastebin.com/EwGkcQPh Jun 02 00:12:53 QCA4019 Jun 02 00:13:53 oh Jun 02 00:13:59 ath10k-ct is available Jun 02 00:14:01 try that Jun 02 00:14:57 the firmware in openwrt is quite old Jun 02 00:15:19 ct happens to be newer as well Jun 02 00:17:23 mangix: thanks! so unselect the ath10k-firmware-qca4019 and select ath10k-firmware-qca4019-ct ? Jun 02 00:17:35 or the ath10k-firmware-qca4019-ct-htt Jun 02 00:18:06 either. the ct developer tests mainly htt. Jun 02 00:18:55 and I see that its also using ath10k-firmware-qca9887 Jun 02 00:19:00 should I select the ct for that too? Jun 02 00:19:47 no Jun 02 00:19:52 deselect everything Jun 02 00:19:58 select QCA4019 Jun 02 00:20:47 10-4. Thanks! Jun 02 00:21:02 Time to compile and test. I really hope it resolves all these strange issues Jun 02 00:21:34 If I do a pull on github, would that add the fix you just pushed? Jun 02 00:22:22 no Jun 02 00:22:27 it pulls my entire branch Jun 02 00:22:56 i can set it up such that it goes on a separate branch. that would do what you want Jun 02 00:25:58 I guess I can just download the patches, and add them to their appropriate places? Jun 02 00:26:30 of course Jun 02 00:27:08 Thanks Rosen! (I assume from Signed-off-by on the patches) :-) Jun 02 00:27:20 I will report if it fixed the issues I was experiencing Jun 02 00:28:43 the patches only silence stupid warnings Jun 02 00:28:53 the firmware will make all the difference Jun 02 00:29:41 Yup, thats what I am looking for. I can live with warnings, as long as I have a working device lol Jun 02 00:34:52 mangix: just to confirm - these two patches - I just placed at their appropriate folders, and I do not need to add via menuconfig or anything else, they get compiled when I run make, correct? Jun 02 00:41:30 It failed to compile lol Jun 02 00:43:07 mangix: https://pastebin.com/7KsmvFr0 - could the patches have something to do with the failiure to compile? Jun 02 00:46:25 yup, removed the patches and it compiles just fine Jun 02 00:48:42 build #519 of ramips/mt76x8 is complete: Failure [failed sourceupload] Build details are at http://phase1.builds.lede-project.org/builders/ramips%2Fmt76x8/builds/519 blamelist: Michael Gray , John Crispin , Koen Vandeputte , Daniel Golle , Alex Jun 02 00:48:42 Maclean , Hans Dedecker , Kevin Darbyshire-Bryant , Ivan Shapovalov , Mirko Parthey Jun 02 00:55:24 dedomraz: i pushed a newer version Jun 02 00:56:25 10-4, will test a bit later, already flashing new build with ath10k-ct :-) Jun 02 00:57:21 oh actually Jun 02 00:57:26 that patch is not for ath10k-ct Jun 02 00:57:34 it's for regular ath10k Jun 02 01:52:59 mangix: I flashed ath10k-ct - still have pretty bad lag from router to connected devices via wifi Jun 02 01:55:46 Actually latency seems to be even more severe - between 2ms and 4500ms Jun 02 01:55:51 if i have a definition for an interrupt parent in a .dtsi file, do i need to set the status to "okay" in the .dts file for my board? **** ENDING LOGGING AT Sat Jun 02 03:00:08 2018