**** BEGIN LOGGING AT Sun Dec 27 02:59:57 2020 Dec 27 04:01:36 r14281 again works (August 28 2020). The snapshots from today both do not. sysupgrade on top of r14281 and factory on top of the stock firmware. Dec 27 04:02:41 what should I do? Dec 27 05:40:52 would it be fine to define an led that's on the inside of a router (you can only see it thru a little crack) in the device tree? Dec 27 05:51:51 just for background, im adding support for this device Dec 27 05:55:08 I wouldn't assign it anything by default unless stock does Dec 27 05:55:19 but the option is nice no? Dec 27 05:59:10 alright sounds good. i'll just make a note in the device page or something in case someone somewhere happens to install it and finds a use for it. Dec 27 06:02:48 worst case scenario you get told to take it out when you submit the PR on github or patch on the mailing list Dec 27 06:04:59 i actually already have a pr in github but its been a month since the last reply lol. by the way, do you think you could help me with the led naming a bit? Dec 27 06:10:56 i'll just ask just in case someone can help Dec 27 06:12:21 so this device has a microcontroller that controls a single red/blue led and that's connected to the cpu with 3 gpio pins. based on what combo of pins you pull high or low, it'll blink different patterns with either color. right now the names for the pins are rt4230w:ledctrl:x where x is 1,2, and 3 but on the pr someone said that the names should be different. any advice on what to do with the names? also Dec 27 06:12:21 the pr is #3115 Dec 27 06:53:54 lmore377: adding existing LEDs (regardless of if you can see them or not) should be fine, DTS should describe the hardware as it is (not just to make linux work) Dec 27 06:54:30 but yeah, a comment about the LED's location sounds good Dec 27 06:55:35 iirc, the model name prefix has been dropped from all devices a couple of weeks ago Dec 27 06:55:52 err: iirc, the model name prefix for LEDs has been dropped from all devices a couple of weeks ago Dec 27 06:56:52 see https://git.openwrt.org/d181b2cefa5881d270e0e4cf9f42d1feaf2f7222 Dec 27 07:03:53 pkgadd: thanks I didn't know about that Dec 27 07:09:01 btw. target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts is using a single rgb LED, controlled by the TI/National LP5523/55231 LED driver chip. perhaps it helps as a potential reference Dec 27 07:10:50 it's really a pity that the rt4230w (or something similar, at a similar price point) isn't available in Europe, looks like a really nice device (but importing it, with shipping alone -before customs- kills any price advantage) Dec 27 07:40:59 damn that controller runs over i2c. do you know if there's a way to like have a script that intercepts led commands from openwrt and does it's own thing? Dec 27 07:48:52 the LP5523 controlled rgb LED is exposed to OpenWrt, but switched off by default (as soon as lp5523 module is loaded), no idea if there's a way to intercept LED sequences from the OEM firmware Dec 27 10:43:36 Hey guys, I've found an issue with mediatek 7620 - what is the best way to report it? Dec 27 10:51:53 reiffert: probably sending a patch to fix it ;) The next best way might be to add a ticket to the bug tracking system. Dec 27 11:04:05 FS#3539 Dec 27 11:54:25 reiffert: what is jboot? Dec 27 11:56:57 russell--: https://openwrt.org/docs/guide-user/installation/recovery_methods/jboot_web_recovery Dec 27 12:00:04 up until several minutes ago, i was not aware such a thing existed Dec 27 12:08:20 where in gituhub would I find the part that splits the image in parts and installs it into mtdblocks, I'm trying to find if there was a change between 8/26 and 12/26 specifically for ramips but I couldnt find any in openwrt/tree/master/target/linux/ramips Dec 27 12:18:06 if I'd knew how to do it I'd fetch the source tree for a specific date and could try to narrow down when it breaks Dec 27 12:23:14 how can i enable debug msgs in syslog for hostapd without recompiling openwrt/hostapd? can it be done? is there a package with that enabled? Dec 27 15:02:28 hi everyone. i'm struggling with getting ethernet to work on mikrotik rb2011 on ath79. pretty much everything else works, except wired networking. rb2011 has ar8237 gbit switch for the first 5 ports and sfp, and internal 100m switch for ports 6-10 Dec 27 15:04:38 i'm at the point where the switches are initialized, swconfig detects link status on the ports, but i can't reach anything. however, ARP table is built up over time, and i'm even able to create conflict if i plug it in my main network with ip 192.168.1.1 (because there's already a gateway with the same IP) Dec 27 15:05:08 i just can't ping anything from the rb2011, or ping it from anywhere Dec 27 15:05:27 here's my github repo with the current (a bit messy) state: https://github.com/danijelt/openwrt Dec 27 15:09:30 i got qca,ar8327-initvals values from the mach-rb2011.c file from ar71xx, as well as gmac-config and pll-data values. i tried using only eth0/mdio0, and eth1/mdio1, i tried using both, i tried defining ports on eth0 as they are defined in ar9344_pcs_cr5000.dts with has the same switch and 5x gbit ports, i tried not defining them, i tried with and Dec 27 15:09:30 without gmac-config, i tried phy-mode rgmii and rgmii-id (which should be the correct value since the delays are configured in ar8327 registers), and nothing helped Dec 27 15:13:07 a bit more hw info: rb2011 uses ar9344 SoC. According to old mach file, gmac0 is connected to the ar8327 switch, gmac1 is internal switch. port0 on ar8327 is cpu, port6 is sfp. mode defined there is rgmii for port0 and sgmii for port6. gmac1 is in gmii mode. i got ar8327-initvals by reading that mach file, referring to the ar8237 datasheet and Dec 27 15:13:07 comparing it to other ar9344 boards using ar8327 which are already ported to ath79 Dec 27 16:13:21 I was checking out a specific git revision, how can I make sure that the feeds are from that timeframe of the revision? Dec 27 17:40:16 building and installing r14281 over r14281 on ramips/mt7620 has worked. Dec 27 18:28:07 reiffert: normally the feed is flexible with the openwrt core version Dec 27 18:36:03 adrianschmutzler: ping? Dec 27 18:37:23 f00b4r0: pong Dec 27 18:37:49 adrianschmutzler: I just saw your comment on GH. How close are we to stable closing? Dec 27 18:38:00 Possibly very close Dec 27 18:38:15 my main concern is that the 4K_SECTORS situation hasn't been resolved. That has consequences beyond mikrotik devices Dec 27 18:39:16 I don't expect any major changes on that battleground Dec 27 18:39:33 you do understand that this will break sysupgrade on all affected devices? Dec 27 18:40:03 I do understand, but that's nothing I can act on personally Dec 27 18:40:09 and it will make a number of them extremely slow, in particular for the first boot after sysupgrade (we're looking at _minutes_, not seconds) Dec 27 18:40:24 so nobody cares? Dec 27 18:40:32 probably Dec 27 18:40:43 amazing. So it's okay to release known broken software? Dec 27 18:40:53 despite the fix being available? Dec 27 18:41:06 considering the size of the project, you cannot expect every area to be working Dec 27 18:41:29 has there been any change to the situation upstream concerning the fix Dec 27 18:41:31 ? Dec 27 18:41:35 I suspect a lot of users expect upgrades between stable releases not to softbrick their devices. Dec 27 18:41:48 I for one certainly holds that expectation. Dec 27 18:41:58 that's why I consider to just disable these, devices, at least a subset Dec 27 18:42:29 try git grep 4K_SECTORS Dec 27 18:42:37 you're looking at a _lot_ of devices Dec 27 18:42:39 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Dec 27 18:42:39 Apart from that, that's why there is a preparation and rc phase Dec 27 18:43:12 PaulFertser, ping re the patches, re what adrianschmutzler said Dec 27 18:44:12 anyway, I forgot again, is the mikrotik nand problem a separate issue or entangled with the 4k problem? Dec 27 18:44:34 adrianschmutzler: just in case, I'd like to emphasise that if there's a release with broken 4K support, there won't be a clean upgrade path to a fix. It's break on release, and break again on fix Dec 27 18:44:39 r14793 from 10/28 is still working on mt7620 .. any guesses what could have broken it on yesterdays snapshot? FS#3539 for details Dec 27 18:44:42 adrianschmutzler: separate Dec 27 18:44:53 shibboleth: didn't have a chance to send them yet, sorry. I do not think there's any chance they get accepted prior to the next release branching anyway. Dec 27 18:45:46 device support/p1 is pretty straightforward, the device is identical to the c2600 save for the extra pcie lane Dec 27 18:45:55 f00b4r0: do have a link at hand what that was about? is this severe enough for disabling devices? Dec 27 18:46:55 adrianschmutzler: i would recommend disabling the nand mikrotik devices. As for the 4K sectors I'll leave that to the powers that be. Expect a lot of complaints though. Dec 27 18:46:58 adrianschmutzler: https://github.com/openwrt/openwrt/pull/3026#issuecomment-673597461 Dec 27 18:47:17 ah, that bad sectors thing Dec 27 18:47:40 adrianschmutzler: tl;dr: we don't perform badblock management on the kernel segment: every time it's written, the tool assumes 0 badblocks. Of course after a while that assumption doesn't hold water. Dec 27 18:48:08 so, based on the discussion for ipq40xx, that effectively affects ath79 and ramips then? Dec 27 18:49:19 I'm not aware of mikrotik in other targets? Dec 27 18:49:19 adrianschmutzler: correct Dec 27 18:49:24 indeed Dec 27 18:49:44 i think there's only one NAND device in mikrotik/ramips Dec 27 18:49:54 okay, so I would disable those relatively soon already. Dec 27 18:50:24 seems desirable. People will complain but I think it's better than luring users into false security Dec 27 18:50:53 and for the 4k I would wait until the branch and the first complaints, and then either somebody fixes it (/applies the fix) or I just will disable all of them Dec 27 18:51:24 adrianschmutzler: the problem is it will break sysupgrade. People upgrading remote device will be in a world of pain Dec 27 18:51:36 at the very least you should put a note in the release notes Dec 27 18:52:30 and if I'm not mistaken, not only will it break sysupgrade but the devices won't preserve their settings across reboots either, due to mismatching blocksize between image and kernel Dec 27 18:53:00 Well, the release notes will be after the release. I assume we will either have fixed or disabled devices by then Dec 27 18:53:35 honestly, the situation is really bad and not addressing it will poorly reflect on the project, in my very humble opinion. Dec 27 18:54:19 am I affected? [ 1.056540] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. Dec 27 18:54:26 system type : MediaTek MT7620A ver:2 eco:6 Dec 27 18:55:00 mt7620: CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y Dec 27 18:55:34 do I need that or not having means I'm not affected? Dec 27 18:55:44 mt7620 is a "special" case because it also sets LIMITS to 16MB. Meaning all devices with less than 16MB flash are effectively using 4K sectors already (which is why some people complain they're slow) Dec 27 18:56:52 well, I'm afraid I cannot do much in this context. and unfortunately, with a project that big there is always something which cannot be fixed for a release Dec 27 18:57:25 it's a little more than "something" tbh Dec 27 18:58:15 it would be great if sysupgrade would detect, warn and ask back for "are you sure?" for affected devices Dec 27 19:00:51 adrianschmutzler f00b4r0 are you saying that mikrotik nand devices might get dropped? that means that the work i just started a few days ago on rb2011 could become useless? https://github.com/openwrt/openwrt/pull/3729 Dec 27 19:06:29 not dropped, the just won't be built by default Dec 27 19:06:36 the code remains as is Dec 27 19:06:47 you just won't get prebuilt images for download Dec 27 19:06:54 until the issue is fixed somehow Dec 27 19:11:55 Uhh… guys? I'm probably late to the party, but the current snapshot is completely broken on my APU2C4. Dec 27 19:12:35 f00b4r0: what's the nand device in ramips? Dec 27 19:12:45 let me check Dec 27 19:13:07 if memory serves me, there was already a discussion somewhere about other devices affected by this, not just mikrotik... maybe some tplink? there's even a note in the wiki for some device telling people to remap partitions in case of bad blocks Dec 27 19:14:26 For ath79, it probably would be as simple as putting DEFAULT := n directly into Device/mikrotik_nand? Dec 27 19:15:47 Ok, ubus is dead. WTF…?! Dec 27 19:16:02 adrianschmutzler: indeed. For ramips I was under the impression one of the RBM was NAND, but it's not obvious from DTS. I'm looking at website Dec 27 19:16:12 https://paste.debian.net/1178534/ Dec 27 19:17:24 adrianschmutzler: seems I'm wrong. All ramips we support are NOR. Dec 27 19:17:45 maybe it's one of the still-open PRs we both had in mind for ramips ... Dec 27 19:18:01 possible :) Dec 27 19:18:35 would you kindly prepare a short commit message for disabling the NAND devices for me? Dec 27 19:18:45 so I don't have to scan that entire discussion? Dec 27 19:18:48 doesn't MIR3G use NAND? Dec 27 19:19:10 or is there a difference between NAND and eMMC? Dec 27 19:19:16 (I assume you are not too intent to send a patch ...) Dec 27 19:19:39 adrianschmutzler: I'm not, but I can help with the commit message. moments :) Dec 27 19:23:17 mangix: eMMC is apparently NAND, but it behaves similar to SD card (also featuring NAND inside), and whatever software works with it doesn't need to deal with low-level details. Dec 27 19:23:45 unrelated to 4k spi/nand, does anyone have any idea or tips about the switch issue on rb2011 i described above? i'm working on it for the last 3 days and either i'm doing something totally wrong or ath79 needs rework to support the rb2011 hw configuration? Dec 27 19:25:19 Hmm… something's weird. An image built like I usually do (with the image builder) is completely broken on the current snapshot. The standard image works, though. Dec 27 19:26:33 adrianschmutzler: sent you an email. Off to diner, ttyl Dec 27 19:26:55 thanks, do you want to be mentioned for that one, or can I just put it into my patch? Dec 27 19:27:09 no need, make it your own ;) Dec 27 19:27:13 really off now. Dec 27 19:27:18 thanks again! Dec 27 19:27:24 np yw Dec 27 19:27:28 my ramips/mt7620 broke between r15101 and yesterdays snapshot. Can someone help get some ideas please Dec 27 19:32:05 reiffert: what is broken? Dec 27 19:36:19 there's someone named looter in #openwrt who is also saying an mt7620 build broke his Archer C2 Dec 27 19:37:33 reiffert: and what's your device? Dec 27 19:37:57 Hauke: the bootloader doesn't find the partition to start from. I was documenting it in https://bugs.openwrt.org/index.php?do=details&task_id=3539 Dec 27 19:40:58 I just built a couple of snapshots for testing and the last working version is r15101. Currently building r15207 which is about mid of December. Dec 27 19:43:25 adrianschmutzler: a D-Link DWR 960 Dec 27 19:48:48 reiffert: thanks for narrowing it doen which comit broke it Dec 27 19:54:59 r15207 was building but the version.buildinfo file still says r15101-61e381d322 and wasn't updated from the previous build. Dec 27 19:55:52 ignore that, my bad. I'll update when r15207 is working or not Dec 27 20:03:27 I narrowed it down to urandom-seed. Without urandom-seed, the system doesn't boot. I haven't noticed any change that could cause this… Dec 27 20:23:28 rsalvaterra: dev/random blocking? Dec 27 20:24:09 Nope. Dec 27 20:25:05 At least, the system didn't come up in two days. Even a blocking /dev/random wouldn't cause this. Dec 27 20:25:38 And there's always urngd. Dec 27 20:26:58 Building a new image with urandom-seed, but with DISABLED_SERVICES="urandom_seed"… Dec 27 20:27:18 r15207 is working .. from 12/13 Dec 27 20:32:07 … and it also breaks. Dec 27 20:32:37 so random blocking :) Dec 27 20:33:41 IIRC urngd can't be used on mt7621. I forgot the details. Dec 27 20:33:45 mangix: It can't be. I never had this issue in over two years. Dec 27 20:34:09 MT7621? This is x86-64, an APU2C4. Dec 27 20:34:15 aoh Dec 27 20:34:41 that's strange Dec 27 20:34:45 I'm on mt7620 Dec 27 20:34:53 Also, [ 27.612980] random: crng init done. Dec 27 20:35:17 So, at this point, there's enough entropy. Dec 27 20:36:08 * rsalvaterra scratches his head… Dec 27 20:37:22 reiffert: it could be related to the image size Dec 27 20:37:25 or the kernel size Dec 27 20:37:45 (I don't want urandom-seed because I don't like the idea of writing to the flash at every boot.) Dec 27 20:39:04 Hauke: yep .. currently building b837534f029da10abbd1069392867e0700134ace mt76: update to the latest version Dec 27 20:39:20 mangix: Oh, urngd works just fine on my MT7621 system. I can't vouch for the entropy quality, though. Dec 27 20:39:28 there is one other mt76 related fix which looked promising .. "736eee5cc6d9e96f5fae26bd6fcbfdc3d7968166 mt76: Fix compile against glibc Dec 27 20:41:14 Hauke: isn't the kernel size checked by a couple of scripts.. I remember something similar back in the days with ipq40xx Dec 27 21:00:44 This is something else… urandom-seed is innocent. I need to keep digging… Dec 27 21:07:54 nbd: can you please have a look at https://github.com/openwrt/openwrt/pull/2494? Dec 27 21:12:38 r15239 is working on mt7620 Dec 27 21:16:54 Curious -- is this normal / intentional-choice that the 'master' builds/snapshots do not include LuCI by default, that will change for test-20.12 builds, , or if this is a mistake/regreission Dec 27 21:18:28 enyc: I'm calling it normal. You can install it with opkg update; opkg install luci; Dec 27 21:18:41 reiffert: well inded can and that does work =) Dec 27 21:19:08 and so-far said snapshots work well on Homehub v5a in some silghtly-fiddly configs Dec 27 21:21:56 not clear to me how to tell if WPA2 or WPA3 in use with any particular wifi-client [...] Dec 27 21:26:48 Hm… How do I mount the filesystem bound to the loop0 device from OpenWrt, on another system? I need to recover the data from /overlay/upper. Dec 27 21:31:46 The overlay is ext4, so it should be easy to mount, but I can't find any documentation on how to do it (I don't have much experience with loopfs). Dec 27 21:33:51 rsalvaterra: it's not loopfs, it's just a loopback device. What filesystem's in the dump? Probably the easiest would be to use binwalk -e? Dec 27 21:34:22 rsalvaterra: ah, with ext4 it's just mount -o loop your.image.ext4 /wherever Dec 27 21:35:04 Uh… what image? Dec 27 21:35:26 rsalvaterra: the filename of the file containing your filesystem. Dec 27 21:35:32 This is what I have on a normal OpenWrt system… Dec 27 21:36:11 rsalvaterra: if it's a real device you should be able to just mount it as usual. Dec 27 21:36:37 https://paste.debian.net/1178546/ Dec 27 21:36:37 from my life system: Dec 27 21:36:38 /dev/mtdblock4 on /overlay type jffs2 (rw,noatime) Dec 27 21:36:45 overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work) Dec 27 21:37:13 reiffert: This is x86-64, squashfs with ext4 overlay. Dec 27 21:37:27 I'm very sorry. Dec 27 21:38:09 I'd love to avoid the dump-and-binwalk dance, but… Dec 27 21:38:25 rsalvaterra: I see now where the confusion is from. It's a tricky trick used by OpenWrt. You also need to check parameters from "losetup -l", that loop0 has some offset. Dec 27 21:38:45 No losetup here. Dec 27 21:39:30 Ok, let me explain: I have a broken OpenWrt system (on a mSATA device). I booted a working OpenWrt system from a USB drive. Dec 27 21:40:00 When mounting it determines where squashfs ends and configures the loop device accordingly. And you need to somehow learn that offset to mount it externally. Dec 27 21:40:14 Without losetup it should probably be available from /proc or /sys somewhere. Dec 27 21:40:44 That's… horrible. Dec 27 21:41:12 So it's just writing in the raw device (sda) after the squashfs? Dec 27 21:42:36 rsalvaterra: basically, yes. Dec 27 21:42:44 What the actual fuck…! Dec 27 21:43:33 Yeah, binwalk. I don't care. Dec 27 21:44:20 I'll just dump 200 MiB and be done with it. Should be more than enough. Dec 27 21:45:30 Can anyone even explain why this is done? Why not just create a real partition? Dec 27 21:45:38 Would you prefer OpenWrt to require LVM instead? Dec 27 21:46:23 How else to repartition on upgrades? Dec 27 21:48:00 adrianschmutzler: can you give me a crash course in device/dts reviewing at some point? Dec 27 21:50:58 Public recorded webinar would be great. Dec 27 21:52:12 works for me Dec 27 22:08:03 mangix: I think I'm actually just an idiot… let me just test my theory… Dec 27 22:11:02 PaulFertser: binwalk did the trick nicely. It still even had the sysupgrade.tgz there, to make things easier. :) Dec 27 22:14:00 won't an msata device just have a partition table? Dec 27 22:15:32 russell--: No, it's like PaulFertser said. The loop device just points to an offset in the raw mSATA device. It's weird, indeed, and it caught me completely by surprise. Dec 27 22:16:30 what devices is this from? Dec 27 22:16:44 x86-64, an APU2C4. Dec 27 22:16:57 that's what i guessed Dec 27 22:17:27 Oh, well… TIL. :P Dec 27 22:22:37 mangix: Yeah, I'm an idiot. I'm including extra files, some of them in /etc, and didn't notice my local etc directory had 700 permissions. *facepalm* Dec 27 22:22:54 hi Dec 27 22:23:09 is Gabor Juhos present on this channel? Dec 27 22:23:15 I have some questions about pci-rt3883.c Dec 27 22:34:48 Hauke: I dont know how but r15355 (todays snapshot) is working great. I'm resolving the bug report Dec 27 22:42:25 rsalvaterra: what is the filesystem of an initramfs? Dec 27 22:44:21 aparcar[m]: tmpfs, I think. It's a cpio archive which is extracted to tmpfs at boot. Dec 27 22:44:44 so how would you call the filesystem? Dec 27 22:45:31 Hm… call? What do you mean? Dec 27 22:45:56 what type is it Dec 27 22:46:03 squashfs, ext4, etc Dec 27 22:46:09 or is tmpfs an actual thing? Dec 27 22:46:27 It's not a filesystem, it's a cpio archive. Similar to tar. Dec 27 22:46:41 ok so cpio Dec 27 23:17:49 mangix: please review this list and let me know what packages could be moved http://sprunge.us/3sWpKc Dec 27 23:27:19 aparcar[m]: many of those have been moved Dec 27 23:28:07 thc-ipv6 stuff can probably be moved at this point Dec 27 23:28:49 I have no idea what ugps is Dec 27 23:38:22 aparcar[m]: not really, because it depends heavily on what's in the device support PR Dec 27 23:38:59 as you might have mentioned, at least my knowledge is limited to specific areas Dec 27 23:39:11 mentioned->realized **** ENDING LOGGING AT Mon Dec 28 03:00:17 2020