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

Created on 28 Aug 2015  路  4Comments  路  Source: SoftEtherVPN/SoftEtherVPN

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?

bug help wanted

Most helpful comment

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

https://github.com/SoftEtherVPN/SoftEtherVPN/blob/bed99f9a56e29a0fcd7a9e3d02f84f9d8621eb3d/src/Cedar/Client.c#L8104

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:

https://github.com/SoftEtherVPN/SoftEtherVPN/blob/d7d0e6d36fe1d73eca6205d9b2144ded67f52b13/src/Cedar/VLanUnix.c#L527

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!

All 4 comments

Could you please verify that this problem still occur?

@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

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

https://github.com/SoftEtherVPN/SoftEtherVPN/blob/bed99f9a56e29a0fcd7a9e3d02f84f9d8621eb3d/src/Cedar/Client.c#L8104

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:

https://github.com/SoftEtherVPN/SoftEtherVPN/blob/d7d0e6d36fe1d73eca6205d9b2144ded67f52b13/src/Cedar/VLanUnix.c#L527

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!

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AdroitAdorKhan picture AdroitAdorKhan  路  13Comments

yurivict picture yurivict  路  7Comments

Adrian-Voelker picture Adrian-Voelker  路  16Comments

TheNomad11 picture TheNomad11  路  5Comments

kvv213 picture kvv213  路  11Comments