Unsupported Screen Size: The viewport size is too small for the theme to render properly.

Ssh Keepalive

forums forums SQLyog SQLyog: Bugs / Feature Requests Ssh Keepalive

  • This topic is empty.
Viewing 8 reply threads
  • Author
    Posts
    • #10058
      magge
      Member

      I'm behind a router/firewall that keeps breaking my connections. In putty I can keep my connection by enabling a keepalive every 60 seconds. Is this possible with SQLyogs SSH tunneling?

      Thanks for any info,

      Magnus

    • #23006
      peterlaursen
      Participant

      We will look into the options available with SSH tunnel by next week.

      main puropose is to support private/public key authentication, but we will look into this too.

    • #23007
      magge
      Member

      Great news.

      Btw, did something happen between 5.2 beta 4 and 5.2 final causing ALT+TABing away from the Query editor, and the ALT+TABing back again, and the editor area is no longer active. In other words I have to click once in the editor before I can continue writing.

      I'm pretty sure I switched back and forth between SQLyog and my mail program when looking up people in the DB before…

      I know it's a detail, but it's bothersome.

      Magnus

    • #23008
      peterlaursen
      Participant

      I do not have 5.2 beta4 installed anymore, but I can confirm the focus issue by comparing 5.19 and 5.2.

      That will be fixed of course.

    • #23009
      magge
      Member

      Nice! 🙂

    • #23010
      peterlaursen
      Participant

      We cannot do this – and I shall try to explain why. There are two reasons.

      1) 'keepalive' is not a configuration itself. It must be allowed for in configuration, but the client must send data at intervals. With Putty simply 16 0-bits are sent (compare a FTP-client that sends the NOOP command). This is enough to tell SSHD that the client is still active.

      We could of course code a similar small loop sending the same with a wait(some_seconds) or sleep(some_seconds) command ourselves. However will wil then need to monitor the traffic in the tunnel ourselves (there is no way to get the information form PLINK) as those data should only be sent when no other data are sent.

      But the most important reason is.

      2) When you connect the common way with Putty you create a remote (and secure) shell. We create a tunnel to MySQL. So those data (16 0-bits or whatever) will be tunnelled to MySQL and not used for the purpose: to keep the connection alive!

    • #23011
      magge
      Member

      Ok, I am familiar with SSH tunneling – but isn't there a SSH session wrapping the tunnel? I've used this many times for remote desktop connections. For that I simply specify a tunnel in putty and connect to a SSH server that has access to the remote desktop server, finally the remote desktop client connect to the locally forwarded port. If I would have keepalives for that SSH session, that would also mean my tunnel was kept alive (given whatever equipment that is breaking the connections is between the SSH client and server offcourse).

      Before submitting this thread I googled abit on puttys features and I noticed that keepalives should be avaliable quote “everywhere”, not just in the GUI but also in plink, psftp and so on.

      Changelog: http://www.chiark.greenend.org.uk/~sgtatha…ty/changes.html (second last point under beta 0.58).

      I also made a desperate try of just upgrading plink.exe in the SQLyog dir, but that just made SQLyog time out when trying to make connections. The thought behind this was that plink would use my default settings from putty (where I have specified a keepalive). 🙂

      I have no idea how one should go about specifying that plink is to use keepalives, though. Only mention I find of it is infact in the changelog (above link). I took a super-quick look at the plink sources and found only 2 references to “keepalive”;

      Code:
      // magge: i suppose this one gets defaults. perhaps same as putty defaults.
      do_defaults(NULL, &cfg);

      // magge: uses cfg.tcp_keepalives without modifying default/initial setting (?)
      error = back->init(NULL, &backhandle, &cfg, cfg.host, cfg.port,
      &realhost, nodelay, cfg.tcp_keepalives);

      So maybe this will work if SQLyog is upgraded to the latest plink 0.58 and keepalives are enabled in the default settings of putty ? :huh:

      If I'm way off here, I'm sorry I wasted your time. I have no experience with plink whatsoever. 😎

    • #23012
      peterlaursen
      Participant
      Quote:
      So maybe this will work if SQLyog is upgraded to the latest plink 0.58 and keepalives are enabled in the default settings of putty ?

      1) the PLINK shipped with SQLyog is our own build. You cannot get it from anywhere else, and can't replace with a 'standard' one. We have compiled in the handles for SQLyog to use.

      2) (standard) PLINK uses Putty profiles. Those profiles are encrypted, and we have not been able to find any docs for the format of such profile – so we cannot replicate it! We do not want it to be obligatory to have (and understand) Putty to use SQLyog SSH-tunnelling. SQLyog is a user-friendly GUI-tool! <_< 3) still with tunnelling the 16 0-bit 'keep-alive word' would be tunnelled to MySQL and would cause an error here!

      I do not claim it cannot be solved. I hoped that just calling PLINK with a parameter would do, but as it depends on Putty that is not so.

    • #23013
      magge
      Member

      Ok, I see…

      In the above code it seems you could enable/disable keepalives by overriding cfg.tcp_keepalives though, in standard plink. Hopefully that does not mean that it'll be sending it's keepalive bytes to the tunneled application (which would likely cause corruption of data?) but rather internally between the SSH server and client.

      Anyways, perhaps you could look into the sourcecode for a newer version of plink to see how they solved it there and “just” patch up that version with whats needed extra for SQLyog. 😛 Easier said than done, I'm sure.

      But in the end this is not a big issue for most people. Only the ones with a crappy gateway. So I will stop my wining about this now, hehe. 😎

Viewing 8 reply threads
  • You must be logged in to reply to this topic.