POP via ssh
Scott Evans
It seems a little clunky to work via tunneling but I guess that's
how any ssh widget has to work right now; is SSL support somehow
smoother? I notice that our mail server has a pop3s daemon (SSL)
that I could fire up, but I imagine you need SSL support build
in to your POP client then, as opposed to doing a tunnel.
Anyway. A comment: vm-setup-ssh-tunnel contains code to choose a
random port, then test it before using it. I understand the concept
but I wonder if there's a more elegant implementation. The current
implementation:
- Pauses for a little bit while trying to make the test connection.
Since this will pretty much always fail, it's slow.
- Throws up a *warning* buffer and echoes an error to the minibuffer
after the test connection fails. That's disconcerting -- it
always seems like the POP process didn't work, even when it does.
It seems like it would be cool to have a variable
vm-local-tunnel-port, defaulting to 5110 or whatever.
Though I guess that's my single-user-windowsness showing
through; if there's 5 people running on a multiuser Unix
box this wouldn't work to well. So, uh, any better ideas?
Kyle Jones
> This just became important to me, so I tried it out. Very cool!
> It seems a little clunky to work via tunneling but I guess that's
> how any ssh widget has to work right now; is SSL support somehow
> smoother? I notice that our mail server has a pop3s daemon (SSL)
> that I could fire up, but I imagine you need SSL support build
> in to your POP client then, as opposed to doing a tunnel.
You would need stunnel installed. Apparently under Windwos you
have to run it as a daemon, so you would have VM use a normal POP
connection that connected to the stunnel daemon. The daemon woul
encrypt and forward the data to the SSL-POP3 server.
> Anyway. A comment: vm-setup-ssh-tunnel contains code to choose a
> random port, then test it before using it. I understand the concept
> but I wonder if there's a more elegant implementation. The current
> implementation:
> - Pauses for a little bit while trying to make the test connection.
> Since this will pretty much always fail, it's slow.
It's supposed to be fast. A TCP port that has no listener should
reset the connection immediately, which should cause any
connection attempt to fail forthwith.
> - Throws up a *warning* buffer and echoes an error to the minibuffer
> after the test connection fails. That's disconcerting -- it
> always seems like the POP process didn't work, even when it does.
I've never seen this. VM isn't generating the warning so it must
be something int he guts of XEmacs. Maybe you should turn your
warning level down so that you don't see this message.
those who know me have no need of my name
>Scott Evans <g...@antisleep.com> wrote:
>> Anyway. A comment: vm-setup-ssh-tunnel contains code to choose a
>> random port, then test it before using it. I understand the concept
>> but I wonder if there's a more elegant implementation. The current
>> implementation:
>> - Pauses for a little bit while trying to make the test connection.
>> Since this will pretty much always fail, it's slow.
>
>It's supposed to be fast. A TCP port that has no listener should
>reset the connection immediately, which should cause any
>connection attempt to fail forthwith.
perhaps a packet filter is being used that discards syn packets.
--
bringing you boring signatures for 17 years
Kyle Jones
VM's test connections all go to 127.0.0.1. Who would put a
firewall on the loopback interface? Is that even possible?
Scott Evans
> Scott Evans <g...@antisleep.com> wrote:
> > Anyway. A comment: vm-setup-ssh-tunnel contains code to choose a
> > random port, then test it before using it. I understand the concept
> > but I wonder if there's a more elegant implementation. The current
> > implementation:
> > - Pauses for a little bit while trying to make the test connection.
> > Since this will pretty much always fail, it's slow.
>
> It's supposed to be fast. A TCP port that has no listener should
> reset the connection immediately, which should cause any
> connection attempt to fail forthwith.
Hmmm. It seemed kinda slow on Win98. On Win2000 (that's all I have
at work) the open-network-stream call takes about a second, maybe a
little less. I can try it at home again to time it.
> > - Throws up a *warning* buffer and echoes an error to the minibuffer
> > after the test connection fails. That's disconcerting -- it
> > always seems like the POP process didn't work, even when it does.
>
> I've never seen this. VM isn't generating the warning so it must
> be something int he guts of XEmacs.
Yeah, it comes from said open-network-stream call:
(1) (stream/warning) failure to open network stream to host "127.0.0.1" for service "3444"
and I get this in the minibuffer:
connection failed: Invalid argument, 127.0.0.1, TEST-CONNECTION
> Maybe you should turn your warning level down so that you don't see
> this message.
Seems kludgy but I guess I could do this...
(setq display-warning-suppressed-classes (list 'stream))
Though it still shows the "connection failed" minibuffer error. Plus,
I see network errors pretty often on this work machine. I'd have to
see if those get suppressed 'cause I need them.
Anyway, it'd be nice to solve that problem some other way but maybe there
isn't another way.
Is Windows the only OS exhibiting this behavior? Anyone else tried
the ssh support?
Scott Evans
> > reset the connection immediately, which should cause any
> > connection attempt to fail forthwith.
>
> Hmmm. It seemed kinda slow on Win98. On Win2000 (that's all I have
> at work) the open-network-stream call takes about a second, maybe a
> little less. I can try it at home again to time it.
Just tried in on Win98. It takes about 1.4s to run this:
(defun gse-test()
(condition-case nil
(progn (open-network-stream "TEST-CONNECTION" nil "127.0.0.1" 4339))
(error nil)))
That's a fairly fast machine (800mhz pIII).
Kyle Jones
There's no detectable delay on my 266MHz PII running FreeBSD 4.5.
You should post your test to the XEmacs beta list and see if the
gang can figure out why it runs so slowly.
Scott Evans
> > Just tried in on Win98. It takes about 1.4s to run this:
> > (defun gse-test()
> > (condition-case nil
> > (progn (open-network-stream "TEST-CONNECTION" nil "127.0.0.1" 4339))
> > (error nil)))
> >
> > That's a fairly fast machine (800mhz pIII).
>
> There's no detectable delay on my 266MHz PII running FreeBSD 4.5.
> You should post your test to the XEmacs beta list and see if the
> gang can figure out why it runs so slowly.
Done. In the meantime let's talk about writing "native" ssh code in
elisp. :)
Angus Duggan
>
> You would need stunnel installed. Apparently under Windwos you
> have to run it as a daemon, so you would have VM use a normal POP
> connection that connected to the stunnel daemon. The daemon woul
> encrypt and forward the data to the SSL-POP3 server.
I have a patch for stunnel-3.22 which enables inetd mode on windows. stunnel
can be used directly in VM, not using daemon mode. I'll post the patch here
if there is interest.
a.
--
Global Graphics Software Ltd., Seattle, WA 98109
Unsolicited commercial email unwelcome
http://knackered.org/~angus/