**** BEGIN LOGGING AT Fri Jun 15 03:00:10 2018 Jun 15 04:02:50 mangix: you're running zbt right? Jun 15 04:36:34 i got really poor 2.4ghz performance, though 5ghz is fine Jun 15 05:01:13 ausjke: no Jun 15 05:01:30 i don't have any my76 devices Jun 15 05:33:30 build #892 of ath25/generic is complete: Failure [failed sourceupload] Build details are at http://phase1.builds.lede-project.org/builders/ath25%2Fgeneric/builds/892 blamelist: Daniel Engberg , Daniel Golle Jun 15 05:53:17 mangix: please dont mis quote me on the forum Jun 15 06:14:58 @ausjke sometimes the auto channel takes a long time to scan too, is there any way to set a timeout limit on the scan? and same for 5GHZ/dfs? Jun 15 06:18:50 biangbiangmian: define "long"? Jun 15 06:19:19 just anecdotal, but it was scanning for about 5 minutes for me without even deciding on a channel Jun 15 06:19:33 the mt7603e Jun 15 06:20:00 i'm in a dense residential aria with a lot of 2.4GHz AP's though Jun 15 06:20:29 however, i had the same problem with the 5GHz, and there's only two or three of those, but it landed on a DFS channel and did the dance again Jun 15 06:20:49 two or three other 5GHz AP's, i mean Jun 15 06:21:24 my 5GHz radio is a mt7621e Jun 15 06:21:34 sorry mt7612e Jun 15 06:39:55 Si Jun 15 06:45:14 any chance to merge golang package into 18.06? karlp :)? Jun 15 06:51:10 hey everyone. ok i was in here a few nights ago and asked about a router and using it with ip cameras and if anyone is willing to start conversing with me to help me understand. or at least point me to some starting points. I know my around computers but i have never ever learned routers. However when i told them my model... they told me to pretty much throw it in the garbage and Jun 15 06:51:10 get a 'good' router Jun 15 06:51:59 well i stumbled upon a wicked deal... either way it was $20 so flipping it just made it worth it anyways. but it's a asus rt-ac56r Jun 15 06:52:14 am i getting warmer? Jun 15 06:52:36 and if so... or not i guess.. why? what makes one better then the other Jun 15 06:58:33 vibespredah: it's usually a question of the driver for the wireless Jun 15 07:00:30 the asus rt-ac56r uses broadcom radios, which usually means run-very-fast-away. Jun 15 07:48:41 ahhh Jun 15 07:48:48 so what should i be lookking for Jun 15 08:30:39 dwmw2_gone: mornin' :-) Does this look right? https://pastebin.com/D8zMRcTi specifically in pppoatm_send ? Jun 15 08:52:24 dwmw2_gone: fyi https://pastebin.com/UZYTU199 Jun 15 09:00:20 <_lore_> ping nbd Jun 15 09:09:43 vibespredah: qualcom-atheros 802.11n radios have the best driver support (ath9k), afaik Jun 15 09:22:34 do you actually need to modify the router or it's sw in anyway? Jun 15 09:22:44 I don't really follow what you need to do with an IP camera. Jun 15 09:27:05 [ 90.696628] pppos_atm_send() pre-add refcount=0x1 truesize=0x1c0 Jun 15 09:27:05 [ 90.702769] pppos_atm_send() post-add refcount=0x1c1 truesize=0x1c0 Jun 15 09:27:12 [ 90.723033] atm_pop_raw() pre-sub refcount=0x1c1 truesize=0x2c0 Jun 15 09:27:13 [ 90.729038] atm_pop_raw() post-sub refcount=0xffffff01 truesize=0x2c0 Jun 15 09:27:55 ldir: I bet if you printk("%p", skb) it's the same skb, yes? Jun 15 09:28:07 it had 0x1c0 bytes when we accounted for it Jun 15 09:28:15 and 0x2c0 by the time we take it off again Jun 15 09:28:26 the count goes negative... which takes it into the "fuck you" state Jun 15 09:28:45 what is fucking with it in the interim Jun 15 09:30:42 well I wonder if it *is* the same skb 'cos we're doing AAL5 encap at some point, and splitting our pdu into atm cells. Jun 15 09:31:09 using separate skbs for 53-byte cells would be batshit insane Jun 15 09:31:21 or when we do the refcount_add are we using the correct truesize ? Jun 15 09:31:22 I'm fairly sure AAL5 should be done in the hardware, not on the kernel side Jun 15 09:31:35 pskb_expand_head() in the ltq-atm driver is expanding the skb Jun 15 09:32:55 look at pskb_expand_head() in net/core/skbuff.c Jun 15 09:33:08 /* It is not generally safe to change skb->truesize. Jun 15 09:33:09 * For the moment, we really care of rx path, or Jun 15 09:33:09 * when skb is orphaned (not attached to a socket). Jun 15 09:33:09 */ Jun 15 09:33:09 if (!skb->sk || skb->destructor == sock_edemux) Jun 15 09:33:10 skb->truesize += size - osize; Jun 15 09:33:59 Is that addition happening? Jun 15 09:35:07 check if it's the same skb, too. Jun 15 09:35:59 ok, will try. Jun 15 09:36:02 :-) Jun 15 09:36:24 "skb=%p", skb Jun 15 09:38:18 and definitely print in pskb_expand_head() when it does that addition, and what skb->sk and skb->destructor are Jun 15 09:39:05 * ldir adds to the list :-) Jun 15 10:24:46 _lore_: pong Jun 15 10:24:58 <_lore_> nbd: hi, how are you? Jun 15 10:27:02 fine, thx Jun 15 10:27:04 how about you? Jun 15 10:27:39 <_lore_> fine thx Jun 15 10:28:18 <_lore_> I was looking at rts/cts configuration on mt76x2 and it seems it is enabled for ofdm/mcs rates but not for vht Jun 15 10:28:24 <_lore_> is it intentional? Jun 15 10:29:37 <_lore_> or should be enabled by default for all rates? Jun 15 10:53:06 _lore_: which register? Jun 15 11:08:11 <_lore_> nbd: I guess MT_TX_PROT_CFG6, MT_TX_PROT_CFG7 and MT_TX_PROT_CFG8 Jun 15 11:13:05 build #702 of armvirt/64 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/armvirt%2F64/builds/702 Jun 15 11:20:02 _lore_: i think this is something that needs to be reviewed more carefully, the vendor driver has a bunch of different protection modes that affect these settings Jun 15 11:20:10 and it's not really clear to me which ones we should use and when Jun 15 11:20:31 but before i look into that, it seems that we have some regressions brought to light by your rssi calc fix Jun 15 11:20:45 i think mt76x2_phy_update_channel_gain might be buggy Jun 15 11:21:57 <_lore_> uhm, I read the email Jun 15 11:22:22 <_lore_> previously the rssi was overestimated Jun 15 11:22:35 <_lore_> and maybe it was hiding some issues Jun 15 11:23:10 <_lore_> are you able to reproduce the issue? Jun 15 11:24:34 <_lore_> regarding the protection the conf is a little bit messed up since protection is enabled for OFDM/MCS but not for VHT and (maybe) CCK Jun 15 11:28:12 i'm not able to reproduce the issue Jun 15 11:28:21 and to be clear, your patch isn't what's buggy Jun 15 11:28:34 i think it simply triggered existing bugs in that function Jun 15 11:28:37 that were previously hidden Jun 15 11:28:52 i need to carefully review those register settings again Jun 15 11:29:01 <_lore_> yes, this is exactly what I mean :) Jun 15 11:29:24 <_lore_> I will review the code Jun 15 11:31:21 https://openwrt.org/submitting-patches says one should *always* squash commits when submitting patches. Is that always true? Take for example the three most recent commits here: http://code.azarus.ch/openwrt/log/?h=helios4 Jun 15 11:31:57 should all of those be squashed? makes little sense to me, as they'd be all over the place :/ Jun 15 11:34:32 ldir? any progress? Jun 15 11:37:25 azarus: I think the reasoning is to squash commits by topic Jun 15 11:38:39 azarus: and its more directed towards github PRs where people tend to make lots of incremental commits (like commit #1: add feature, commit #2: fix type, commit #3: correct mistake made in #2, commit #4: forgot to bump copyright year, commit #5: rewrite anything made in the last four commits and use a different approach, ...) Jun 15 11:38:45 jow: so in this example, I'd squash "mvebu: add .dtb file for Helios4" and "mvebu: initial support for the Helios4" ? Jun 15 11:39:28 azarus: unfortuantely the link you gave yields "invalid branch: helios" Jun 15 11:39:32 so I can't say Jun 15 11:39:39 but from what you wrote it sounds sane Jun 15 11:39:41 add a 4 to that ;) Jun 15 11:39:44 http://code.azarus.ch/openwrt/log/?h=helios4 Jun 15 11:39:58 (i pasted it correctly, it seems) Jun 15 11:40:05 this does not look like it requires any squashing Jun 15 11:40:25 maybe reordering Jun 15 11:40:33 first uboot, then dtb, then initial support Jun 15 11:40:34 oh, what should come first? Jun 15 11:40:36 ah, ok Jun 15 11:40:44 but thats just my hunch Jun 15 11:40:57 It makes sense tough. Jun 15 11:41:08 people like Hauke mkresin blogic pepe2k are the ones marging stuff, so their preferences apply Jun 15 11:41:43 But preparing it all nice for them is polite ;) Jun 15 11:58:41 jow: is there some kind of "merge team" or why doesn't everyone do this? Jun 15 11:59:23 as i already wrote here some times, it's sad to watch the number of open pull requests (some without any) reaction rise and rise :-( maybe you need more people with commit rights? Jun 15 12:00:32 we're especially waiting for 3 device support patches to be reviewed/merged for our project (german freifunk / gluon framework based on openwrt) Jun 15 12:01:06 ( namely CPE210, archer c7 v5 and avm 450E ) Jun 15 12:05:44 rotanid: there is no merge team. it's just a list of people who have the time and patience to deal with PRs Jun 15 12:07:42 rotanid: and not everyone touches everyting. for example I don't feel comfortable with packages or ar71xx. hence I usually touch these Jun 15 12:08:35 i just think that ignoring PRs is the best way to not get help ( more devs ) and it worked better last year when there was still the fresh LEDE spirit Jun 15 12:08:41 rotanid: doing the PR thingy is really time consuming Jun 15 12:09:00 we also take PRs, so i know Jun 15 12:10:31 rotanid: the review I'm talking about. and most PRs are intially in a shape which can be best described of a questionable quality Jun 15 12:11:02 i was told the latter by someone else, too Jun 15 12:11:13 but is it a solution to simply ignore most? Jun 15 12:11:38 no it isn't. it is just an explaination why it is like it is Jun 15 12:11:46 i know you meant reviews, as we also have to do it in our project Jun 15 12:12:59 i perfectly understand that not every crap can be merged, i agree with that Jun 15 12:13:41 i also know that there's no ideal solution or magic trick to solve the situation Jun 15 12:14:58 maybe a more real world example: avm 450E Jun 15 12:15:20 at blocktrron already knows that I don't like to do the reverse mac address thingy in c code Jun 15 12:15:27 as it will not work with ath79 Jun 15 12:15:57 the avm boxes have everything we need stored in the tffs Jun 15 12:16:34 and the avm 300e already extracts the mac address from the tffs. on other targets it is done the same Jun 15 12:25:17 mkresin: if there are problems or reasons not to merge something, then there are and that's fine Jun 15 12:26:14 the 'auto' channel in wireless said 'it will pick the lowest channel number', should it be 'the best/clean channel' instead? Jun 15 12:26:57 on my mt7621a router, the auto-channel takes forever and now I must use a fixed number, i.e. 1/6/11 for 2.4Ghz Jun 15 12:28:53 ausjke: auto == ACS (Automatic Channel Selection), which need to be implemented by the driver to my knowledge Jun 15 12:29:49 ausjke: the hostapd config file says: Supported ACS drivers: ath9k, ath5k, ath10k Jun 15 12:33:04 mkresin: the default is wpad-mini these days, but hostapd doc might be still correct, the wireless setting on openwrt.org does not mention 'auto' is driver-specific though Jun 15 12:33:53 and yes i have been using ath9k in the past so got used to 'auto', seems like it is either not implemented or not working well on mt7621a, not at all Jun 15 12:36:01 do we have a simple debug setup, where separate debuginfo files are placed in the build dir so that gdb can get at them when you're running gdbstub on the openwrt target? Jun 15 12:36:17 two side comments: google still finds wiki.openwrt.org instead of openwrt.org content, a bit annoying; and, google is so much better than dokuwiki's search, i like dokuwiki, but its interface for search sucks Jun 15 12:37:45 indeed, a permanent redirect would be awesome Jun 15 12:42:45 back to mt7621a, wireless performance is _very_ poor comparing to my older ath9k router, iperf3 gave me miserable result(1Mbps udp, 12Mbps tcp), speedtest is slightly better Jun 15 12:45:35 tried 4 threads in parallel, udp is 4Mbps while tcp is 13Mbps under iperf3, i would expect udp is better? i know there are many things to tweak for iperf and wireless settings, but the result of simple testing should have better result? Jun 15 12:47:02 checking /etc/interrupts, first I saw ERR:644, something is wrong from some driver, secondly, all ethernet/2.4G/5G interrupts are on cpu0, which is not good, at least these 3 should be bound to different cpus, so when they're used at the same time at full speed, it can be better load-balanced as far as interrupts are concerned Jun 15 12:47:07 trying that now Jun 15 12:48:07 /proc/interrupts --> /etc/interrupts Jun 15 13:00:42 dwmw2_gone: usually gdbserver is enough, I never needed extra debug files Jun 15 13:01:26 dwmw2_gone: gdbserver on the target plus ./scripts/remote-gdb target:9000 ./build_dir/target-*/foobar-*/.../executable Jun 15 13:02:03 scripts/remote-gdb takes care of setting sysroot etc. for gdb to find the unstripped shared objects Jun 15 13:05:06 jow: what's the purpose of CONFIG_DEBUG in make package/pkg/{clean,compile} CONFIG_DEBUG=y then? Jun 15 13:05:23 for native onboard debugging? Jun 15 13:06:20 ausjke: it mainly adds -g3 to the build Jun 15 13:06:31 stripping semantics etc. are unchanged Jun 15 13:06:48 and cmake based packages (at least the various u* ones) build with debug by default iirc Jun 15 13:07:30 i c, but i never needed g3... Jun 15 13:07:43 well -g3 == -g Jun 15 13:08:30 default is g2? Jun 15 13:08:49 dunno, forget about then umber Jun 15 13:08:55 all I wanted to say is that it adds -g Jun 15 13:09:10 whatever format version this implies Jun 15 13:09:46 TARGET_CFLAGS:=$(TARGET_OPTIMIZATION)$(if $(CONFIG_DEBUG), -g3) $(call qstrip,$(CONFIG_EXTRA_OPTIMIZATION)) Jun 15 13:10:11 thats from rules.mk Jun 15 13:11:22 just double checked gcc, g3 adds macro expansion, default -g is -g2, many packages have it by default, but openwrt will strip them anyways i think... Jun 15 13:11:29 yes Jun 15 13:17:57 I use MIPS mt7628 board. How to disable ethernet led so it stops to blink on ethernet link/data? Jun 15 13:18:03 And how to do this before compiling the firmware? Jun 15 13:19:26 biboc_: echo 0 to led network heartbeat trigger or something like that? Jun 15 13:19:46 under /sys search for gpio/led control file Jun 15 13:20:02 I only have wifi led: Jun 15 13:20:03 ~# ls /sys/class/leds/ mediatek:orange:wifi Jun 15 13:20:21 ~# ls /sys/class/leds/ Jun 15 13:20:22 mediatek:orange:wifi Jun 15 13:20:33 ooh...wired ethernet, it might be PHY level thing Jun 15 13:20:49 yes Jun 15 13:20:59 not sure if you can use mii/ethtool to do it but it will be too late unless you can write to those registers under u-boot Jun 15 13:21:06 Where is this configured? I can't find it in .dts file Jun 15 13:21:32 sometimes the ethernet-PHY led is 'automatically on' by default unless the driver modify the phy setting for it Jun 15 13:21:49 i don't think it's in dts, it has nothing to do with gpio etc Jun 15 13:22:34 Ok but somewhere someone tells ethernet-PHY to use specific led? or it is hardcoded in the driver? Jun 15 13:22:50 led/gpio Jun 15 13:35:55 jow: neat; thanks Jun 15 13:36:06 will play Jun 15 13:55:29 anyone? Jun 15 13:59:36 biboc_: where is the code and its dts, is it on github somewhere? i don't have a mt7628 build Jun 15 13:59:56 https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/MT7628.dts ? Jun 15 14:00:14 https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/LINKIT7688.dts Jun 15 14:00:27 Yes they are similar Jun 15 14:00:43 LINKIT is based on mt7628an.dtsi Jun 15 14:01:50 need time to dive in, some dts can configure phy registers (marvell?), not sure about mt7628 yet Jun 15 14:02:04 Ok thanks, let me know Jun 15 14:03:38 I want to stop ethernet driver to control it and control it by myself from user-space Jun 15 14:14:30 morning Jun 15 14:23:46 build #27 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/mediatek%2Fmt7623/builds/27 Jun 15 14:39:45 biboc_: if that's your goal, i would bypass the dts and look at the ioctl used in either mii-tools or ethtools to see how they interface with mdio registers, then your app code can do whatever you want with the phy-led Jun 15 14:48:27 biboc_: you need to switch some SoC pins from ethernet led mode to gpio mode Jun 15 14:49:32 @ausjke: yes and no. I know how to control it from user-space but I want it to be OFF at boot Jun 15 14:50:31 biboc_: replace https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/LINKIT7688.dts#L57 Jun 15 14:50:43 biboc_: with ralink,group = "gpio", "p4led_an", "p3led_an", "p2led_an", "p1led_an", "p0led_an", "p4led_kn", "p3led_kn", "p2led_kn", "p1led_kn", "p0led_kn" Jun 15 14:51:00 biboc_: and add a trailing ; Jun 15 14:53:04 hey everyone. ok i was in here a few nights ago and asked about a router and using it with ip cameras and if anyone is willing to start conversing with me to help me understand. or at least point me to some starting points. I know my around computers but i have never ever learned routers. However when i told them my model... they told me to pretty much throw it in Jun 15 14:53:04 the garbage and get a 'good' router Jun 15 14:53:04 well i stumbled upon a wicked deal... either way it was $20 so flipping it just made it worth it anyways. but it's a asus rt-ac56r Jun 15 14:53:04 am i getting warmer? Jun 15 14:53:04 and if so... or not i guess.. why? what makes one better then the other Jun 15 14:53:06 vibespredah: it's usually a question of the driver for the wireless Jun 15 14:53:12 the asus rt-ac56r uses broadcom radios, which usually means run-very-fast-away. Jun 15 14:53:17 ahhh Jun 15 14:53:17 so what should i be lookking for Jun 15 14:53:29 anyone able to continue convo? Jun 15 14:54:56 mkresin Ok let me try Jun 15 14:56:19 vibespredah: but as before, what do you actually need to do? Jun 15 14:56:29 thjere's nothing wrong with vendor wifi if you don't need to do anything with the router Jun 15 14:56:39 you just said, "use an ip camera with a router" Jun 15 14:56:46 I'm not even sure wehre openwrt comes into this Jun 15 15:00:08 ausjke: I'd say very definitely 27250b83 and 5bdea3a2e5c shoudl be squished together, because that's how all other boards get added, Jun 15 15:00:14 those commits are useless by themselves. Jun 15 15:01:07 squashed*? Jun 15 15:01:11 stintel? Jun 15 15:01:32 precisely which urls were failing due to the compression? Jun 15 15:02:08 dwmw2_gone: /ozwcp/cp.html Jun 15 15:03:09 main/WebServer.cpp: m_pWebEm->RegisterPageCode("/ozwcp/cp.html", boost::bind(&CWebServer::ZWaveCPIndex, this, _1, _2, _3)); Jun 15 15:05:09 ah, they are indeed handled as special cases Jun 15 15:06:22 karlp: it was you who send the fix ath79 dts warning patch, wasn't it? Jun 15 15:17:18 yar Jun 15 15:17:29 dwmw2_gone: just got home after driving home from Macclesfield 4 hr drive - urgh. And I have to be up 0100 ready for $paidjob. Jun 15 15:17:31 I tried to onyl fix the obvious ones and ones that I could confirm Jun 15 15:17:36 there were a few leftovers. Jun 15 15:17:48 I dind't break anything did I? Jun 15 15:17:52 it's been merged Jun 15 15:18:08 karlp: no everything is fine. Jun 15 15:18:20 good good, they shouldn't have done anything wrong :) Jun 15 15:18:52 karlp: I rather would like to ask if you can have a look at the pending PRs, to ensure no new warnings are introduced Jun 15 15:18:52 there some odd looking usb ones for a different usb controller though, I didn't have that hardware to confirm Jun 15 15:19:02 I'll try :) Jun 15 15:19:19 (can we make travis just do it?) Jun 15 15:20:00 would love to see something like that. would save me hours of compile testing Jun 15 15:20:15 but someone need to pickup the job. as usual Jun 15 15:20:32 does travis already do the build logs? Jun 15 15:20:54 I've not looked at travis plugins much, but it shouldn't be a terrrrible job to make it grep for dtc warnings and fail. Jun 15 15:20:59 (we then just have to get to zero first) Jun 15 15:21:56 karlp: are we using travis for PRs to the openwrt repo? Jun 15 15:22:37 ah no, it got turned off for "reasons" Jun 15 15:22:39 * karlp shrugs Jun 15 15:22:44 no idea how to make patchwork do it. Jun 15 15:31:41 karlp: for the two git-sha, which git are you referring to? Jun 15 15:32:19 am I the only one seeing bad 2.4Ghz performance(comparing to the ath9k at least, same location, similar setting) on zbt-we1326? Jun 15 15:32:58 also, for routers with 2 radios(2/5G), should we change irq-affinity to make sure they don't share one core at least? Jun 15 15:37:44 ausjke: in your own tree, you were talking about helio commits to squish? Jun 15 15:37:49 you said they should be separate? Jun 15 15:37:55 because otehrwise they would be "all over the place" Jun 15 15:38:28 ausjke: fairly poor 2.4g perf is pretty well established for mt76 Jun 15 15:44:00 karlp: no helio commit, just trying to help on the led/phy thing, it has been a while and i'm actually new to mediatek cpus Jun 15 15:44:43 karlp: bad to know that, no wonder, but still, 2.4Ghz performance is really weak Jun 15 15:46:01 * ausjke is suddenly interested in mt7621a+ath9(for 11bgn)+mt76x2e(for 11ac) Jun 15 15:48:58 is there any 11ac pcie card with mediatek radios? rbm33g+ath9k+762x11ac seem a good combination then Jun 15 15:50:13 ausjke: sorry, mixed your nick up with azurus Jun 15 15:51:18 stintel: https://github.com/dwmw2/packages/commits/domoticz-18.06 Jun 15 15:51:23 building now to test... Jun 15 16:03:58 hey mips finally found a buyer again Jun 15 16:05:12 source? who bought it? Jun 15 16:06:52 some AI startup Jun 15 16:07:20 That's sure to end well. Jun 15 16:07:38 self-aware plastic routers :P Jun 15 16:07:50 SkyMIPS Jun 15 16:07:51 "ai accelleration chips" Jun 15 16:08:38 https://www.eetindia.co.in/news/article/18061508-wave-computing-acquires-mips Jun 15 16:09:44 " push our dataflow fabric out to the edge" Jun 15 16:09:51 "infuse its scalable dataflow technology " Jun 15 16:09:59 b.i.n.g.o. Jun 15 16:10:43 damnit, I still needed "synergy" on my card. Jun 15 16:10:52 * mamarley 's corporate-BS-detector catches fire. Jun 15 16:11:26 lets see who is the next one buying MIPS Jun 15 16:12:41 karlp: I think there are no synergies Jun 15 16:12:42 well, these are ex mips staff, Jun 15 16:12:50 sounds like they were just waiting for thr price to get low enough :) Jun 15 16:13:16 both companies are controlled by the same VC boss, no wonder. Jun 15 16:13:28 or this AI stuff is just to get some captial and the plan in the beginning was to buy mips Jun 15 16:15:56 Hauke: that's what I mean. Jun 15 16:16:52 poor mips, frankly its only hope is to be sold to some chinese companies such as loogson(?) or ingenic Jun 15 16:17:30 ausjke: that would be problematic as MIPS CPUs are used by the US military Jun 15 16:17:41 they have money and market to sustain the architecture, then you have the non-money/market side of story that can't make it work Jun 15 16:17:59 Hauke: right, which is why it's not happenning Jun 15 16:18:53 I also agree that for the technologie itself some chineese companie would be the best Jun 15 16:19:12 but trump would have to approve this Jun 15 16:19:54 if trump doesn't approve it, wait for 2 weeks and try again Jun 15 16:20:24 the back and forth with the zte stuff every other 2 weeks is simply marvelous Jun 15 16:20:38 build #893 of ath25/generic is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ath25%2Fgeneric/builds/893 Jun 15 16:22:55 is mt76 the default 2.4/5G driver for mt7621 in 18.06 already? Jun 15 16:23:27 the 2.4ghz is so bad(comparing to ath9k) that I actually lose connection a few times a day, which _never_ happened with ath9k for years Jun 15 16:23:51 cellphone is on 5Ghz, seems fine, pc wifi is 2.4G only Jun 15 16:24:22 wigyori: could you try my u-boot update on your older allwinner devices please: https://patchwork.ozlabs.org/project/openwrt/list/?series=49347 Jun 15 16:26:01 ausjke: it's not like there's another driver... Jun 15 16:29:59 before i embarked for a new wifi router i was told mediatek is the most oss friendly on 11ac, i was a little aware of its 11n/2.4g not good enough, but, not realized it's so bad to be close to unusable? or am I missing something? Jun 15 16:30:30 will load factory image to compare, though i already replaced it, hope zbt has a download link Jun 15 16:35:44 where is the mt76 driver located? build_dir/linux/net/wireless/{ralink/rt2x00, mediatek/mt7601u} is it under rt2x00? Jun 15 16:38:33 Hauke: yup Jun 15 16:44:50 wigyori: thanks Jun 15 17:09:47 i switch txpower from 100mw to 1000mw, nothing changes on rate per my testing, the signal strength looks the same on wifi monitor, and luci always show "Tx-Power: 0dBm" Jun 15 17:10:30 iwinfo wlan0 txpower does show default txpower is 0dBm, so Luci is not helping at all Jun 15 17:11:33 jow: for 18.06 luci on mt7621 i don't think setting txpower via luci(or /etc/config/wirelss) is working at all, always staying at 0dBm by iwinfo Jun 15 17:11:59 maybe that's one reason 2.4G signal is so weak Jun 15 17:21:34 iw set reg, iw phy phy0 set txpower, nothing can be used to change txpower, so on zbt1326, the default 2.4G is 1dBm, 5G the max is 12dBm(1mW and 15mW). both are too low, and could not be changed? Jun 15 17:22:58 depends whether iw is actually even reading out the right values. Jun 15 17:23:09 there's been _much_ heartache with this sort of thing over the years Jun 15 17:34:19 https://github.com/openwrt/mt76/issues/68 same issue with mt76 and nbd claims 'fixed it', but to me it persists in 18.06 Jun 15 17:35:31 nbd: https://github.com/openwrt/mt76/issues/68 i don't see the fix is there for 18.06, as i could not change txpower for mt76x2e and mt7603e at all Jun 15 17:35:52 always 0dBm/2.4G 12dBm/5G here Jun 15 17:40:33 tried different iw reg set, no help, it's like hard-coded for the universe Jun 15 17:42:52 nothing to do with regset, like, "is reading the power actually implemented, and does it report the right number" Jun 15 17:47:03 What is the best practice for update openwrt/lede firmware on a router? Flash a new image? Jun 15 17:49:01 jdarnley: use luci to upgrade while keeping your old config normally works fine, unless you're jumping a lot of versions(e.g. 15.05 to 18.06) Jun 15 17:49:30 for your particular board check openwrt.org for some upgrade info, as always Jun 15 17:49:33 No, I was planning to to an update from 17.something Jun 15 17:49:54 17.01.0 Jun 15 17:50:00 i don't see any issues upgrading from 17.01.x to 17.01.y (y>x) Jun 15 17:50:22 have not tried upgrading from 17 to 18.06 though, i install 18.06 instead Jun 15 17:50:42 luci works fine with 17.01.x upgrades Jun 15 17:50:51 Will luci update correctly even though lede and openwrt merged again? I am still on a lede firemware. Jun 15 18:03:07 Seems to have worked. Jun 15 18:03:13 Thanks for the info. Jun 15 18:04:07 nbd: the fix is in mt76 in 18.06, but it is not working for me, i.e. the 2.4G/1mW and 5G/15mW can not be changed at all no matter what. Jun 15 18:04:50 * ausjke is reading mt76 and hope to be able to bump up txpower to where FCC allows at least Jun 15 18:25:17 dwmw2_gone: https://pastebin.com/TKkXu1N5 I removed a shed load of existing debug to get to this core. Hope it's useful. Going to sleep now, up silly in the morn. Jun 15 18:55:39 __lore__: ping Jun 15 18:58:16 pushed a bunch of mt76 gain adjustment fixes Jun 15 19:02:43 nbd: cherry-picked to 18.06 and building for test now Jun 15 19:22:36 Hello :) Jun 15 19:23:33 I see there is now nginx available as http-backend for luci, how well is it working and "supported"? I would test it for sure but I only have one main x86 router for time being so I woin't test it on that :D Jun 15 19:23:45 So, more of inquiry :) Jun 15 19:25:27 ola. Can I get somehow board name from console ? I am asking cuz this patch. Thanks https://patchwork.ozlabs.org/patch/890989/ Jun 15 19:26:40 nbd: same, 1mW/2.4G, 15mW/5G, read-only, no way to increase/decrease mt76 txpower Jun 15 19:29:16 made sure the newest mt76 is used Jun 15 19:31:51 hello folks i need some help. i got myself a second hand tp-link td-w8970 and i think its broken and i mean its really broken. when i try to power it on it stays silent i.e. only the power on led glows. and when i try to do anything nothing happens. looks like its dead. but i did pry it open and i put the pomona soic clip to read using a raspberry pi 2. when i power on the raspberry pi only the power led glows and the flashrom shows no flash chip Jun 15 19:31:51 detected. but i can see the main power on. Jun 15 19:32:04 so i guess the device is still breathing but the flashrom is somehow damaged so can i do something to bring back this device back to life? because i am getting VDSL next week and i would like to use this device as my main cpe device any help is much appreciated. thanks. Jun 15 19:39:53 getting close to the radio will show stronger signal still download/2.4Ghz is 1Mbps, for 5Ghz it is 60Mbps, upload is the same though, both 6mbps, close to the max speed, it seems 2.4G Tx is not doing well Jun 15 19:40:09 Can anyone help me how to use this patch https://patchwork.ozlabs.org/patch/890989/ when I compiling from source? Thanks Jun 15 19:49:04 zeetard: have you confirmed your flashrom setup works with a known-good system? Jun 15 19:49:31 yes it does work excellent m4t. Jun 15 19:50:00 i tried it on another system and raspberry read the rom excellent. Jun 15 19:50:17 but on this td-w8970 only power led blinks. Jun 15 19:50:53 and on another td-w8970 power and icon before 1st lan blinks. Jun 15 19:51:01 here only power m4t. Jun 15 19:51:08 so i guess the chip is toast. Jun 15 19:51:15 maybe Jun 15 19:51:51 are you powering it over the soic clip or do you have the ac adapter plugged into it as well? Jun 15 19:52:57 no power adapter connected. just the soic clip alone. Jun 15 19:54:52 i guess if the rpi stays running then its probably not a psu issue Jun 15 19:54:54 if i replace the chip can the device work as expected? Jun 15 19:55:14 then? Jun 15 19:55:24 i am not any good with electronics. Jun 15 19:55:27 it has a calibration partition Jun 15 19:55:53 max to max soldering, simple 4 pin soldering max in about 30 minutes. Jun 15 19:56:04 i wont use the wifi on this device. Jun 15 19:56:08 oh Jun 15 19:56:46 say if i take a new chip and ask my friend to solder and i take the details from another donor device (without the wifi cal data) can i have the vdsl up and running? Jun 15 19:57:25 ausjke: tx power control for mt7603 is not implemented. it will use the same tx power as the vendor driver Jun 15 19:57:48 as for mt76x2, it typically also has the same tx power as the vendor driver and uses the limits from the eeprom Jun 15 19:58:38 i think so, if the issue is only a bad flash chip Jun 15 19:59:35 i would try to connect to the cpu with jtag though Jun 15 20:01:53 jtag.... Jun 15 20:02:05 zeetard: btw which revision is it? v1? v3? Jun 15 20:02:29 why have i not thought of it yet. and oh yes it v1.2, yes there is a v1.2 Jun 15 20:02:46 i will ask my friend to set up the connection solder for jtag. Jun 15 20:02:54 its too late and he sleeping. Jun 15 20:04:28 im not sure if e.g. openocd would support that though Jun 15 20:04:38 lantiqs are kind of obscure Jun 15 20:04:49 hmmm Jun 15 20:05:14 do i need special tools? or the raspberry pi is enough for openocd Jun 15 20:05:31 rpi is enough i think, havent tried it though Jun 15 20:05:39 excellent. Jun 15 20:05:49 then now i need to wait for 8 more hours. Jun 15 20:05:57 he is still asleep. Jun 15 20:06:53 maybe this would work https://github.com/openwrt-vgv7519/openocd-lantiq Jun 15 20:07:13 says vrx200, dunno if that means vrx268 too Jun 15 20:07:31 nice........ Jun 15 20:07:35 i mean naissssssssssss. Jun 15 20:09:44 the point of jtag would be to try to see if the cpu is otherwise OK even if the flash is dead Jun 15 20:10:31 yeahhhhhhhhhhh Jun 15 20:10:57 i will set it up once he wakes up. phew i saved myself a few bucks. Jun 15 20:20:27 nbd: thanks. strange the zbt vendor sets 2G to 1mW while 5G to 15mW, too low for any purposes, will try to ask Jun 15 20:28:35 ausjke: 2G simply does not report the actual tx power Jun 15 20:28:39 because that's not implemented in the code yet Jun 15 20:28:44 so it will be more than 1mW Jun 15 20:28:54 time to push off.... thank you gentlemen, especially TheTrash and m4t for your kind patience with me and offering the nice suggestions Jun 15 20:29:15 have a nice day. Jun 15 20:33:31 nbd: cellphone show -60dBm at 10 meters, close to the device it is -30dBm, confused by the numbers as they're in uW instead mW range Jun 15 20:34:00 be it -60dBm or -30dBm shown by my android wireless tool, same low speed(1Mbps) Jun 15 20:34:56 something else is not right, 2.4G is weak, but should not be 1Mbps weak Jun 15 20:43:23 im building snapshot image with make image PROFILE="archer-c7-v2" PACKAGES=... some of the packages I use are collectd-mod-*, just now `make` failed with message Unknown package 'collectd-mod-conntrack' and a few similar messages. What could be a reason for it? I this temporary issue, or has these packages been dropped? Jun 15 20:53:13 There are some truly wonderful people who lurk in this and other channels... you know who you are! Absolute magic. atm vc-mux works again :-) Jun 15 20:56:18 padavan might support zbt-we1326 which seems have better wifi performance, older code for sure Jun 15 21:03:48 blogic: I'll quote properly next time :) Jun 15 21:24:41 * karlp sighs. Jun 15 21:25:10 * ausjke sighs Jun 15 21:25:13 taht danube openocd patch was written in 2013, never submitted to openocd. Jun 15 21:26:08 after 2-month journey with mediatek, totally disappointed, with 1mbps 2.4G, it's essentially a piece of trash Jun 15 21:26:30 * karlp is very happy. Jun 15 21:26:37 5gh is better than the isp provided Jun 15 21:26:46 and 2.4 works enough for the 2.4gig devices I have. Jun 15 21:26:58 which device? Jun 15 21:27:17 an old ar71xx device in STA mode. Jun 15 21:27:44 you were always going to be unhappy I think, no matter what happened :) Jun 15 21:27:47 yeah i had no issues with my routerstation-pro running atheros 2.4/5G Jun 15 21:28:16 karlp: not really, it all started from this mediatek tryout mess Jun 15 21:28:45 rspro is showing its age, need a replacement, back to ground zero Jun 15 21:30:24 ausjke: i'm running zbt-we3526 for a while now, 2.4ghz used to be of questionable quality till a couple of months ago Jun 15 21:31:36 ausjke: now it's been running smoothly with quite a number of diverse stations for the past couple of weeks Jun 15 21:32:37 dangole: good to know, running 1806? Jun 15 21:32:38 I'm curl'ing a big file at ~100kB/sec over 2.4gig through my zbt1326 now. Jun 15 21:33:07 karlp: that's the same speed i got actually Jun 15 21:33:15 it's not great, but it's functional at least. Jun 15 21:33:16 spent the whole day on this, fxxxxxx it Jun 15 21:34:11 6 people depend on it, only 2 has 5G Jun 15 21:34:25 the 1326 doesn't look like a completely different design compared to the 3526 Jun 15 21:34:56 dangole: i don't mind getting a 3526, it takes 2-3 weeks to arrive though Jun 15 21:34:59 let me check Jun 15 21:35:09 here it's 12 people and though some got 5g devices, most of them are connected via 2.4g most of the time Jun 15 21:35:11 speed test on my phone on 5gh gets ~200Mbits/sec Jun 15 21:35:33 best on my 5G is 60mbps Jun 15 21:35:45 with phone running iperf or speedtest Jun 15 21:35:46 that's lame, my wife's laptop gets 300 or so Jun 15 21:37:35 dangole: can you run a speedtest over 2.4G to see its actually speed? Jun 15 21:37:36 same phone, same position, on 2.4gh, gets ~6Mbs/3Mbps down/up Jun 15 21:38:14 if you do android, there is actually an iperf app, though you need get iperf to the router, but there are some public iperf router to play with, then it's the same as running speedtest Jun 15 21:38:15 i'm traveling right now, will be back home only in a couple of weeks, but got remote access Jun 15 21:38:34 s/public iperf router/public iperf server/ Jun 15 21:38:47 dangole: i c, thanks Jun 15 21:45:07 so 3526 has one SATA and its USB is 3.0 instead of 2.0, otherwise identical to 1326, but nearly doubled its price Jun 15 22:18:55 loaded openwrt.org snapshot, with 1 meter 2G/20mbps-5G/100mbps, 3m 2G/8mbps-5G/60mbps, 6m 2G/2mbps-5G/40mbps, 10m both <1mbps Jun 15 22:19:22 original firmware, nothing tweaked other than running psk2 Jun 15 22:20:16 based on cellphone wifi apps, the txpower disappears faster than expected, and it directly impacts the speed, of course **** ENDING LOGGING AT Sat Jun 16 03:00:04 2018