MapTool Dev Build (testing, version 0.95) - Jan. 28, 2012

[jfrazierjr]

@jfrazierjr Good points. It just goes to show what little interaction I've had with Apple products in the past 5-7 years. In jest, if a person REALLY loves MapTool, what better time to get a new Mac :lol? What remains, though, is what to do with the FTP disparity between 6 and 7, w/o having to go into the Java library itself just to keep MT running in 1.6.

I don't believe Apple provides J7 at all; a user would have to go to a third-party source to get it and that's not what most Apple users will expect. For Windows people, getting drivers from multiple different sites, applications from other sites, and languages from yet other sites is just par for the course.

Well.. that is true now, but until J7 that was not the case. However, this really has nothing to do with the fact that Apple's incessant tweaking of their OS means there is no backwards compatibility from version to version with Java versions. It is patently ridiculous that I can't have a Mac with 10.6(released 4.5 years ago) and still get Java 7 while I could have Windows XP(released 10 YEARS ago) and get Java 7... all because Apple won't make backwards compatibility a requirement.

[Lee]

@Azhrei About J7 in OS X, I think it's available. I came across Apple recently actively encouraging users to not have older, non-Oracle versions in the system, doing a plug-in scrub sometime back in October, and synchronizing with the last Oracle release. If we want to keep parallel compatibility with Java 6 and 7, the only section of the MT code barring that, I think, are the FTP classes. So it may be possible to solve this by using the OpenJDK version. Since tiorthan wrote a more comprehensive implementation of the offical library, I didn't really look beyond the surface level of the OpenJDK, though he did mention the same thing when he was working on it.

@Sol: jfj's right, it's likely because of a differently written URN, a difference problem that's prevalent because router manufacturers made their own "interpretations" of implementing UPnP, so we see spaces, parentheses (or lack of), even blank xml files as in my old router. In the query used to search for devices, the sbbi-lib uses a direct string of "urn:schemas-upnp-org:device:InternetGatewayDevice:1", whereas cling has regex pattern that translates to "urn:(schemas-upnp-org):device:(InternetGatewayDevice):(1)". This might explain why your device fared well in the old library but couldn't provide necessary device details in cling.

I'll amend the pattern in cling to allow for both and will try to get it up later today. Let me know if it succeeds when you test it

Edit: Oh and please sdo as jfrazierjr suggested and go to 192.168.2.1:80/igd.xml and 192.168.2.1:80/wcn.xml and put a spoiler note containing what comes up if its not blank. I PM'd a test file for you to try discovery through service type instead of device. Hopefully, the schema is better formed and returns correctly.

[Sol Invictus]

Argh!

HULK ANGRY!
In an attempt to update the router's firmware, I kind of broke it. I will only be able tomorrow to talk to people with physical access to it. And I don't even know if they will be there at all.
Well, there is one hint to why the cling library might not have worked: The router's firmware indeed was terribly outdated.
It's funny, because the router was only installed a few months ago. Well, I'll get back to you once the router is running again.

Since I don't know when this might be, maybe only next week, I guess it will be best to assume that the problem with the cling library will be solved with the new firmware - once it's there.

[Lee]

Ow. I'm sorry to hear that. Try doing ipconfig on the command prompt. If you're getting a value for default gateway, try going to that address, it might have changed during firmware updating. you can also try checking later if the router becomes responsive; sometimes an update can be lengthy depending on the model.

[Sol Invictus]

Almost good news: @Lee, you were right, the update just took all night. The firmware is up to date now.
Bad news: Neither the device detection based UPnP of the latest build nor the service detection based build you sent me are working.
Here the details of the service detection based UPnP Dev build:

Debug Info

==== MapTool Information ====
MapTool Version: DEVELOPMENT
MapTool Home...: C:\Users\Conrad E. Neubert\.maptool
Max mem avail..: 247M
Max mem used...: 31M

==== Java Information ====
Java Vendor.: Oracle Corporation
Java Home...: D:\Programme\Java\jre7
Java Version: 1.7.0_09
............: Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
............: Java HotSpot(TM) Client VM (build 23.5-b02, mixed mode, sharing)


==== OS Information ====
OS Name........: Windows Vista
OS Version.....: 6.0
OS Architecture: x86
Processor......: x86 Family 6 Model 23 Stepping 6, GenuineIntel
PATH...........: null
Number of Procs: 2

==== User Information ====
User Name: Conrad E. Neubert
User Home: C:\Users\Conrad E. Neubert
User Dir.: D:\D&D\testing\MapTool_Dev 0.45 (cling version - search by service)

==== Network Interfaces ====
Display Name..: Software Loopback Interface 1
Interface Name: lo
Address...: 127.0.0.1
Address...: 0:0:0:0:0:0:0:1

Display Name..: Intel(R) WiFi Link 5100 AGN
Interface Name: net3
Address...: 192.168.2.108
Address...: fe80:0:0:0:605a:380aa71%11

Host Address...: 192.168.2.108
Default Gateway: 192.168.2.1

==== Locale Information ====
Country.: Deutschland
Language: Deutsch
Locale..: Deutsch (Deutschland)
Variant.:

==== Display Information ====
Number of Displays: 1
Display 1: 1280x800(32)

==== Internet Gateways ====

console output UPnP server setup fail

There is no other setting I need to enable on the router to make that work, right? The router does have an "Intrusion Detection Feature", would I need to switch that off? I am kind of hesitant to do that.

[Azhrei]

[...] @Lee, you were right, the update just took all night. The firmware is up to date now.

Wow. It takes my routers about 6-8 minutes to do an update, including the reboot.

There is no other setting I need to enable on the router to make that work, right?

For most routers there's just the "Enable/Disable UPNP" setting. Of course, Google'ing "enable upnp <routermodel>" would probably clarify that.

I just installed the OpenWRT firmware on one of my TP-Link routers and had to manually install upnpd afterwards, but that wouldn't apply to your situation. (I usually use DD-WRT and it has UPNP support in the standard firmware.)

Thanks for helping with the testing, btw.

The router does have an "Intrusion Detection Feature", would I need to switch that off? I am kind of hesitant to do that.

No, don't turn that off! It only applies to the WAN port (the one attached to your ISP), not the LAN ports or wireless connections. Changing it wouldn't have any effect anyway.

[Lee]

Edited:
@Sol Good to hear about your router. Could you test 192.168.2.1:80/igd.xml on your browser and see if it shows content? You might as well try pulling up 192.168.2.1:80/UPNP_WANIPConnection.xml and 192.168.2.1:80/UPNP_WANPPPConnection.xml as well. It may not be because of a different URN that you aren't seeing anything; the querying might be correct but the files being looked for by cling (i.e. igd.xml) isn't there because the manufacturer chose to implement otherwise.

@Azhrei at this point, I'd like to ask before going through the process of injecting stuff into the actual cling library, would it be better instead to setup the 2 UPnP libraries instead and either offer a choice of which one to use to the user during the event of server instantiation/debug info gathering or chain the 2 together, where the older library does a search after the newer one fails at retrieval?

I ask because, due to some of the arbitrary ways older router implemented UPnP 1.0, we can't predict what else is out there that needs a handling pattern to properly retrieve their internal information. Perhaps it would be better to cater to routers based on a period before and after 2008 (the end of sbbi-upnp, I believe).

[Azhrei]

would it be better instead to setup the 2 UPnP libraries instead and either offer a choice of which one to use to the user during the event of server instantiation/debug info gathering or chain the 2 together, where the older library does a search after the newer one fails at retrieval?

Ugh. I would rather not that the user had to choose, but then I'd rather not have to carry around the baggage of both implementations.

The problem you've seen (correct me if I'm wrong) is that various routers' implementation of the UPNP spec can be different, causing library A to work for router 1 but not router 2, and library B to work for a router 2 but not router 1? Do I have that right?

Hm. Under those circumstances I don't see any way to support all possible routers without including all libraries.

I suppose if we're going to force people to use the latest Java we could force them to use the latest UPNP standard, but it's not nearly as easy for a user to upgrade router firmware (!) as it is to download a newer Java version. And newer firmware isn't a guarantee of an updated UPNP implementation anyway.

I say we go with the library that supports the most recent version of the standard and if it doesn't work, tell the user they will need to manually configure the router for port mapping. I want to avoid modifying the UI for something as low-level as choosing a UPNP library. If we added our own factory class we could put multiple libraries into a subdirectory and then try them all in order but that seems like more work than it's worth.

Your opinion?

[Lee]

I believe it's a problem of older router models with stock firmware. Newer models, or ones using well implemented 3rd party firmware, are likely to be better behaved.

We do have the option to just keep using sbbi-upnp as we've had a good track record with it regardless of the router make. I did do 2 builds for each library, so it wouldn't be a problem to switch out cling for ye olde faithful sbbi-upnp.

I suspect that during sbbi's life cycle, special contexts were created (or at least the base was extended) to barge through bad information and handle a bad implementation whenever someone came across the problem in their router and reported it. Whereas it is safe to assume newer models (also better 3rd party firmware), at this late stage of UPnP 1.0, will have adhered to a strict implementation of UPnP which makes them responsive to even the oldest UPnP library out there. It was proven by the last testing thread done where Sol's router, and my new router (released this year), were processed correctly.

A 2nd alternative would be for me to stop the cling service on a bad descriptor encounter and start up the old library, or vice-versa.

Edit: Speaking about the sbbi implementation, I saw a TODO in the UPnPUtil code to provide a list of IGD's to choose from when more than one is found. I put this in, but since you mentioned above that it wouldn't be good to make such a change to the GUI to give a user a choice of library, should I then delete what I put in (original code defaulted at IGD[0])?

[Sol Invictus]

I wasn't at home for the weekend, sorry for the late answer.
I did some research about my router and although it's not that old, everbody seems to be unhappy about it. :-/ Unfortunately other users didn't seem to get UPnP working on this router model properly either, at least for certain games and applications.
(Does anyone know btw whether switching the DMZ on or off will have any influence on UPnP?)

Could you test 192.168.2.1:80/igd.xml on your browser and see if it shows content? You might as well try pulling up 192.168.2.1:80/UPNP_WANIPConnection.xml and 192.168.2.1:80/UPNP_WANPPPConnection.xml as well.

It did show content for the first adsress (http://192.168.2.1/igd.xml). Do you need me to post that content?
But for http://192.168.2.1/UPNP_WANIPConnection.xml and http://192.168.2.1/UPNP_WANPPPConnection.xml it just gives me the "404 Not Found".

For what it's worth - my opinion on the whole UPnP thing:
Keep the program light, so it's easier to work on it for new supporters. You do not need to know a lot about computers to be able to manually forward a port. The disadvantage is only that it takes a little bit more time than UPnP. My situation where I needed to acquire permission to meddle with the router first is pretty unique. Plus, there is an easy workaround if UPnP doesn't work on the GM's router that does come natural: have one of the players host the server. That's what my group used to do before I got access to my router.
All in all: Use only one library, and make it the one that will cause the least problems until MT 1.4 comes out.

[Lee]

Yes, the page content would be helpful. It would help pinpoint which part is malformed/missing.

Of course, it's always better to use the simplest solution available. The UPnP goal for MT should be to provide something that universally works, or as close to universal as possible. For the user, when a message of UPnP mapping fails, it should mean that the router isn't capable at all. For the developer, the choice of what to use means that it should be something that he/she can drop in and forget about for a reasonable amount of time.

I did some reading on it and I was correct to find that sbbi did put hacks in to deal with bad descriptor instances, whereas cling, as evidenced by their design "motto", is very strict in adherence to UPnP 1.0 standards. There IS a cling fork made by one of its main contributors; this fork apparently was made with hacks put in to deal with devices such as yours. What I don't know is if changes made there would eventually find its way back to the main branch, or if development will always run parallel to the main branch as time goes by.

Advantages for using the sbbi library is that the hacks are available without compiling a new library. Any 1.0 device now and in the future would, theoretically, respond to it unless some manufacturer introduces a new brand of stupid into the environment. The advantages for cling are that it's current, better made, and designed with multiple device types (e.g. Android) in mind - something that might be attractive for MT 1.4; while sbbi can also do the same things, integration doesn't seem to be as evident as in cling.

Edit: I forgot to mention that I dropped a note asking the things I mentioned above regarding the fork. I've yet to hear back from the author, so it's a wait-and-see.

[wolph42]

So to put my endless optimism into play: what's the ETA? I know that that's Azh call but I assume that he's checking out this thread occasionally as well. As for me. I've toyed around with the test build and did not run into any issues so that's promising. I have a game next Saturday which I'm considering running in your test build but then I would like to know whether b89 will be compatible with your test version?

[Lee]

That's good news indeed wolph. I'm afraid that I'm not privy to the ETA. As for compatibility, it depends. If the core devs accept the general fix for path/token location, then yes. If not, then it would end up being incompatible. The change to the Token model will definitely trigger a version difference. However, since I didn't look into detail on how MT enforces "versioning", it might be that a higher build # would allow the difference and make the conversion to b89 standards on save. Hopefully, that will be the case. We'll have to ask Azhrei about it to know for sure.

With the pertinent questions asked by Azhrei on that particular bug thread, it's fair to assume that my approach was pervasive and he'd prefer something that was less so. I'll admit that it isn't the perfect solution, but it's probably the best that can be done to get the most "bullet points" while working with what MT gives to work with. Honestly, I won't be able to pull out the first, and simplest, fix I made for it since I didn't back it up. There were so many twists and turns to get to the latest version that I have lost all idea how I got the first one working. So it means that if it's not accepted, we'll revert back to most of the bugs mentioned in that thread, and someone else will have to work on a fix for it as it's a headache I don't want to revisit

[wolph42]

Thanks for the heads up. Now let's wait for the verdict

[Sol Invictus]

Yes, the page content would be helpful. It would help pinpoint which part is malformed/missing.

I sent you a pm with the file. Hope it helps. I have a bad conscience though because I make you work so much on my router's particular problem.