Take Static IP settings across from FW 3.x to 4.x

Previous with firmware 3.x I could transfer /etc/config/dhcp and /etc/tertf/tertf_info.bak across from router to router to transfer across my static IP settings for all my devices.

In firmware 4.0 there doesn’t appear to be a /etc/tertf directory by default

Has anybody done this transfer from an older firmware 3.x unit? Any hints or solutions?

2 Likes

I also would like to know this, I used to do the same procedure on previous firmware…
Most devices remains “Unknown” for me even if I give them Hostnames…

@alzhao @lizh gentlemen, any comment on this? Thanks.

I don’t know. @dengxinfa can you check?

4.x uses /etc/oui-tertf/client.db instead of /etc/tertf/tertf_info.bak
/etc/oui-tertf/client.db is an SQLite3 file that you need to edit using the SQLite3 tool

Thank you for clarification.

I tried to have a look at the client.db with various SQLite tools but think it’s going to be beyond me :frowning:

Couldn’t work out how to import my current (manipulated) tertfinfo file (or even individual entries) into the db :thinking:

Hokay,

Had a chance to play.

If you just edit /etc/config/dhcp on the Flint running 4.x and copy and paste all your old static IP addresses from your old DHCP file then the first time you fire the Flint up you’ll get lots of unknown hosts with DHCP random addresses.

After a reboot, you will then get your static IP addresses sticking with your recorded device names.

Seems that the client.db will slowly start populating itself as well.

Only just starting playing around with but looks good so far.

2 Likes

BUMP

Sorry guys, just finally got to do a full live migration (the first effort was just a test).

Just copying across the DHCP file doesn’t work :frowning: Still lots of unknown devices: Points of concern:
Even though the device shows unknown it is already in the DHCP file with a device name allocated
Some of the devices that appear in the DHCP file don’t appear in the LAN section in the Gl-Inet interface
Deleting and recreating the DHCP entry either in LUCI or the Gl.Inet interface doesn’t fix
Also appears that connecting via an Access Point means devices attached to the AP show as unknown. If you remove the AP and attach devices direct to the Flint, it picks some up.

Help please:
Situation: Currently running Flint on 3.214 with 2 access points. Want to upgrade the Flint to 4.xxx but don’t want to have to manually re-enter all the static IP settings.

Currently running firmware V4.

In /etc/oui-tertf/ there is a file called “client.db”. This file has all the clients names saved with their mac. What if you copy both the files, the DHCP & the client database?

~Edit: Just saw you already looked into this.

How many static IP’s do you have?

For me it works, but i don’t copy the entire file. I only copy the static rules themselves like so:

cat<<'EOF' >> /etc/config/dhcp
config host '78d249b3ac13'
        option mac '78:d2:49:b3:ac:13'
        option ip '10.0.0.8'
        option name 'JohnexSwitch1'

config host '8394ed61e3d1'
        option mac '83:94:ed:61:e3:d1'
        option ip '10.0.0.9'
        option name 'JohnexSwitch2'

config host '001b2444813e'
        option mac '00:1b:24:44:81:3e'
        option ip '10.0.0.10'
        option name 'JohnexServer'

EOF

They show up correctly in my clients list.

1 Like

Sqlite is not as hard as it sounds…

First, copy the file to a more powerful environment with sqlite client.
ssh root@192.168.8.1 "cat /etc/oui-tertf/client.db" > "client.db"

Than open the dB with sqlite3 client.db.
I’ll fast forward here: Look for available tables .tables, analyze layout .schema client.
Now let’s see the content:
select * from client;

From the schema we know the content:
mac | IP | tx | rx | seen | iface | type | name
The first two and the last one are important here.

I don’t know if the database is just the data source or just a receiver for the needed goal. But if you’d like do export/import data while running, I can also take a look at home.

1 Like

In fact, you don’t need to export/import, because the client.db is everything. Maybe you’ll need to restart the process, that is using the file, to reload the altered DB.

Easy backup:
sqlite3 client.db .dump > backup.sql
Easy restore:
sqlite3 client.db < backup.sql

NOTE: The .dump will write a lot more into the file, than a copy the whole db or a SELECT * FORM client … It will also give instructions how to create/overwrite the table.
But we can also learn a lot from this file. vim backup.sqlwill show the lines:

INSERT INTO client VALUES('00:1F:16:AA:BB:CC','192.168.8.164',3936451,830191135,1658485224,'cable',2,'LupusELaptop');
INSERT INTO client VALUES('40:4E:36:AB:CD:EF','192.168.8.236',7452752,404097620,1658484734,'5G',1,'LupusEMobile');

We can use these lines in sqlite3 client.db or as command.

sqlite3-cli is available in the package repositories
sqlite3-cli | 3330000-1 | 94.4 KB | SQLite is a small C library that implements a self-contained, embeddable,… should be easier than exporting/importing.

Since the file is created at startup, I would not recommend to use the recovery, rather than delete the first part with create table ... and just execute the INSERT INTO statements.

Can anyone confirm by now, that a change in the database would lead to the wanted result?
If this database is only a storage for display the values at the fancy wegui, we can stop here. Else we can develop a few ‘recover status x from sd card’ queries.

Right now, i can’t find any process, using this file in normal runtime.
Checked by ls -al /proc/*/fd/ | grep -i client.db.

At the moment I’ve got 30 active devices (and a number more that are off-line). Maybe another 30 intermittent devices.

Yeah didn’t just copy the file across. I copied all the static IP entries only across to the existing V4 DHCP file underneath the default info.

I think I might just bite the bullet and find a time when nobody else is home, do the upgrade and just manually re-enter all the statics. Need to ensure same IP as there’s a bit of IOT devices in there that are addressed locally.

Do it when everyone is home like i usually do :stuck_out_tongue: Nobody can complain to the admin so :stuck_out_tongue: