Jump to content

Retrieve MAC address from WAN provisioned phone


chrispopp
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...