Jump to content
Vodia PBX forum
chrispopp

Retrieve MAC address from WAN provisioned phone

Recommended Posts

chrispopp    0

Is there a way I can retrieve the MAC address over WAN for a provisioned phone? The provisioning was done using the username@domain.com and provisioning password manually.

Share this post


Link to post
Share on other sites
Vodia PBX    0

Hmm. What version? 4? We have given up on user@domain some time ago because it was not easy to handle and instead always try to use the MAC.

 

If this is a snom phone, you might see the MAC in the REGISTER message in one of the headers.

Share this post


Link to post
Share on other sites
Vodia PBX    0

Well, I think you will have to go through the list and do this more or less manually. A upgrade would not help much unfortunately. If the number is really large it could make sense to have a PCAP for the registration and try to "fish" MAC addresses out. If they are in the LAN, they would be visible on the PCAP.

Share this post


Link to post
Share on other sites
chrispopp    0

They are not on LAN unfortunately. Even under PCAP, would the MAC of the phone really show?

 

I was thinking to fish it using the provisioning server field {MAC} parameter, and pass it somewhere into the Generated log files. Would this be possible?

Share this post


Link to post
Share on other sites
Vodia PBX    0

Well you would not see the MAC layer of the packet in the PCAP; but you could e.g. search for HTTP provisioning requests or MAC hints in the REGISTER packet. PCAP would be still easier than distilling that from the various logs of the PBX.

 

But another approach could be more useful, to have the PBX provision the URL to use the {mac} parameter in it; then the phone would do this on its own. On idea is to modify the som_3xx_fw template, so that you download a dummy file there that will contain the MAC address for the user; then you'll have that in logs and can match extensions to MAC addresses.

Share this post


Link to post
Share on other sites
chrispopp    0

Well you would not see the MAC layer of the packet in the PCAP; but you could e.g. search for HTTP provisioning requests or MAC hints in the REGISTER packet. PCAP would be still easier than distilling that from the various logs of the PBX.

 

But another approach could be more useful, to have the PBX provision the URL to use the {mac} parameter in it; then the phone would do this on its own. On idea is to modify the som_3xx_fw template, so that you download a dummy file there that will contain the MAC address for the user; then you'll have that in logs and can match extensions to MAC addresses.

That's what I'm going to try. Any idea on how to setup that fw template to dump it's mac in a file somehow?

Share this post


Link to post
Share on other sites
Vodia PBX    0

Actually if you upgrade the PBX will automatically use MAC in the files. I would make a backup of the working directory and give it a quick shot (potentially using a 30-day demo license). You can then still restore the backup and move back. In theory that should work, as many customers went that path. Chances are it will also work for you.

Share this post


Link to post
Share on other sites
chrispopp    0

I don't think that will be an option, as I don't want to upgrade all the phones, and then re-downgrade them. I rather just manually retrieve the MAC addresses from a generated file and add it manually in a new installation of a 5 server or something similar. Could you help with getting the MAC address dumped some how?

Share this post


Link to post
Share on other sites
Vodia PBX    0

Well if there are thousands of phones it makes sense to spend a lot of time on a as-automatic-as-possible approach. If we are talking about 5 phones, you can as well call them up and ask them to turn the phone around and tell you what they see there.

 

Also, I forgot what was the point again to know what MAC addresses are being used? I assume that would be for an upgrade of the PBX. You want to avoid the risk that the upgrade does not work as expected?

Share this post


Link to post
Share on other sites
chrispopp    0

Well if there are thousands of phones it makes sense to spend a lot of time on a as-automatic-as-possible approach. If we are talking about 5 phones, you can as well call them up and ask them to turn the phone around and tell you what they see there.

 

Also, I forgot what was the point again to know what MAC addresses are being used? I assume that would be for an upgrade of the PBX. You want to avoid the risk that the upgrade does not work as expected?

 

I want to try to update from version 3 to version 5 which uses MAC based provisioning. Finding out the MACs will allow me to re-configure the PBX with the newly provisioning system, and maintain the same phones with the same extensions. There are only 100 phones over several domains.

Share this post


Link to post
Share on other sites
Vodia PBX    0

Hmm. I would still try to have the PBX do the job. We (Vodia) spent a lot of time with the PnP files to make it as smooth as possible. In order to limit the damage, maybe you can block HTTP access on the firewall, so that only a certain phone can access the PnP side of the PBX (just an idea).

 

Also, you could still try to get PCAP for the REGISTER packets unless they are using TLS. For example in the packet below the REGISTER contains the MAC in the sip-instance:

 

REGISTER sip:snom-test-xxx.local SIP/2.0
Via: SIP/2.0/UDP 192.168.203.42:44100;branch=z9hG4bK-d8t7hih3alex;rport
From: "1020" <sip:1020@snom-test-xxx.local>;tag=x5ntva7ffl
To: "1020" <sip:1020@snom-test-xxx.local>
Call-ID: 46000000b5b6-x4pyz178xx4n
CSeq: 11375 REGISTER
Max-Forwards: 70
Contact: <sip:1020@192.168.203.42:44100;line=bkcucywg>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:6c0e6ff2-8c51-4fae-84e0-00041370004A>";audio;mobility="fixed";duplex="full";description="snom720";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
User-Agent: snom720/8.7.3.25.5
Allow-Events: dialog
X-Real-IP: 192.168.203.42
Supported: path, gruu
Expires: 3600
Content-Length: 0
If you can still provision the phones with the running V3, you should also consider changing the template so that it "reveals" its identity if you cannot see anything in the REGISTER packet.

Share this post


Link to post
Share on other sites
chrispopp    0

 

Hmm. I would still try to have the PBX do the job. We (Vodia) spent a lot of time with the PnP files to make it as smooth as possible. In order to limit the damage, maybe you can block HTTP access on the firewall, so that only a certain phone can access the PnP side of the PBX (just an idea).

 

Also, you could still try to get PCAP for the REGISTER packets unless they are using TLS. For example in the packet below the REGISTER contains the MAC in the sip-instance:

 

REGISTER sip:snom-test-xxx.local SIP/2.0
Via: SIP/2.0/UDP 192.168.203.42:44100;branch=z9hG4bK-d8t7hih3alex;rport
From: "1020" <sip:1020@snom-test-xxx.local>;tag=x5ntva7ffl
To: "1020" <sip:1020@snom-test-xxx.local>
Call-ID: 46000000b5b6-x4pyz178xx4n
CSeq: 11375 REGISTER
Max-Forwards: 70
Contact: <sip:1020@192.168.203.42:44100;line=bkcucywg>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:6c0e6ff2-8c51-4fae-84e0-00041370004A>";audio;mobility="fixed";duplex="full";description="snom720";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
User-Agent: snom720/8.7.3.25.5
Allow-Events: dialog
X-Real-IP: 192.168.203.42
Supported: path, gruu
Expires: 3600
Content-Length: 0
If you can still provision the phones with the running V3, you should also consider changing the template so that it "reveals" its identity if you cannot see anything in the REGISTER packet.

 

I'll try that, and report back. Thanks for all your help

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×