Glad to hear it worked for you! That's interesting, I purchased my screw terminal connector from the exact auction you linked to so I'd assume they're the same. I'll have to look at my other QSEs to see if they all have the same tiny center pin as the one I tested.
QUATECH ThinkQ QSE-100D-BA 4 Port RS-232 Serial Server (CHEAP!)
- Thread starter electron
- Start date
Glad to hear it worked for you! That's interesting, I purchased my screw terminal connector from the exact auction you linked to so I'd assume they're the same. I'll have to look at my other QSEs to see if they all have the same tiny center pin as the one I tested.
Dan Electron,
It wont make any difference if you test it remotely using another laptop, its the MAC address of the router NOT the MAC address of the PC that may somehow been stored in NVram inside the Quatech itself. The drivers are additonal considerations not primary.
The manual mentions that NVram is being used during the installation and specifically warns against doing any future "hard resets".
change your router or do a 30 second "hard reset" to the Quatech (pin in rear); This is the ONLY way to confirm how the intial negotiation session is stored. The drivers are just part of the process;
until you have tried that your observations are meaningless. You have to "purge" the thing to see if you can reconnect to it remotely again...my guess is you wont be able to, despite knowing in advance the Gateway and all the unique IP address from the "remote" home network
This is what we need to know: how the installation session is permanantly married-stored and where.
It wont make any difference if you test it remotely using another laptop, its the MAC address of the router NOT the MAC address of the PC that may somehow been stored in NVram inside the Quatech itself. The drivers are additonal considerations not primary.
The manual mentions that NVram is being used during the installation and specifically warns against doing any future "hard resets".
change your router or do a 30 second "hard reset" to the Quatech (pin in rear); This is the ONLY way to confirm how the intial negotiation session is stored. The drivers are just part of the process;
until you have tried that your observations are meaningless. You have to "purge" the thing to see if you can reconnect to it remotely again...my guess is you wont be able to, despite knowing in advance the Gateway and all the unique IP address from the "remote" home network
This is what we need to know: how the installation session is permanantly married-stored and where.
damage
Senior Member
just ran wireshark. the udp packet is a broadcast packet which will be dropped by the local router so simple port forwarding won't work.
sdeens, please reread my post. I didn't use the router, there is no 'remote' networking involved. This QSE was plugged into a new laptop it had never seen before, with a direct Cat5E connection, there was NO router involved, and it still worked.
Damage: I ran wireshark as well, but I am talking about trying to find a remote QSE, not one on the local subnet (which explains why you saw the broadcast and I didn't).
Damage: I ran wireshark as well, but I am talking about trying to find a remote QSE, not one on the local subnet (which explains why you saw the broadcast and I didn't).
If I might make a suggestion, perhaps you should brush up on your knowledge of drivers, networking, and TCP/IP in general before you call someone's observations meaningless. You might be over-thinking the problem a bit as there's nothing wrong with Dan's logic so far. I am also able to connect to a serial port remotely, from both within a corporate environment as well as from across a 3G link.
Steve
Senior Member
I have not commented because I don't claim to know that much about networking, but calling someones observations "meaningless" is a bit harsh, especially for a new member. Those of us that know and support Dan for many years know he is seldom wrong about network issues and even if he were, doesn't deserve that kind of tone, especially for how hard he works for this community.
If this were open for bets, I'd put all my chips on electron
I really think/hope there is a misunderstanding here somewhere, but hopefully we'll know soon once he responds with an update from tech support.
That said, if you have a PC running on both networks, maybe you could consider trying the Leaf Networks (similar to Hamachi, but free) product, it would avoid the whole port forwarding mess. I do still recommend implementing a site-to-site VPN solution whenever you want to connect 2 networks over the internet.
That said, if you have a PC running on both networks, maybe you could consider trying the Leaf Networks (similar to Hamachi, but free) product, it would avoid the whole port forwarding mess. I do still recommend implementing a site-to-site VPN solution whenever you want to connect 2 networks over the internet.
How secure is the Leafs Networks? If I use this product to get the Quatech up and running and have a pc going, I also thought of putting an extra HD or two in the machine and use it as off site backups.
Leafs Networks has been around for a while, received tons of positive press, so I'm sure they are as secure as typical Hamachi/LogMeIn connection, but I haven't researched it yet. I plan on playing with this service once I have some time, it has potential.
Dan
"sdeens, please reread my post. I didn't use the router, there is no 'remote' networking involved."
I re-read your post four times, but what is NOT clear is: was your test remote from say 10 miles away via the internet and not via a direct local CAT-5 connection? NOT interested in local tests but ONLY remote ones from 2nd or 3rd part routers...That is what Gary Mull was also telling you.
REMOTE means 90 miles away in our case thru a 3rd router and ONLY tests involving a hard reset to ascertain the marriage of the QUATECH involved.
We need to know ONLY (repeat ONLY), if it can negotiate TCP or UDP packets remotely thru a different router (not the original one it was first configured with); otherwise its uselss to us from a remote UDP packet managment perspective.
That is what the manual suggests is the problem and that is why I asked you to do the "hard rest" three times to see if it invaldates the marriage to your orginal router. My guess is you will NOT be able to see it 10 miles away (must be outside via internet) and ONLY remotely via the internet using any PC connection. But it has to be tested outside the local Gateway only...NOT INSIDE behind the router using cat-5 direct connections
This scenario and ONLY this scenario is EXACTLY what Gary Mull and I BOTH are trying to evaluate. Its remote access thru 3rd party routers it has NEVER seen is what we are really interested in and ONLY interested in.
I will get the REAL answers about its REMOTE accesibility from TECH SUPPORT if they answer the phone...but its looks like its very limited and a driver update will NOT fix somethign perhaps the logic board is NOT desgined to accomodate.
I don't think you guys understand what Gary Mull and I have observed and are asking...
we are BOTH it seems trying to run applications for UDP remote managment thru the 3nd party unmarried router 90 miles away (the one it was NEVER been married to and has NEVER seen before)..so far it looks like it can NOT do that.
and that is why a HARD RESET will at least narrow down any marriage issue that could be involved here.
and we can later worry about doing "site to site VP tunneling" solutions, but ONLY after we first know what it can do natively and what remote UDP capablitites it supports...
This QUATECH is 4 year old hardware technology from 2005 before all this VP tunneling was standarized inside these newer routers such as the new D-link : D-615
so it may NOT truly support remote management of UDP via any tunneling and the manual is vague on this point. I read every word of it,
"sdeens, please reread my post. I didn't use the router, there is no 'remote' networking involved."
I re-read your post four times, but what is NOT clear is: was your test remote from say 10 miles away via the internet and not via a direct local CAT-5 connection? NOT interested in local tests but ONLY remote ones from 2nd or 3rd part routers...That is what Gary Mull was also telling you.
REMOTE means 90 miles away in our case thru a 3rd router and ONLY tests involving a hard reset to ascertain the marriage of the QUATECH involved.
We need to know ONLY (repeat ONLY), if it can negotiate TCP or UDP packets remotely thru a different router (not the original one it was first configured with); otherwise its uselss to us from a remote UDP packet managment perspective.
That is what the manual suggests is the problem and that is why I asked you to do the "hard rest" three times to see if it invaldates the marriage to your orginal router. My guess is you will NOT be able to see it 10 miles away (must be outside via internet) and ONLY remotely via the internet using any PC connection. But it has to be tested outside the local Gateway only...NOT INSIDE behind the router using cat-5 direct connections
This scenario and ONLY this scenario is EXACTLY what Gary Mull and I BOTH are trying to evaluate. Its remote access thru 3rd party routers it has NEVER seen is what we are really interested in and ONLY interested in.
I will get the REAL answers about its REMOTE accesibility from TECH SUPPORT if they answer the phone...but its looks like its very limited and a driver update will NOT fix somethign perhaps the logic board is NOT desgined to accomodate.
I don't think you guys understand what Gary Mull and I have observed and are asking...
we are BOTH it seems trying to run applications for UDP remote managment thru the 3nd party unmarried router 90 miles away (the one it was NEVER been married to and has NEVER seen before)..so far it looks like it can NOT do that.
and that is why a HARD RESET will at least narrow down any marriage issue that could be involved here.
and we can later worry about doing "site to site VP tunneling" solutions, but ONLY after we first know what it can do natively and what remote UDP capablitites it supports...
This QUATECH is 4 year old hardware technology from 2005 before all this VP tunneling was standarized inside these newer routers such as the new D-link : D-615
so it may NOT truly support remote management of UDP via any tunneling and the manual is vague on this point. I read every word of it,
AceCannon
Active Member
Update
So my two cheap Hong Kong PlayStation power supplies have been retrofitted with screw terminal plugs and both power up.
I plugged the first one in to my cheapo Ebay'd 24port switch, could not find the IP address in my routers web-based setup. The Quatech was apparently still configured with the previous owner's IP address.
Ran the Windows "driver" software from Quatech (link) qtewizard.exe which quickly found the Quatech despite its IP address which did not fall into my LAN's subnet. Was easily able to tell it to get an IP from my routers DHCP server.
Then I could see the IP address from the routers webpage. Went to the Quatech's web server and it offered to do the firmware upgrade. I was 4.xx, so I upgraded to 4.26 without an issue using the appropriate file.
Repeated the process with my second Quatech. Windows device manager now shows my new COM9 through Com16. Ran the Nuvo Configurator and was able to transfer data with no problem through both Quatech's to the Nuvo Grand Concerto (connected each one separately, ran two separate test transfers).
Overall, I would say this was pretty easy for me, and I would consider myself fairly LAN not-savvy.
So my two cheap Hong Kong PlayStation power supplies have been retrofitted with screw terminal plugs and both power up.
I plugged the first one in to my cheapo Ebay'd 24port switch, could not find the IP address in my routers web-based setup. The Quatech was apparently still configured with the previous owner's IP address.
Ran the Windows "driver" software from Quatech (link) qtewizard.exe which quickly found the Quatech despite its IP address which did not fall into my LAN's subnet. Was easily able to tell it to get an IP from my routers DHCP server.
Then I could see the IP address from the routers webpage. Went to the Quatech's web server and it offered to do the firmware upgrade. I was 4.xx, so I upgraded to 4.26 without an issue using the appropriate file.
Repeated the process with my second Quatech. Windows device manager now shows my new COM9 through Com16. Ran the Nuvo Configurator and was able to transfer data with no problem through both Quatech's to the Nuvo Grand Concerto (connected each one separately, ran two separate test transfers).
Overall, I would say this was pretty easy for me, and I would consider myself fairly LAN not-savvy.
beelzerob
Senior Member
What do you mean by "it offered"? I haven't updated the firmware yet, but I assumed that it was just like all others...go the manufacturers website, download the firmware updater, run it, etc. You make it sound like it's a little more automated than that. (which would be great!)
AceCannon
Active Member
Enter Quatech device's IP address in browser. One of the resultant menu choices is to update the firmware. You then point it to the firmware file you have already downloaded from the manuf website and the deed is done.
It is plenty easy.
The only thing I initially puzzled over was finding the IP address. I figured my router would "DHCP it" an address right off, but it held onto the old address from the previous owner. The first thing to do is plug it into the LAN, then run the "Driver" utility and the Quatech will be found regardless its IP address. (as has already been mentioned here by others... sorry to potentially be redundant).
