SPA504G Provisioning using TFTP issues

[idemkovitch]

Hello group,

Hopefully you can point me in a right direction. We use SPA504G phones with Asterisk. I do know how to setup phones and they work great. Now I want to automate provisioning and this is where I hit a brick wall.

Not sure if it's firmware related or what, but seems like no instructions that I find (from 2010) work. All phones is on last 7.6.2 firmware.

Here is what I've done:

1. Downloaded template from phone via /admin/spacfg.xml

2. Created TFTP on our Asterisk server. Added option 150 to DHCP (router) and pointed to Asterisk server's IP. Btw, this is NOT option 66, phone didn't grabbed it until I changed to Option 150

3. Phone reset to factory defaults, rebooting. On TFTP I see phone asks for 3 files in order. Does it twice:

SEP7081053D862B.cnf.xml

XMLDefault504G.cnf.xml

XMLDefault.cnf.xml

None of those is what I find in documentations..

4. I did place file SEP708... to TFTP, copied templated file from other phone with NO CHANGE. I see in TFTP log that file being served and then I see "tftpd: read(ack): Connection refused" message. TFTP works fine, I can get that file from other PCs in same subnet and in other subnets. So, it's something about how phone does it..

5. I did try to feed file directly to the phone doing this:

http://192.168.99.xxx/admin/resync?tftp://192.168.xxx.xxx/SEPA44C119EEBF8.cnf.xml

I see on TFTP file was taken. And I see message in browser that phone will reboot and apply. And nothing happens...

I'm little lost as it looks like all the manuals outdated, file naming structure changed, etc. Not sure where to look for debug information.

Thank you!

[Philip D'Ath]

I used http for provisioning.  These are my DHCP options:

ip dhcp pool phone
 network 192.168.100.0 255.255.255.0
 default-router 192.168.100.1 
 dns-server a.b.c.d e.f.g.h
 option 160 ascii http://xxx.ifm.net.nz
 option 66 ascii http://xxx.ifm.net.nz
 update arp

This is a simple provisioning file (start simple, and see if you can get that to work first).  Call it spa504G.cfg and put it in the root on the www server.

<flat-profile>

<Profile_Rule group="Provisioning/Configuration_Profile">http://xxx.ifm.net.nz/spa
$PSN.cfg</Profile_Rule>
<Profile_Rule_B group="Provisioning/Configuration_Profile">http://xxx.ifm.net.nz/C
isco/SPA$PSN/$MA.cfg</Profile_Rule_B>

<Resync_On_Reset group="Provisioning/Configuration_Profile">Yes</Resync_On_Reset>
<Resync_Periodic group="Provisioning/Configuration_Profile">3600</Resync_Periodic>

<SPCP_Auto-detect group="System/System_Configuration">No</SPCP_Auto-detect>

</flat-profile>

[Dan Lukes]

I found the surprising example of the device that choke on unsolicited option 160.

Read last paragraph of this comment.

[Dan Lukes]

option 66 ascii http://xxx.ifm.net.nz

It should be noted you are living on the edge a lot.

Option 66 is the standard tftp option with "just hostname" value only. While Cisco phones can accept nonstandard full URL text here, other devices may choke on it and fail to boot entirely.

To be on safe side - you should serve this non-standard option 66 to Cisco phones only (they can be recognized by vendor identification in DHCP request) or you should not provide option 66 at all.

Option 160 is vendor specific option, thus DHCP clients are generally more hardened to not to choke on different format/content provided in the value. But even here you should serve such option to appropriate DHCP client only. There may be an other vendor device will use option 160 for different purposes. It may not only fail to boot - in the worst case it may be bricked.

[Philip D'Ath]

ps. If you respond to any of the *.xml requests you'll put the phone into "skinny" mode, and then it wont ask for the sip *.cfg files.

Make the changes below and then factory reset your phone.

[idemkovitch]

Philip,

Do I understand correctly that:

1. Phone asks only for .xml files is because I already put it in "skinny" mode?

2. In order to get it "out" of skinny mode I need to factory reset. Can I do it online? Can't get a hold of physical phone at the moment..

Also, should it work just fine via TFTP? I understand you use HTTPS but should it work the same via TFTP? We are on internal network, no need to HTTPS..

[Philip D'Ath]

1. Not sure.  I just now it is important not to respond to those requests.

2. Whenever I have a config problem with a phone I often just factory reset it to get it back to its factory default "out of box" state.

The config I have you was for http.  Change http to tftp if you want to use tftp.  Change it to https if you want to use https.

[Dan Lukes]

We also use SPA5xxG with Asterisk, but I run separate HTTP server with own PHP script for the purpose of provisioning.  TFTP is so dumb protocol and anyone can download anyone's configuration including SIP credentials. We wish to avoid identity thefts so we use HTTPS to serve provisioning while the phone is authenticated by unique certificate embedded inside (by manufacturer). 

OK, lets go.

NOT option 66, phone didn't grabbed

It works. I assume wrong content/format of the option value. But forget it, option 150 works for you, so no reason to change.

phone asks for 3 files

It's part of SPCP/SIP mode autodetection. If those files are found the SPCP mode is assumed. SIP mode is assumed otherwise. It will ask for resource specified by option 150 then. I assume you has read SIP mode documentation - SPCP stuff is not covered here.

 did place file SEP708... to TFTP, ... Connection refused

Damn. You didn't disclosed content of DHCP's option 150 you have. You are mangling file names. We know no content of such file - it seems you are assuming there's a prophet here.

So many possible causes. But if you are providing SIP provisioning file under the name of SPCP configuration file then it will not work. SPCP configuration file use different syntax and content of the file.

phone will reboot and apply. And nothing happens

So confusing statement. You claimed the phone has applied the configuration and you claimed "nothing happened" at the same time. I'm unsure what you are expecting to happen. Insufficient information to make conclusion. I guess wrong content of such file.

Not sure where to look for debug information.

Phone is willing to send them to you. Configure syslog&debug server, turn on highest level of debug. A syslog server must be running in the IP you configured or you can use generic packet dumper to catch network packets carrying the messages.

[idemkovitch]

Dan,

All good info. So, somehow I already switched phone to "SPCP" mode and it will not ask for sip*.cfg files anymore. Correct?

Damn. You didn't disclosed content of DHCP's option 150 you have. You are mangling file names. We know no content of such file - it seems you are assuming there's a prophet here.

I'm not sure what you mean. But here is what I see on server:

Jul  2 15:31:53 localhost in.tftpd[5528]: RRQ from 192.168.33.104 filename SEP7081053D862B.cnf.xml
Jul  2 15:31:53 localhost in.tftpd[5528]: tftpd: read(ack): Connection refused

So, it knows file name. But for some reason nothing happens..

So confusing statement. You claimed the phone has applied the configuration and you claimed "nothing happened" at the same time. 

I guess I didn't explain clearly. When I send request via URL(command to phone to get config)  - I get message that "phone will reboot and apply" but phone does not reboot and does not apply anything.

Phone is willing to send them to you. Configure syslog&debug server, turn on highest level of debug. A syslog server must be running in the IP you configured or you can use generic packet dumper to catch network packets carrying the messages.

I just set rsyslog on my Asterisk server, not seeing anything yet in /var/log/messages

Did I specify address/options correctly on phone? Do I need to reboot something?

And another question. Should it matter to phone if it's TFTP or HTTP(S)?

[Dan Lukes]

somehow I already switched phone to "SPCP" mode and it will not ask for sip*.cfg files anymore. Correct?

No, as far as I know. Mode is detected on every boot (by default). Just stop to provide SPCP configuration files by TFTP and phone will not start in SPCP mode anymore.

I'm not sure what you mean. But here is what I see on server:

Jul  2 15:31:53 localhost in.tftpd[5528]: RRQ from 192.168.33.104 filename SEP7081053D862B.cnf.xml
Jul  2 15:31:53 localhost in.tftpd[5528]: tftpd: read(ack): Connection refused

I mean we don't know the origin of SEP7081053D862B.cnf.xml name. It may be hardwired name of SPCP configuration file (but we know no MAC of phone in question, so I can neither confirm nor reject such hypothesis). It may be taken from misconfigured DHCP's option 150 (but we know no content of such option, so I can neither confirm nor reject such hypothesis).

For now I assume you are still providing SPCP configuration files to phone. Just don't do it. Lets allow the SPCP autodetection to timeout. SIP configuration will be requested then. SIP configuration files have different names (sorry, I use option 160 to claim provisioning source including file name so long so I don't remember the default filename).

I get message that "phone will reboot and apply" but phone does not reboot and does not apply anything.

Hm. So many possible reasons for it. My favourite is - the phone is confused by (syntactically wrong) SPCP configuration files mis-served to them during boot. Stop providing them and try again.

Did I specify address/options correctly on phone?

Yes, it's configured correctly as long as there's syslog server running on 192.168.33.1. I'm not familiar with rsyslogd configuration. Are you sure you have configured it to put debug messages into /var/log/messages file ? Your configuration may order daemon to save them elsewhere or not to save them at all ...

Should it matter to phone if it's TFTP or HTTP(S)?

Beyond few CPU ticks required to establish HTTPS connection ? No, phone doesn't care the provisioning file source.

But you may care. As I mentioned above, TFTP protocol is so dumb. Anyone may ask any configuration file, so SIP credentials needs to be considered public property. Identity theft is easy here. With HTTPS you may verify the phone's identity (as there's unique certificate embedded inside every phone). Thus you may reject request for provisioning file send by rogue user.

Of course, you may not be interested in such kind of security - it depend on your requirements.

[idemkovitch]

Reading more on that. HTTPS sounds good, but we have better things to do :)

We have very small office and nobody will be stealing identities..

Anyway. I got log running and phone actually sends logs to it :)

Requesting resync https://192.168.33.31:443/spa504G.cfg

Requesting resync https://192.168.33.31:443/Cisco/SPA504G/a44c119eebf8.cfg

As you see - phone actually tries HTTPS. From what I gather from some videos and manuals - Option 150 that I use is a "Cisco" option - so they use it for tftp first. Now that I removed all files from TFTP - they try same IP (btw, I have only IP address under option 150) but with HTTPS..

Question is.. WHAT IS Option 150? Because as you mentioned below - I don't want to set those up possibly confusing other devices on network.. Main router's DHCP serves those..

Right now it look like in order to get it to work I need to 

1. Keep option 150 - from what I found in Cisco video - it says "Cisco-TFTP" - I like that it's Cisco specific. Is it a good idea to keep using it? It only contains IP address

2. See picture - seems like changing this to TFTP will force those requests to go to TFTP server. Or HTTP if I want to..

The only negative I see is that by default (after factory reset) those phones look in HTTPS. This means first step after phone connected - need to change to "HTTP" or "TFTP" and reboot.

Do I understand process better now?

Or I should change to Option 66 and then phone will look in TFTP for spa504g.cfg?

[Dan Lukes]

nobody will be stealing identities

Does it include authors of viruses/worms occasionally running on user's computers ?

OK, but to be on safe side, ask your provider to block most expensive international destinations. You has been warned.

As you see - phone actually tries HTTPS

Phone should not use HTTPS by default. It should use TFTP. So either defaults has changed on 7.6.2 firmware or phone is not in factory-default state or there's something (DHCP ?) ordering phone to use HTTPS.

WHAT IS Option 150

Option 150 has been so called 'site-specific option'. E.g. option with ad-hoc meaning per particular site. Cisco has used it with no formal allocation from appropriate authority. Also Etherboot has used it for unknown purpose. And GRUB used it to obtain path of configuration file.

As of RFC3942 the option 150 has been reclaimed as publicly defined option and Cisco has documented their use (RFC5859).  Now it needs to be recognized standard option with documented meaning.

So you can consider it safe as long as there's no old Etherboot/GRUB/other unknown device connected. But if you wish to be pretty sure, you may still consider not to serve option 150 to non Cisco phone clients. If your DHCP server can take it, of course.

Is it a good idea to keep using it?

Yes, as long as it fit your requirements.

The only negative I see is that by default (after factory reset) those phones look in HTTPS. This means first step after phone connected - need to change to "HTTP" or "TFTP" and reboot.

Well, if you didn't missed something and it's true factory default value, then you may consider to use option 160 instead. It allow you to define even transport protocol. Thus zero-touch deployment will be maintained.

It should be noted I'm using option 160 to force phone to use HTTPS. I'm not familiar with 7.6.2 firmware, but previous firmwares up to 7.6.1 has used TFTP by default. Thus I need to use option 160 to force virgin phone to fetch initial configuration via HTTPS.

Thus option 160 may keep you safe against future changes of factory default values.

Do I understand process better now?

You tell me it ;-)

Or I should change to Option 66 and then phone will look in TFTP for spa504g.cfg?

I'm unsure about the 7.6.2 exact behavior. Just try. But note that even option 66 may affect other device boot.Moreover, it may make things worse - there are more devices aware of/asking option 66 than those requesting option 150. So the decision depends on list of devices connected - now and even in the future.

As I mentioned above, I'm using option 160 to avoid all those uncertainties and changes in factory default values. But my DHCP server sends such option to SPA kind of devices only.

Also note I'm using DHCP option for initial provisioning of virgin phone only. This configuration will configure Provisioning_Rule and turn off SIP/SPCP detection as well as DHCP option logic. Thus further configurations are loaded according Provisioning_Rule value only.

[idemkovitch]

Dan,

I tried option 66 and it did go to TFTP by default. So, it's option 150 that send to HTPS. At least this part is clear..

Our DHCP server is Mikrotik router. Also I'm sure I can make it detect "Cisco" phones - I probably won't do that... I think I will just use Option 160 because that is just a string from what I understand..

OK, but to be on safe side, ask your provider to block most expensive international destinations. You has been warned.

Yes, we are so small that it won't be issue :) Our provider bills us upfront in $20 increments. If something happens I will know very quickly.

Trying option 160, seeing some strange stuff on TFTP side.

Jul  4 08:15:45 localhost in.tftpd[6701]: RRQ from 192.168.99.112 filename SEPA44C119EEBF8.cnf.xml

Jul  4 08:15:45 localhost in.tftpd[6701]: sending NAK (1, File not found) to 192.168.99.112

Jul  4 08:15:45 localhost in.tftpd[6702]: RRQ from 192.168.99.112 filename XMLDefault504G.cnf.xml

Jul  4 08:15:45 localhost in.tftpd[6702]: sending NAK (1, File not found) to 192.168.99.112

Jul  4 08:15:45 localhost in.tftpd[6703]: RRQ from 192.168.99.112 filename XMLDefault.cnf.xml

Jul  4 08:15:45 localhost in.tftpd[6703]: sending NAK (1, File not found) to 192.168.99.112

Jul  4 08:15:49 localhost in.tftpd[6704]: RRQ from 192.168.99.112 filename /aster

Jul  4 08:15:49 localhost in.tftpd[6704]: sending NAK (1, File not found) to 192.168.99.112

Jul  4 08:15:49 localhost in.tftpd[6705]: RRQ from 192.168.99.112 filename /aster/spa504G.cfg

Jul  4 08:15:49 localhost in.tftpd[6705]: sending NAK (1, File not found) to 192.168.99.112

Jul  4 08:15:49 localhost in.tftpd[6706]: RRQ from 192.168.99.112 filename /aster/Cisco/SPA504G/a44c119eebf8.cfg

Jul  4 08:15:49 localhost in.tftpd[6706]: sending NAK (1, File not found) to 192.168.99.112

Because option is text - I added "/aster" folder to see what it's doing. As you see - phone still tries to get SPCP stuff from root. I thought maybe DHCP cached this option 66, so I rebooted router, rebooted phone and tried again with same result. Do you think phone is doing "smart" logic and tries to pull SPCP stuff from root?

[Dan Lukes]

option 150 that send to HTTPS. At least this part is clear..

For this firmware version only. I suspect such behavior is not common.

Trying option 160, seeing some strange stuff on TFTP side.

RRQ for all three *.cnf.xml files are part of SPCP/SIP autodetection. Those files should not exists, so the NAK is expected answer.

The 'DHCP option 160' is SIP feature. The SPCP/SIP autodetection occur before the phone switch to SIP mode thus no option 160 affects it. All SPCP (e.g. three *.cnf.xml) files will be requested from root.

Once SPCP detection fail, phone enter SIP mode and SIP configuration become loaded, the autodetection may be turned of (by loaded configuration). So autodetection will happen no more during subsequent reboots.

RRQ from 192.168.99.112 filename /aster

I assume you have option 160 filled with something like 'tftp://xxx.xxx.xxx.xxx/aster'

It's possible, but suboptimal. Use full file name, not the just directory. E.g. use something like tftp://xxx.xxx.xxx.xxx/aster/a-name-of-configuration-file.xml

You will save superfluous attempt to fetch /aster directory from TFTP server.

[idemkovitch]

RRQ for all three *.cnf.xml files are part of SPCP/SIP autodetection. Those files should not exists, so the NAK is expected answer.

Yes, NAK is correct. But I only have option 160 at moment and didn't expect phone to go to the root. So, phone reads full value 'tftp://xxx.xxx.xxx.xxx/aster' and then parses it and uses only address for those requests? That's what I wasn't sure about. If it was DHCP glitches or phone doing that.

It's possible, but suboptimal. Use full file name, not the just directory. E.g. use something like tftp://xxx.xxx.xxx.xxx/aster/a-name-of-configuration-file.xml

I put it like this just for testing purposes to see if this DHCP option pulled and used. I was planning to change it to root when done. What this file you suggesting will contain?