none
what ports does Bing Maps use

    Question

  • I cannot view Bing Maps with my cell phone service provider.  Whether using my phone or tethering with my laptop the page will load, I get the functions and they seam to be working however the images do not display.  I was thinking that maybe Bing uses a certain port or uses an ip address that is different then that used by Bing.  Anyone know?
    Sunday, April 21, 2013 10:03 PM

Answers

  • I was able to briefly look over your capture log and as expected there's a lot of data in there. So rather than go through all of it, I think it might help you more if I outlined some key things to look for.

    The capture log is (by default) sorted by time in ascending order, and each line has an associated chronological (frame) number, which is the first column on the left entitled 'No.' and starts with 1. Whenever a request is made to access a URL resource (like dev.virtualearth.net), that FQDN needs to be associated with an IP address. Once that's done, your network stack then makes a connection to that IP and the desired port on the destination system (like port 80). The first time a connection is attempted a DNS request must occur (destination port 53) to get the FQDN's IP. As a side note, in order to do a good structured capture and test, I would recommend that you first clear out your computer's DNS resolver cache to ensure an actual DNS lookup is performed while capturing. To do this go to a cmd prompt and type: ipconfig /flushdns

    Let's start by examining some lines. If you look at frame 577 you will see a DNS request for 'dev.virtualearth.net'. If you click it and look through the packet details window just beneath (the white window), you will notice a line that says 'Reponse In: 671'. Now go to frame 671 and look through its packet details window, and you'll see the IP for the resource it's trying to access:

        dev.virtualearth.net: type CNAME, class IN, cname platform.maps.glbdns.microsoft.com
        platform.maps.glbdns.microsoft.com: type A, class IN, addr   70.37.130.200

    So here the IP is 70.37.130.200 (note that in some cases it could map to multiple IPs in which case you would see multiple type 'A' record lines)

    Now jump to frame 825 and you will see your actual HTTP REST request (to the above IP) for your coordinates. Sifting through the packet details window, you'll also see the destination port which it's trying to connect to at that IP, which in this case is port 80. Also notice the source port on your computer which in this case is 35470.

    Now scroll down to frame 858 and you'll see the reply from 70.37.130.200 (with a source port of 80) TO your IP of 10.0.0.2 at port 35470.

    This process is contingent on a few things:

    1) Successful ability to do a DNS lookup
    2) Successful ability to connect to the destination IP and Port (which in this case is 80)
    3) Successful ability for the destination system to connect back to your source port (which in this case is 35470)

    Side note: The Windows firewall and almost all home wifi routers these days are stateful, which for our purposes here means they'll allow the remote traffic back to your machine because the firewall knows your machine initiated the connection in the first place (unless there's an explict rule saying not to). If you're running a stateless packet filtering type thing, then that's a different story.

    Anyway, if an IP/Port was unreachable then the frame line would have a black background and say something like 'DESTINATION UNREACHABLE' - see frame 1305 as an example (note that this is not a problem here since it's just an ICMP packet in this case). So if you see a line like that, and the protocol is HTTP, TCP, or DNS, then that would likely indicate a problem somewhere upstream.

    Remember that the IPs in your capture, may not be the same IPs accessed when using the cellular connection, or even the same if you run it again immediately after. Point is that you'll need to run a capture on your laptop while tethered to see what's actually transpiring.

    Let me know how you make out and good luck.

     

    Friday, April 26, 2013 4:57 AM

All replies

  • The Bing Maps platform uses a large number of IP ranges which consist of several hundred IP addresses. If the issue is at your phone service providers end there isn't a whole lot you can do about it. If this was an issue on your own network or on a corporate network you and were an Enterprise Bing Maps customer then you could contact the Bing Maps Enterprise Support team who would be able to provide you with the list of IP ranges for Bing Maps.

    http://rbrundritt.wordpress.com

    Monday, April 22, 2013 9:23 AM
    Owner
  • To help narrow down the issue, does your phone display the images if you're using WiFi instead of cell service? If not, then what if you disable the cellular service on the phone (like 'airplane mode' or something) and just enable WiFi then try?

    Monday, April 22, 2013 6:43 PM
  • Works fine with wifi.  I was hoping to find out what port or ip address is used so I could do some testing of get in touch with my provider to resolve the problem.
    Tuesday, April 23, 2013 11:53 PM
  • I see,,, well short of someone providing you with that info, you might have to go about this the hard way.

    Just to be sure we're on the same page here, I'm assuming you wrote some application for your phone using the Bing maps control or API, and that it runs as expected (i.e. you can see the image and such) in the emulator on your laptop when connected to the WiFi, and that it also runs properly on your phone when connected to the WiFi, but fails on both when connected using cellular.

    And so barring an easier solution, I might try sniffing the traffic with Wireshark.

    Since you indicated that when you tether your laptop to the phone using the phone's cellular connection, it behaves in the same manner (i.e. no image, but things like geocoding work), then I would start by connecting the laptop to your WIFI (which does work properly), run Wireshark on it to capture the traffic, and then run the application in the phone emulator. Then afterwards look through the captured traffic to see what's going on. Although the IPs won't necessarily always be the same (since as Richard indicated there are hundreds) it'll give you somewhere to start.

    I'd also do the same capture process by tethering the laptop to the phone but this time using the phone's cellular, instead of WiFi. 

    If you haven't used Wireshark before, then you'll have to spend a little time figuring it out, especially how the filtering works so that you can configure it to filter out the unwanted elements (like arp requests and such). Otherwise parsing through the captured traffic could be a real nightmare. 

    I'm usually able to solve a lot of problems like this using things like Wireshark and Fiddler (another great tool).

    Tom

    Wednesday, April 24, 2013 2:27 AM
  • I did as you said however I am not really sure how to read the data so here is a link to the file. If you don't mind I was wondering if you could have a look at it. If in Wireshark format.

    Thanks


    • Edited by Bandito40 Wednesday, April 24, 2013 8:37 PM
    Wednesday, April 24, 2013 2:40 PM
  • Okay I'll see if I can take quick look at it later today, however in the interim you should probably edit your post to remove the link now, because it may have your map key embedded in it and perhaps some other sensitive info as well. You might also want to remove the file from google docs.

    Wednesday, April 24, 2013 4:27 PM
  • Link removed.  Thanks for your help.
    Wednesday, April 24, 2013 8:37 PM
  • I was able to briefly look over your capture log and as expected there's a lot of data in there. So rather than go through all of it, I think it might help you more if I outlined some key things to look for.

    The capture log is (by default) sorted by time in ascending order, and each line has an associated chronological (frame) number, which is the first column on the left entitled 'No.' and starts with 1. Whenever a request is made to access a URL resource (like dev.virtualearth.net), that FQDN needs to be associated with an IP address. Once that's done, your network stack then makes a connection to that IP and the desired port on the destination system (like port 80). The first time a connection is attempted a DNS request must occur (destination port 53) to get the FQDN's IP. As a side note, in order to do a good structured capture and test, I would recommend that you first clear out your computer's DNS resolver cache to ensure an actual DNS lookup is performed while capturing. To do this go to a cmd prompt and type: ipconfig /flushdns

    Let's start by examining some lines. If you look at frame 577 you will see a DNS request for 'dev.virtualearth.net'. If you click it and look through the packet details window just beneath (the white window), you will notice a line that says 'Reponse In: 671'. Now go to frame 671 and look through its packet details window, and you'll see the IP for the resource it's trying to access:

        dev.virtualearth.net: type CNAME, class IN, cname platform.maps.glbdns.microsoft.com
        platform.maps.glbdns.microsoft.com: type A, class IN, addr   70.37.130.200

    So here the IP is 70.37.130.200 (note that in some cases it could map to multiple IPs in which case you would see multiple type 'A' record lines)

    Now jump to frame 825 and you will see your actual HTTP REST request (to the above IP) for your coordinates. Sifting through the packet details window, you'll also see the destination port which it's trying to connect to at that IP, which in this case is port 80. Also notice the source port on your computer which in this case is 35470.

    Now scroll down to frame 858 and you'll see the reply from 70.37.130.200 (with a source port of 80) TO your IP of 10.0.0.2 at port 35470.

    This process is contingent on a few things:

    1) Successful ability to do a DNS lookup
    2) Successful ability to connect to the destination IP and Port (which in this case is 80)
    3) Successful ability for the destination system to connect back to your source port (which in this case is 35470)

    Side note: The Windows firewall and almost all home wifi routers these days are stateful, which for our purposes here means they'll allow the remote traffic back to your machine because the firewall knows your machine initiated the connection in the first place (unless there's an explict rule saying not to). If you're running a stateless packet filtering type thing, then that's a different story.

    Anyway, if an IP/Port was unreachable then the frame line would have a black background and say something like 'DESTINATION UNREACHABLE' - see frame 1305 as an example (note that this is not a problem here since it's just an ICMP packet in this case). So if you see a line like that, and the protocol is HTTP, TCP, or DNS, then that would likely indicate a problem somewhere upstream.

    Remember that the IPs in your capture, may not be the same IPs accessed when using the cellular connection, or even the same if you run it again immediately after. Point is that you'll need to run a capture on your laptop while tethered to see what's actually transpiring.

    Let me know how you make out and good luck.

     

    Friday, April 26, 2013 4:57 AM
  • Hi Ricky, is there a subset EMEA IP Range for dev.virtualearth.net that is published , I've come across a firewall that doesn't work with FQDN's and need the IP Ranges.

    Thanks


    MS CRM Bing'd - http://bingsoft.wordpress.com
    Dynamics XRM Tools CRM 4 to CRM 2011 JavaScript Converter Tool
    CRM 2011 OData Query Designer
    CRM 2011 Metadata Browser
    CRM Forum Guidance

    Friday, November 08, 2013 9:40 AM
  • For security reasons the IP ranges are not published publically. The best way to handle fire walls are to allow "virtualearth.net" rather than the individual IP ranges as new IP addresses are added regularly.

    http://rbrundritt.wordpress.com

    Friday, November 08, 2013 9:47 AM
    Owner