**** BEGIN LOGGING AT Fri May 31 02:59:58 2019 May 31 05:42:15 <_abc_> Hi. Does anyone have a facorite SPI flash programmer for use with openwrt projects? For upgrading serial spi flash on routers in particular. Has to work on linux host. May 31 05:47:29 * _abc_ assumes it's too early for intelligent talk, he being on EU tz, morning here now, will be back much later for NAm TZ irc chatting. May 31 06:07:35 _abc_: use and ardunio ... that is what i do, much cheaper May 31 06:08:48 <_abc_> It does not necessarily need to be cheap blogic May 31 06:16:37 i was more considering simple and available May 31 06:18:51 <_abc_> And unreliable. I would like to work on the openwrt modding project, not on fixing broken things in arduino land. May 31 06:22:27 I have been using the atmel uC method since 10+ years, not been unreliable here, but i guess you knew the answer to your question prior to asking so go ahead and buy what you think works best for you. May 31 06:22:34 if it does the trick then thats good May 31 06:23:33 what also works is just buying a jtag. my bdi3000 is what i use as a last straw with the mtk/qca spi boot stubs May 31 06:23:47 the unit costs around 3k incl the FW blobs May 31 06:24:11 <_abc_> bdi3000 noted. A little overkill for what I need now :) May 31 06:34:12 https://flashrom.org/Supported_programmers May 31 06:47:12 <_abc_> Anyone using this? https://github.com/dword1511/serprog-stm32vcp May 31 06:48:45 <_abc_> I assume CH341 based usb dongles are not so popular besides being very slow and very cheezy hw wise. May 31 06:50:13 i use a ch341a and axtw100 May 31 06:50:19 i use a ch341a and an xtw100 May 31 06:50:24 <_abc_> Is it not very very slow? May 31 06:50:31 not really May 31 06:50:37 they are cheap so its okay May 31 06:50:46 <_abc_> sure they are cheap May 31 06:54:26 <_abc_> using this? gweentea ? https://github.com/mytbk/xtw100 May 31 06:58:16 _abc_: flashrom with a teensy is what i use May 31 06:58:34 <_abc_> ok, thanks for the input. Moving on for a bit now. May 31 07:00:35 https://www.flashrom.org/Teensy_3.1_SPI_%2B_LPC/FWH_Flasher ... but i made my own board May 31 07:06:54 people seem to use raspberry pi's a lot as well May 31 07:27:00 well, almost anything with spi bus (or a gpio) should work May 31 07:33:41 the raspi has the advantage that you are leveraging a hardware spi interface, i think May 31 07:34:41 and they are cheap-ish and easy-ish to find May 31 07:39:44 argh, what is the make target to clean the python host package? May 31 08:01:03 i'm on 10099-gcf463159df and getting a "Patch failed! Please fix ./patches-setuptools/001-reproducible.patch!" May 31 08:01:14 i think i found the make target May 31 08:04:20 package/python/host/{clean,compile} May 31 08:04:50 which didn't fix it ... /me gets out magnifying glass for closer inspection May 31 09:00:09 gweentea: hmm, I wonder if xtw100 support could be added to flashrom May 31 09:01:08 dirclean fixed it May 31 09:11:46 * ldir comes in very late to conversation May 31 09:12:31 russell--: on previous occasions removing openwrt/tmp has been helpful for solving 'strange' problems for me. May 31 09:33:40 I'm using an external toolchain. I noticed that the toolchain in staging_dir is different (according to cmp) to the toolchains I linked. What does OpenWRT do to the toolchain bins when copying them to the staging_dir? May 31 09:34:42 Has anyone had any strange behavior with the LEDs on ath79? On my device, it seems that the LEDs are off by one, so if I connect my cable to for example LAN2, then the LED of LAN1 starts to blink May 31 09:35:36 The LED for WAN works out of the box, and I have ensure that the GPIOs controlling the LEDs are enabled. Since the LEDs are off by one, then there is one port where no LED turns on May 31 09:35:53 LED might be wrong, I mean the lights above the switch port May 31 10:05:41 kristrev: Bootloader may set the pinmux registers so that some LEDs are directly handled by hardware. May 31 10:06:13 kristrev: which is your device? May 31 10:06:26 kristrev: In this case if you want to use them as normal GPIO LEDs you need to clear corresponding pinmux registers. May 31 10:07:36 gch981213: Thanks, I tried to clear the register but it seems to have no effect. Exporting the gpio + setting value to 0/1 also does not seem to do anything. The LEDs work correctly with the vendor firmware, so there is something I am doing (or rather not doing) :) May 31 10:08:02 russell--: ZBT WD323. I though I was almost done adding support for the device, but then this issue appeared May 31 10:08:07 the ports work just fine May 31 10:47:00 Hellsenberg: well I dont know. I just use the windows software (please dont kill me) for xtw100. and yeah it is faster May 31 10:47:34 just giving you project ideas :P May 31 10:57:18 <_abc_> Does anyone know if the AR7241 has the same pinout as the AR7240? 7240 seems impossible to find. May 31 11:00:46 ldir: /me used magnifying glass as a mallet (dirclean), which was effective and didn't strain the eyes May 31 11:01:52 _abc_: https://forum.mikrotik.com/viewtopic.php?t=65278 suggests otherwise, or at least not drop-in-compatible, though no hard evidence May 31 11:02:49 <_abc_> Seems to be the same chip, different variant. Normally on MIPSen GPIOs are strapped with resistors up and down to determine boot characteristics, no? I'm trying to access some gpios which are nor broken out to leds or such, they seem to go to pull resistors. May 31 11:04:15 <_abc_> KanjiMonster: you seem to be right but the 7241 ds pinout I found seems to match what I have (wr741 v1.5) which is a 7240. Pin count and location for all key pins seems to match May 31 11:04:19 <_abc_> power clock usb etc May 31 11:05:45 i had trouble with ethernet not working when the wrong (7240 vs 7241, iirc) soc was used (variants of ubnt nanostation m's) May 31 11:06:03 memory has faded a bit May 31 11:06:05 if not 100% equal, they might be very similar w.r.t. pinout May 31 11:06:54 <_abc_> Internal mods are there for sure, these come in Xteen Si revisions, I am interested in the pinout of gpios which lead to pull resistors where it is possible to solder ww wires. May 31 11:06:57 i do remember it was cold out when i was debugging it May 31 11:07:17 <_abc_> What was cold out? May 31 11:07:28 the weather May 31 11:07:44 i was sitting outside on an apartment steps May 31 11:07:51 <_abc_> O.o May 31 11:08:00 was ~freezing May 31 11:08:11 so, ~6 months ago ;-) May 31 11:08:24 <_abc_> Prepping to become an airplane mechanic are you ? :) May 31 11:08:45 field work can be fun, but less fun in winter May 31 11:09:18 <_abc_> Aha so some gpio pins are used for EJTAG. There should be a header... May 31 11:10:42 <_abc_> No obvious header pads. Would they have optimized the header out already in v1.5? May 31 11:11:31 jtag is usually easy to spot, just from the number of pins involved May 31 11:11:50 _abc_: it might have higher power draw on some pins (or something like that, I'm no hardware engineer) or the pinstrap pins have different meanings, which is why the mikrotik guy said it requires modifications May 31 11:13:28 <_abc_> yeah but no ejtag breakout means what? May 31 11:13:36 <_abc_> "perfect design"? May 31 11:18:27 saved 0.02c May 31 11:36:17 ...times 500000 devices ;) May 31 12:17:45 <_abc_> Normally ejtag header even unpopulated is no longer present by rev 2 or so. Getting it right from 1.x is hard ime :) May 31 12:18:38 <_abc_> Next problem: I have identified 3 gpios which are unused in this wr741 hw, identified resistors they are connected to, set them up as exported with echo $gpio >../export and now: May 31 12:19:01 <_abc_> a) they read as 1 while the external setup is pulldown 10k, and inverted pin logic is 0 May 31 12:19:13 <_abc_> b) making them outputs and writing to them has them stay at 0. May 31 12:19:32 <_abc_> Is it customary for non managed (led etc) gpio pins to be "crippled" in the openwrt kernel? May 31 12:19:42 <_abc_> I.e. no support for controlling them? May 31 12:19:52 <_abc_> The fw support is clearly there. May 31 12:21:37 <_abc_> hmm? May 31 12:24:55 <_abc_> Guys? :) May 31 12:25:15 <_abc_> Am I in uncharted territory. I'll have to read sources to find out myself. Hints would be nice? Please? May 31 12:26:30 <_abc_> Conclusion: the router uses platform control for leds, not a module, leds can be controlled using tp-link specific led names in sysfs. The unused gpios are strapped down with 10k on hw, can be exported and set in out, but read "1", and cannot be written. May 31 12:26:39 <_abc_> why?! May 31 12:27:15 * Hellsenberg is being silent because they cannot provide any information on the topic :( May 31 12:31:37 <_abc_> Is the source of bb / 17.01 etc online in a repo somewhere I can browse? May 31 12:37:11 hi, I'm currently looking into a problem with gue tunneling over ipv6 and I don't exactly know where to ask. All packets originating from my edge router x running kernel 4.14.121 seem to have a bad udp checksum. All packets from my workstation running 4.19.46 have a good one though. The checksum in the packets coming from the router are the values returned by udp6_set_csum and I think this is not correct because the way it seems to be May 31 12:37:11 calculated is that it's missing out the bytes in the "Destination Options for IPv6" frame. Here is a summary of everything I could capture: https://paste.sh/L2H84XZq#_scPYrIaE-rgH-_ulpSk5jrJ May 31 12:59:52 <_abc_> Older release files from say bb 17.x are no longer in packages.openwrt.org ? May 31 13:00:51 <_abc_> Are they online somewhere one can find and use as is or do I need to set up an offline repo for the router to find? May 31 13:03:06 http://downloads.openwrt.org/ there are archives as well May 31 13:05:14 and http://archive.openwrt.org/ May 31 13:05:49 But do keep in mind the BB is no longer supported and contains multiple unpatched security vulnerabilities. May 31 13:06:23 s/the/that May 31 13:07:38 BB is 14.x though. I'm not sure about the support status of LEDE 17.x. May 31 13:08:18 <_abc_> Don't worry, I am tinkering with hw. It has to be 17 because someone made a firmware image for ths 741 with hacked in usb support. This is what I am using for testing. May 31 13:08:45 <_abc_> A link to the kernel sources showing gpio area would be very nice though. I have no idea why I can't control gpios in the usual way using sysfs May 31 13:20:44 <_abc_> I'll wait for perhaps jeffsf to chip in a bit. I have a lot of gpio questions. Is the rpi/etc specific openwrt version off topic here? That one deals a lot with gpio. May 31 13:30:06 About my earlier ath79 LED issue. I had a bit of a mess in my DTS - took a break, cleaned up the file and now they work as intended May 31 13:45:52 <_abc_> kristrev: interesting, say more? kernel led gpio driver, platform specific to ath79? May 31 14:00:27 Just want to clarify my understanding. For /dev/spi and /dev/i2c to be present, the peripherals need to be enabled in the .dts, kernel support needs to be enabled and the relevant kmods need to be installed. Is this correct? May 31 14:07:56 Functionality is missing between a previous (vendor-supplied) firmware and current stock openwrt. I suspect it's down to differences in the dtb May 31 14:56:18 <_abc_> shifttymike: which vendor? rpi/banana/bb etc? May 31 15:03:29 _abc_: On ath79 devices you will in some cases need to enable gpio pins by writing to certain registers. Which register to write is given in the datasheet for your device May 31 15:15:53 <_abc_> kristrev: I thought is it automated using sysfs May 31 15:17:05 <_abc_> kristrev: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr741nd.c;h=5931654bbdb9679511e4164212cb863b6aa7ebbd;hb=refs/heads/lede-17.01 my current "patient". I am doing this for historic reasons, see function ath79_gpio_function_disable() in there and the dts initialized tables. May 31 15:17:19 <_abc_> kristrev: or I did not understand what you meant. May 31 15:17:59 <_abc_> kristrev: on the router which runs 17.04 the ath79_* controlled leds and buttons work, the other gpios are not active at all, not reachable from software. May 31 15:20:15 I have not worked with ar71xx, so I cannot give any answers unfortunately May 31 15:20:28 <_abc_> It's the same thing as ath79, just older. May 31 15:20:37 <_abc_> See it refers to ath79 inside it May 31 15:21:41 _abc_: I'm confused by mention of DTS and ar71xx, as ar71xx is, as far as I know, mach-based and does not use DTS/DTB May 31 15:22:25 The deprecated exposure of GPIOs in sysfs required a board definition to indicate what "GPIO 7" means in terms of internal registers May 31 15:22:33 <_abc_> Did you see my direct link to the thing I seem to be using ? The real thing uses a modded source tree but not kernel modded https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr741nd.c;h=5931654bbdb9679511e4164212cb863b6aa7ebbd;hb=refs/heads/lede-17.01 May 31 15:22:40 For ar71xx, that would likely be in the mach file May 31 15:22:43 While ar71xx/ath79 are used for the same boards, they work very differently May 31 15:22:47 <_abc_> See the 1st few lines? #defines May 31 15:22:53 As jeff says, ar71xx uses mach-files, ath79 dts May 31 15:23:16 <_abc_> Okay, mach files, I used dts loosely as meaning the same thing. May 31 15:23:19 I have only worked with ath79, so I do not know anything about the mach-files used by ar71xx May 31 15:24:11 <_abc_> Let's focus on the file I linked: Why can't I find the ath79_gpio_function_disable() function and the includes in the top 2 include lines in the tree? Looking harder May 31 15:25:00 Those macro definitions are later used in the initialization subroutines, such as gpio_led tl_wr741nd_leds_gpio[] May 31 15:25:35 <_abc_> ath79_gpio_function_disable() is one of the things which fascinate me at the moment. Why "disable". Does that mean the remaining gpios remain enabled? Because they are not! May 31 15:26:00 which then get called in early kernel initialization by static void __init tl_wr741nd_setup(void) May 31 15:27:20 <_abc_> Why is the definition of the function not in the tree?! I find it only in patches. https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=refs%2Fheads%2Flede-17.01&st=grep&s=ath79_gpio_function_disable -- where the heck is it? May 31 15:28:24 Because a lot of things that are needed to support the plethora of all-in-one routers haven't been (and may never be) accepted upstream in Linux May 31 15:29:21 <_abc_> Sure but there should be some sort of "base" file, or are those patches going back to "day zero" when that raw kernel src was imported into openwrt and patched? May 31 15:29:49 Patches are refreshed with every kernel change of significance May 31 15:30:10 make target/linux/{clean,prepare} will show you the patched results May 31 15:30:14 <_abc_> So it's roughly what I said? Raw kernel major src is imported, patch set is applied, etc? May 31 15:30:29 <_abc_> I'm reading git sources do not have an unpacked tree locally. May 31 15:31:08 <_abc_> Also, does this mean the git browser does not "see" the kernel srcs themselves as shown? May 31 15:31:09 You will with the above command, or after a build in build_dir/target/linux-*/linux-*/ May 31 15:31:11 <_abc_> Or does it. May 31 15:31:30 <_abc_> I would prefer to focus on the web interface to git I linked to for now. May 31 15:32:00 Linux sources are downloaded and extracted, based on the definitions of KERNEL_VERSION (as I recall) in the OpenWrt source tree May 31 15:32:20 OpenWrt sources do not include the Linux sources (or most packages' sources) May 31 15:32:31 <_abc_> But then the whole thing is not checked into git at all? May 31 15:32:54 <_abc_> I feel like I am looking at the chopped off bits of a monster :) I can see the bits but not the monster's carcass. Okay, moving on. May 31 15:33:23 <_abc_> I did not know git can be set up to "ignore" a huge imported src set like the linux kernel's May 31 15:34:33 <_abc_> reading https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/patches-4.4/002-add_back_gpio_function_select.patch;hb=c476954633887d8a1fcd80482e821074d7c4a36e it looks like the gpios must be enabled to work, disable is "facultative" ? May 31 15:34:36 It doesn't -- it isn't part of the souce May 31 15:35:18 git also "auto-ignores" git trees within an outer tree May 31 15:35:40 and large swaths can be .gitignore-ed by naming the directory May 31 15:36:58 See https://openwrt.org/docs/guide-developer/build-system/use-patches-with-buildsystem May 31 15:37:13 <_abc_> Ah ok. May 31 15:37:42 <_abc_> So I am effectively looking at the patches and added openwrt tree in the git I am looking at, not at the whole kernel build tree after patching. May 31 16:05:43 <_abc_> The internet has become a cesspool. Impossible to search technical stuff. May 31 16:06:10 <_abc_> 'kernel source 3.10.49 "ath79_gpio_init" ' on google brings TWO results. Wow. May 31 16:07:08 <_abc_> Is ath79 in the mainline kernel tree from kernel org at all? I think not? May 31 16:17:03 yes, but not back in 3.10.... May 31 16:18:09 <_abc_> https://www.8devices.com/community/viewtopic.php?f=13&t=782&start=40 here's a patch which contains what is relevant, but everyone seem to do whatever they want, no consensus?! Note they open a sys devtree entry called ath79_gpio there but that does not exist on my 17.04 openwrt May 31 16:18:32 <_abc_> ath79_gpio_chip.of_node = of_find_node_by_path("/ath79-gpio"); in void __init ath79_gpio_init(void) May 31 16:19:37 <_abc_> So the only way to get a full tree and read it would be for me to get the sources for 3.10.49 then the openwrt patches for that src major and openwrt patch level and apply the patches. Correct? May 31 16:21:47 your build directory contains the complete sources May 31 16:22:06 <_abc_> I do not have a build directoty. People keep going back to this. If I had a build directory I would not be asking :) May 31 16:23:16 Running menuconfig, selecting target and then make target/linux/prepare will probably not consume large amounts of storage May 31 16:23:39 if storage is the issue May 31 16:24:43 <_abc_> I do not have the tree installed at all, there is no space on the current machine, I have a mini farm of headless machines for this, it's a lot of work. Too many things going on at the same time. I need to simply get the build system installed on one of them. Until then, I learn what I need to know by reading sources and git online and discussing here (sorry for the noise). May 31 16:25:34 yeah, just stop trying. get a buildrood and have it build teh source for you that you care about. you're going to keep running into pain until you do. May 31 16:27:08 <_abc_> I'm actually trying to do forensics, find out why this 2015 configured 741nd with usb mod and custom BB on it does not let me control perfectly good GPIOs which are seen and configurable in /sys/class/gpio/export etc May 31 16:28:46 <_abc_> modprobe -f is not healthy in general on openwrt right? Even from the same kernel and so on? May 31 16:31:07 iirc it taints the kernel May 31 16:31:15 <_abc_> [new item] on 18.06.2 suggest network throughput and so on parameter tuning using echo and so on? May 31 16:31:30 2 (F): A module was force loaded by insmod -f. May 31 16:32:51 <_abc_> Is there a general-purpose exposed API for gpio poking and peeking in the kernel by default? In the manner of ioctl() etc on x86? For ar71xx and or ath79* ? May 31 16:33:16 <_abc_> *in the manner of not ioctl but that other thing lapsus prevented me from writing May 31 16:34:13 <_abc_> https://github.com/torvalds/linux/blob/master/include/linux/ioport.h this stuff. May 31 16:36:12 _abc_: isn't there /sys/class/gpio ? May 31 16:36:15 any perl nerds know what's wrong with this: system("find @ARGV -type f -name '*.lua' -exec echo the name is {} \;"); ? I just get "missing argument to -exec" May 31 16:36:19 <_abc_> http://git.annexia.org/?p=ioport.git;a=blob_plain;f=port.c;hb=refs/heads/master or this May 31 16:36:47 <_abc_> Hellsenberg: yes and it works and it permits exporting the gpios which are not leds or switches and I did that and nothing is moved on the external HW. May 31 16:37:11 <_abc_> Hellsenberg: which is somewhat confusing but I am quite sure of what I did. May 31 16:37:21 <_abc_> I am a hw guy. May 31 16:37:59 "On non-x86 architectures, this operation probably isn't possible." I/O addresses (as opposed to memory addresses) isn't a thing on many non-x86 architectures May 31 16:38:14 <_abc_> Thus my question, whether it exists on mipsen May 31 16:38:39 oh, nvm, adding a \ fixes it, but my real problem was it hanging. May 31 16:38:45 <_abc_> Even the concept of iopl() does not seem to exist. May 31 16:38:45 most likely, no May 31 16:38:46 need intermediate file bullshit... May 31 16:39:36 <_abc_> karlp: I think you need more quoting around the args of echo May 31 16:39:44 _abc_: even though it's not the chip you have, this might help: https://www.openhacks.com/uploadsproductos/ar9331_datasheet.pdf May 31 16:40:03 it uses MMIO for devices May 31 16:40:15 <_abc_> 9331 has different io assignment from 7241/7240 May 31 16:40:25 <_abc_> mmio? May 31 16:40:25 but it has the same arch, doesn't it? May 31 16:40:40 well, memory mapped IO, as opposed to port IO (on x86) May 31 16:40:41 no, it just needed a \\; on the last bit. May 31 16:41:10 <_abc_> Hellsenberg: sure all mipses do memory mapped everything May 31 16:41:29 so you just need to read/write to the right place May 31 16:41:46 <_abc_> Unless there is a mask register to set. Which I think there is. May 31 16:43:04 <_abc_> How does one work with /sys/class/misc/network_latency/ /sys/class/misc/network_throughput/ for fine tuning ? May 31 17:22:12 <_abc_> I now suspect the EJTAG_DISABLE bit in the GPIO_FUNCTION_1 register is not set so the EJTAG gpio muxed pins are EJTAG and not GPIO, even though this board has no EJTAG header pads. May 31 17:22:33 <_abc_> And there is no way to look/know since there is no way to see a full source tree without building it :) May 31 17:23:06 Again, make target/linux/{clean,prepare} May 31 17:23:26 No build, but will download, extract, and patch May 31 17:23:27 <_abc_> Yes, once sources installed etc. Not the case till Sunday evening at least. May 31 17:24:37 Run a VM, install Debian, 16 GB or larger virtual disk May 31 17:24:49 <_abc_> There is no room on the laptop for such things :) May 31 17:25:04 <_abc_> I will kick one of the zombie headless machines into life on Sunday. May 31 17:25:18 USB stick for 10 dollars / euros, whatever May 31 17:25:23 <_abc_> Hm? May 31 17:25:47 <_abc_> Oh that, I have. I need the speed though. So no USB for this. May 31 17:26:02 <_abc_> Small 120GB SSDs were under $25 new here since Xmas May 31 17:26:05 How much time are you wasting by not looking at the source? May 31 17:26:34 <_abc_> It is facultative since I need to hedge for future problems in current releases of openwrt, I am not trying to fix an old release. May 31 17:26:56 <_abc_> The hedging is for the hw I designed and am going to integrate with newer machines. This is a guinea pig learning project for now. May 31 17:27:27 <_abc_> I hope you can see how tinkering with 5 year old source trees just to see whether a bit is set or not in a register is not a productive step in the bigger picture. May 31 17:28:00 <_abc_> What exactly is JUMPSTART mode on AR9331 ? Referring to the datasheet. May 31 17:28:15 No, I can't -- it's common practice to dig through even Linux 2.6 kernels to figure out how to port a device May 31 17:28:38 <_abc_> This is all hw related, there is no sw driver. May 31 17:59:42 <_abc_> Someone DDoS'd the house wifi which is a D-Link older router, second time it happens in a few days, needs hw reset to restart. May 31 18:00:13 <_abc_> not nice. Of course it is old fw but newest for that device from the maker. D-link blergh. May 31 18:02:55 <_abc_> wtf is wrong with the networks now. May 31 18:03:00 <_abc_> 2nd time I changed irc servers in 5 minutes May 31 18:04:40 <_abc_> And here we go again May 31 18:06:43 <_abc_> . May 31 18:16:08 <_abc_> Mh, reading headlines, russian army is adopting debian based Astra Linux. May 31 19:26:56 tmn505_: It's okay with me. Thank you. May 31 19:39:54 kab-el: thanks, I was just replying to Vladimir Vid about it. May 31 19:42:25 kab-el: and good luck on exam session. May 31 22:16:16 * russell-- is seeing "[ 31.204939] print_req_error: I/O error, dev loop0, sector 1498 May 31 22:16:30 on a soekris net4826 May 31 22:16:48 but dd if=/dev/sda of=/dev/null shows no errors May 31 22:17:12 <_abc_> Would a neighbor's pc run with lids off be a good explanation for wifi signal going from -65dBm to -75dBm during that time? May 31 22:20:15 probably not May 31 22:21:57 <_abc_> Then what would, in your opinion? May 31 22:22:06 <_abc_> This is a new thing happening in the house. May 31 22:23:12 <_abc_> brb May 31 22:25:59 so, any other ideas? May 31 22:36:29 abcabc__: how far from the ap are you? May 31 22:37:01 5m through 2 imterior walls May 31 22:37:54 *n May 31 22:38:48 what band? May 31 22:40:03 2.5G May 31 22:40:53 2.4 May 31 22:41:39 if you have 'watch' on the router: watch -d iwinfo wlan0 assoclist May 31 22:41:58 you'll see a fair amount of bouncing around under even the most normal conditions May 31 22:42:23 non openwrt router (not yet) May 31 22:42:41 do you have a linux client device? May 31 22:42:55 yes May 31 22:44:31 iw wlan0 station dump May 31 22:44:59 watch -d iw wlan0 station dump May 31 22:45:06 and walk around (if possible) May 31 22:45:49 the interference is so bad sometimes that a laptop 1m from the router disconnects. May 31 22:46:02 wireless if FM (effing magic) May 31 22:46:11 too close can overdrive the radio May 31 22:46:39 it works okay for 3 years now May 31 22:46:41 is* May 31 22:47:11 the signal is (usually) a power measurement, has nothing to do with noise May 31 22:47:38 i get both, sig and noise May 31 22:48:19 the noise is often just a fixed number May 31 22:48:59 that's related to the spec for the lower limit of power it can demodulate May 31 22:49:15 (iirc) May 31 22:49:46 signals bounce off things, so any change in the geometry of your environment can affect received signal strength May 31 22:49:58 including people May 31 22:50:22 no changes May 31 22:50:23 or semi-animated electrolyte bags May 31 22:50:41 what does "no changes" mean? May 31 22:52:49 the saline bags did not increase in weight recently. May 31 22:52:59 they move though May 31 22:53:12 reflections can take surprising paths May 31 22:54:00 again, run the watch command i posted above and walk around and see what happens with the signal value May 31 22:54:43 measuring things leads to understanding May 31 22:54:57 everything else is just guessing May 31 22:55:31 (says an empiricist) May 31 22:56:32 ok, thanks, will try. zzz time now Jun 01 00:05:39 russell--: I'm seeing a number of print_req_error: I/O error, dev loop0, sector xxx as well, on multiple devices. my gut feeling would point towards the mtdsplit Jun 01 00:06:18 but I never investigated it any deeper, as the hardware is fine Jun 01 02:39:24 After commit afc056d7dc, the button stopped working properly on my ramips/mt7620 target. The first press of a button after reboot will get a LARGE SEEN, and it will be interpreted as a long press. So even a short press on reset will trigger FACTORY RESET.... Is anyone experiencing the same problem? Jun 01 02:40:17 After commit afc056d7dc, the button stopped working properly on my ramips/mt7620 target. The first press of a button after reboot will get a LARGE SEEN, and it will be interpreted as a long press. So even a short press on reset will trigger FACTORY RESET.... Is anyone experiencing the same problem? **** ENDING LOGGING AT Sat Jun 01 02:59:57 2019