As has been noted elsewhere mac_vendor.db is pretty huge and uses up lots of space in /overlay (edit: at least on my MT300N-v2)
I realize that others might be interested in prefix-to-vendor mappings, but I know what 4 devices connect to my travel router. I’d just as soon truncate the database so that all prefixes come from unknown vendors, and use that 920kB of space for something else.
Thus: what’s the on-disk format of this file, so I can create a new one and reclaim the disk space.
I checked my GL-MV1000W, the mac_vendor.db file is actually in /rom as part of the firmware. In such case, the overlay /etc/tertf//mac_vendor.db file is a “virtual” file and, if you delete it, it only sets an overlay flag and the rom “real” file is still taking up storage.
It’s not copied on boot, at least not on my MT300N-v2. Maybe it is on first boot, but here’s what I see after truncating and vacuuming the database, and rebooting:
root@router:/# ls -il /etc/tertf/* /rom/etc/tertf/* /overlay/upper/etc/tertf/*
3177 -rw-r--r-- 1 root root 12288 Jan 25 06:15 /etc/tertf/mac_vendor.db
4437 -rw-r--r-- 1 root root 472 Jan 25 07:04 /etc/tertf/tertfinfo_bak
3177 -rw-r--r-- 1 root root 12288 Jan 25 06:15 /overlay/upper/etc/tertf/mac_vendor.db
4437 -rw-r--r-- 1 root root 472 Jan 25 07:04 /overlay/upper/etc/tertf/tertfinfo_bak
767 -rw-r--r-- 1 root root 950272 Feb 15 2021 /rom/etc/tertf/mac_vendor.db
There was no tertfinfo_bak in the /rom squashfs, so one was created, and that write operation was trapped, and redirected into /overlay/upper. After disassembling /usr/bin/gltertf (the only binary in /usr to reference mac_vendor.db), it appears that sqlite is doing something clever/stupid since gltertf is the only thing that opens mac_vendor.db and only to do a SELECT. And now that that file was written, it’s being served from /overlay/upper rather than /rom.
Too much work. I don’t want to maintain build infra for my various gl.inet products. Easier and more maintainable to keep a shell script to apply my local changes: opkg update, install my ssh keys, install some packages, configure things, patch out undesirable behavior from the startup scripts… So I can either temporarily install sqlite to truncate the database, or just keep a copy of the truncated database for my configurator script to install.
An even easier workaround - which does not require installing sqlite and that doesn’t cripple the behavior of tertf - is this:
rm -f mac_vendor.db
ln -s /rom/etc/tertf/mac_vendor.db .
Ideally the database should be opened read-only which would mean that nothing would be written to /overlay. This might be fixed in fw4 but until that happens, a symlink to /rom will cause writes to fail but reads still work.
Yes, that saves memory in overlay, but you still have 1M of it in /rom. The trick is to get that out of /rom, make the firmware smaller, so more flash is available in overlay from the get go. Isn’t it?
So, I can produce a shrunk mac_vendor.db, but now how do I inject that into imagebuilder to replace what is there?
Haven’t figured out how. I took the 928kB mac_vendor.db and vacuumed it down to 12kB. Then I copied it over to imagebuilders /files directory as /files/etc/tertf/mac_vendor.db, and then built a new firmware with no other changes. I ended up with the 928kB mac_vendor.db; I thought it might have taken my vacuumed version instead.