**** BEGIN LOGGING AT Sun Jan 03 02:59:56 2021
Jan 03 04:29:58 <dread26> hello
Jan 03 04:30:11 <dread26> anybody built openWRT for YUN?
Jan 03 04:57:17 <kbeflo> #openwrt
Jan 03 05:21:01 <russell--> hurricos: which merakis?
Jan 03 09:27:12 <mangix> swalker_: keyutils version seems to be wrong
Jan 03 10:17:28 <mkresin> xdarklight: Hauke: Linux 5.10 for lantiq: https://git.openwrt.org/?p=openwrt/staging/mkresin.git. Have fun!
Jan 03 10:32:03 <Borromini> hi guys. looking for some guidance on dtsi naming. i have a gs1900-10hp and it seems to share everything with the gs1900-8hp (except two SFP ports). there's also a non-PoE gs1900-8 sibling.
Jan 03 10:32:50 <Borromini> can i create a shared dtsi and call that rtl8380_zyxel_gs1900-series.dtsi e.g.? There's bigger models in the GS1900 range but those don't use the RTL8380 SoC and wouldn't use that dtsi.
Jan 03 10:36:14 <svanheule[m]> Borromini: if you're not adding details, maybe "rtl8380_zyxel_gs1900.dtsi" is sufficient?
Jan 03 10:36:41 <Borromini> svanheule[m]: ok, thanks.
Jan 03 10:37:01 <Borromini> another question: it looks like PoE isn't defined in the dts, is that correct?
Jan 03 10:37:21 <Borromini> i don't see any mention of it in other realtek dts files (e.g. that d-link 1210 thingy)
Jan 03 10:37:43 <svanheule[m]> the Netgear GS108Tv3 and GS110TPP have a similar base, there I was also considering an -8port suffix for the dtsi; but maybe that's confusing when used on the GS110TPP
Jan 03 10:38:18 <Borromini> yeah and defining a range like 8-10 won't work i think with all those underscores and hyphens in the naming
Jan 03 10:38:30 <svanheule[m]> PoE is purely user-space currently, except for uart1 needing to be enabled in the DTS
Jan 03 10:39:39 <Borromini> ok, thanks
Jan 03 11:41:12 <xdarklight> mkresin: I will, thanks :)
Jan 03 13:20:27 <Hauke> mkresin: thanks
Jan 03 13:55:32 <johnf> the dlink dir-825 b1 seems to have lost it's reference to the physical mac address, I'm going to create and test a patch to fix this, but I need a working example of another ath79 platform where the MAC is properly taken from the firmware, can someone suggest a good reference please?
Jan 03 14:04:00 <johnf> hmm, so there's this: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/nand/base-files/etc/board.d/02_network
Jan 03 14:04:04 <johnf> which is doing some mac setup
Jan 03 14:04:23 <johnf> looks like ath79 does not have much mac support, or I'm looking at the wrong stuff
Jan 03 14:07:34 <johnf> ok, I was looking at the wrong stuff, much better to grep than github search, this doesn't appear that bad
Jan 03 14:09:05 <plntyk> "mac support" is a bit opaque
Jan 03 14:09:52 <plntyk> ex: commit a99614a44f205f48db4278988566d2b6b2b96295 "implementation appears relatively arbitrary"
Jan 03 14:10:59 <johnf> sorry, the mac address is randomly assigned on boot
Jan 03 14:11:03 <johnf> it's not pulled from the firmware
Jan 03 14:11:11 <johnf> I would like to correct this, and assign the correct mac
Jan 03 14:11:36 <johnf> https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/tp9343_tplink_tl-wr940n-v4.dts#L69
Jan 03 14:11:42 <johnf> this appears to be a good example of the current method
Jan 03 14:11:57 <johnf> I'm trying to understand the offset calculation code that was previously in CC
Jan 03 14:12:24 <johnf> which is here: https://github.com/openwrt/chaos_calmer/blob/chaos_calmer/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-b1.c#L132-L147
Jan 03 14:13:09 <johnf> ok, it's actually not really that bad at all
Jan 03 14:15:25 <johnf> hmm, it looks like there's actually two possible calibration data locations, this is going to be hard to do as a single line
Jan 03 14:23:56 <aliceussr> Hello, comrades!
Jan 03 14:24:17 <aliceussr> Please help me: i have low speed WiFi with MTK7620A - 15-10Mbit/sec. Please send me howto for increse speed WiFi, i use OpenWRT 19.07.5.
Jan 03 14:24:18 <johnf> greetings, alice
Jan 03 14:24:42 <johnf> it's very very hard to help you with that I'm afraid
Jan 03 15:19:36 <dangole> aliceussr: someone recently did some testing on mt7620a https://github.com/teixeluis/openwrt-perf-tests/
Jan 03 15:20:44 <dangole> aliceussr: that revealed that the chip performs much better if you force it to either HT40 (ie. option noscan '1') or use HT20-only.
Jan 03 16:30:01 <aliceussr> Hello! I find firmware for YOUKU YK1-L
Jan 03 16:30:08 <aliceussr> Please, help me.
Jan 03 16:31:32 <hurricos> russell--: Meraki MR16. I am almost entirely sure it was because I added too many packages directly to the kernel rather than as modules in the initramfs
Jan 03 16:31:46 <hurricos> since the error went away when I removed the last one I had added
Jan 03 16:32:06 <grift> aliceussr: did you read this?
Jan 03 16:32:16 <grift> 16:19 < dangole> aliceussr: someone recently did some testing on mt7620a
Jan 03 16:32:26 <grift> https://github.com/teixeluis/openwrt-perf-tests/
Jan 03 16:32:34 <grift> 16:20 < dangole> aliceussr: that revealed that the chip performs much better if you force it to either HT40
Jan 03 16:32:44 <grift> (ie. option noscan '1') or use HT20-only.
Jan 03 16:33:03 <aliceussr> grift: I find firmware for YOUKU YK1-L.
Jan 03 16:33:21 <aliceussr> grift: I use all this: WiFi very low!!!!!
Jan 03 16:33:47 <grift> aliceussr: ok
Jan 03 16:40:19 <hurricos> grift: I wonder if someone could post some minstrel rate tables from that mt7620a experiment.
Jan 03 16:40:53 <hurricos> It feels like the drivers is either skipping beats in HT20 or picking rates really weirdly.
Jan 03 16:41:08 <hurricos> mt76 does still use minstrel though. I'm pretty sure.
Jan 03 16:41:20 <russell--> hurricos: i just bought another dozen mr24's for $100 ($8.33 each, shipped).
Jan 03 16:41:40 <hurricos> russell--: You're the Portlander who's using QCA9880v2's in them?
Jan 03 16:42:14 <russell--> i'm the portlander, but not with stock radios
Jan 03 16:42:26 <russell--> with* stock radios
Jan 03 16:42:39 <hurricos> thanks again for debugging on those by the way
Jan 03 16:43:18 <hurricos> ath10k is a fickle beast. What kind of perf do you get on the ath9k cards btw?
Jan 03 16:43:30 <hurricos> I never probed far into your setup out there
Jan 03 16:43:37 <russell--> not sure i've measured it
Jan 03 16:43:59 <hurricos> Do they stay outdoors?
Jan 03 16:44:14 <russell--> the ones we've used are all indoors
Jan 03 16:44:42 <hurricos> I ask because the outdoor versions of the MR12/16 (MR62/MR66) are being pulled down right now pretty much everywhere I've asked on /r/meraki
Jan 03 16:44:44 <russell--> we've toyed with putting them in an enclosure for outdoor use, but haven't found a suitable one
Jan 03 16:45:10 <hurricos> CPU is bad, MIPS 7240 / 7161 respectively, but the enclosures are solid and the motherboards are interchangeable
Jan 03 16:45:39 <hurricos> with the exception that MR16 -> MR66 loses 4 antenna UFLs so you need dualband N antennas.
Jan 03 16:45:49 <russell--> i did try swapping in a ath10k radio to one but mysteriously killed it
Jan 03 16:45:53 <hurricos> (goes from 4 to 2 as MR16 internals are dualband)
Jan 03 16:46:19 <russell--> the mr24 that is, even after putting the stock radio back in
Jan 03 16:46:30 <hurricos> Yes, I remember now ... electronics are weird. We have an MR24 with QCA9880v2 hanging but I haven't played with sysupgrading so
Jan 03 16:46:53 <hurricos> I am not sure what that is from and can't think of a similar situation which would cause it sadly. I bet it was just chance
Jan 03 16:47:28 <russell--> probably shorted something in th process
Jan 03 16:47:59 <russell--> i do recall the antenna pigtails being not quite lengthy enough
Jan 03 16:48:15 <hurricos> Yes, since the card is lower profile ...
Jan 03 16:48:25 <russell--> i've had many of them open, first time i killed one
Jan 03 16:50:27 <russell--> in fact in ~15 years of hacking on routers, second time i killed anything. the other was plugging an unplugged 12V charger into a ubnt airrouter that takes 5V, the capacitor charge was enough to smoke the switcher chip.
Jan 03 16:51:00 <russell--> even that i was able to repair with an LDO regulator
Jan 03 16:51:55 <hurricos> I have been mucking a bit more with the MX60, same SoC as the MR24 but no PCIe switch
Jan 03 16:52:37 <hurricos> it has SATA pads, but requires some caps to connect SATA signaling lines and properly supply power
Jan 03 16:54:43 <hurricos> Also been fighting with BCM43645 cards which use brcmfmac fine under OpenWrt -- but the SoC does not support MSI-X and I haven't figured out what would go into tweaking the driver to use MSI proper to initialize the card.
Jan 03 16:54:50 <hurricos> so :\
Jan 03 16:55:14 <hurricos> they go for much cheaper than QCA9880's -- something like $9, for 4x4 Wave2 AC
Jan 03 17:08:42 <Borromini> hurricos: you're not voluntarily using broadcom stuff on openwt are you?
Jan 03 17:09:32 <hurricos> Borrowmini: I am. brcmfmac works if you have the PCIe support, and it's cheap.
Jan 03 17:10:26 <hurricos> While shifting the entire horrifying brcm-wl stack onto the the wireless MCU is not smart from a security standpoint
Jan 03 17:10:28 <hurricos> https://blog.quarkslab.com/reverse-engineering-broadcom-wireless-chipsets.html
Jan 03 17:11:01 <hurricos> ... when I'm just trying to set up WAPs for a building our hackerspace is in, it makes sense. Then I save the QCA's I displace for more fun projects.
Jan 03 17:12:50 <hurricos> that is when the PCIe works. I don't have a good workflow to do repeated tweaks to get it to work. I would need to jump through so many hoops to get a CI pipeline that works and I just don't have the attention span :\
Jan 03 17:13:05 <hurricos> Borromini:
Jan 03 17:15:50 <hurricos> As soon as <$20 mt76 mPCIe cards start being made en masse I will be all over those. But I don't see it happening soon
Jan 03 17:17:06 <hurricos> although driver development is very promising. Seeing stuff like dbdc supported in OpenWrt is fantastic. Props to nbd.
Jan 03 17:18:23 <nbd> thx. the nice thing about mediatek is the fact that they're actively working with us on decent upstream drivers
Jan 03 17:18:44 <nbd> instead of just throwing things over the wall or even actively blocking stuff
Jan 03 17:20:07 <hurricos> that has the knock-on effect of causing vendors that produce fully integrated hardware to actually use the hardware
Jan 03 17:20:39 <hurricos> So in a sense OpenWrt does so well by feeding the beast and collecting its err, waste :^)
Jan 03 17:20:57 <hurricos> Or at least it's good for us using aftermarket stuff.
Jan 03 17:21:50 <hurricos> We used to be spending nearly $75 per node on AR9331s in weatherproof cases ....
Jan 03 17:22:35 <nbd> my primary goal with the driver development work that i do is to show the value of proper upstream drivers for commercial product development
Jan 03 17:22:52 <nbd> so that customers of chipset vendors start demanding upstream stuff from their vendors
Jan 03 17:23:29 <nbd> and preferably solutions that don't involve offloading everything onto proprietary firmware
Jan 03 17:23:35 <nbd> so things can still be customized
Jan 03 17:24:27 <hurricos> Where did that go wrong with ath10k? was it just the Qualcomm acquisition or?
Jan 03 17:25:38 <hurricos> I sometimes hope they would open the ath10k source once they're no longer making the chips (see ath9k_htc), but I doubt it with FCC these days ....
Jan 03 17:26:07 <hurricos> and I'm sure some vendors would be unhappy having paid for the SDK already.
Jan 03 17:26:11 <nbd> the acquisition was a really big part of it, yes
Jan 03 17:27:42 <nbd> they also burnt out most of their internal devs that actually cared about opening up more
Jan 03 17:30:45 <rsalvaterra> nbd: I also had the idea ath9k was open because some *really big* customer (Google?) demanded it.
Jan 03 17:31:43 <hurricos> How big of a customer is Google though? You don't find ath9k in smartphones. 3 generations tops of Chromebooks is the only thing I can think of
Jan 03 17:31:55 <nbd> rsalvaterra: i think that's correct, though the customer wasn't google (IIRC)
Jan 03 17:32:05 <nbd> i think it was a laptop vendor
Jan 03 17:32:15 <nbd> that wanted linux support for their laptops
Jan 03 17:32:21 <rsalvaterra> Yeah, I also don't think it was Google, but I know it was a large customer.
Jan 03 17:32:24 <hurricos> Probably Dell
Jan 03 17:32:29 <nbd> could be
Jan 03 17:32:46 <rsalvaterra> Asus? With the Eee PC fever?
Jan 03 17:33:06 <nbd> they initially had no interest in using it for embedded hardware
Jan 03 17:33:42 <dangole> at least the eeepc comes with ar9285. dell laptops usually come with intel nics.
Jan 03 17:33:54 <nbd> after we made ath9k work on embedded devices in openwrt, customers started asking atheros for commercial support on ath9k
Jan 03 17:34:28 <nbd> initially they didn't have any people to handle that support, so they sent their customers to me
Jan 03 17:36:11 <rsalvaterra> It's hard for me to understand why would a company refuse to do all its development upstream. I mean, the big ones (Intel, AMD) already say the value of it.
Jan 03 17:37:14 <nbd> lots of reasons actually
Jan 03 17:37:40 <nbd> paranoid lawyers arguing against releasing potential trade secrets
Jan 03 17:38:17 <nbd> internal dev teams working on proprietary code for years that is nowhere near anything that could be upstreamed
Jan 03 17:38:31 <nbd> sdks built with lots of hacks to squeeze out more performance
Jan 03 17:38:56 <nbd> fear of losing control over the development process
Jan 03 17:39:08 <rsalvaterra> So, lawyers an legal stuff aside, they're basically ashamed of their code. :P
Jan 03 17:39:28 <nbd> most of the time they're quite proud of their crap
Jan 03 17:39:52 <rsalvaterra> Wow.
Jan 03 17:40:12 <nbd> also, they often don't really understand the value of upstream work
Jan 03 17:40:31 <nbd> or even how to do it
Jan 03 17:42:22 <rsalvaterra> I know there are also cultural issues… I remember in Japan, for example, developers took it very hard when someone told them to fix something in their code. :)
Jan 03 17:43:03 <rsalvaterra> (This is an example from the Linux kernel.)
Jan 03 17:44:30 <johnf> nbd: if i wanted to port this mac retrieval method to today's dts format is there a way to do it? https://github.com/openwrt/chaos_calmer/blob/chaos_calmer/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-b1.c#L132-L147
Jan 03 17:44:53 <johnf> it's using an ascii format, and I need to try two possible offset addresses
Jan 03 17:45:10 <johnf> I can't find any examples of something similar and think it may be more than you can do in a dts file
Jan 03 17:45:38 <hurricos> johnf: two possible? sounds like two different mac addresses for two different wnics
Jan 03 17:46:42 <johnf> nah, it has that
Jan 03 17:46:54 <rsalvaterra> dangole: Did you see the DCDE patch? Turned out to save a bit more space than I expected. :)
Jan 03 17:47:01 <johnf> but if you look at lines 132 and 134
Jan 03 17:47:14 <johnf> you'll see it tries two offets, DIR825B1_CAL_LOCATION_0 and DIR825B1_CAL_LOCATION_1
Jan 03 17:47:25 <hurricos> I think that's assuming if one ART is corrupted
Jan 03 17:47:56 <hurricos> dir825b1_is_caldata_valid checks for ART magic. So yeah
Jan 03 17:48:43 <hurricos> Meraki MR16 has precisely the same chipsets (AR9220+AR9223) and has the same double-ART
Jan 03 17:48:46 <hurricos> just not in ASCII
Jan 03 17:49:31 <hurricos> You should pick one ART out of the two -- you will already need to deal with kmod-owl-loader to get the ART loaded anyways
Jan 03 17:52:25 <nbd> johnf: i'm not aware of any way to express retrieving ASCII MAC via DT
Jan 03 17:52:46 <hurricos> There was https://patchwork.ozlabs.org/project/netdev/patch/1555445100-30936-1-git-send-email-ynezz@true.cz/#2154649
Jan 03 17:52:52 <hurricos> when MAC is stored in NVMEM
Jan 03 17:52:58 <hurricos> but not mainlined
Jan 03 17:53:41 <johnf> wow, ok
Jan 03 17:53:48 <johnf> this is much much more intense than i expected
Jan 03 17:54:03 <hurricos> You can always patch it afterwards :^)
Jan 03 17:54:10 <hurricos> just in an init script. I think?
Jan 03 17:54:31 <johnf> it would be fairly easy to do
Jan 03 17:54:39 <johnf> to read the flash, get the value
Jan 03 17:54:42 <johnf> and then put into the config
Jan 03 17:54:52 <johnf> but would this be accepted as a patch?
Jan 03 17:54:55 <hurricos> that's how it's done absent a better answer. But like ...let me see. You should find a block already doing exactly that for another device
Jan 03 17:55:15 <johnf> give me a second, need my laptop
Jan 03 17:55:29 <hurricos> check out target/linux/ath79/generic/base-files/etc/board.d/02_network
Jan 03 17:57:08 <johnf> I think I saw that before
Jan 03 17:57:10 <johnf> just a moment though
Jan 03 17:57:58 <johnf> so in cc, in the ath79 folder, the following devices used the parse_ascii_mac function
Jan 03 17:58:01 <johnf> dev-eth.c dev-eth.h mach-dgl-5500-a1.c mach-dhp-1565-a1.c mach-dir-505-a1.c mach-dir-615-c1.c mach-dir-615-i1.c mach-dir-825-b1.c mach-dir-825-c1.c mach-tew-673gru.c mach-tew-712br.c mach-tew-732br.c
Jan 03 17:58:58 <johnf> this appears to be some kind of mac lookup: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ar9330_dlink_dir-505.dts#L78
Jan 03 17:59:03 <johnf> but I don't really understand it
Jan 03 17:59:27 <hurricos> that's just for the phy
Jan 03 17:59:38 <johnf> oh, but now that you show me 02_network
Jan 03 17:59:41 <johnf> I do understand that!
Jan 03 17:59:47 <hurricos> the gigabit ethernet mac talks to the gigabit phy and like
Jan 03 17:59:48 <johnf> ok, I can totally do that, and that's the standard place to do it
Jan 03 17:59:57 <hurricos> there's mdio addresses and stuff. Yeah you totally want to patch it in 02_network
Jan 03 18:00:56 <hurricos> and as for the differences between the two ART partitions -- @johnf I suggest you build pointing to each of the two ART partitions and see if you can find differences in wireless performance
Jan 03 18:01:12 <hurricos> since whatever you commit and which gets merged is permanent
Jan 03 18:01:22 <hurricos> or hard to fixup later anyhow.
Jan 03 18:01:59 <hurricos> you probably should use the primary that's being used in ar71xx but it's good to verify
Jan 03 18:03:29 <johnf> what's in the ART partitions?
Jan 03 18:03:53 <johnf> i'm sorry, don't really know that much about this
Jan 03 18:04:09 <johnf> it's factory radio calibration data and stuff?
Jan 03 18:04:26 <johnf> in the CC code it appears to be checking some magic, to decide which to use
Jan 03 18:05:07 <hurricos> Precisely that yeah.
Jan 03 18:05:48 <hurricos> the magic is a55a or 5aa5 depending on how you look at endianness. The ART in ath9k just instructs the radio hardware how to calibrate its PLLs and power amps and carrier sense circuitry
Jan 03 18:06:02 <hurricos> the magic just confirms "yes, this is an ART" like the Unix 'file' utility does
Jan 03 18:06:19 <johnf> ok, so now we are talking about two changes, if I understand you right
Jan 03 18:06:30 <johnf> something to the mtd, to correct the ART stuff
Jan 03 18:06:47 <johnf> and something inside 02_network, which I understand much better, to get the correct MAC
Jan 03 18:08:05 <hurricos> the first one is just something in the dts to make sure you have a partition that points to ART
Jan 03 18:08:07 <hurricos> https://github.com/openwrt/openwrt/commit/359b1ed3f1dac316f4223bd1a4368034951d1d38#diff-8b83bb26de456e21b301d799c3d3631f12c8c8e5733af4c4fe7e9452b469b336R168
Jan 03 18:08:30 <hurricos> then something to extract it in 10-ath9k-eeprom
Jan 03 18:08:32 <hurricos> https://github.com/openwrt/openwrt/commit/359b1ed3f1dac316f4223bd1a4368034951d1d38#diff-4c8871443ea276110fdf077235b2ee3ca96ea5996b3dba820789fd1e3f69e23dR146
Jan 03 18:08:52 <hurricos> the thing to extract it will pick an address in mtd partition containing one or more ARTs
Jan 03 18:09:50 <hurricos> you can figure out where that is by dumping the flash and grepping for a55a in output of hexdump or --
Jan 03 18:10:07 <hurricos> https://github.com/openwrt/chaos_calmer/blob/chaos_calmer/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-b1.c#L49
Jan 03 18:10:15 <hurricos> https://github.com/openwrt/chaos_calmer/blob/chaos_calmer/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c#L47
Jan 03 18:11:02 <hurricos> the first link is your ar71xx DIR. The second is my ar71xx MR16. Just repeat the analogy from my MR16 ath79 into your caldata lookup in 10-ath9k-eeprom so that the script pulls the eeprom from the right address in flash for kmod-owl-loader to load into the hardware
Jan 03 18:12:19 <johnf> hmm, ok, I will look this over
Jan 03 18:12:23 <johnf> thanks hurricos
Jan 03 18:12:25 <hurricos> in fact .... your dir is so similar, you should probably take my mr16 commit and copy it
Jan 03 18:12:28 <johnf> really appreciate the help
Jan 03 18:13:01 <hurricos> your dir has the same wireless SoC's, the same CPU ... the only big differences are the use of less total flash and the use of a Realtek switch
Jan 03 18:13:16 <johnf> wow, that's surprising
Jan 03 18:13:25 <johnf> especially for a Meraki device
Jan 03 18:13:30 <johnf> I would have expected more Cisco custom
Jan 03 18:13:55 <hurricos> it makes development very easy because the radio is very unopinionated about how it should operate :^)
Jan 03 18:14:23 <hurricos> But yes I would totally like ...
Jan 03 18:14:50 <hurricos> look through the dts under ath79 -- grep for something with a realtek switch, I think the Ubiquiti 8x poe switch has one
Jan 03 18:15:26 <hurricos> then tweak the other stuff so that it comes up under ath79 in menuconfig (see the many ath79 porting commits)
Jan 03 18:15:47 <hurricos> compile it and boot it and see what you get.
Jan 03 18:16:09 <hurricos> This is why dts are so nice, it's easy to reuse code
Jan 03 18:20:42 <johnf> ok, I'm going to try it soon
Jan 03 18:20:49 <johnf> and I will let you know how it goes
Jan 03 18:20:53 <johnf> I'm sure I"ll have more questions :)
Jan 03 18:20:57 <johnf> thanks again
Jan 03 18:21:23 <hurricos> thanks for helping bring yet another many-gigabit-port device to Openwrt :^) these look nice, I may buy one if you finish porting
Jan 03 18:21:49 <johnf> just to be clear, you can use one today
Jan 03 18:21:58 <johnf> the issue with them presently is that they randomize the mac
Jan 03 18:22:12 <johnf> as my friend who is using one's isP does DhcP and mac locks
Jan 03 18:22:20 <johnf> if his router reboots he looses internet
Jan 03 18:22:41 <johnf> we fixed this, for now, but locking the mac address of the system in config
Jan 03 18:22:50 <johnf> but it would be better to obtain the real mac address
Jan 03 18:22:55 <johnf> this is what I want to fix
Jan 03 18:23:01 <johnf> I will also endeavour to get the ART data
Jan 03 18:23:09 <johnf> as, if I can, it should improve the quality of the wireless
Jan 03 18:23:50 <johnf> (err, right?)
Jan 03 18:24:07 <hurricos> well not really. They probably have two identical ARTs :^)
Jan 03 18:25:17 <johnf> sorry, I don't understand this 100%
Jan 03 18:25:22 <hurricos> Oh the MAC is randomized?
Jan 03 18:25:27 <johnf> yes
Jan 03 18:25:40 <johnf> the current DTS does not reference the ART: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
Jan 03 18:25:44 <hurricos> the board was ported to ath79 in 97de133368762824ba3d7e9d95f97011a597ec1a / Aug 2018. You should report this
Jan 03 18:26:02 <hurricos> art also known as caldata
Jan 03 18:26:07 <hurricos> just the WAN MAC?
Jan 03 18:26:27 <hurricos> Are you running a modern version of OpenWrt?
Jan 03 18:26:38 <johnf> 19.07.5
Jan 03 18:26:45 <hurricos> ar71xx or ath79?
Jan 03 18:26:49 <johnf> not ath79
Jan 03 18:26:52 <hurricos> you should run ath79
Jan 03 18:26:55 <johnf> whoops, not enough ^W
Jan 03 18:26:58 <johnf> ath79
Jan 03 18:27:01 <hurricos> OK
Jan 03 18:27:11 <johnf> I do not know which interfaces are random or not
Jan 03 18:27:28 <johnf> but the dts does not have a mac reference on eth0 or eth1
Jan 03 18:28:29 <hurricos> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=97de13336
Jan 03 18:28:58 <hurricos> so https://git.openwrt.org/?p=openwrt/openwrt.git;a=blobdiff;f=target/linux/ath79/base-files/etc/board.d/02_network;h=5edfd9e2ceca03a3c3ea5d880dbf794518897dc8;hp=79b39b22f4a44abcf47a256ea298d7bc8496d6a1;hb=97de13336;hpb=a441c86d93657121afe8117f8329b7095f7154d2 is not activating
Jan 03 18:29:00 <johnf> wait
Jan 03 18:29:03 <johnf> what
Jan 03 18:29:18 <hurricos> right right. Sorry, the DTS doesn't refer to the MAC if there's no way to do it in the Dts
Jan 03 18:29:53 <johnf> but
Jan 03 18:29:55 <johnf> https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/nand/base-files/etc/board.d/02_network
Jan 03 18:30:04 <johnf> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blobdiff;f=target/linux/ath79/base-files/etc/board.d/02_network;h=5edfd9e2ceca03a3c3ea5d880dbf794518897dc8;hp=79b39b22f4a44abcf47a256ea298d7bc8496d6a1;hb=97de13336;hpb=a441c86d93657121afe8117f8329b7095f7154d2
Jan 03 18:30:14 <johnf> somehow the details of that commit on 02_network were lost
Jan 03 18:31:14 <hurricos> nand is specific tree
Jan 03 18:31:37 <hurricos> you want generic:
Jan 03 18:31:39 <hurricos> https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/generic/base-files/etc/board.d/02_network
Jan 03 18:32:00 <hurricos> https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/generic/base-files/etc/board.d/02_network#L493
Jan 03 18:32:09 <swalker> mangix: fixed the upstream, thanks
Jan 03 18:32:26 <johnf> hmm, so it should work
Jan 03 18:32:29 <johnf> ok, that's super strange
Jan 03 18:32:33 <johnf> I am going to do some more testing
Jan 03 18:32:33 <hurricos> so that's just a shell script. You should trace the definition of mtd_get_mac_text "caldata" 0xffb4
Jan 03 18:32:48 <hurricos> it uses libraries defined up here: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/generic/base-files/etc/board.d/02_network#L3
Jan 03 18:33:39 <johnf> this stuff really looks like it should work
Jan 03 18:34:42 <hurricos> It should. You should file a bug: https://bugs.openwrt.org/
Jan 03 18:38:51 <johnf> ok, I'm going to test it a bit
Jan 03 18:38:58 <johnf> my friend had the problem, I don't have the full details
Jan 03 18:39:12 <johnf> I thought it was just missing the mac setting, but now I see it's done elsewhere as it can't be done in kernel
Jan 03 18:39:22 <johnf> I will investigate thoroughly before reporting and or fixing a bug
Jan 03 18:39:30 <hurricos> right, or it could but if I understand correctly the only stuff used in DTS is what's upstreamed
Jan 03 18:41:10 <johnf> actually, wait, just a second
Jan 03 18:41:47 <johnf> I'm looking at master
Jan 03 18:42:35 <johnf> nah, it's in 19.07 as well
Jan 03 18:42:37 <johnf> as it should be really
Jan 03 18:44:12 <hurricos> adrianschmutzler: I have refresh https://github.com/openwrt/openwrt/pull/3634 against master, just a heads-up.
Jan 03 18:51:34 * enyc hrrms -- my Testing/master lantiq  seems to have got readonly fs!
Jan 03 18:54:06 <Borromini> too big an image?
Jan 03 18:54:16 <Borromini> not enough free space for an overlay?
Jan 03 18:55:59 <johnf> hurricos: ok, it's confirmed, eth0 is not receiving the correct mac information
Jan 03 18:58:14 <johnf> eth1 and the wlan interfaces are receiving mac addresses that are related to the box sticker
Jan 03 18:58:18 <johnf> https://gist.github.com/johnfzc/5302a3d8ba327235e1e6d5800390bec5
Jan 03 18:58:26 <johnf> I will continue to investigate a bit later
Jan 03 19:00:53 <johnf> even if the address is wrong, the value read from the firmware should be consistent on each execution
Jan 03 19:01:18 <johnf> ah, but if it's invalid text, which is easier to achieve than eight bytes or whatever a standard mac is
Jan 03 19:04:51 <hurricos> johnf: you could check that by tracing those shell scripts. Also, it looks like the DTS is incorrect:
Jan 03 19:05:09 <hurricos> https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts says both the gmac0 and gmac1 are both up, but
Jan 03 19:05:37 <hurricos> page 5 here shows the WAN port connects to the realtek switch: https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=1029486
Jan 03 19:06:31 <hurricos> one of those gmacs should not OKAYed
Jan 03 19:07:09 <Borromini> mangix: ping
Jan 03 19:07:39 <hurricos> Oh shoot. No. Sorry. Both are valid. That RTL8366S takes both MACs! http://realtek.info/pdf/rtl8366s_8366sr_datasheet_vpre-1.4_20071022.pdf
Jan 03 19:26:12 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Jan 03 19:40:07 <johnf> hurricos: my abilities are much less avanced than your own, thank you, for helping to maintain my humility
Jan 03 19:50:51 <johnf> I suspect the offset is wrong, I'm checking a few basic things
Jan 03 20:11:45 <enyc> Borromini: don't think so, 128mb flash .......
Jan 03 20:18:25 <rsalvaterra> adrianschmutzler: ping
Jan 03 20:18:31 <Borromini> should be plenty
Jan 03 21:41:51 <aparcar[m]> nbd: can you help me with https://github.com/openwrt/openwrt/pull/3739 ? I don't know how to re-evaluate the prerequirements
Jan 03 22:20:49 <mangix> aparcar[m]: what's the status on https://patchwork.ozlabs.org/project/openwrt/patch/20201230033511.3181-1-rosenp@gmail.com/ ?
Jan 03 22:23:54 <aparcar[m]> On this side of the earth it's still sunday
Jan 03 22:24:05 <aparcar[m]> mangix: so maybe wait a bit more?
Jan 03 22:46:16 <aparcar[m]> is dedeckeh sometimes around?
Jan 03 22:47:05 <pkgadd> yes, but recently not that often
Jan 03 22:48:11 <pkgadd> but today from 09:00-21:30 UTC (so roughly european daytime)
Jan 03 22:56:23 <aparcar[m]> pkgadd: thank you
Jan 03 22:57:54 <pkgadd> looking through the last ~week, those times seem to be quite regular
Jan 03 22:58:36 <aparcar[m]> #datamining
Jan 03 23:11:35 <aparcar[m]> mangix: okay I merged the usbutils removal, please add it to packages.git
Jan 03 23:18:07 <mangix> cool
Jan 03 23:18:13 <mangix> here's hoping nothing blows up
Jan 03 23:44:19 <aparcar[m]> usually no :)
Jan 03 23:57:52 <mangix> funny, I'm updating busybox to 1.33. The date patch doesn't apply anymore. Guess I'll do it a different way.
Jan 04 00:04:02 <mangix> musl was properly fixed upstream with version 1.33. incredible.
Jan 04 00:33:56 <blocktrron> nbd: i've seen the mt7915 rate-control is done via the MCU firmware - is this subject to change or is there no way around this (presumably MU-MIMO)?
Jan 04 00:55:52 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (99.2% images and 98.1% packages reproducible in our current test framework.)
**** ENDING LOGGING AT Mon Jan 04 02:59:57 2021