ipaccess_drop_oml(): invalidate the feature vector

It's possible that a BTS gets disconnected, updated to a more recent
version or downgraded to an older version, and then connects to the
BSC again.  That more recent or older BTS version may have a different
set of supported features, so osmo-bsc must not trust the previously
reported feature vector.

Change-Id: Ie93af849d7771b4fff3cdf647c82510cd8543975
---
M src/osmo-bsc/bts_ipaccess_nanobts.c
1 file changed, 19 insertions(+), 0 deletions(-)

diff --git a/src/osmo-bsc/bts_ipaccess_nanobts.c b/src/osmo-bsc/bts_ipaccess_nanobts.c
index 9f17359..1a57deb 100644
--- a/src/osmo-bsc/bts_ipaccess_nanobts.c
+++ b/src/osmo-bsc/bts_ipaccess_nanobts.c
@@ -641,6 +641,10 @@
 
 	bts->ip_access.flags = 0;
 
+	/* Reset the feature vector */
+	memset(bts->_features_data, 0, sizeof(bts->_features_data));
+	bts->features_known = false;
+
 	/*
 	 * Go through the list and see if we are the depndency of a BTS
 	 * and then drop the BTS. This can lead to some recursion but it

