NicSetSetting: change of MAC Address does not take effect until manual restart of VPN Client

[scandox]

I have been using NicSetSetting to set the MAC address of Virtual NICs joining a Hub. I used static leases, so the MAC address effectively determines the IP Address the NIC should obtain.

I have noticed however that the change of MAC Address, though recorded in Softether data, is not reflected in the actual OS, until after a restart of the VPN Client itself. This means on first contact my NIC's are configured with incorrect IP addresses.

I also tried:

• Enable and Disable of NIC
• Setting it multiple times
• Disconnecting any Accounts and then Reconnecting.

However only vpnclient stop && vpnclient start works for me. I am using two separate clients:

• Version 4.17 Build 9562 on Debian Wheezy
• Version 4.18 Build 9570 on Raspbian

Both exhibit the same behaviour. Is this a bug or a feature?

[moatazelmasry2]

Could you please verify that this problem still occur?

[scandox]

@moatazelmasry2 Sorry for the slow response. Haven't been active with Softether for a few months.

Today I took a look at this.

• I setup a server and client
• Connected the client
• Checked the MAC Address which was 00:AC:B2:5A:26:93
• Logged in to vpncmd and ran "NicSetSetting ether MAC:/00-AC-BA-B5-B4-78
• Logged out of vpncmd and ran ifconfig. Still seeting MAC ending with 93
• Restarted vpnclient
• Ran ifconfig and now see MAC ending with 78

So it seems to me this issue is still live. The versions of Server and Client were:

• Client Ver 4.24, Build 9651 on Ubuntu 16.06
• Server Ver 4.24, Build 9651 on Ubuntu 16.06

[scandox]

@moatazelmasry2 I'm not really a C++ person but it seems to me the issue lies in or around the code here:

SoftEtherVPN/src/Cedar/Client.c

Line 8104 in bed99f9

StrToMac(r->MacAddress, set->MacAddress);

r in this case being the result of r = Search(c->UnixVLanList, &t);. After this there are calls to CiSaveConfigurationFile and CiNotify and CiSendGlobalPulse - none of which seem to do anything much at OS level. So maybe it is merely setting the MAC on the internal list, saving it to a config and then not actually attempting to update the virtual adaptor?

When the client restarts of course it will initialize the adaptor correctly with what it finds in the config.

Looking further at the initialization of the TAP device for the Virtual NIC we see this line which seems to set the MAC Address at init:

SoftEtherVPN/src/Cedar/VLanUnix.c

Line 527 in d7d0e6d

ioctl(s, SIOCSIFHWADDR, &ifr);

This is in a function called UnixCreateTapDeviceEx - so I guess what we need is a UnixModifyTapDevice call, which actually calls ioctl with the new MAC? Given that this doesn't already exist though perhaps there is a good reason!

[moatazelmasry2]

Didn't test that yet, but this looks like a very good analysis. Solid work!!!. Now we need someone to implement that :)

[Hamilkar247]

If i good understand, problem with set MAC address still exist?

[scandox]

@Hamilkar247 Yes it looks that way. There is no apparent change to the way this works,