<zula>
upon trying to connect (which always fails) it seems like all networking (including cellular) is being reset. anytime reconnect is tried, the same networking reset happens.
<LuK1337>
is wlan mac legit in settings?
<zula>
yeah, that looks good to me
<LuK1337>
so it's same as bt
<LuK1337>
except last octet?
<zula>
nope
<LuK1337>
then it's not good
<zula>
you know which vendor prefix should be used for these devices?
<LuK1337>
i mean i told you that it should be the same as bt mac except last octet...
<luca020400>
LuK1337: this stuff never fails to amaze me
<zula>
yes, i understood. they differ completly.
<LuK1337>
ls -laZ /data/vendor/oemnvitems/
<LuK1337>
you should have 4 files there
<LuK1337>
with 666 perms
<LuK1337>
and u:object_r:vendor_data_file:s0 secontext
<LuK1337>
and /mnt/vendor/persist/wlan_mac.bin should be 600 with u:object_r:mnt_vendor_file:s0 secontext
<zula>
let me check
<LuK1337>
with modification date same as boot
<luca020400>
why do they keep using this stupid way of getting mac address
<LuK1337>
it worked for them for last 7 years
<LuK1337>
so why not
<zula>
OnePlus6:/ # ls -laZ /data/vendor/oemnvitems/
<zula>
total 48
<zula>
drwxrwx--x 2 radio radio u:object_r:vendor_data_file:s0 4096 2018-11-10 11:08 .
<LuK1337>
still makes me cringe less than bringing in stuff like
<LuK1337>
• Newly added Bitmoji AOD, co-designed by Snapchat & Bitmoji, which will liven up the ambient display with your personal Bitmoji avatar. Your avatar will update throughout the day based on your activity and things happening around you ( Path: Settings - Customization - Clock on ambient display - Bitmoji )
<luca020400>
ah.
<zula>
fyi: after delete & reboot, now all files have the u:object_r:vendor_data_file:s0 secontext
<zula>
the mac is incorrect again every reboot (without deleting /data/vendor/oemnvitems/ again)
<zula>
wifi with system mac does seem to be working. i'm pretty sure my issue before was caused by another reboot which again caused the incorrect mac.
<zula>
vendor spl 05/2021 now btw
<zula>
how could I fix the mac permanently?
<zula>
i guess this needs to be fixed within LOS?
<LuK1337>
i don't even know why it's behaving that way for you to begin with
<LuK1337>
here i can reboot as many times as i wish
<LuK1337>
and I'd never get wrong secontext
<zula>
hm
<zula>
i will gladly provide additional information to debug this
<LuK1337>
I'd gladly take a look at .patch file instead
<LuK1337>
also hope you aren't using magisk
<LuK1337>
if you are then it's possible that this is why
<zula>
i did install magisk so i could access /data/vendor/oemnvitems
<zula>
how could i otherwise?
<LuK1337>
adb root
<LuK1337>
lol
<zula>
is that working again
<zula>
good
<LuK1337>
was it ever broken on lineage?
<zula>
yes
<LuK1337>
i can't recall
<zula>
definitely many moons ago
<LuK1337>
if anything you just had to enable it in dev options
<zula>
no, the dev option was missing
<zula>
that was the issue
<LuK1337>
but i don't recall it ever being totally broken
<LuK1337>
unless many moons ago you had magisk
<zula>
no, i never used magisk until adb root wasn't working anymore (due to missing option in dev opts)
<zula>
but it's present now so let's not worry about that
<luca020400>
maybe very early 17.1?
<zula>
yes, i think so
<LuK1337>
pre official if anything
<LuK1337>
but then probably adb root was working unconditionally...
<luca020400>
I think we turned it off really soon...
<luca020400>
compared to the toggle
<luca020400>
or he simply didn't try because no toggle
<zula>
the incorrect wifi mac after reboot (without having deleted /data/vendor/oemnvitems/ previously) occurs without magisk as well.
<LuK1337>
we can solve it the other way around
<LuK1337>
if we go back 2 hours in time
<LuK1337>
you won't be even aware that your mac address is wrong
<zula>
well, since fixing the mac apparantly also fixed the wifi issue i'd rather not :P
<LuK1337>
didn't you say that updating fw fixed that?
<LuK1337>
i know that these files are labeled there
<LuK1337>
( feel free to blame OnePlus )
<zula>
why do you not have the same issue then?
<LuK1337>
fuck if i know
<zula>
i patched /vendor/etc/selinux/vendor_file_contexts to fix this permanently (until i flash new fw..)
<zula>
i'm glad this is working for me now (thanks for your hints), but i suspect there are more users affected by this who do not have the technical skill to understand this issue. so maybe it would be worth it to get this fixed in the device build.
<LuK1337>
sure, tell me how to fix it
<LuK1337>
or even how to make it broken on my device
<zula>
well, removing the 2 lines in /vendor/etc/selinux/vendor_file_contexts setting incorrect secontext does fix this
<zula>
otherwise you could probably chcon the files correctly in a startup script or something
<LuK1337>
lineage does not ship vendor
<zula>
i know
<zula>
but it can modify vendor
<LuK1337>
no, it can't.
<LuK1337>
that's not something that'd be accepted for official build
<zula>
i understand
<zula>
but there must be ways to work around broken things on vendor?
<LuK1337>
possibilities are endless
<zula>
then i don't get what stops this from being fixed :D
<LuK1337>
gerrit is open for contributions as always :^)
<LuK1337>
i'd prefer to know why X happens than workaround it
<zula>
i know. and if i was at all competent when it comes to android i would contribute a patch immediately (as i have done for many projects in the past).
<zula>
isn't the question rather why it doesn't happen for you?
<LuK1337>
not really
<LuK1337>
since it doesn't happen for most of users
<zula>
as far as i can tell, my device is behaving as i would expect it regarding the context set in /vendor/etc/selinux/vendor_file_contexts
<LuK1337>
well not even stock rom behaves that way then
<LuK1337>
and if it behaved that way on stock
<LuK1337>
it'd be broken too
<zula>
okay
<luca020400>
damn taxes
<zula>
btw, is there a reason that fastboot boot is not supported in LOS userspace fastbootd?
<LuK1337>
someone would need to implement it
<LuK1337>
while in regular bootloader it's implemented by Qualcomm