Active Topics

 


Reply
Thread Tools
Posts: 13 | Thanked: 5 times | Joined on Oct 2009
#51
Originally Posted by fragos View Post
When MAC addresses were 1st used they were unique. My bad for not keeping up with the times -- all numbered identification schemes will eventually exceed their numerical capacity. The MAC address is associated with a specific port, physical connection, on the network. I have two Ethernet ports on my Desktop and each has it's own MAC address. I think we're splitting hairs on terminology. As a manufacturer of telecommunications equipment our manufacturing process insured we never repeated a MAC address on any of our networking gear with Ethernet ports. Clearly your NIC provider has lousy manufacturing process control.
Each "port" on your desktop is a NIC. However, even then there is not a 1:1 relationship (as far as the network is concerned) between NIC / network port and MAC. I run multiple virtual machines with bridged interfaces behind a single physical NIC connected to a single switch port. Each of the bridged virtual interfaces has a randomly generated "probably unique" MAC. If you mix that with an older, hub-centric network, there is no direct association as far as the network is concerned at all. You get a series of broadcast ARPs with responses that are broadcast to every port. In this case, machine A doesn't care what network port machine B is connected to at all...just that it's in the same broadcast domain. (Reasonably modern networks are all switched)

We haven't *actually* exceeded the entire 2^48 address space. I can guarantee you that 3com has made more than 16M NICs since the beginning of time - but they have 23 OUIs to spread things around. The original *intention* was to have everything be unique...but that would require everyone playing by rules that don't actually exist. The reality is that MAC address are reused within a single mfr. I saw a handful of dupes in a shipment of 200+ 10bT NICs 15 years ago - and if I'm remembering correctly they were 3com 3c509's...not exactly some no-name brand from China.

It's still not a real problem. Your MAC address doesn't make it past the very first router it hits. It does, however, make it a poor choice for globally identifying a piece of hardware. In this case, IMEI / IMSI is the way to go.

Last edited by devbike; 2009-11-11 at 00:25.
 

The Following User Says Thank You to devbike For This Useful Post:
Posts: 3,841 | Thanked: 1,079 times | Joined on Nov 2006
#52
If manufacturers start duplicating MAC addresses in manufacturing runs then a lot of customers would end up with tons of problems. It sounds unlikely to me that they do, or customers would have raised hell by now. We would have had trouble at work, as we buy batches of computers all the time. We don't fiddle with the MAC address. We register them though, then we plug all the new boxes into the network. No dups so far..
If a practice of producing equipment with unchanging MAC addresses exists then it doesn't seem to be followed by vendors like HP or Dell, at least.
__________________
N800/OS2007|N900/Maemo5
-- Metalayer-crawler delenda est.
-- Current state: Fed up with everything MeeGo.

Last edited by TA-t3; 2009-11-11 at 10:18.
 
Posts: 263 | Thanked: 679 times | Joined on Apr 2008 @ Lyon, France
#53
Originally Posted by qwerty12 View Post
Not entirely hard to get the IMEI in C - for the N900 - at least:

Code:
#define SIM_DBUS_NAME  "com.nokia.phone.SIM"
#define SIM_DBUS_IFACE "Phone.Sim.Security"
#define SIM_DBUS_PATH  "/com/nokia/phone/SIM/security"
#define SIM_IMEI_SIG  "get_imei"
Is there anywhere that the various DBus names, interfaces, paths and methods are documented? I didn't find them, after a short search, but perhaps there's another way to find out (maybe a DBus browser or query tool that tells you all the DBus APIs registered by an app)?

Cheers,
Dave.
 
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#54
Originally Posted by qwerty12 View Post
Not entirely hard to get the IMEI in C
Also, for shell scripts and such:

Code:
sysinfo-tool -g /certs/npc/esn/gsm
You can also substitute "wlan_id" or "bt_id" for "gsm" to get the WiFi or Bluetooth MAC address without long pipelines.
 

The Following 6 Users Say Thank You to lma For This Useful Post:
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#55
Originally Posted by R-R View Post
How is the IMSI protected ?
IMSI can be obtained in pretty much the same way as the IMEI.

Here's a quick dbus-send command-line example: dbus-send --system --type=method_call --print-reply=True --dest=com.nokia.phone.SIM /com/nokia/phone/SIM Phone.Sim.get_imsi which returns one argument: an int32 with the IMSI.

Code:
/* gcc -Wall imsi_example.c -o imsi_example `pkg-config --cflags --libs glib-2.0 dbus-glib-1` */

#include <stdlib.h>
#include <glib.h>
#include <glib/gprintf.h>
#include <dbus/dbus-glib.h>

#define SIM_DBUS_NAME  "com.nokia.phone.SIM"
#define SIM_DBUS_IFACE "Phone.Sim"
#define SIM_DBUS_PATH  "/com/nokia/phone/SIM"
#define SIM_IMSI_SIG  "get_imsi"

static gchar* get_imsi(DBusGConnection *connection)
{
  GError *error = NULL;
  DBusGProxy *proxy;
  gchar *imsi = NULL;
  guint32 tmp1;

  g_return_val_if_fail(connection, imsi);

  proxy = dbus_g_proxy_new_for_name(connection, SIM_DBUS_NAME, SIM_DBUS_PATH, SIM_DBUS_IFACE);
  if (!dbus_g_proxy_call(proxy, SIM_IMSI_SIG, &error, G_TYPE_INVALID, G_TYPE_STRING, &imsi, G_TYPE_INT, &tmp1, G_TYPE_INVALID))
  {
    if (error->domain == DBUS_GERROR && error->code == DBUS_GERROR_REMOTE_EXCEPTION)
      g_printerr("Caught remote method exception %s: %s", dbus_g_error_get_name(error), error->message);
    else
      g_printerr("Failed to call method: %s\n", error->message);
    g_clear_error(&error);
  }
  g_object_unref(proxy);

  return imsi;
}

int main(void)
{
  GError *error = NULL;
  DBusGConnection *connection;
  gchar* imsi;

  g_type_init();

  connection = dbus_g_bus_get(DBUS_BUS_SYSTEM, &error);
  if (!connection)
  {
    g_printerr("Failed to open connection to system bus: %s\n", error->message);
    g_clear_error(&error);
    return EXIT_FAILURE;
  }

  imsi = get_imsi(connection);
  (void) g_printf("%s\n", imsi ? imsi : "Failed to retrieve IMSI\n");
  if (!imsi)
    return EXIT_FAILURE;
  g_free(imsi);

  return EXIT_SUCCESS;
}

Last edited by qwerty12; 2009-11-11 at 15:13.
 

The Following 3 Users Say Thank You to qwerty12 For This Useful Post:
Fargus's Avatar
Posts: 1,217 | Thanked: 446 times | Joined on Oct 2009 @ Bedfordshire, UK
#56
Originally Posted by code177 View Post
Good idea, but kinda overkill Don't Nokia devices have a unique ID somewhere? Would be surprised if they didn't.
I notice that most of the thread has gone the route of assuming GSM devices of some sort but if you want to do something that works for non-gsm too (e.g. N8x0 and N7x0) then I suspect a combination of the device serial number and product code with a 'salted' delimitation? e.g.

<product code><delimiter><serial number>

The delimiter is whatever you choose but I suspect the other two will be variable length. I'm sure other O/S will also have a means to determine these even if it's only the old *#06#
 
Fargus's Avatar
Posts: 1,217 | Thanked: 446 times | Joined on Oct 2009 @ Bedfordshire, UK
#57
Originally Posted by R-R View Post
How is the IMSI protected ?

Carriers usually don't care about the IMEI cause they let you change your phone (my understanding) but the IMSI is your account number which links to your usage, etc...

It would probably be easy to find where the IMEI is sent and change it on the fly with some LD_PRELOAD or other techniques, but I'm guessing that the IMSI is in the smart card and has some form of crypto handshake with the provider?

Or is this just a receipt for fun^W disaster?

EDIT: http://en.wikipedia.org/wiki/IMSI-catcher
Also interesting, we should make sure the N900 show that (!) when it's not using encryption!

Also interesting: http://www.gsm-security.net

EDIT2: Uhm, of course there is a handshake, no multi-IMSI backup for multi-line use hehe (unless someone give you the key stored in the SIM, which, won't happen! ;-)
But still, changing the IMEI could be useful for those stuck with data plans tied to a specific device!
Just a thought - some carriers send out new SIM cards on a regular basis. Are we sure that when this happens that the IMSI is migrated to the same number on the SIM? If not then I suppose we ought to allow for this possibility in any app requiring this functionality.

The other thought is when someone changes their account but retains their number etcetera. Not so much a technical issue but something worth thinking about as use-case.
 
Posts: 13 | Thanked: 5 times | Joined on Oct 2009
#58
Originally Posted by TA-t3 View Post
If manufacturers start duplicating MAC addresses in manufacturing runs then a lot of customers would end up with tons of problems. It sounds unlikely to me that they do, or customers would have raised hell by now. We would have had trouble at work, as we buy batches of computers all the time. We don't fiddle with the MAC address. We register them though, then we plug all the new boxes into the network. No dups so far..
If a practice of producing equipment with unchanging MAC addresses exists then it doesn't seem to be followed by vendors like HP or Dell, at least.
It doesn't happen every day. I haven't see an unintentional duplicate MAC in over 10 years...but I haven't done bulk desktop stuff since then.

Also, it's highly improbably that you would even notice in most cases. If you buy a batch of 200 PCs, do they all end up in the same IP subnet? If not, you won't see the conflict. If you're using DHCP to register everything, how many DHCP servers do you have vs DHCP relays? Again, as long as the MAC is on it's own broadcast domain, you don't have a problem, but it *does* happen...and I'm not alone.

http://www.google.com/search?q=dupli...ress+-spoofing
 
Posts: 3,841 | Thanked: 1,079 times | Joined on Nov 2006
#59
I believe you when you say it's happening, but fortunately this doesn't seem to be often enough to hit us. And yes, we usually put the new boxes at the same subnet, because we keep moving them out of there later. I also have a database with all the mac addresses ever.. (for those that we dhcp anyway). I can take another look specifically for this, but I haven't noticed any dups before.
__________________
N800/OS2007|N900/Maemo5
-- Metalayer-crawler delenda est.
-- Current state: Fed up with everything MeeGo.
 
Reply

Tags
maemo 5, n900, python, unique id


 
Forum Jump


All times are GMT. The time now is 00:10.