25 Feb
2017
25 Feb
'17
5:22 p.m.
On Fri, Feb 24, 2017 at 04:53:03PM +0100, Harald Welte wrote:
MAC will work when we have exactly one MSC|SGSN per machine: on loopback, MACs
are 0* and if two of the same run on the same ethernet device we will get
collisions (i.e. it doesn't help to create new IP addresses).
But having two of the same on the very same box is very unusual, right?
For those cases, like test setups, the VTY command solves it.
So yes, sounds like a plan.
Next question, *which* MAC? We have osmo_get_mac_addr(), yes, but it naturally
needs a device name. In osmo-bts, I find:
osmo-bts/src/common/abis.c:251: osmo_get_macaddr(bts_dev_info.mac_addr,
"eth0");
o_O that looks really bad! Hardcoded "eth0"? Ok for sysmobts, but otherwise,
seems like pure coincidence that it has worked out for everyone before.
(I'll open up an issue for that, but first awaiting your responses.)
I'm on unfamiliar turf ... is it possible to find the MAC for a given bind
instead? At first glance I thought: nice, there's and fd in osmo_get_macaddr(),
so I could just plug an fd sort of like:
int osmo_get_macaddr_from_fd(uint8_t *mac_out, int fd)
{
int rc;
struct ifreq ifr = {};
memcpy(&ifr.ifr_name, dev_name, sizeof(ifr.ifr_name)); /* but */
rc = ioctl(fd, SIOCGIFHWADDR, &ifr);
if (rc < 0)
return rc;
memcpy(mac_out, ifr.ifr_hwaddr.sa_data, 6);
return 0;
}
But shucks, there's still a dev_name involved. Can't I get the SIOCGIFHWADDR of
the device that socket will use? Wait a minute, that won't work because the
kernel decides on the device to use based on the routing table...
Go through the list of interfaces and pick the first non-NULL MAC? But that
would be vulnerable to server reconfig of possibly completely unrelated
interfaces.
At the moment it seems to me picking a MAC isn't all that simple or portable
(also need a separate FreeBSD impl), and requiring a unique ID in the config
file is so much simpler.
Does anyone have better insights and ideas than me?
[...]
All-in-all, I think the string approach is not too bad
in terms of
keeping GSUP simple while having a clan approach to interworkng with
MAP.
Yes, no objections there.
I would extend
the GSUP clients to allow setting an ID from VTY, or maybe a
random ID. At this point it would suffice to make the MSC side say it is
"MSC-00-00-00-00-00-00" but that's beside the point.
A random ID would not be permissible, as it has to be persistent accross
MSC/VLR/HLR re-starts, in order to make above-mentioned mechanisms
working.
I would say, why not simply use the same approach as in OsmoBTS, i.e. use
the MAC address (together with the MSC or SGSN prefix). The MAC address
is unlikely to change frequently or on short notice. For people who
know what they're doing, we can have a VTY command to override the
identity with a manually-specified string. If that option is not set,
the default "(SGSN|MSC)-MAC" is used. OAP seems like a funny but futile minor obstacle, but
nothing that can
provide any reasonable level of security.
heh "funny but futile"
Seems to me OAP was basically my initiation ritual at Osmocom ;)
For some
messages, OsmoHLR uses the conn pointer from msg rx to route the
response back -- that works.
This should be done in all request-response style procedures, I think.
Looking up by ID would also work in case meanwhile the
old connection
has died and a new connection has been established
Fine with me.
That patch of mine, if we apply it for optimization, needs to cleanup
lu_operation instances in case a conn is closed.
OsmoHLR should probably warn on the error log in case two conns are open
simultaneously for the same peer ID; even reject a second conn for the same ID
to help users do less foot shooting.
~N
With the attached and possibly very stupid patch,
OsmoHLR works for me with
both MSC and SGSN talking to it even though they have identical IPA IDs: I
bluntly store the conn in struct lu_operation and re-use it later.
For synchronous responses (i.e. no asynchronous activity in between)
this will work. So I think it's an optimization for those cases, and we
shouldn't rely on this to always work for all transactions at all time
in the future. Rather, we should make sure it works even without that
optimization?