Debugging the reason why your router cannot be found
Version 6 (Alan McGovern, 11/09/2009 01:11 AM)
| 1 | 1 | h1. Debugging the reason why your router cannot be found |
|
|---|---|---|---|
| 2 | 1 | ||
| 3 | 2 | Alan McGovern | The uPnP specification is (generally speaking) badly implemented by a lot of router vendors. There are so many different quirks that I've come across that it's very hard to say whether or not a specific router will work with Mono.Nat. For the cases where your router does not work, here's how to debug the issue. |
| 4 | 1 | ||
| 5 | 6 | Alan McGovern | If you are unable to debug the issue yourself, if you attach the verbose output of Mono.Nat to an email and send it to me, I should be able to offer some suggestions to get your device working. |
| 6 | 6 | Alan McGovern | |
| 7 | 2 | Alan McGovern | h2. Step 0: Enabling debug output |
| 8 | 1 | ||
| 9 | 2 | Alan McGovern | If you're running in a console application you can print debug information straight to the screen: |
| 10 | 2 | Alan McGovern | |
| 11 | 2 | Alan McGovern | <pre>NatUtility.Logger = Console.Out;</pre> |
| 12 | 2 | Alan McGovern | |
| 13 | 2 | Alan McGovern | If you want to log to a file, it's just as easy: |
| 14 | 2 | Alan McGovern | |
| 15 | 2 | Alan McGovern | <pre>NatUtility.Logger = new StreamWriter (File.OpenWrite ("logfile.txt"));</pre> |
| 16 | 2 | Alan McGovern | |
| 17 | 2 | Alan McGovern | If you fail to get past step 1 below, or just want all the debug output, you should enable verbose mode: |
| 18 | 2 | Alan McGovern | |
| 19 | 2 | Alan McGovern | <pre>NatUtility.Verbose = true</pre> |
| 20 | 1 | ||
| 21 | 1 | h2. Step 1: Detecting available services |
|
| 22 | 1 | ||
| 23 | 1 | In order to detect what services are available on the local network, a udp broadcast message is sent. There are two kinds of message: |
|
| 24 | 1 | # The 'tell me everything you support' message |
|
| 25 | 1 | # The 'respond if you support service X' message |
|
| 26 | 1 | ||
| 27 | 1 | Mono.Nat uses the 'tell me everything you support' style message. I haven't come across a router which has failed to respond to this, though there are some which fail to respond to the second type of message. If your router fails at this step, then this is probably why. Typical output from this step is a dozen or so copies of the following: |
|
| 28 | 1 | ||
| 29 | 1 | <pre> |
|
| 30 | 1 | UPnP Response: HTTP/1.1 200 OK |
|
| 31 | 1 | SERVER: Ambit OS/1.0 UPnP/1.0 AMBIT-UPNP/1.0 |
|
| 32 | 1 | EXT: |
|
| 33 | 1 | LOCATION: http://192.168.0.10:80/Public_UPNP_gatedesc.xml |
|
| 34 | 1 | CACHE-CONTROL: max-age=3600 |
|
| 35 | 1 | ST: upnp:rootdevice |
|
| 36 | 1 | USN: uuid:e346a71d-99ef-86a6-3222-e9ba2bb3dfa0::upnp:rootdevice |
|
| 37 | 1 | ||
| 38 | 1 | ||
| 39 | 1 | UPnP Response: HTTP/1.1 200 OK |
|
| 40 | 1 | SERVER: Ambit OS/1.0 UPnP/1.0 AMBIT-UPNP/1.0 |
|
| 41 | 1 | EXT: |
|
| 42 | 1 | LOCATION: http://192.168.0.10:80/Public_UPNP_gatedesc.xml |
|
| 43 | 1 | CACHE-CONTROL: max-age=3600 |
|
| 44 | 1 | ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 |
|
| 45 | 1 | USN: uuid:e346a71d-99ef-86a6-3222-e9ba2bb3dfa0::urn:schemas-upnp-org:device:InternetGatewayDevice:1 |
|
| 46 | 1 | </pre> |
|
| 47 | 1 | ||
| 48 | 1 | h2. Step 2: Getting the service listing |
|
| 49 | 1 | ||
| 50 | 1 | If your router advertises one of the three services that Mono.Nat assumes will allow port forwarding, you will see output similar to this: |
|
| 51 | 1 | ||
| 52 | 1 | <pre> |
|
| 53 | 1 | UPnP Response: Router advertised a 'urn:schemas-upnp-org:service:WANIPConnection:' service |
|
| 54 | 1 | Found device at: http://192.168.0.10:80/Public_UPNP_gatedesc.xml |
|
| 55 | 1 | Parsed device as: 192.168.0.10:80 |
|
| 56 | 1 | Fetching service list: 192.168.0.10:80 |
|
| 57 | 1 | </pre> |
|
| 58 | 1 | ||
| 59 | 5 | Alan McGovern | h2. Step 3: Parsing a service listing |
| 60 | 1 | ||
| 61 | 1 | The service listing contains the details required to connect to the upnp service on the router. If the listing can be retrieved and parsed, you'll see output similar to this: |
|
| 62 | 1 | ||
| 63 | 1 | <pre> |
|
| 64 | 1 | 192.168.0.10:80: Parsed services list |
|
| 65 | 1 | 192.168.0.10:80: Found service: urn:schemas-upnp-org:service:Layer3Forwarding:1 |
|
| 66 | 1 | 192.168.0.10:80: Found service: urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1 |
|
| 67 | 1 | 192.168.0.10:80: Found service: urn:schemas-upnp-org:service:WANIPConnection:1 |
|
| 68 | 1 | 192.168.0.10:80: Found upnp service at: /Public_UPNP_C3 |
|
| 69 | 1 | 192.168.0.10:80: Assuming control Uri is relative: /Public_UPNP_C3 |
|
| 70 | 1 | 192.168.0.10:80: Handshake Complete |
|
| 71 | 1 | </pre> |
|
| 72 | 1 | ||
| 73 | 6 | Alan McGovern | h2. Step 4: Your device has been found |
| 74 | 1 | ||
| 75 | 6 | Alan McGovern | Once the control Uri has been discovered, you will be passed the device via the DeviceFound event. You should store this object locally to avoid the time consuming process of detection every time you want to use it. Steps 1 - 4 can take anywhere between a few hundred milliseconds to 30 seconds to complete, though usually they will take less than 5 seconds. |
| 76 | 6 | Alan McGovern | |
| 77 | 6 | Alan McGovern | Some routers will not support all the available methods. For example not all routers will support listing all the existing mappings, others may not support retrieving the external ip address. If calling these methods throws an exception, it's not necessarily a Mono.Nat bug. However, sometimes it might be possible to work around the issue by applying a device-specific fix. If a method is failing for you but you think your router should support it, send me the exception and stacktrace and I'll see what I can do. |
| 78 | 1 | ||
| 79 | 4 | Alan McGovern | h2. Submitting patches so your router works without modifications |
| 80 | 1 | ||
| 81 | 1 | If your router requires a fix to be detected with Mono.Nat, please let me know and supply a patch with the required changes. I'll gladly incorporate any changes which increase compatibility with different router models. |