[WXC/VFX] WRP400 configuration on xnet vfx service

Forums › Vodafone New Zealand › [WXC/VFX] WRP400 configuration on xnet vfx service

careym

7 posts

Wannabe Geek

# 30658 16-Feb-2009 20:16

On holiday and having a play with the WRP400 my folks have attached to an xnet vfx service - looks like a nice piece of kit. A couple of things I am looking into;

1. From http://myvfx.xport.co.nz/User/Addresses/ their account appears to have a pair of sip addresses, account.name@xport.co.nz which is an alias for phone.number@xport.co.nz are these intended to be connected directly too from SIP compatible softphones over the internet, eg Ekiga or similar? When we try to place a call from ekiga we are given the error "could not connect to remote host". We can ping xport.co.nz however is it not accepting connections from unknown parties?

2. Are there configuration knobs we need to tune with on our hardware to enable receipt of calls directly into Line 1 of their WRP400 over the internet without using the xnet service, sip connections direct to our IP address e.g sip:ip.address what is the user that xnet have configured our WRP400 to accept calls for on Line 1? account.name@ip.address? or something else - looks like we might be able to use Line 2 to do this as it is not locked out but still having two phones is a bit strange when we should be able to dial into Line 1 from the internet without going through xnet infrastructure, xnet then just get a busy signal should someone try to dial in from their system.

3. Finally trying to figure out the dialling procedure for using the POTs phone we have on the fxs port of our WRP400 Line 1. How can we dial and connect to an internet based sip service e.g account.name@ekiga.net, or is the xnet service not intended to be used in this way?

4. Also want to find out how World Exchange are programming the device, nothing sinister my folks own the hardware so what is it up to when it requests the file http://58.28.20.69/configs/default/default$MA.cfg. $MA screams a boring old $shell substitution or similar. Cant find anything on the web but I do see that the firmware image contains a couple of squashfs lzma file systems (credit: http://wiki.openwrt.org/OpenWrtDocs/Hardware/Linksys/WRP400 ) interested in the contents of the ./www directory so can find out. Has anyone got copies of these files handy to save me the hassle?

Cheers,

Mark Carey

sbiddle

28603 posts

Uber Geek

Moderator

Trusted

Biddle Corp

Lifetime subscriber

# 196150 16-Feb-2009 20:54

VFX does not support inbound URI calling. You can't connect using a URI even if you're registered with another SIP provider, it all has to be via POTS.

As for dialling other SIP URI's it's possible to have these configured in your dialplan. The device only supports a single SIP registration for inbound calls but can have on demand SIP registrations for outbound. A while back the guys at WxC did create some custom config files for users who asked - I have no idea whether this is something they will still do or not, it would pay to ring or email them and ask.

To accept inbound calls on a the 2nd line you have to be registered with a SIP provider.

From memory if you dial out via an on demand SIP URI in your dialplan on the 1st line the device will still accept incoming calls that come in via VFX and will give you a call waiting tone.

$MA is just the MAC address of the device, VFX create a provisioning file linked to the MAC address of the device you register and this is then automatically downloaded to the device. The Linksys provisioning guide contains everything you need to know about creating provisioning files for Linksys phones and ATA's. You won't be able to extract anything from this or see anything as it's encrypted.

careym

7 posts

Wannabe Geek

# 196161 16-Feb-2009 21:52

Thanks for the pointers very helpful

The Linksys Provisioning Guide is not freely available but a similar document suggests,

"...$MA expands to the unit’s MAC address, using lower case hex digits, s.a. 000e08abcdef..."

Which strangely doesnt seem to work .....

careym

7 posts

Wannabe Geek

# 196162 16-Feb-2009 21:55

but if the request is changed to use https you get a file .....

careym

7 posts

Wannabe Geek

# 196164 16-Feb-2009 22:01

And in that file is the url of another file, which once downloaded (https again) definately looks to be encrypted.

However so our WRP400 can interpret the file contents it must be able to decrypt the file and program the FXS Line 1 parameters.

The default$MA.cfg file mentions a key option "[--key $K]" and the firmware is supposedly buildable on CentOS (a Redhat derivative) so hmmm ......

sbiddle

28603 posts

Uber Geek

Moderator

Trusted

Biddle Corp

Lifetime subscriber

# 196165 16-Feb-2009 22:05

Why are you so interested in the contents of the file? There is nothing of any value in it.

As for the provisioning guide being difficult to find.. Google is your friend. Search for "linksys provisoning guide" and you'll find various versions of the file(s) within the first few links detailing everything you need to know.

careym

7 posts

Wannabe Geek

# 196168 16-Feb-2009 22:08

RE: encryption the Linksys SPA Provisioning Guide I have suggests OpenSSL and AES 256 is the algorithm. Further in the provisioning guide implies that the $K should be a pointer to the crypto secret ....

careym

7 posts

Wannabe Geek

# 196169 16-Feb-2009 22:10

sbiddle: Why are you so interested in the contents of the file? There is nothing of any value in it.

sbiddle inquiring minds want to know .... and if there is nothing of value then there is nothing of value and nothing to worry about .....

Niel

3267 posts

Uber Geek

Trusted

# 196268 17-Feb-2009 13:15

Suggest you do not say in the public domain that you are attempting to reverse-engineer the WxC setup. It will not go down very well.

You can never have enough Volvos!

careym

7 posts

Wannabe Geek

# 196579 18-Feb-2009 18:31

Niel: Suggest you do not say in the public domain that you are attempting to reverse-engineer the WxC setup. It will not go down very well.

Sorry but there needs to be some clarification here, there is no reverse engineering going on here at all, all I am doing is viewing a file which is freely available from a WxC server, if you knew the ethernet MAC of our WRP400 you could get the same files as well.

The files arent protected they are there in the open, security by obscurity is no security at all, no breaking of secret codes, OpenSSL with a publically available secret isnt magic.

Perhaps you should clarify what part of what I am doing you see as reverse engineering, excuse the bluntness, put up or go and comment on a thread where you actucally know what you are talking about rather than forum whoring for posts!