<PaulFertser>
raenye: haven't yet read any additional code to fix your "eeprom", sorry.
<raenye>
that's fine, no rush
<raenye>
so far it's quite stable
<raenye>
I'm just thinking it could be a good idea to submit a patch upstream
<raenye>
assuming per-device uci-defaults is acceptable
<raenye>
that way everything works after factory reset
<PaulFertser>
raenye: but if you need fixing eeprom either way for this dbdc issue, and it's something similar to fix the bands issue then you wouldn't need uci-defaults.
<raenye>
PaulFertser: True. BTW, any idea if mt76 driver supports 256-QAM on 2.4 GHz? MT7615DN supposedly has it
<raenye>
I'll probably buy another unit to flash, wonder if the eeprom mess is a one time thing
<PaulFertser>
raenye: judging by the code and some github comments it's normal and expected for phy0 on mt7615d to be dual-band, so probably you do not need this uci-defaults patch as it behaves the same as the other dbdc devices.
<PaulFertser>
Namidairo: hey, do you probably know if it's a bug or phy0 on mt7615d dbdc should really be advertised as dual-band?
valku has joined #openwrt-devel
<raenye>
PaulFertser: it's phy0
<raenye>
phy1 is ac and is fine
<raenye>
PaulFertser: but then the auto-generated config assumes 802.11ac, 5ghz, and channel 36
<raenye>
and there are residues of the spurious band elsewhere (e.g., channel scan)
<PaulFertser>
raenye: probably that's how all mt7615d devices currently behave, if it's a bug, should be fixed in the mt76 driver.
<PaulFertser>
raenye: have you tried scanning on phy0 on 5 GHz, does it really not work?
<raenye>
yes, no results
<raenye>
I guess it is a bug in mt76
cmonroe_ has joined #openwrt-devel
<raenye>
this can be configured via luci (change AC to N, and then band can be changed) but is annoying for the user
<PaulFertser>
raenye: but if it's a bug in mt76 then it should be fixed there.
<raenye>
btw, is there a way to incorporate uci-defaults in an already built firmware? via image-builder perhaps?
<raenye>
PaulFertser: mt76 fix is needed; but until that is done.... given eeprom patch, the user can manually configure phy0 correctly
<PaulFertser>
raenye: uci-defaults can be added to files/ when using ImageBuilder
<PaulFertser>
raenye: do you feel like trying an mt76 patch if I provide you with one?
<raenye>
perhaps I should understand better what is ImageBuilder and why I need it
<raenye>
sure, I'll try
<raenye>
I just don't know how to add it to my git setup
<PaulFertser>
raenye: ImageBuilder uses all the ready-made binaries from repositories and then assembles it all in a squashfs image, it doesn't compile anything.
<raenye>
I'll be back in ~30 minutes
danitool has joined #openwrt-devel
<raenye>
PaulFertser: back now
<PaulFertser>
raenye: my idea is to try putting https://termbin.com/jh07 into package/kernel/mt76/patches/120-wifi-mt76-do-not-enable-5ghz-phy0-dbdc.patch
<PaulFertser>
raenye: then you do "make package/kernel/mt76/clean" to be sure and rebuild the image.
<raenye>
PaulFertser: this affects all mt76 dbdc devices, right?
hanetzer3 has joined #openwrt-devel
<raenye>
BTW, why sysupgrade forces me to factory reset ("upgrade: The device is supported, but the config is incompatible to the new image (1.1->1.0). Please upgrade without keeping config)"?
<PaulFertser>
raenye: probably making a github pull request on mt76 github, not sure.
<raenye>
PaulFertser: I meant with respect to the new device
<raenye>
and let me thank you once again for all your help
<raenye>
I thought this would take much longer to resolve
tidalf_ has joined #openwrt-devel
tidalf has quit [Read error: Connection reset by peer]
<PaulFertser>
raenye: and for the device itself don't worry about this patch, make the support as if this patch is already accepted and send it as either github pull request against master branch on OpenWrt github or to the mailing list the usual git send-email way.
tidalf has joined #openwrt-devel
tidalf_ has quit [Read error: Connection reset by peer]
<raenye>
I'm not sure how to do this. I did not use a github account, so I cannot do a pull request, right?
<raenye>
unless I fork on github and apply my patch there
<raenye>
anyway I need to flatten the commits
<raenye>
also, this exact device has a 2nd model number
<raenye>
with identical hardware but different D-Link hardware ID, so different firmware is needed
<raenye>
I have everything needed to create firmware for the other model too (D-Link DRA-1360-A1) but no actual device to test
tidalf_ has joined #openwrt-devel
<raenye>
Assuming someone in the world with a DRA1360 wants OpenWrt, how would I make them find out about it and ask for a test build?
tidalf has quit [Read error: Connection reset by peer]
MaxSoniX has quit [Quit: Konversation terminated!]
<PaulFertser>
raenye: "git rebase -i" is a great tool to squash commits. OpenWrt wiki has articles detailing how to offer support for a new device upstream.
<PaulFertser>
raenye: probably if you create a topic on the OpenWrt web forum someone would find it and test.
<PaulFertser>
raenye: sending a patch to the mailing list requires you to be subscribed (but you do not need to enable mail delivery). Sending a "github pull request" requires a github account.
<dangole>
tom-: that may be. i don't know how. i was just asked to make a signed tag :/
<raenye>
PaulFertser: quite annoying, couldn't send a pull request for a single commit so I had to reset, push force, and reference the (now orphan) commit hash of your patch
<raenye>
but I submitted the pull request
<raenye>
thanks again for your help.
<raenye>
github has nothing to do with website documentation, right?