Reading the m1's Serial Number

I searched the docs and can't find a reference to fetching the m1's serial number via an external application.  I'd like to include code in my program to verify that the serial number of the m1 matches the one in my program before allowing access (like RP does).  The serial number is contained in Global (07), page 43, but I don't see any commands in Elk's command protocols to gather that.  Can anyone point me in the direct of docs or links that speak to this?
 
Thanks,
Chuck

Hmm, I just read mine off the board...

Thanks for your reply, but no 'Hmm' is required, really.  I guess I didn't give enough info to answer my query ;-)  I'd like to have the software I wrote be specific for each m1 to avoid pirating.  So, basically, the program will only work on the machine that has the same serial number matching the one imbedded in the program's code. 
 
If anyone knows if the serial number is available programmably I'd appreciate a pointer to the docs.  An answer to a more general question will help I suppose, can installer Globals be accessed programmably?
 
Chuck

Care to elaborate? For example, Elk RP can run on any (Windows) machine...
 
If you write a program to read the serial (not sure if it's possible or not), it could be applied to a WAN connection and (possibly) used to read serial numbers from other M1's (e.g. one with an internet facing XEP).

I would hope the serial # is accessible to RP after a valid user code is entered otherwise the security hole is already there. 

I'd assume it's part of the initial validation process, but that doesn't mean that I can scan external IP addresses and be provided with SN's to your system...
 
If I had software which could scan a LAN (or any network for that matter) and be provided with a SN, I could then insert that SN into RP and likely log in... assuming the Access Code hasn't been changed.

Obviously its possible (or not), but not through the documented user interface.
 
There's really no reason for the M1 to tell a client (RP / your program) its secrets.  Typically, the authentication should be implemented as the client sending the serial number and the RP access code, and the M1 just accepting or denying the connection.  But the M1 will at least tell you if the serial number or access code is wrong. 
 

 
If you really want to pursue this, try analyzing the serial port data stream between the M1 and the XEP.
 
RP talks to the XEP, and the XEP talks to the M1.  Most of the time, the data the XEP sends to a client  on the network is the same data (zone changes, status, etc) that comes out of the M1 serial port.  When RP connects, the XEP and M1 carry on a private conversation.  While RP is connected, the normal M1 data stops and the XEP is unable to send that to clients. 
 
Although interesting, your ROI on researching this is going to be low.

Your reply was helpful since it clarified that I don't need the m1 to return the serial number just to compare it to what the user sends and report success/failure.  Thanks.

And to futher clarify - I'm just guessing about how the M1 authentication works.  The M1 -should- make the authentication based on information provided to it.  Then again I've seen some poorly developed stuff where the system provides the client the authentication info and the client makes the authentication.

I will keep looking, thanks again.

chuckfa said:

I will keep looking, thanks again.

Click to expand...

 
If you are trying to tie your software to a specific Elk, tie it to the MAC address, that may be easier than the S/N.

That would work, I will see if the XEP offers that info up.  Thanks

chuckfa said:

That would work, I will see if the XEP offers that info up.  Thanks

Click to expand...

 
If you are trying to do this over the ethernet interface, all you need to do is send it an IP ARP request, which contains the IP address of the XEP, and it will respond with its MAC address.

I'm not sure how to send the request to the m1.

Linwood said:

If you are trying to tie your software to a specific Elk, tie it to the MAC address, that may be easier than the S/N.

Click to expand...

 
That is assuming the client and the Elk are on the same network segment.  It won't work behind a router.  I don't see anything in the ASCII protocol that would uniquely identify an Elk system.