Using clink version 1.7, I am able to discover an IGD, but once I start the process of mapping ports, the IGD responds as OK, yet the mappings have different ports and the characters in the description come up as symbols/strange characters.
However in version 1.6.1 the mapping does so correctly. Are there any known issues with xml parsing/creation and 1.7?
I checked to be able to IGD devices in my home, and the control point can find out the device, Buffalo WZR-RS-G54HP.
Could you tell me your router model number ?
I will check if I can buy the model in Japan.
It happens on both BEFSR41 ver. 3 and ver. 4. I'm working right now on getting some debug output from 1.6.1 (works fine) and 1.7 (breaks). I'll probably be posting a reply with my findings this afternoon/evening...
It seems that I can but your router, BEFSR41,
at second about $100 in Japan.
I will buy it and check your problem :-)
Using BEFSR41 with the latest firmware, I checked that your problem.
However It seems that the latest CyberLink of the CVS server can control the some SOAP actions.
Please tell me your problem in more detail.
Could you build the latest package as the jar file for your check ?
hmm, ok, I've been testing with 1.6.1 and 1.7, I'll try to package the latest CVS and go from there. Sorry for the delay in response, but a power spike ripped through and killed a bunch of my PC's so I've been unable to do much testing as a result. Is your BEFSR41 version 3 or version 4? Just curious as I'm running across an different issue with version 4.
I can't get the V3 or V4, but I have the old version, V2 now.
ok, here's what I have so far. BEFSR41 ver. 4 router, and I've tried clink versions 1.6.1, 1.7 and checked out cvs. Both 1.7 and cvs are unable to accurately communicate with the router.
Stderr reports numerous connection reset errors, and after the discovery process, I am able to map one port, then the router is unable to be spoken to from the client. I cannot remove port mappings after the first mapping, which by the way is successful, but it takes a veeery long time to complete, as opposed to 1.6.1 which is fairly snappy.
I'm going to be testing a ver 3 router shortly. The ver 3 does not have the connection reset issues, but instead corrupts the mapping information (with debug on, I can't detect any anomalies within the packet dump).
If you would like I can send you verbose output, as well as a testing application and source code, however, I would prefer to send them directly as the output is in the pages, and the code isn't open (at least for the time being).
Just finished testing on BEFSR41 ver 3. The best way to explain this is to show what's happening.
clink 1.6.1 gives this output, doesn't miscommunicate, and is generally snappy:
clink 1.7.0 gives this output, does not handle subscriptions correctly, and is slower than 1.6.1:
In 1.7, it's corrupting the information somehow, yet as far as I can tell from the packet dumps in cyberlink debug, as well as a packet sniff, everything appears to be ok.
I understood your problem, I will check why the latest version is wrong and very slow.
Could you sent me your test application ?
Thanks for your report :-)
Let me revise my conclusions on the BEFSR41 ver 3... When I mentioned that I am able to create a mapping, it does create it on the router, but the client never gets the response, so the client continually tries to create new mappings, with no success.
I can't get the V3 or V4, but I have the old version
If you want, I'll have a ver 4 available within the week that I can ship to you for testing purposes.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.