Re: [LEDE-DEV] [PATCH v2] ramips: add support for Ubiquiti EdgeRouter X-SFP
its in my staging tree which i will push later today or tomorrow. i pushed nand fixes for v4.9 end of last week, could you try the v4.9 kernel on your board please and let me know if it works ? John On 04/06/17 21:52, Sven Roederer wrote: Hi, I got a notification from patchwork, that this was accepted on 01.06.17, but I still can't find it on master. Can anyone explain? Svne On Montag, 29. Mai 2017 11:24:49 CEST Sven Roederer wrote: This patch adds support for the Ubiquiti EdgeRouter X-SFP and improves support for the EdgeRouter X (PoE-passthrough). ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] MT7688 SPI confusion
spi duplex is fucked in HW. the spi is a m25p80 engine and not a real spi. you need to use spi-gpio if you require a real spi On 05/06/17 02:57, Daniel Golle wrote: Hi! I'm currently trying to get SPI with two devices connected to work on MT7688 and noticed that the spi-mt7621 driver got a pretty weird work-around going on: if CS# is set it does only half-duplex transfers which if CS# is not set it does full-duplex. John has then disabled full-duplex alltogether on the Chaos Calmer branch [1]. What I'm trying to achieve is to use WrtNode2R's spi-bridge [2] to communicate with the STM32 MCU running RT-Thread. This somehow works in Chaos Calmer when using WrtNode modified tree [3] but doesn't work well on LEDE git HEAD... Any ideas? Apart from the spi-based rpc/console the Wrtnode2R comes with a flash tool for the STM32 [4] -- it would of course be much nicer to have a SPI backend for stm32flash to achieve the same thing. To be able to implement that I'd like to first understand what is needed to get SPI fixed so that the not-very-beautiful existing tooling can be replaced. Any experience with more than one SPI slave connected to MT76xx SoCs, stm32flash via SPI and general ideas/inspiration on bridging with RTOS running on MCUs next to an embedded Linux SoC is more than welcome :) Cheers Daniel [1]: commit 877ee7d7f54847b4e95c1feb6de0f5413e2fe7a1 Author: John Crispin Date: Tue Apr 19 21:01:34 2016 + ralink: add spi fix the fullduplex on CS1 is broken. remove the fullduplex support and run on plain half duplex on both CS lines. Signed-off-by: John Crispin git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49201 3c298f89-4303-0410-b956-a3cf2f4a3e73 [2]: https://github.com/WRTnode/openwrt-packages/blob/master/wrtnode/spi-bridge/src/main.c [3]: https://github.com/WRTnode/openwrt [4]: https://github.com/WRTnode/openwrt-packages/blob/master/wrtnode/WRTnode2r-stm32/src/main.c#L57 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1
Hi Paul - The solution I put into Unbound scripts was due to this trickiness. dnsmasq and its little extra functions have become entrenched and necessary in base OpenWrt/LEDE. This includes the oddities in architecture for UCI and LuCI. Normally, it is much easier to bind to the wild card address. So one might assume that the primary binds to #53, and any other instance must use a different port. It is also possible to bind per interface. An instance may bind to 127.0.0.1#53, another 192.168.1.1#53, and yet another to 192.168.2.1#53. Depending on subnet management and access limiting controls, this could get complicated. Requirements first. In an ecosystem with a choice of DNS servers (multiple instances each and stub vs recursive), what shall be the direct or inferred protocol to denote the primary DNS instance? The scripts all but write themselves with such requirement set and agreed to. - Eric > (in short: when dnsmasq.noresolv=1 and dnsmasq.resolvfile is unset, then > /tmp/resolv.conf is not handled). > > After some analysis the conclusion is that the dnsmasq init script should > handle /tmp/resolv.conf, if and only if, when its main instance is run. The > main instance is designated the one that will listen on 127.0.0.1#53 > (naturally there can be only one such instance). > > When using unbound with UCI unbound.dhcp_link set to “dnsmasq”, the unbound > init script does **not** handle /tmp/resolv.conf and leaves it to dnsmasq to > do so. In the dhcp_link=dnsmasq setup it is unbound that listens on > 127.0.0.1#53 and so no instance of dnsmasq can possibly be the main instance. > Which makes sense. > > An attempt to solve this problem just within the scope of the dnsmasq init > script has proven to be more convoluted than I first thought. > > A simple, sane and much more elegant solution would be: > a) dnsmasq indeed only handles /tmp/resolv.conf when it runs the main > instance and > b) unbound does so when it the main instance, i.e. will listen on > 127.0.0.1#53. > > Do you agree ? > > If so, could you share your thoughts on how best to do the unbound change ? > A few different approaches to the determination of $resolvsym seem possible, > but I’m sure that picking best/easiest/whatever approach is best chosen by > you. > > Regards, > Paul > > >> Op 4 jun. 2017, om 16:26 heeft Paul Oranje het volgende >> geschreven: >> >> Good afternoon, >> >> Conclusions: >> 1) Always initialise $resolvfile (i.e. independently of the state of >> noresolv). >> 2) The value of $resolvfile cannot not be used the determine the dnsmasq >> main instance since several instances likely will an equal value. >> 3) The main dnsmasq instance is the instance that listens on 127.0.0.1:53 >> (of which there can only be one or none). >> 4) When no local DNS resolver runs /tmp/resolv.conf should soft-link >> $resolvfile (and that could possible be something else than >> /tmp/resolv.conf.auto). >> >> ad 3) >> The designated main instance can be determined at runtime by: >> - at start of an instance X, when this instance is configured to listen on >> 127.0.0.1#53 and no process listens on that socket, then >> - at stop of an instance X, when this instance is configured to listen on >> 127.0.0.1#53 and a process listens on that socket, then >> >> For a listening-on test something like “nslookup localhost 127.0.0.1#53 >> >/dev/null” would seemingly work (though not on OWRT CC), but that will >> incur a timeout delay (10 sec ?) when no daemon is listening. >> Understandably, suggestions for an alternative test that will not incur such >> a timeout are welcome. >> >> The above determination of the main instance assume that only one of >> multiple instances is configured to listen on 127.0.0.1#53, otherwise the >> tests may result erroneously in undefined behaviour. >> >> ad 4) >> A use-case for setting resolvfile to a non-default might be the use of >> different upstream resolvers for different subnets, though that could easily >> be achieved with the server options of UCI dhcp.dnsmasq[x]. >> >> >> Regards, >> Paul >> >> >> >>> Op 4 jun. 2017, om 00:09 heeft Hans Dedecker het >>> volgende geschreven: >>> >>> On Sat, Jun 3, 2017 at 3:33 PM, Paul Oranje wrote: Thanks, please see a few quick reactions of mine inline ... Paul > Op 3 jun. 2017, om 14:18 heeft Hans Dedecker het > volgende geschreven: > > On Thu, Jun 1, 2017 at 12:00 PM, Paul Oranje wrote: >> Hello Hans, >> >> A new version of this small patch is worked on -overlooked your previous >> comment and have lately been busy with other stuff-, but after studying >> the code a little more I’ve a few questions. The intended patch changes >> code that was added with commit a35f9bbc43c3da06eed042f80dc09e8c1da681b4 >> (dnsmasq: Multiple dnsmasq instances support) that was authored by you. >> >> >> The routines dnsmasq_start() and dnsmasq_stop() contain a guard on >>>
Re: [LEDE-DEV] [OpenWrt-Devel] Remerge logo ideas
I understand that and I had no intention to restart such discussion. I'm sorry if what I wrote was misinterpreted as such. I didn't mean to. On 5 June 2017 at 02:08, David Lang wrote: > the vote on the name was held several months ago, please stop trying to > re-do the vote just because it didn't come out the way you wanted it to. > k -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - c...@av.it.pt Skype & GTalk -> carlosmf...@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] solar wifi AP designs
On 06/04/2017 08:46 PM, Dave Taht wrote: > I keep finding nicely integrated solar/battery/camera designs like these > > https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Delectronics&field-keywords=solar+wifi&rh=n%3A172282%2Ck%3Asolar+wifi > > But what I'd like is just something with solar and battery that could > function as an AP, that was well supported by lede. Ideas? > A router that runs on a 12V supply - https://www.amazon.com/TP-Link-Archer-C7-Wireless-Gigabit/dp/B00BUSDVBQ/ref=sr_1_2?ie=UTF8&qid=1496629045&sr=8-2&keywords=tp+link+archer+c7 Good old fashioned lead acid battery - https://www.amazon.com/Interstate-Batteries-SLA1116-Lead-Battery/dp/B004KNPIWS/ref=sr_1_4?ie=UTF8&qid=1496628899&sr=8-4&keywords=Interstate+Batteries 12V Solar Panel - http://www.homedepot.com/p/Nature-Power-22-Watt-Amorphous-Solar-Panel-Charging-Kit-with-8-Amp-Charge-Controller-for-12-Volt-Systems-42022/300854090?MERCH=REC-_-PIPHorizontal1_rr-_-204759893-_-300854090-_-N Duct Tape :-) - http://www.homedepot.com/p/NATIONAL-1-89-in-x-40-yd-Utility-Grade-Duct-Tape-Silver-1118105/202352331 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Remerge logo ideas
the vote on the name was held several months ago, please stop trying to re-do the vote just because it didn't come out the way you wanted it to. k ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Remerge logo ideas
Julian, thank you for the correction. I truly thought that WRT was from Wireless Router. I stand corrected :) Bill, I understand that it would be a risk to change the name. I don't mind that the project continues to use the OpenWRT brand. I just was pointing out that it doesn't truly reflects what it is being used today. Let me give you an example. About 3-4 years ago, when I was starting my PhD, I decided to use OpenWRT to power about 32 VM's inside my computer. I wanted to test a distributed network protocol that I had been developing for some time in Python. Since OpenWRT has such a low memory footprint, It was the perfect environment for me. I could test the network protocol with a real linux kernel in a virtual network environment, having only 8GB of RAM on the host. I got to test the protocol and it worked. Then I used it in some SBC's also with OpenWRT. On 2 June 2017 at 23:24, Philip Prindeville wrote: > Can we add “Powered by LEDE” in little tiny letters underneath? ;-) > > >> On May 29, 2017, at 4:11 AM, Jamie Stuart wrote: >> >> Hi, >> First of all, I’m glad to hear the process of remerging LEDE with OpenWrt is >> moving forward. >> For what it’s worth, if prefer the LEDE name (it’s friendlier - ‘leddy’ - >> and not tied to the name of an old router!) >> >> However, it seems the consensus is that the OpenWrt name should remain. I >> thought that maybe we should take this opportunity to at least give the >> project an updated look? >> Maybe a new logo? I’m personally not one for mascots, so I had a quick go at >> a few simple text-based designs: >> >> http://i.imgur.com/9zyXSYR.png >> >> What are you thoughts? >> >> Jamie, onebillion > ___ > openwrt-devel mailing list > openwrt-de...@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - c...@av.it.pt Skype & GTalk -> carlosmf...@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] MT7688 SPI confusion
Hi! I'm currently trying to get SPI with two devices connected to work on MT7688 and noticed that the spi-mt7621 driver got a pretty weird work-around going on: if CS# is set it does only half-duplex transfers which if CS# is not set it does full-duplex. John has then disabled full-duplex alltogether on the Chaos Calmer branch [1]. What I'm trying to achieve is to use WrtNode2R's spi-bridge [2] to communicate with the STM32 MCU running RT-Thread. This somehow works in Chaos Calmer when using WrtNode modified tree [3] but doesn't work well on LEDE git HEAD... Any ideas? Apart from the spi-based rpc/console the Wrtnode2R comes with a flash tool for the STM32 [4] -- it would of course be much nicer to have a SPI backend for stm32flash to achieve the same thing. To be able to implement that I'd like to first understand what is needed to get SPI fixed so that the not-very-beautiful existing tooling can be replaced. Any experience with more than one SPI slave connected to MT76xx SoCs, stm32flash via SPI and general ideas/inspiration on bridging with RTOS running on MCUs next to an embedded Linux SoC is more than welcome :) Cheers Daniel [1]: commit 877ee7d7f54847b4e95c1feb6de0f5413e2fe7a1 Author: John Crispin Date: Tue Apr 19 21:01:34 2016 + ralink: add spi fix the fullduplex on CS1 is broken. remove the fullduplex support and run on plain half duplex on both CS lines. Signed-off-by: John Crispin git-svn-id: svn://svn.openwrt.org/openwrt/branches/chaos_calmer@49201 3c298f89-4303-0410-b956-a3cf2f4a3e73 [2]: https://github.com/WRTnode/openwrt-packages/blob/master/wrtnode/spi-bridge/src/main.c [3]: https://github.com/WRTnode/openwrt [4]: https://github.com/WRTnode/openwrt-packages/blob/master/wrtnode/WRTnode2r-stm32/src/main.c#L57 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] solar wifi AP designs
I keep finding nicely integrated solar/battery/camera designs like these https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Delectronics&field-keywords=solar+wifi&rh=n%3A172282%2Ck%3Asolar+wifi But what I'd like is just something with solar and battery that could function as an AP, that was well supported by lede. Ideas? -- Dave Täh Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1
Hello Eric, While trying to solve FS#785 some questions about rewriting /tmp/resolv.conf have arisen - insight has grown. (in short: when dnsmasq.noresolv=1 and dnsmasq.resolvfile is unset, then /tmp/resolv.conf is not handled). After some analysis the conclusion is that the dnsmasq init script should handle /tmp/resolv.conf, if and only if, when its main instance is run. The main instance is designated the one that will listen on 127.0.0.1#53 (naturally there can be only one such instance). When using unbound with UCI unbound.dhcp_link set to “dnsmasq”, the unbound init script does **not** handle /tmp/resolv.conf and leaves it to dnsmasq to do so. In the dhcp_link=dnsmasq setup it is unbound that listens on 127.0.0.1#53 and so no instance of dnsmasq can possibly be the main instance. Which makes sense. An attempt to solve this problem just within the scope of the dnsmasq init script has proven to be more convoluted than I first thought. A simple, sane and much more elegant solution would be: a) dnsmasq indeed only handles /tmp/resolv.conf when it runs the main instance and b) unbound does so when it the main instance, i.e. will listen on 127.0.0.1#53. Do you agree ? If so, could you share your thoughts on how best to do the unbound change ? A few different approaches to the determination of $resolvsym seem possible, but I’m sure that picking best/easiest/whatever approach is best chosen by you. Regards, Paul > Op 4 jun. 2017, om 16:26 heeft Paul Oranje het volgende > geschreven: > > Good afternoon, > > Conclusions: > 1) Always initialise $resolvfile (i.e. independently of the state of > noresolv). > 2) The value of $resolvfile cannot not be used the determine the dnsmasq main > instance since several instances likely will an equal value. > 3) The main dnsmasq instance is the instance that listens on 127.0.0.1:53 (of > which there can only be one or none). > 4) When no local DNS resolver runs /tmp/resolv.conf should soft-link > $resolvfile (and that could possible be something else than > /tmp/resolv.conf.auto). > > ad 3) > The designated main instance can be determined at runtime by: > - at start of an instance X, when this instance is configured to listen on > 127.0.0.1#53 and no process listens on that socket, then > - at stop of an instance X, when this instance is configured to listen on > 127.0.0.1#53 and a process listens on that socket, then > > For a listening-on test something like “nslookup localhost 127.0.0.1#53 > >/dev/null” would seemingly work (though not on OWRT CC), but that will incur > a timeout delay (10 sec ?) when no daemon is listening. > Understandably, suggestions for an alternative test that will not incur such > a timeout are welcome. > > The above determination of the main instance assume that only one of multiple > instances is configured to listen on 127.0.0.1#53, otherwise the tests may > result erroneously in undefined behaviour. > > ad 4) > A use-case for setting resolvfile to a non-default might be the use of > different upstream resolvers for different subnets, though that could easily > be achieved with the server options of UCI dhcp.dnsmasq[x]. > > > Regards, > Paul > > > >> Op 4 jun. 2017, om 00:09 heeft Hans Dedecker het >> volgende geschreven: >> >> On Sat, Jun 3, 2017 at 3:33 PM, Paul Oranje wrote: >>> Thanks, please see a few quick reactions of mine inline ... >>> Paul >>> Op 3 jun. 2017, om 14:18 heeft Hans Dedecker het volgende geschreven: On Thu, Jun 1, 2017 at 12:00 PM, Paul Oranje wrote: > Hello Hans, > > A new version of this small patch is worked on -overlooked your previous > comment and have lately been busy with other stuff-, but after studying > the code a little more I’ve a few questions. The intended patch changes > code that was added with commit a35f9bbc43c3da06eed042f80dc09e8c1da681b4 > (dnsmasq: Multiple dnsmasq instances support) that was authored by you. > > > The routines dnsmasq_start() and dnsmasq_stop() contain a guard on > writing and resetting /tmp/resolv.conf: > [ "$resolvfile" = "/tmp/resolv.conf.auto” ] && > > As explained in FS#785, the guard test fails when $noresolv is true and > $resolvfile has not been explicitly configured to its default > "/tmp/resolv.conf.auto", causing /tmp/resolv.conf to remain a soft link > to /tmp/resolv.conf.auto (the WAN its DNS). > > The routine dnsmasq_stop() the guard is commented with > #relink /tmp/resolve.conf only for main instance > > This suggests that only for the main (first ?) instance /tmp/resolv.conf > would be handled, which makes sense, but the test to accomplish that > seems wrong. > > Q1: > What is the supposed relation between dnsmasq instance and the value of > the value/setting of resolvfile ? The DNS servers learned on the wan interface(s) by netifd are written
Re: [LEDE-DEV] [PATCH v2] ramips: add support for Ubiquiti EdgeRouter X-SFP
Hi, I got a notification from patchwork, that this was accepted on 01.06.17, but I still can't find it on master. Can anyone explain? Svne On Montag, 29. Mai 2017 11:24:49 CEST Sven Roederer wrote: > This patch adds support for the Ubiquiti EdgeRouter X-SFP and > improves support for the EdgeRouter X (PoE-passthrough). > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Planning v17.01.2
Hi, I decided to delay 17.01.2 by another week to wait for Kernel 4.4.71 getting released which will fix a number of networking related vulnerabilities. The currently projected release date is Saturday, the 10th. Regards, Jo ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Archer c7 corrupted firmware bootloop - tftp aborting - serial not working
> "Alberto" == Alberto Bursi writes: Alberto> On 06/04/2017 02:54 PM, QWeRKUS qwErkus wrote: >> Thank you for your reply. JTAG seems even trickier than serial. So >> far all my attempts to scan for a valid JTAG chain end up with: >> >> Error: JTAG scan chain interrogation failed: all zeroes >> >> There a just too many variables to check for a newbie like myself, so >> I guess I'll go with the spi programmer. Turns out this is another >> thing the pi can do (via flashrom) so no need for new hardware. Are >> you sure you need to desolder the chip though ? Shouldn't this be >> working with a 8 pin SOIC clamp and and external 3.3V power source (I >> have an old ATX PSU doing the job) ? >> >> Alberto> It should, but in some cases it does not (depends from how the Alberto> board was designed) and in those situations you need to Alberto> desolder the chip. I got most of these "cases where it does not Alberto> work" in PC and laptop boards though. If the CPU is trying to access the SPI bus at the same time, it can be problematic. On a TP Link WDR3600 board, I had to figure out how to hold the CPU in reset. You might be able to do that from the JTAG nSRST pin. Make sure it's connected. On the WDR3600 board, there was a shunt resistor missing. http://www.jtagtest.com/pinouts/ejtag Tie nSRST to ground with a jumper wire or similar, attach your SOIC clip, and run flashrom. -- Russell Senior, President russ...@personaltelco.net ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ATH10K-CT debug messages
Unless you are having problems, you can ignore the messages. If you do have problems, send me 'dmesg' or similar and I can decode them. The latest patches I sent have an option in the ath10k debug-mask to disable printing these if you don't want to see them. Thanks, Ben On 06/04/2017 03:40 AM, Kevin Darbyshire-Bryant wrote: FAO that nice Mr Greer, I'm getting (for free) a nice selection of ath10 debug messages when using the Ath10K-ct firmware & driver in LEDE. A small collection reproduced below. Are they of any interest/use? [ 60.808281] ath10k: []: 73060100 0500FC17 70201031 0800 8000 B8F74000 01000600 7D060100 [ 60.817474] ath10k: [0008]: 085CFC0F D8654400 0800 8000 7D060100 065CFC0F B8F74000 D0714400 [ 60.826651] ath10k: [0016]: 1900 7D060100 065CFC0F 0900 D0714400 98889C00 DF060100 100CFC0B [ 60.835834] ath10k: [0024]: 8A291001 0300 DF060100 130CFC03 E6060100 234CFC0F 0100 0100 [ 60.845019] ath10k: [0032]: 0100 ED060100 234CFC0F 0100 0100 0100 2F070100 234CFC0F [ 60.854206] ath10k: [0040]: 0100 0100 0100 36070100 234CFC0F 0100 0100 0100 [ 60.863394] ath10k: [0048]: 3F070100 234CFC0F 0100 0100 0100 46070100 234CFC0F 0100 [ 60.872582] ath10k: [0056]: 0100 0100 4D070100 234CFC0F 0100 0100 0100 54070100 [ 60.881763] ath10k: [0064]: 234CFC0F 0100 0100 0100 56070100 0C64FC07 0100 5D070100 [ 60.890946] ath10k: [0072]: 234CFC0F 0100 0100 0100 5D070100 092C 80F24300 0200 [ 60.900134] ath10k: [0080]: 5D070100 065C000C 0800 D0714400 A0889C00 5D070100 0928000C [ 60.909321] ath10k: [0088]: 61661071 80F24300 E8F84300 5D070100 0928000C 60661071 80F24300 E8F84300 [ 60.918509] ath10k: [0096]: 5D070100 085C0008 80F24300 00664400 5D070100 065C000C 1100 D0714400 [ 60.927695] ath10k: [0104]: A8889C00 5D070100 045C000C 03001081 80F24300 5D070100 02280008 [ 60.936871] ath10k: [0112]: 0300 0300 5D070100 02280004 0300 5F070100 4F4C0014 7300 [ 60.946053] ath10k: [0120]: BCE44100 747D4300 7100 5F070100 4F4C0014 6300 F4E44100 [ 60.955240] ath10k: [0128]: 747D4300 01007200 5F070100 564C0014 747D4300 08CD9B00 1100 [ 60.964426] ath10k: [0136]: 203D 5F070100 564C0014 747D4300 50CD9B00 1200 [ 60.973619] ath10k: [0144]: 202D 5F070100 564C0014 747D4300 98CD9B00 1000 0A00 403D [ 60.982800] ath10k: [0152]: 5F070100 564C0014 747D4300 E0CD9B00 1300 203D 5F070100 [ 60.991988] ath10k: [0160]: 035C0014 0100 14CC20BE 8930 94AC9B00 747D4300 63080100 0B200010 [ 61.001168] ath10k: [0168]: 80F24300 0A04 [ 61.007172] ath10k_pci :01:00.0: ATH10K_END [ 61.071878] br-wifi_guest: port 2(wlan1-1) entered disabled state [ 62.127413] br-wifi_priv: port 2(wlan1) entered forwarding state [ 62.134543] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1-1: link becomes ready [ 62.141350] br-wifi_guest: port 2(wlan1-1) entered forwarding state [ 62.147823] br-wifi_guest: port 2(wlan1-1) entered forwarding state [ 64.147395] br-wifi_guest: port 2(wlan1-1) entered forwarding state [ 120.754049] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 120.760686] br-wifi5_priv: port 2(wlan0) entered forwarding state [ 120.766948] br-wifi5_priv: port 2(wlan0) entered forwarding state [ 120.781339] ath10k_pci :01:00.0: htt peer map vdev 0 peer 14:cc:20:be:89:30 id 131 [ 120.797138] device wlan0-1 entered promiscuous mode [ 120.806036] ath10k_pci :01:00.0: ath10k_pci ATH10K_DBG_BUFFER: [ 120.812372] ath10k: []: 4CF90100 0920040C 00F34300 0300 4CF90100 065C040C 0800 [ 120.821564] ath10k: [0008]: D0714400 B0889C00 4CF90100 4E4C0410 01991091 0700 4C01 A8C99B00 [ 120.830746] ath10k: [0016]: 4CF90100 035C0414 07001109 14CC20BE 8930 CCAC9B00 4CF90100 [ 120.839938] ath10k: [0024]: 025C0414 00F34300 CCAC9B00 14CC20BE 8930 0100 4CF90100 0928040C [ 120.849120] ath10k: [0032]: 61661071 00F34300 1CF94300 4CF90100 0928040C 60661071 00F34300 1CF94300 [ 120.858307] ath10k: [0040]: 4CF90100 045C040C 03001081 00F34300 4CF90100 0B200410 00F34300 [ 120.867489] ath10k: [0048]: 0A04 4CF90100 07200404 00F34300 4CF90100 094C0414 [ 120.876660] ath10k: [0056]: 0300 0100 FF00 0100 8000 4CF90100 074C0408 0300 [ 120.885842] ath10k: [0064]: 4CF90100 08200404 00F34300 4CF90100 0A4C0410 0300 0100 [ 120.895028] ath10k: [0072]: FF00 8100 4CF90100 084C0408 0300 4CF90100 0A200404 [ 120.904216] ath10k: [0080]: 00F34300 4CF90100 075C040C 0800 D0714400 B0889C00 4CF90100 09280410 [ 120.913402] ath10k: [0088]: 62661071 00F34300 1CF94300 4CF90100 5B4C0404 A8C99B00 4CF90100 [ 120.922591] ath10k: [0096]: 055C0404 00F34300 33FA
Re: [LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1
Good afternoon, Conclusions: 1) Always initialise $resolvfile (i.e. independently of the state of noresolv). 2) The value of $resolvfile cannot not be used the determine the dnsmasq main instance since several instances likely will an equal value. 3) The main dnsmasq instance is the instance that listens on 127.0.0.1:53 (of which there can only be one or none). 4) When no local DNS resolver runs /tmp/resolv.conf should soft-link $resolvfile (and that could possible be something else than /tmp/resolv.conf.auto). ad 3) The designated main instance can be determined at runtime by: - at start of an instance X, when this instance is configured to listen on 127.0.0.1#53 and no process listens on that socket, then - at stop of an instance X, when this instance is configured to listen on 127.0.0.1#53 and a process listens on that socket, then For a listening-on test something like “nslookup localhost 127.0.0.1#53 >/dev/null” would seemingly work (though not on OWRT CC), but that will incur a timeout delay (10 sec ?) when no daemon is listening. Understandably, suggestions for an alternative test that will not incur such a timeout are welcome. The above determination of the main instance assume that only one of multiple instances is configured to listen on 127.0.0.1#53, otherwise the tests may result erroneously in undefined behaviour. ad 4) A use-case for setting resolvfile to a non-default might be the use of different upstream resolvers for different subnets, though that could easily be achieved with the server options of UCI dhcp.dnsmasq[x]. Regards, Paul > Op 4 jun. 2017, om 00:09 heeft Hans Dedecker het > volgende geschreven: > > On Sat, Jun 3, 2017 at 3:33 PM, Paul Oranje wrote: >> Thanks, please see a few quick reactions of mine inline ... >> Paul >> >>> Op 3 jun. 2017, om 14:18 heeft Hans Dedecker het >>> volgende geschreven: >>> >>> On Thu, Jun 1, 2017 at 12:00 PM, Paul Oranje wrote: Hello Hans, A new version of this small patch is worked on -overlooked your previous comment and have lately been busy with other stuff-, but after studying the code a little more I’ve a few questions. The intended patch changes code that was added with commit a35f9bbc43c3da06eed042f80dc09e8c1da681b4 (dnsmasq: Multiple dnsmasq instances support) that was authored by you. The routines dnsmasq_start() and dnsmasq_stop() contain a guard on writing and resetting /tmp/resolv.conf: [ "$resolvfile" = "/tmp/resolv.conf.auto” ] && As explained in FS#785, the guard test fails when $noresolv is true and $resolvfile has not been explicitly configured to its default "/tmp/resolv.conf.auto", causing /tmp/resolv.conf to remain a soft link to /tmp/resolv.conf.auto (the WAN its DNS). The routine dnsmasq_stop() the guard is commented with #relink /tmp/resolve.conf only for main instance This suggests that only for the main (first ?) instance /tmp/resolv.conf would be handled, which makes sense, but the test to accomplish that seems wrong. Q1: What is the supposed relation between dnsmasq instance and the value of the value/setting of resolvfile ? >>> The DNS servers learned on the wan interface(s) by netifd are written >>> in /tmp/resolv.conf.auto. By default a dnsmasq instance uses >>> /tmp/resolv.conf.auto as resolver file unless configured otherwise. >> Indeed and whether dnsmasq uses the (whatever) resolvfile is governed by the >> noresolv parameter; these two parameters are orthogonal. >> The init script though skips setting resolvfile when noresolv is true. > Agree the value of noresolv should have no influence on reading he > resolvfile parameter; this behavior has been introduced in commit > 2ac21bd793946a214295b760cd652b4150d3dc07 So I blamed the wrong commit. >> >>> Using /tmp/rsolv.conf.auto as resolver file triggers logic to rewrite >>> /tmp/resolv.conf >> Why would the question whether local DNS resolution is handled by the DNS >> available on WAN interface be determined by this specific **value** of >> $resolvfile (and irrespective of the actual existence of that file) ? >> >> Also the above question (Q1) is about the relation with the dnsmasq >> **instance**. >> Could you please share your thoughts on the relation behind first instance >> and the value of $resolvfile ? > If resolvfile is set to /tmp/resolv.conf.auto assumption is made this > is the main dnsmasq instance due to a lack of a better criterium. DHCP > configs in use before the introduction of multiple dnsmasq instances > used /tmp/resolv.conf.auto as netifd by default populates the file > /tmp/resolv.conf.auto. That's the only link I see between the main > dnsmasq instance and the value of resolvfile >> >> A fix I considered is to omit this guard altogether (so different from the patch previously submitted), so that the local DNS service will allw
Re: [LEDE-DEV] Archer c7 corrupted firmware bootloop - tftp aborting - serial not working
On 06/04/2017 02:54 PM, QWeRKUS qwErkus wrote: > Thank you for your reply. JTAG seems even trickier than serial. So far > all my attempts to scan for a valid JTAG chain end up with: > > Error: JTAG scan chain interrogation failed: all zeroes > > There a just too many variables to check for a newbie like myself, so > I guess I'll go with the spi programmer. Turns out this is another > thing the pi can do (via flashrom) so no need for new hardware. Are > you sure you need to desolder the chip though ? Shouldn't this be > working with a 8 pin SOIC clamp and and external 3.3V power source (I > have an old ATX PSU doing the job) ? > > It should, but in some cases it does not (depends from how the board was designed) and in those situations you need to desolder the chip. I got most of these "cases where it does not work" in PC and laptop boards though. -Alberto ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Archer c7 corrupted firmware bootloop - tftp aborting - serial not working
Thank you for your reply. JTAG seems even trickier than serial. So far all my attempts to scan for a valid JTAG chain end up with: Error: JTAG scan chain interrogation failed: all zeroes There a just too many variables to check for a newbie like myself, so I guess I'll go with the spi programmer. Turns out this is another thing the pi can do (via flashrom) so no need for new hardware. Are you sure you need to desolder the chip though ? Shouldn't this be working with a 8 pin SOIC clamp and and external 3.3V power source (I have an old ATX PSU doing the job) ? many thanks for your help, qwerkus On Sun, Jun 4, 2017 at 1:19 PM, Russell Senior wrote: >> "QWeRKUS" == QWeRKUS qwErkus writes: > > QWeRKUS> Thank you for your replies. Turns out the problem was the > QWeRKUS> ground connection, and serial nowworks with > QWeRKUS> pl2303. Unfortunately I mixed up 2 addresses when flashing the > QWeRKUS> new firmware, and erased from 0x9f00 on instead of > QWeRKUS> 0x9f02. As a result, my boot loader is corrupt. Now I'm > QWeRKUS> trying some last resort salvage over JTAG, using an rpi with > QWeRKUS> openocd as JTAG dongle. Assuming I manage to compile openocd > QWeRKUS> with ath79 support (which currently fails), can I use the > QWeRKUS> u-boot from pepe2k to restore my uboot ? I yes, how does it > QWeRKUS> work: just copying the bin to flash from 0x9f00 onwards ? > > Another approach is to write the flash with an external programmer. You > might need to desolder the flash chip, if you can't figure out how to > hold the CPU in reset. It looks like the c7 has a regular SPI flash > chip. It is probably just an 8-pin part, and not too hard to desolder, > if you need to. Solder wick is handy for cleaning up the pads after you > remove it. > > I have recently used a bus pirate or a teensy 3.1 with the flashrom > program to read/write spi flash. Likely to be Way easier that trying to > figure out JTAG. Make *very* sure you have a (or several) complete > backup of the flash part before writing over it. > > > -- > Russell Senior, President > russ...@personaltelco.net ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Archer c7 corrupted firmware bootloop - tftp aborting - serial not working
> "QWeRKUS" == QWeRKUS qwErkus writes: QWeRKUS> Thank you for your replies. Turns out the problem was the QWeRKUS> ground connection, and serial nowworks with QWeRKUS> pl2303. Unfortunately I mixed up 2 addresses when flashing the QWeRKUS> new firmware, and erased from 0x9f00 on instead of QWeRKUS> 0x9f02. As a result, my boot loader is corrupt. Now I'm QWeRKUS> trying some last resort salvage over JTAG, using an rpi with QWeRKUS> openocd as JTAG dongle. Assuming I manage to compile openocd QWeRKUS> with ath79 support (which currently fails), can I use the QWeRKUS> u-boot from pepe2k to restore my uboot ? I yes, how does it QWeRKUS> work: just copying the bin to flash from 0x9f00 onwards ? Another approach is to write the flash with an external programmer. You might need to desolder the flash chip, if you can't figure out how to hold the CPU in reset. It looks like the c7 has a regular SPI flash chip. It is probably just an 8-pin part, and not too hard to desolder, if you need to. Solder wick is handy for cleaning up the pads after you remove it. I have recently used a bus pirate or a teensy 3.1 with the flashrom program to read/write spi flash. Likely to be Way easier that trying to figure out JTAG. Make *very* sure you have a (or several) complete backup of the flash part before writing over it. -- Russell Senior, President russ...@personaltelco.net ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] ATH10K-CT debug messages
FAO that nice Mr Greer, I'm getting (for free) a nice selection of ath10 debug messages when using the Ath10K-ct firmware & driver in LEDE. A small collection reproduced below. Are they of any interest/use? [ 60.808281] ath10k: []: 73060100 0500FC17 70201031 0800 8000 B8F74000 01000600 7D060100 [ 60.817474] ath10k: [0008]: 085CFC0F D8654400 0800 8000 7D060100 065CFC0F B8F74000 D0714400 [ 60.826651] ath10k: [0016]: 1900 7D060100 065CFC0F 0900 D0714400 98889C00 DF060100 100CFC0B [ 60.835834] ath10k: [0024]: 8A291001 0300 DF060100 130CFC03 E6060100 234CFC0F 0100 0100 [ 60.845019] ath10k: [0032]: 0100 ED060100 234CFC0F 0100 0100 0100 2F070100 234CFC0F [ 60.854206] ath10k: [0040]: 0100 0100 0100 36070100 234CFC0F 0100 0100 0100 [ 60.863394] ath10k: [0048]: 3F070100 234CFC0F 0100 0100 0100 46070100 234CFC0F 0100 [ 60.872582] ath10k: [0056]: 0100 0100 4D070100 234CFC0F 0100 0100 0100 54070100 [ 60.881763] ath10k: [0064]: 234CFC0F 0100 0100 0100 56070100 0C64FC07 0100 5D070100 [ 60.890946] ath10k: [0072]: 234CFC0F 0100 0100 0100 5D070100 092C 80F24300 0200 [ 60.900134] ath10k: [0080]: 5D070100 065C000C 0800 D0714400 A0889C00 5D070100 0928000C [ 60.909321] ath10k: [0088]: 61661071 80F24300 E8F84300 5D070100 0928000C 60661071 80F24300 E8F84300 [ 60.918509] ath10k: [0096]: 5D070100 085C0008 80F24300 00664400 5D070100 065C000C 1100 D0714400 [ 60.927695] ath10k: [0104]: A8889C00 5D070100 045C000C 03001081 80F24300 5D070100 02280008 [ 60.936871] ath10k: [0112]: 0300 0300 5D070100 02280004 0300 5F070100 4F4C0014 7300 [ 60.946053] ath10k: [0120]: BCE44100 747D4300 7100 5F070100 4F4C0014 6300 F4E44100 [ 60.955240] ath10k: [0128]: 747D4300 01007200 5F070100 564C0014 747D4300 08CD9B00 1100 [ 60.964426] ath10k: [0136]: 203D 5F070100 564C0014 747D4300 50CD9B00 1200 [ 60.973619] ath10k: [0144]: 202D 5F070100 564C0014 747D4300 98CD9B00 1000 0A00 403D [ 60.982800] ath10k: [0152]: 5F070100 564C0014 747D4300 E0CD9B00 1300 203D 5F070100 [ 60.991988] ath10k: [0160]: 035C0014 0100 14CC20BE 8930 94AC9B00 747D4300 63080100 0B200010 [ 61.001168] ath10k: [0168]: 80F24300 0A04 [ 61.007172] ath10k_pci :01:00.0: ATH10K_END [ 61.071878] br-wifi_guest: port 2(wlan1-1) entered disabled state [ 62.127413] br-wifi_priv: port 2(wlan1) entered forwarding state [ 62.134543] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1-1: link becomes ready [ 62.141350] br-wifi_guest: port 2(wlan1-1) entered forwarding state [ 62.147823] br-wifi_guest: port 2(wlan1-1) entered forwarding state [ 64.147395] br-wifi_guest: port 2(wlan1-1) entered forwarding state [ 120.754049] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 120.760686] br-wifi5_priv: port 2(wlan0) entered forwarding state [ 120.766948] br-wifi5_priv: port 2(wlan0) entered forwarding state [ 120.781339] ath10k_pci :01:00.0: htt peer map vdev 0 peer 14:cc:20:be:89:30 id 131 [ 120.797138] device wlan0-1 entered promiscuous mode [ 120.806036] ath10k_pci :01:00.0: ath10k_pci ATH10K_DBG_BUFFER: [ 120.812372] ath10k: []: 4CF90100 0920040C 00F34300 0300 4CF90100 065C040C 0800 [ 120.821564] ath10k: [0008]: D0714400 B0889C00 4CF90100 4E4C0410 01991091 0700 4C01 A8C99B00 [ 120.830746] ath10k: [0016]: 4CF90100 035C0414 07001109 14CC20BE 8930 CCAC9B00 4CF90100 [ 120.839938] ath10k: [0024]: 025C0414 00F34300 CCAC9B00 14CC20BE 8930 0100 4CF90100 0928040C [ 120.849120] ath10k: [0032]: 61661071 00F34300 1CF94300 4CF90100 0928040C 60661071 00F34300 1CF94300 [ 120.858307] ath10k: [0040]: 4CF90100 045C040C 03001081 00F34300 4CF90100 0B200410 00F34300 [ 120.867489] ath10k: [0048]: 0A04 4CF90100 07200404 00F34300 4CF90100 094C0414 [ 120.876660] ath10k: [0056]: 0300 0100 FF00 0100 8000 4CF90100 074C0408 0300 [ 120.885842] ath10k: [0064]: 4CF90100 08200404 00F34300 4CF90100 0A4C0410 0300 0100 [ 120.895028] ath10k: [0072]: FF00 8100 4CF90100 084C0408 0300 4CF90100 0A200404 [ 120.904216] ath10k: [0080]: 00F34300 4CF90100 075C040C 0800 D0714400 B0889C00 4CF90100 09280410 [ 120.913402] ath10k: [0088]: 62661071 00F34300 1CF94300 4CF90100 5B4C0404 A8C99B00 4CF90100 [ 120.922591] ath10k: [0096]: 055C0404 00F34300 33FA0100 0B200010 80F24300 0A04 [ 120.931778] ath10k: [0104]: 33FA0100 0724 80F24300 33FA0100 094C0014 0001 FF00 [ 120.940964] ath10k: [0112]: 0100 8000 33FA0100 074C0008 4FFA0100 4F4C0014 [ 120.950152] ath10k: [0120]: 8300 2CE54100 747D4300 0100 010
