I implemented an SSH server using libssh 5.5.
Running a single ssh client connecting to the server on port 22, all works fine.
The problem arises when I try to connect a second client (I use PUTTY ssh terminal as clients). The server thread waiting for a client connection in ssh_bind_accept is not activated, and the newly opened (second) terminal is obviously 'dead' (the first open
terminal works correctly).
I wonder if there is something important to set that I'm missing.
Here are the calls i perform:
1. Create the session:
sshbind = ssh_bind_new();
session = ssh_new();
2. Call the listen:
ssh_bind_listen(sshbind)
3. Call the accept:
ssh_bind_accept( sshbind, session )
4. Open a putty terminal, which unlocks the *ssh_bind_accept* at step 3
5. Create a new thread and continue terminal dialogue in newly created thread
Basically, the server I developed is based on the sample here: How to use libssh as server?
Having to support multiple client terminals, I have a listener,
and when a connection is created (return from ssh_bind_accept), I create a new thread and continue the ssh connection there. After forking, I create new bind and session, and put myself waiting in ssh_bind accept.
The problem is that opening a second terminal, doesn't cause the ssh_bind_accept to return.
Did you try to do a ssh_bind_free(sshbind) in the child process after having forked ? It is possible that having the listener file descriptor in multiple processes at same time causes problem.
Aris
Related
Im fairly new to Tmux but from what I've read, its using a client-server connection.
Why is that neccessary? Is that only for managing sessions? Why does it communicate through a socket rather than directly with the client?
If anyone could provide me an explanation, that would be appreciated.
Thanks.
Tmux requires a server that is able to keep located the processes when a session is detached.
If you run a process with the "nohup" or "disown" the process in going to run in background even when user logout, however the problem is to recover the control of the process when the user login again.
Tmux server keep those processes associated, so when you login and the user attach the session again. Tmux server is able to MUltipleX several Terminal sessions among other things.
All the magic of Tmux in made by the server, but you don't have to be afraid of Tmux server because, the Tmux server is not running as a general system daemon, the Tmux server is launched from the userspace individually, and when not user sessions are allocated Tmux server automatically stop itself, this is the reason why when you type "tmux ls" and sessions were not previously created the message "failed to connect to server: Connection refused" is displayed (The server is not running, hereby connection is refused).
Apologies if this is a pretty simple question, but I'm pretty new to IWS.
When ever I startup IWS (it's running on Microsoft Server that I remote desktop into) and enter my login details I get this message:
Failed to start TCP/IP Server, please check if the TCP port is already in use
During this same session I will also get the message below whenever I try to change tags in my trend sheets:
WARNING: Tag changes in any trend group will only take place in the next day history file.
It seems any changes I make in relation to tags and driver sheets are ignored and I want to know if this is related to the above error messages and how do I go about debugging/fixing this?
Note: I do not get these messages in other IWS sessions on other servers and I don't experience these problems.
Projects running the TCP/IP Server task use a TCP Port that is defined in the InduSoft Project Settings - Communication tab. By default, InduSoft uses port 1234. The error message you mention can occur if another process binds to that port before InduSoft has started the TCP/IP Server task.
Change the TCP Port. 1234 is the standard Port for Indusoft.
Try to Map your useds Ports before chosing some.
Or kill the process that are using the Port 1234, as explained in the link.
https://receitasdecodigo.com.br/java/listar-e-matar-processo-pela-porta-em-uso-no-windows-pelo-cmd
I use RpcBindingFromStringBinding to connect from MS-RPC client to local Daemon server and vice versa. I use LRPC or local Named Pipes. Randomly calls to NdrClientCall2 fails from first attempt, event if server is alive, error code is -2147467259. Freeing binding and creating new one and do request does not helps. It is reproduced when Excel process add-in start Daemon process, both can be server and client. Cannot reproduce on 2 console executable.
Any ideas?
I used RPC from C#. During start I got GC of RPC server handles. Not reproduced in tests until GC calls.
I'm using Inet1.Ocx in a vb6 project to connect to a remote host.
I was wondering, is there anything to do to disconnect from server while still executing ?
i will explain more,
i write the host name and user name and password and hit (Connect) button but i find out that i misspelled the host name, while the status of the connection (Still Connecting) i attempt to disconnect to re-write the host name, but i get a message error (Still executing the last connection) ... how can i terminate the (Last connection) while (Still executing) ?!
Have the connection and login on a seperate form and then add a disconnect button which closes the form and the connection.
http://www.bigresource.com/VB-How-to-Close-FTP-connection-using-inet-MntXMWW4FX.html
This might help ;)
I have a test driver program that launches a separate test server process. The test server process listens on a local port, and after it's ready, the test driver runs a test that accesses the test server.
Currently the test driver repeatedly tries to connect to the local port (loop some, sleep some, try again). It's not an optimal solution, and is clearly unreliable.
Is it possible to wait for some event that says "somebody listens on a local port"? Trying to connect to early results in a "port closed" error.
I'd like to implement the solution on Windows, Linux, and Mac OS X. If you have some tips for any of these systems, it's welcome (it's probably going to be system-specific in each case).
On Windows I use a named event for this kind of thing.
The test harness can create the event and communicate the name of the event to the server that it launches; it then waits on the event to be signalled before continuing the test. The server then connects to the event, initialises itself and once it's ready to accept connections it signals the event.
Well, if you launch the server process, you can intercept the stdout of the server right?
So have the server output "server started" when the socket ready. The driver should wait until the server sends this string to stdout, then try to connect to the server port.