GNOME Bugzilla – Bug 566663
static IPv4 addresses stored/loaded in machine order
Last modified: 2014-01-02 16:58:06 UTC
Please describe the problem: I copied my gconf settings from my powerbook (big endian) to my macbook (little endian), and selected a static IPv4 connection. My IP address ended up being set to 4.0.0.10/24 instead of 10.0.0.4/24, and this address is also shown in the edit dialog. Steps to reproduce: 1. put 167772164,24,0 into the gconf settings for a static IPv4 connection 2. fire up the connection editor on a LE machine Actual results: it shows 4.0.0.10 Expected results: it shows 10.0.0.4 Does this happen every time? yes Other information: Dan says the storage should be big endian all the way through. An alternative is to just store a connection with 10.0.0.4/24, you should get the above in gconf but you get it in LE on a LE machine.
I can confirm the described behaviour and its a bug because it prevents sharing configs between LE and BE machines. All IPs are really stored in NM in network byte order (obtained via inet_pton()), i.e. the first byte is at the lowest address. However the values are stored in integer types. And here it is that the issue aroses. When the connection editor writes out IP as an integer, LE machine interprets the bytes in the opposite order (because integers values are supposed to be stored LSB first on LE). I include two patches resolving the problem: 1. The integer format is preserved to store IPv4 addresses in GConf, however byte order is corrected via ntohl() function. 2. The storage format is changed to strings, which prevents the endianness issues (inet_ntop() and inet_pton() handle the string <-> network byte order IP conversions correctly). The secondary benefit of this patch is that IPs are human-readable. That's why I would prefer to incorporate this patch. Note: There is an inconvenience that both patches change the behaviour in reading/writing config files. That means the backward compatibility is broken and the old config files should be converted. A script should probably be prepared to do the conversion.
Created attachment 148582 [details] [review] correction of endianness of IP integers in gconf files
Created attachment 148584 [details] [review] Changing format of storing IPv4 stuff in GConf to strings This patch stores/reads IPv4 addresses as strings and that's why it resolves endianness issues. This is preferred over the previous patch.
For conversion, the second patch would be easier. If you encounter an integer instead of a string, you assume config endian == machine endian, load it with the old code and write it back as a string. That would convert the config as soon as you upgrade, but the new config would be sharable between LE/BE machines.
we no longer store connections in gconf, so the machine-dependent format is no longer used