LuK1337 changed the topic of #titandev to: Loliés! | *yiff* |
luca020400 has quit [Quit: WeeChat 2.8]
luca020400 has joined #titandev
zula has joined #titandev
<zula> Hi, are you aware of wifi crashing when using "use system mac" for a wifi network (instead of using a random mac) on latest LOS/enchilada?
<LuK1337> no but at the same time i don't really care at the moment
<LuK1337> sooner or later q firmware support will not be the priority
<LuK1337> assuming that i can get both R and Q bootable at the same time
<LuK1337> if i can't that'll be a problem...
<LuK1337> but i can imagine that with wrong wlanmac you wouldn't be able to connect to the network
<LuK1337> but "crash" idk about that
<LuK1337> is there an actual crash?
<zula> let me explain:
<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 .
<zula> drwxrwx--x 43 root root u:object_r:vendor_data_file:s0 4096 2020-04-16 16:31 ..
<zula> -rw-rw-rw- 1 radio radio u:object_r:vendor_data_file:s0 6 2021-07-20 14:32 447
<zula> -rw-rw-rw- 1 radio radio u:object_r:wifi_nv_data_file:s0 6 2021-07-20 14:32 4678_0
<zula> -rw-rw-rw- 1 radio radio u:object_r:wifi_nv_data_file:s0 6 2021-07-20 14:32 4678_1
<zula> -rw-rw-rw- 1 radio radio u:object_r:vendor_data_file:s0 124 2021-07-20 14:32 6855
<zula> OnePlus6:/ # ls -laZ /mnt/vendor/persist/wlan_mac.bin
<zula> -rw------- 1 wifi wifi u:object_r:mnt_vendor_file:s0 120 2021-07-20 14:32 /mnt/vendor/persist/wlan_mac.bin
<zula> permissions are fine, but 4678_0 and 4678_1 have a different secontext
<zula> modified date is also correct
<LuK1337> maybe chcon them to u:object_r:vendor_data_file:s0
<LuK1337> they are supposed to be u:object_r:wifi_nv_data_file:s0 but they almost never are for some reason
<zula> done
<LuK1337> so...reboot
<LuK1337> and see if you get different wlan mac
<zula> k
<zula> nope, mac as before
<LuK1337> and it's back to u:object_r:wifi_nv_data_file:s0 as well?
<zula> yes
<LuK1337> cursed phone
<LuK1337> i've seen one more guy who had that
<LuK1337> i think he just edited vendor sepolicy to workaround that
<LuK1337> i still have no clue how his selinux behaved *correctly*
<LuK1337> what if you remove whole /data/vendor/oemnvitems/
<LuK1337> and reboot?
<zula> let me try.
<luca020400> LuK1337: how is this even a thing?
<luca020400> what labels it?
<LuK1337> vendor
<LuK1337> but for some reason labels never work for me
<LuK1337> on these files
<LuK1337> and i tried to labeling these files on op7 i think
<LuK1337> and it never actually worked
<luca020400> is qmi by any chance using chcon?
<LuK1337> no way
<zula> removing /data/vendor/oemnvitems/ and reboot fixed the mac.
<zula> can still reproduce the wifi issue unfortunately
<LuK1337> what's your vendor spl?
<zula> by setting "use system mac"
<zula> feb 1st 2021
<LuK1337> so it's at least somewhat recent
<LuK1337> idk you can try updating fw
<zula> i already did
<zula> it's the latest OOS
<LuK1337> uh i have april 1 spl
<LuK1337> am i on beta fw?
<LuK1337> lol
<zula> someone on xda mentioned there was a 10.3.11
<zula> but only has 10.3.9
<zula> maybe it was pulled because of issues?
<LuK1337> oneplus website is shit
<LuK1337> always outdated
<zula> where did you get your fw?
<zula> thx
<zula> i will update fw and check
<zula> love their changelog
<zula> "fixed known issues"
<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?
<zula> no
<zula> it still occurs without fixing the mac
<zula> OnePlus6:/ # cat /vendor/etc/selinux/vendor_file_contexts |grep oemnvitems
<zula> OnePlus6:/ # cat /vendor/etc/selinux/vendor_file_contexts |grep oemnvitems
<zula> wtf is wrong with this damn client
<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
<zula> i see
zula has quit [Ping timeout: 246 seconds]