06-20-2011 12:26 PM
It is a feature restriction or an error that if I add "*" to avoid domain access restrictions on my app it only works on public IPs and doesn't with local network IPs?
(ie. over wifi my phone has 126.96.36.199 and is trying to access information on a pc with 188.8.131.52, result: timeout)
If the same request is made to a public IP (same pc) ie. 184.108.40.206 then it works as expected.
- This access request is made by a webworks app installed on the phone. the response is in JSONP format.
- PC Firewall disabled.
- Tests made over wifi accessing a local network IP with phone data service enabled and disabled
- Tests made over Internet accessing a public IP, same phone, same app.
As shown in the following link, there is no indication that this behavior is expected:
If anybody knows a working example where "*" works for local network IPs please let me know.
Solved! Go to Solution.
06-22-2011 09:12 AM
astericks "*" for domains will allow access to any domain, whether it is on a local LAN or a public IP address. Some WiFi networks are setup so that they do not allow peer-to-peer connections. Not sure if this is your case or not.
Also, I've seen web server configurations where they listen to a specifc IP address (public address) instead of the local LAN address and will not serve up data.
Not sure if either of these are the case...
Is your device BES (Corporate BlackBerry Enterprise Server) activated or BIS consumer activated?
06-22-2011 11:29 AM
06-22-2011 11:42 AM
ok... sit tight for this possible explaination
A BlackBerry has two different concepts to consider:
1) Physical Network Connection
2) Transport Selection
The Physical Network Connection is pretty self explainatory (wifi, bluetooth, GPRS, CDMA). The Transport Selection can best be thought of as a VPN Tunnel/Connection. These Transports can be BES, BIS, TCP Direct, WAP gateway etc.
Even though you are on WiFi, you can still have your transport (VPN) connected through BIS. This is configured through your application settings.
The browser starting on BB6 uses a special transport (not available to apps) that basically does the equivalent of a DNS lookup and follows logic to see how the endpoint can be accessed. It will then route over the transport that will get to its endpoint.
So in the browser, it is detecting that your IP address isn't public and re-routing over the direct TCP/IP connection to go directly to your local server.
In a BlackBerry App you must declare your transport order list which it will try and failover to the next if it can't be reached on the first transport.
In a WebWorks application the default transport order is BES, BIS-B, TCP_WIFI, TCP_CELLULAR, WAP2, WAP
More info on the transport in WebWorks here:
In your case, you would have to change the order of put TCP_WIFI first. WARNING: Different transports have different failover times. BIS-B and BES will instantly failover if they are not activated with that service. TCP_WIFI will actually do a connection timeout before failing over. So if you don't have a WiFi connection it will timeout on each resource request before it then tries BIS-B.
So it comes down to what you want your application to be able to do. If it is going to access public IPs then you will want to keep the default transport order. If you want it to be able to discover both local and public IPs then you'll have a bit more work to do.
06-22-2011 07:15 PM
Tim! thanks man, that was the answer , just changed the transport order. I am thinking about playing with the transport order and timeout value for each request to cover failover:
config Transport order
And for each request in code put a higher timeout value ie. 30 ms
The other alternative is try to fight it with code, but it is possible with the identity API?, I´m looking at the Transport section.
I'll run some tests and post the results. To be continued...