SC->repeater->LViewer call without using IDs. Possible?

[Dadooda]

Hi UltraVNC team and forum members.

I need to run a multiple set of SC servers connecting to a fewer number of listening viewers residing in my local net with known local IPs.

What I need is something similar to "repeater mode 1" but for SC-LViewer invocation.

So, SC command line is expected to be something like:

-proxy public.ip.isp.com -connect 10.0.0.1

, with public.ip.isp.com being the public entry point for all SC calls and 10.0.0.1 being the private IP of listening viewer.


While I haven't yet carefully examined UVNC source code, I suppose that wouldn' take much effort to implement that kind of, say "repeater mode 3". I'd even attempt to do that if someone who is already aware of UVNC internals confirmed that that's feasible and will not require radical code changes.

Please let me know if that kind of operation is implementable.

[mod=494,1234013692]added sticky[/mod]

[redge]

not yet exist as my knowledge.
nice and great idea for repeater usage for match hostname/ip instead use ID

SC proxy mode I
moved to feature request

[Dadooda]

redge, can you briefly tell what's the protocol difference between forward (Viewer->Server) and reverse (SC->LViewer) call?

[redge]

no protocol change, only port change.
direct over 5900
reverse over 5500

vncviewer --- proxy 590x --- winvnc listen port 5900 + hostname/ip
winvnc --> proxy 550x ---> vncviewer -listen port 5500 + hostname/ip

like below
but replace port and inverse viewer and server position for SC to Lvncviewer
http://www.uvnc.com/addons/repeater.html#mode1

[Dadooda]

no protocol change, only port change.
direct over 5900
reverse over 5500

redge,

forgive me my stupidity. Does what you said mean that a working configuration may be produced right now by just swapping port numbers?

What about current SC which doesn't support -proxy option the way I described it? Shall I use winvnc -id 10.0.0.1 -connect public.ip.isp.com and direct it to repeater's port for incoming Viewer connections?

[redge]

Does what you said mean that a working configuration may be produced right now by just swapping port numbers?

No, I tested and it fail

What about current SC which doesn't support -proxy option the way I described it?

proxy missing for winvnc, allow reverse connection with mode I
ID is for mode II, both (client and server) made outgoing connection

winvnc -id 10.0.0.1 -connect public.ip.isp.com

the actual id do not support other than ID:12345678 full number
winvnc -proxy repeater_ip:port -connect hostname:port

anyway, the repeater must be on the lan where all vncviewers are on internet dmz if you
PC that runs the Repeater has access to the local DNS server, you can use your local DNS names instead of 10.10.10.12.
This could be handy when you have a dynamic DHCP server allocating ip addresses for your PC[/quote]

[Sainsuper]

hi dadooda,
hi think that you don't need the repeater feature for your network
the repeater you are thinkinsg is like a port forwanding
if you have your public ip (with public dns) and more vnc listen the easy way is use a different port for each vnc viewer in listen mode
for example:
in th sc you have:

[HOST]
test1
-connect public.ip.isp.com:5500

[HOST]
test2
-connect public.ip.isp.com:5501

in your network you redirect port 5500 on 10.0.0.1 and port 5501 on 10.0.0.2

so you must start vncviever -listen 5500 on pc with ip 10.10.0.1 and
vncviewer -listen 5501 on pc with ip 10.10.0.2

i hope to help you
sainsuper

[Dadooda]

Sainsuper

hi think that you don't need the repeater feature for your network ...

I think I *DO* need a repeater since I want to share a single port which isn't blocked by destination by local admins of users I'm willing to help.

There's a lot of networks that prohibit outgoing TCP calls to "suspicious" ports (meant: not known by their local administrators and thus being "insecure"). From my point of view that's silly, but that's how it is.

So the idea is to open a listening VNC repeater on port known to everyone (say, 80 or 443) and then share it among remote assistants with the help of virtualisation implemented in an application level protocol.

[Matts]

This would be a great feature !!

Adding some extra unique string would be even more nice !

Any news about this yet ?

[Dadooda]

This would be a great feature !!

I certainly agree with that, that's the reason why I've started this thread. But I see no solution so far.

Hope team members will consider this feature useful and implement it some way some time.

[Matts]

This would be a great feature !!

I certainly agree with that, that's the reason why I've started this thread. But I see no solution so far.

Hope team members will consider this feature useful and implement it some way some time.

I have made a topic some time ago where I suggested that you should be able to have some pool in the repeater where you can "chose" from or add some extra unique ID or IP as you suggest to this connectline.

This would made this much more usefull than it is.

Do you want to have it on the Linux repeater btw ?

[Dadooda]

I have made a topic some time ago where I suggested that you should be able to have some pool in the repeater where you can "chose" from or add some extra unique ID or IP as you suggest to this connectline.

This would made this much more usefull than it is.

Do you want to have it on the Linux repeater btw ?

I don't think that repeater itself is an issue. I think that modifying the application-level protocol to support such virtualisation is the most important task.

Repeaters will then follow.

[Matts]

Now the question remains... will they put it in ?

[elicro]

I wrote a whole new proxy\repeater which can give much more then just that and it's simple to implement it in the current proxy\repeater which gives you the option to connect a client by mouse click.