<Tusker>
will that offset move around given that it's a filesystem ? or does every x20 have it in the same exact location on the ubifs ?
<Tusker>
especially trying to read the EEPROM file, grepping for "15 79 00 00" reveals many duplicates...
<rmilecki>
Tusker: this reads at hardcoded offset: macaddr@5006 { reg = <0x5006 0x6>; }
<rmilecki>
but it's an offset of UBI volume data
<rmilecki>
UBI volumes can store what you want
<rmilecki>
UBI volumes can contain ubifs filesystem as well as raw data
<rmilecki>
I think "Factory" is UBI volume with raw data, to hardcoded offset makes sense there
<Tusker>
ah, OK, that makes more sense
<rmilecki>
*so hardcoded offset makes sense
<Tusker>
so, if it's ubifs, then offsets are not guaranteed, then we'd need to mount it prior to reading the mac address ?
<rmilecki>
Tusker: right
<Tusker>
any examples of that being achieved? :)
<Tusker>
in dmesg, it looks like ubi is loaded before mtk_soc_eth, so timing wise it should be possible, but not sure how to have the kernel mount it
torv is now known as Guest1544
torv has joined #openwrt-devel
Guest1544 has quit [Ping timeout: 480 seconds]
dannyAAM has quit [Ping timeout: 480 seconds]
<Tusker>
any way in DT to get the ubifs to mount automatically? I have it detecting the volume so it attaches, but then the next step to mount it, currently mount -t ubifs ... works fine, but obviously won't work prior to loadin the mac address ?
robimarko has joined #openwrt-devel
svanheule has quit [Ping timeout: 480 seconds]
rmilecki has quit [Quit: Konversation terminated!]
rmilecki has joined #openwrt-devel
<dwfreed>
Tusker: you probably will need to set the mac via board.d
<Tusker>
sure, but how do I mount the ubifs automatically before board.d grabs the file itself ?
<Tusker>
I don't think I should be doing any mount -t ubifs in board.d ...
<dwfreed>
why not
<Tusker>
seems hacky... let me try :)
<dwfreed>
board.d is just shell script; it's free to do whatever it needs to do
<rmilecki>
Tusker: I think it has to be handled in user-space
<rmilecki>
i don't think there will be ever a way for kernel to mount filesystem, read file from it and assign MAC based on it
ar7ch has joined #openwrt-devel
<mrkiko>
A DTS related 2question - if "env-layout" nvmem s used, am I wrong in thinking the related entry for environment config can be removed?
<rmilecki>
mrkiko: do you mean "u-boot,env"?
<rmilecki>
mrkiko: and what is "related entry for environment config"?
<mrkiko>
rmilecki: yes
<mrkiko>
rmilecki: things added to package/boot/uboot-envtools/files/mediatek_filogic for example
<mrkiko>
rmilecki: I am under the impression that I can avoid adding an entry here if I defined nvmem env-layout correctly
<rmilecki>
mrkiko: ah, it depends if you need to modify any U-Boot env variables
<rmilecki>
mrkiko: because we don't support writing using NVMEM kernel interface yet
<rmilecki>
i'm going to work on that but first I want a proper layout driver
<mrkiko>
rmilecki: thanks a lot for the quick catch-up
<rmilecki>
I just sent V2 of my patchset for layout driver today
<rmilecki>
next thing is proper upstream MTD & NVMEM layout binding AND writign support
<mrkiko>
rmilecki: thanks for your work, this will enable a very nice cleanup
<mrkiko>
BTW - if someone could take a look at my smallgl-mv1000 changeset, thanks a lot
<Tusker>
rmilecki: no worries, let me play around with board.d to grab the information. Should I leave the ubifs mounted in /mnt/ubi_factory_data after I have extracted what I need ?
<dwfreed>
generally no
danitool has joined #openwrt-devel
<dwfreed>
probably best to mount it to a randomly generated temp dir, rather than to /mnt, even
<Tusker>
lan_mac=$(get_mac_binary /mnt/ubi_factory_data/default-mac 0x0) < it's stored in bytes in that file... is that correct ?
<dwfreed>
as in raw bytes? iow, if you did hexdump, you'd get the mac in hex spit out?
<mrkiko>
Is there any way to access a nvmem content from user-space ?
<mrkiko>
I mean - a nvmem cell content, to verify definitions correctness?
<mrkiko>
nevermind, think I got it
enyc has quit [Read error: Connection reset by peer]
enyc has joined #openwrt-devel
danitool has joined #openwrt-devel
<ar7ch>
jow: hello, just found this wiki page about netifd: https://openwrt.org/docs/techref/netifd. In particular, the person that wrote it (ldir) asked how to add certain parameters from UCI to hostapd, and provided some of your explanations from IRC on that.
<ar7ch>
I'm researching pretty the same thing and that's what I found: contrary with what you wrote, it is not sufficient to add new UCI-to-hostapd parameter by adding it to `hostapd_common_add_bss_config()` in `lib/netifd/hostapd.sh`.
<ar7ch>
The problem is that sh scripts work with JSON string generated by netifd. When parsing uci -> blob -> json, netifd filters out some uci settings. AFAIK filtering is done with `blobmsg_parse(policy...)`, where policy is array of allowed field names.
<ar7ch>
i.e., for `wifi-iface` this filtering policy is `vif_policy` (`netifd/wireless.c`). However, it is not clear for me why fields like `ssid` are not filtered, since there's no mention of them (there's no word `ssid` in the whole netifd project actually).
<ar7ch>
jow: Could you please comment on that?
enyc has quit [Remote host closed the connection]
enyc has joined #openwrt-devel
<jow>
ar7ch: my comments predate the current imlementation
<jow>
stuff is indeed funneled through netifd now
<jow>
however my impression is that netifd simply passes values through as-is
<jow>
netifd learns existing parameters from the handler script by running the script when netifd starts
<jow>
so maybe you didn't actually restart the netifd process after you added the new parameters
<jow>
the mac80211 wireless backend (the only remaining non-defunct one nowadays) is defined in /lib/netifd/wireless/mac80211.sh
<jow>
also, afair, options such as ssid are mostly hostapd (ap mode) and wpa_supplicant (sta mode) specific
<jow>
mesh and ad-hoc are special-cases since they can be run unencrypted without any supplicant running
<jow>
and iirc a number of parameter is funnelled through an opaque config dictionary within the internal json, without any intepretation by netifd
<jow>
but I'd have to reverse engineer the logic again to fully understand the current flow
<jow>
however in /lib/netifd/wireless/mac80211.sh there
<jow>
is drv_mac80211_init_iface_config() which teached netifd about known uci options for "config wifi-iface"
<jow>
this calls hostapd_common_add_bss_config() from /lib/netifd/hostapd.sh
<jow>
which in turn defines generic options such as `ssid`
<Tusker>
thanks guys
<Tusker>
have to run
Tusker has quit [Quit: Time wasted on IRC: 15 hours 36 minutes 57 seconds]
<ar7ch>
jow: First, thank you for your response!
<ar7ch>
jow: After long hours with debugger I can 100% say that netifd filters UCI config and emits a filtered JSON string. You can tell by adding `echo "$@" > /tmp/netifd_json_dump` to the top of `wireless/mac80211.sh` script
<ar7ch>
Then `netifd_json_dump` will contain a json that is mostly identical with `ubus call network.wireless status`. You can add a new parameter to `/lib/netifd/hostapd.sh`, but it simply will not be found in this json (i tried: https://forum.openwrt.org/t/adding-custom-hostapd-options-via-uci/204552)
<ar7ch>
Moreover, I just added a patch that adds field `foo` in `vif_policy` for a `wifi-iface`. And after that, `foo` is added to the json that is passed to `mac80211.sh`! It also appears on `ubus call network.wireless status`.
<ar7ch>
jow: Wow. Wait a bit. Adding `config_add_boolean bar` in `drv_mac80211_init_iface_config()` *does* make `bar` appear in the JSON. So, in `hostapd.sh` and `hostapd.conf` too. But it requires to kill `netifd` so it fully restarts. `ubus call network reload` does not make changes.
<ar7ch>
jow: How does it work? I'm struggling to find the way how shell scripts propagate options back to netifd.
<slh>
\x: careful with those firmwares, there was some talk by brainslayer on the OpenWrt forums about disassembling and 'fixing' (adding missing fields expected/ required by newer firmwares) BDF files for ipq60xx/ ipq50xx, so that might bomb hard with OpenWrt's BDF files
goliath has joined #openwrt-devel
<robimarko>
considering he has acess to those new FW-s then he also has acess to the BDF templates
<robimarko>
So, all that was most likely done is that fields that were empty when generated with old templates got populated with the new safe defaults
<robimarko>
This is a major issue we have since stock FW-s tends to be quite old and their BDF templates as well