Re: Removing Order Precautions
Config.ini is the file where you set your IB user id and password, amongst other things. It contains all the settings for how IBC is to run, and each setting is accompanied by notes which explain how it¡¯s used. I don¡¯t see how you could possibly have been using IBC without knowing about config.ini, it¡¯s absolutely fundamental. ? If you look in your StartTWS.bat file (or twsstart.sh on Linux, or twsstartmaacos.sh on macOS), you¡¯ll see a line like this that tells you exactly where the file is: ? On Windows: ? set CONFIG=%USERPROFILE%\Documents\IBC\config.ini?????????? ? On Linux/macOS: ? IBC_INI=~/ibc/config.ini??????????????????????????????????? ? ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Robert Grzesik
Sent: Tuesday, August 20, 2024 9:23 PM
To: [email protected]
Subject: Re: [ibc] Removing Order Precautions? Any idea where I can find more information on the config.ini? I can't find anything in the docs about it or what should be in it
|
Re: Removing Order Precautions
Any idea where I can find more information on the config.ini? I can't find anything in the docs about it or what should be in it
|
Re: Removing Order Precautions
Look at the API Precautions section in config.ini. ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Robert Grzesik
Sent: Tuesday, August 20, 2024 5:31 AM
To: [email protected]
Subject: [ibc] Removing Order Precautions? I keep getting order precaution messages for orders I'm placing through IBC. For example, if I put a limit price too far away from the current price, try to place too big of an order, etc (screenshot included). Is there some way that IBC can automatically click yes or make it so that these warnings don't pop up?
|
Re: Removing Order Precautions
Another example of this attached?
|
Removing Order Precautions
I keep getting order precaution messages for orders I'm placing through IBC. For example, if I put a limit price too far away from the current price, try to place too big of an order, etc (screenshot included).
?
Is there some way that IBC can automatically click yes or make it so that these warnings don't pop up?
?
?
|
Re: IBC 3.17.0 not using SecondFactorAuthenticationTimeout setting
Jasmin
If you look at the list of I00BC Settings in the logfile, you'll see:
SecondFactorAuthenticationExitInterval=
SecondFactorAuthenticationTimeout=180
When you do second factor authentication, IBKR gives you 180 seconds to acknowledge the prompt in the IBKR Mobile app. That's how long TWS/Gateway displays the Second Factor Authentication dialog, after which the basic login dialog is displayed. IBC needs to know the length of this interval, and SecondFactorAuthenticationTimeout specifies what it is. The only reason to ever change that setting is if IBKR decide to use a longer or shorter interval for some reason: and in the several years since 2FA was introduced, this hasn't changed. If that interval elapses and you haven't acknowledged the 2FA prompt, IBC restarts the login sequence, and you then get another chance to complete the 2FA (provided you have ReloginAfterSecondFactorAuthenticationTimeout=yes). This will repeat forever until the user finally acknowledges the prompt. So if you're in the bath or asleep in a hotel room on the other side of the world, you don't need to worry about catching the prompt the first time it's displayed.
Increasing the value of SecondFactorAuthenticationTimeout from its default of 180 seconds will just increase the time till you get another prompt after missing. Decreasing it is will probably cause problems in some cases, though if you successfully deal with the prompt quickly it will all work ok. So, please don't ever change SecondFactorAuthenticationTimeout unless it's clear that IBKR have changed the 2FA timeout.
The thing to note is that SecondFactorAuthenticationTimeout has nothing to do with the 'If login has not completed, IBC will exit in 60 seconds' message. This occurs when the 2FA prompt has been acknowledged, and the Second Factor Authentication dialog has been closed by TWS/Gateway. Normally login should now complete in a couple of seconds. But experience has shown that there are rare circumstances where this doesn't happen, and TWS/Gateway just hangs. After a period of time specified in SecondFactorAuthenticationExitInterval, if login hasn't completed, IBC shuts down TWS/Gateway, on the assumption that something is significantly wrong. The start scripts contain a setting that governs whether the script will automatically restart IBC, in the hope that doing so will clear the condition causing the problem.
So it seems that you need to change the SecondFactorAuthenticationExitInterval setting rather than SecondFactorAuthenticationTimeout.
In the scenario you describe, where you have a lower-powered CPU, the best thing to do is to not start all the TWS instances at the same time. Just give each one a minute or two to get going before starting the next. Then maybe there won't be any need to change SecondFactorAuthenticationExitInterval.
Richard
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of Jasmin J. Sent: Thursday, August 15, 2024 12:12 AM To: [email protected]Subject: [ibc] IBC 3.17.0 not using SecondFactorAuthenticationTimeout setting Hello Richard! First I want to thank you for your excellent working IBC program! Now my problem: I have configured "SecondFactorAuthenticationTimeout=180", but in the log IBC says "If login has not completed, IBC will exit in 60 seconds". Why I am setting this long timeout: On my server I am starting several TWS instances and I do not have so much CPU power. So when they starting up all at once I see 100% CPU load which extends the startup time a lot. I found that IBC was complaining that the 2FA didn't finish in time so I increased the timeout to 3 Minutes which is really enough to startup all TWS instances. At least to do the login. I immediately accepted the 2FA requests when they popped up on the phones. So the 2Fa for all accounts was finished within 20..30 seconds after startup. For me it seems the setting is not used by IBC as the default of 60 Seconds is still used instead of the 180. PLS can you check if I am right or advice me which settings I need to modify to get a 3 minute timeout used by IBC. BR, Jasmin PS: I attached the Logfile if you want to check it on your own.
|
IBC 3.17.0 not using SecondFactorAuthenticationTimeout setting
Hello Richard!
First I want to thank you for your excellent working IBC program!
Now my problem:
I have configured "SecondFactorAuthenticationTimeout=180", but in the log IBC
says "If login has not completed, IBC will exit in 60 seconds".
Why I am setting this long timeout:
On my server I am starting several TWS instances and I do not have so much CPU
power. So when they starting up all at once I see 100% CPU load which extends
the startup time a lot.
I found that IBC was complaining that the 2FA didn't finish in time so I increased
the timeout to 3 Minutes which is really enough to startup all TWS instances. At
least to do the login. I immediately accepted the 2FA requests when they popped up
on the phones. So the 2Fa for all accounts was finished within 20..30 seconds after
startup.
For me it seems the setting is not used by IBC as the default of 60 Seconds is
still used instead of the 180.
PLS can you check if I am right or advice me which settings I need to modify
to get a 3 minute timeout used by IBC.
BR,
Jasmin
PS: I attached the Logfile if you want to check it on your own.
|
I¡¯ve just published release 3.20.0 of IBC to GitHub. Download the zip for your platform from here: ?
? This Release contains the following fixes and enhancements: ? * Fixes problems that occur during auto-restart if the autorestart file contains invalid credentials. A cold restart is performed requiring full authentication. * Automatically handles the dialog that occurs, starting in TWS 10.30.nn, when the user invokes the keyboard shortcuts to refresh market data subscriptions or reset the account connection. Ditto when the RECONNECTDATA and RECONNECTACCOUNT commands are sent to IBC. * Uses the correct shortcut keycode, depending on platform, when processing RECONNECTDATA and RECONNECTACCOUNT commands (see #242). * Fixes issues with cold restart after detecting `Login Error` or `Login Failed` dialogs (see #264). ? There are no changes to script files. ? To upgrade to this Release, download the relevant zip file and extract the `IBC.jar` and `version` files, copying them over the current versions in your IBC installation folder. Then restart TWS/Gateway. ? Richard ?
|
Re: Accessing the gateway from another system on my local network
You have the direction reversed, Pranav. You need to use the -L option and not -R when you define the tunnel.
You want ssh to forward operations on the local ports (Windows/WSL) to the remote ports (localhost on Linux):
- -L 4001:localhost:4001
- -L 4002:localhost:4000 or -L 4002:localhost:4002 if you want to use the same port on both machines.
You'd run autossh on the Windows machine or within WSL so that it would be pranav@...?and not .32 at the end.
´³¨¹°ù²µ±ð²Ô
?
|
Re: Accessing the gateway from another system on my local network
Hi ´³¨¹°ù²µ±ð²Ô, ? I am making some mistake. My linux system is at 192.168.88.3 while my windows machine where I am running wsl is at 192.168.88.4. ? The linux machine is running the IB ?gateways. ? So, if I understand tunneling correctly, the local ports on the linux machine need to be tunneled to the local ports of the machine running wsl. ? Here is the commandline I used but am still getting an API timeout error. autossh -M20000 -f -N -R 4001:localhost:4001 -R 4002:localhost:4000 pranav@... ? Pranav
|
Re: Accessing the gateway from another system on my local network
Once again ´³¨¹°ù²µ±ð²Ô, many thanks. I was aware that OpenSSH is now available on Windows when they introduced it, but had completely forgotten about it as I haven¡¯t needed to use it. Richard ? ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of ´³¨¹°ù²µ±ð²Ô Reinold via groups.io
Sent: Thursday, August 8, 2024 3:12 AM
To: [email protected]
Subject: Re: [ibc] Accessing the gateway from another system on my local network? Looks like Windows does ship with a native OpenSSH feature that you can enable through "Settings, --> System --> Optional Features --> OpenSSH Client" as described in . You only need the client package, not the server package. That gives you the ssh command, but not autossh since that is not part of OpenSSH (and therefore not part of the Windows feature). There are independent Windows binary ports available on GitHub, but you can easily make reliable ssh tunnels work with just the Windows OpenSSH ssh command, too. I made a couple quick tests after the Windows OpenSSH client was installed: C:\> where ssh
C:\Windows\System32\OpenSSH\ssh.exe
C:\> ssh -L 7497:127.0.0.1:7497 user@SystemWithTWS
That starts an SSH command line session with the remote system AND a tunnel that forwards any and all connections to local (Windows) port 7497 to port 7497 on the remote system. Creating the tunnel will work whether or not a process on the remote site actually listens on port 7497. Local windows clients will simply get a network connection error until a process on the remote system actually listens (such as TWS with an authenticated paper account). And the tunnel will survive TWS restarts or extended periods of time with no process listening on the remote port. If you are not interested in the command prompt (for example if you want to run the tunnel in the background), simply add -N. If you want to use a different local Windows port (say 12345) use "-L 12345:127.0.0.1:7497" instead. There are many options and variations possible when defining the tunnel with -L. I am using the "-L lport:host:hostport" option here: - lport is the port number on the local (here Windows) system
- host:hostport is the point where all operations on lport are forwarded to AFTER ssh connects to the remote system. "127.0.0.1:7497" in my case actually refers to the remote system that I called "SystemWithTWS" on the command line. This is important in case TWS/IBGW are configured to only accept connections from localhost (IMHO the only really safe option). But it could also be any host that you can reach from within the remote "SystemWithTWS".
A single SSH session can handle several simultaneous port forwards (say TWS ports 7496 and 7497 or IBGW ports 4001 and 4002 or all four of them) and ports may have similar or different traffic types. You can, for example, specify TWS API ports and VNC remote desktop ports through the same tunnel. For example, adding "-L 5933:localhost:5933" would allow a local (Windows) VNC client to connect to the remote VNC desktop ":33" while your local TWS API clients connect to TWS or IBGW. And finally, these kinds of tunnels allow data packets to flow in both directions between the local and remote system, but connection requests are only honored on the local system. Meaning that processes on the remote system cannot reach ito your local system through these tunnels. I am sure there is more, but this should suffice for most users. ´³¨¹°ù²µ±ð²Ô On Wed, Aug 7, 2024 at 03:26 PM, Richard L King wrote: Thanks for that, ´³¨¹°ù²µ±ð²Ô. Do you happen to know if there¡¯s a way of achieving the same thing on Windows (short of installing something like Putty)?
|
Re: Accessing the gateway from another system on my local network
Looks like Windows does ship with a native OpenSSH feature that you can enable through "Settings, --> System --> Optional Features --> OpenSSH Client" as described in . You only need the client package, not the server package. That gives you the ssh command, but not autossh since that is not part of OpenSSH (and therefore not part of the Windows feature). There are independent Windows binary ports available on GitHub, but you can easily make reliable ssh tunnels work with just the Windows OpenSSH ssh command, too.
I made a couple quick tests after the Windows OpenSSH client was installed:
C:\> where ssh
C:\Windows\System32\OpenSSH\ssh.exe
C:\> ssh -L 7497:127.0.0.1:7497 user@SystemWithTWS
That starts an SSH command line session with the remote system AND a tunnel that forwards any and all connections to local (Windows) port 7497 to port 7497 on the remote system. Creating the tunnel will work whether or not a process on the remote site actually listens on port 7497. Local windows clients will simply get a network connection error until a process on the remote system actually listens (such as TWS with an authenticated paper account). And the tunnel will survive TWS restarts or extended periods of time with no process listening on the remote port.
If you are not interested in the command prompt (for example if you want to run the tunnel in the background), simply add -N.
If you want to use a different local Windows port (say 12345) use "-L 12345:127.0.0.1:7497" instead.
There are many options and variations possible when defining the tunnel with -L. I am using the "-L lport:host:hostport" option here:
- lport is the port number on the local (here Windows) system
- host:hostport is the point where all operations on lport are forwarded to AFTER ssh connects to the remote system. "127.0.0.1:7497" in my case actually refers to the remote system that I called "SystemWithTWS" on the command line. This is important in case TWS/IBGW are configured to only accept connections from localhost (IMHO the only really safe option). But it could also be any host that you can reach from within the remote "SystemWithTWS".
A single SSH session can handle several simultaneous port forwards (say TWS ports 7496 and 7497 or IBGW ports 4001 and 4002 or all four of them) and ports may have similar or different traffic types. You can, for example, specify TWS API ports and VNC remote desktop ports through the same tunnel. For example, adding "-L 5933:localhost:5933" would allow a local (Windows) VNC client to connect to the remote VNC desktop ":33" while your local TWS API clients connect to TWS or IBGW.
And finally, these kinds of tunnels allow data packets to flow in both directions between the local and remote system, but connection requests are only honored on the local system. Meaning that processes on the remote system cannot reach ito your local system through these tunnels.
I am sure there is more, but this should suffice for most users.
´³¨¹°ù²µ±ð²Ô
?
?
?
?
On Wed, Aug 7, 2024 at 03:26 PM, Richard L King wrote:
Thanks for that, ´³¨¹°ù²µ±ð²Ô.
Do you happen to know if there¡¯s a way of achieving the same thing on Windows (short of installing something like Putty)?
|
Re: Accessing the gateway from another system on my local network
I am glad you? have all required components in place, Pranav, and I am confident that this will work for you. Let me know if there are any hiccups I can help with.
´³¨¹°ù²µ±ð²Ô
?
?
?
On Wed, Aug 7, 2024 at 07:41 PM, Pranav Lal wrote:
Hi ´³¨¹°ù²µ±ð²Ô and Richard,
?
Many thanks for this. SSH tunneling is going to be the way to go for me. My gateways are running on a dedicated Linux machine on my LAN and I do have key based authentication setup from my windows box.
?
I also have WSL running on the windows machine and am experimenting with it.
?
Note:
Autossh is something that some users may have to install. For me, a simple sudo pacman -S autossh did the job and then man autossh showed me some of the parameters that the program takes.
Pranav
?
?
?
You'd use the "port forwarding" feature of SSH to make the TWS/IBGW API ports available for software that runs on the client system . You can use the same port numbers on the client system that your TWS/IBGW use (say 7497 for a paper account on TWS) or any other local port number you'd prefer..
If you are looking for a temporary connection, you can do that from the ssh command line with one or more -L options. Or, in case you trust both systems, you can use the autossh command that creates and maintains the tunnel automatically should it ever terminate. The tunnel would terminate for network related reasons or system restarts but does survive TWS/IBGW restarts. A single ssh tunnel can serve several ports (say all ports for paper/live and TWS/IBGW) and multiple local clients can connect to the same TWS/IBGW through a single tunnel.
This is the command I use to connect my software development environment (on a Windows laptop) to the cloud based Linux TWS installations with live and paper accounts:
/bin/autossh -f -a -M 20100 -C -L 7496:127.0.0.1:7496 -L 7497:127.0.0.1:7497 -N user@systemwithTWS
Depending on how you perform ssh authentication on the system that runs TWS/IBGW, another option might be necessary. I use certificate/key based authentication and provide the caller's identity via -i.
There is no TWS/IBGW configuration necessary and you leave the "localhost only" option selected. Connection requests from your client software look to TWS/IBGW as if it they come from the local system (connections via SSH tunnels arrive at TWS.IBGW from 127.0.0.1/localhost).
I prefer the transparent ssh tunnel connection over allowing TWS/IBGW to communicate directly with external systems. Granted, you can add security by limiting the permitted systems to certain IP addresses, but keep in mind that the TWS/IBGW port can still be reached from any system and TWS API communication takes place in clear text. SSH tunnels are encrypted (and compressed if you'd like) and you have to manage only one entry point into your TWS/IBGW system.
´³¨¹°ù²µ±ð²Ô
?
On Wed, Aug 7, 2024 at 01:15 PM, Richard L King wrote:
No, the only way to do it is via the UI.
However, I believe you're a Linux user? Many Linux users of IBC use SSH
tunnelling to connect remotely to TWS/Gateway, with the tunnel set up so
that the connection appears to be from localhost: then the Trusted IPs list
is not needed.
I'm not sufficiently familiar with this method to spell it out without
having to look it up, and you may already be familiar with how to do it, so
I'll leave it to you to figure out.
Richard
|
Re: Accessing the gateway from another system on my local network
Hi ´³¨¹°ù²µ±ð²Ô and Richard, ? Many thanks for this. SSH tunneling is going to be the way to go for me. My gateways are running on a dedicated Linux machine on my LAN and I do have key based authentication setup from my windows box. ? I also have WSL running on the windows machine and am experimenting with it. ? Note: Autossh is something that some users may have to install. For me, a simple sudo pacman -S autossh did the job and then man autossh showed me some of the parameters that the program takes. Pranav ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of ´³¨¹°ù²µ±ð²Ô Reinold via groups.io
Sent: Thursday, August 8, 2024 12:56 AM
To: [email protected]
Subject: Re: [ibc] Accessing the gateway from another system on my local network? You'd use the "port forwarding" feature of SSH to make the TWS/IBGW API ports available for software that runs on the client system . You can use the same port numbers on the client system that your TWS/IBGW use (say 7497 for a paper account on TWS) or any other local port number you'd prefer.. If you are looking for a temporary connection, you can do that from the ssh command line with one or more -L options. Or, in case you trust both systems, you can use the autossh command that creates and maintains the tunnel automatically should it ever terminate. The tunnel would terminate for network related reasons or system restarts but does survive TWS/IBGW restarts. A single ssh tunnel can serve several ports (say all ports for paper/live and TWS/IBGW) and multiple local clients can connect to the same TWS/IBGW through a single tunnel. This is the command I use to connect my software development environment (on a Windows laptop) to the cloud based Linux TWS installations with live and paper accounts: /bin/autossh -f -a -M 20100 -C -L 7496:127.0.0.1:7496 -L 7497:127.0.0.1:7497 -N user@systemwithTWS Depending on how you perform ssh authentication on the system that runs TWS/IBGW, another option might be necessary. I use certificate/key based authentication and provide the caller's identity via -i. There is no TWS/IBGW configuration necessary and you leave the "localhost only" option selected. Connection requests from your client software look to TWS/IBGW as if it they come from the local system (connections via SSH tunnels arrive at TWS.IBGW from 127.0.0.1/localhost). I prefer the transparent ssh tunnel connection over allowing TWS/IBGW to communicate directly with external systems. Granted, you can add security by limiting the permitted systems to certain IP addresses, but keep in mind that the TWS/IBGW port can still be reached from any system and TWS API communication takes place in clear text. SSH tunnels are encrypted (and compressed if you'd like) and you have to manage only one entry point into your TWS/IBGW system. ´³¨¹°ù²µ±ð²Ô ? On Wed, Aug 7, 2024 at 01:15 PM, Richard L King wrote: No, the only way to do it is via the UI.
However, I believe you're a Linux user? Many Linux users of IBC use SSH
tunnelling to connect remotely to TWS/Gateway, with the tunnel set up so
that the connection appears to be from localhost: then the Trusted IPs list
is not needed.
I'm not sufficiently familiar with this method to spell it out without
having to look it up, and you may already be familiar with how to do it, so
I'll leave it to you to figure out.
Richard
|
Re: Accessing the gateway from another system on my local network
No objections, Richard. I think I could make it simpler or easier to understand (e.g. all those autossh options) if that helps.
Traditionally I have used cygwin on windows which comes with a complete ssh infrastructure. Recently I use WSL2 more and more which also comes with robust ssh. Let me take a quick look at native Windows SSH. I am sure that will work, too.
?
On Wed, Aug 7, 2024 at 03:26 PM, Richard L King wrote:
Thanks for that, ´³¨¹°ù²µ±ð²Ô.
I think it would be worth adding this to the IBC User Guide. If you¡¯ve no objection, I¡¯ll add it some time soon, with a bit of light editing.
Do you happen to know if there¡¯s a way of achieving the same thing on Windows (short of installing something like Putty)?
?
|
Re: Accessing the gateway from another system on my local network
Thanks for that, ´³¨¹°ù²µ±ð²Ô. I think it would be worth adding this to the IBC User Guide. If you¡¯ve no objection, I¡¯ll add it some time soon, with a bit of light editing. Do you happen to know if there¡¯s a way of achieving the same thing on Windows (short of installing something like Putty)? ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of ´³¨¹°ù²µ±ð²Ô Reinold via groups.io
Sent: Wednesday, August 7, 2024 8:26 PM
To: [email protected]
Subject: Re: [ibc] Accessing the gateway from another system on my local network? You'd use the "port forwarding" feature of SSH to make the TWS/IBGW API ports available for software that runs on the client system . You can use the same port numbers on the client system that your TWS/IBGW use (say 7497 for a paper account on TWS) or any other local port number you'd prefer.. If you are looking for a temporary connection, you can do that from the ssh command line with one or more -L options. Or, in case you trust both systems, you can use the autossh command that creates and maintains the tunnel automatically should it ever terminate. The tunnel would terminate for network related reasons or system restarts but does survive TWS/IBGW restarts. A single ssh tunnel can serve several ports (say all ports for paper/live and TWS/IBGW) and multiple local clients can connect to the same TWS/IBGW through a single tunnel. This is the command I use to connect my software development environment (on a Windows laptop) to the cloud based Linux TWS installations with live and paper accounts: /bin/autossh -f -a -M 20100 -C -L 7496:127.0.0.1:7496 -L 7497:127.0.0.1:7497 -N user@systemwithTWS Depending on how you perform ssh authentication on the system that runs TWS/IBGW, another option might be necessary. I use certificate/key based authentication and provide the caller's identity via -i. There is no TWS/IBGW configuration necessary and you leave the "localhost only" option selected. Connection requests from your client software look to TWS/IBGW as if it they come from the local system (connections via SSH tunnels arrive at TWS.IBGW from 127.0.0.1/localhost). I prefer the transparent ssh tunnel connection over allowing TWS/IBGW to communicate directly with external systems. Granted, you can add security by limiting the permitted systems to certain IP addresses, but keep in mind that the TWS/IBGW port can still be reached from any system and TWS API communication takes place in clear text. SSH tunnels are encrypted (and compressed if you'd like) and you have to manage only one entry point into your TWS/IBGW system. ´³¨¹°ù²µ±ð²Ô ? On Wed, Aug 7, 2024 at 01:15 PM, Richard L King wrote: No, the only way to do it is via the UI.
However, I believe you're a Linux user? Many Linux users of IBC use SSH
tunnelling to connect remotely to TWS/Gateway, with the tunnel set up so
that the connection appears to be from localhost: then the Trusted IPs list
is not needed.
I'm not sufficiently familiar with this method to spell it out without
having to look it up, and you may already be familiar with how to do it, so
I'll leave it to you to figure out.
Richard
|
Re: Accessing the gateway from another system on my local network
You'd use the "port forwarding" feature of SSH to make the TWS/IBGW API ports available for software that runs on the client system . You can use the same port numbers on the client system that your TWS/IBGW use (say 7497 for a paper account on TWS) or any other local port number you'd prefer..
If you are looking for a temporary connection, you can do that from the ssh command line with one or more -L options. Or, in case you trust both systems, you can use the autossh command that creates and maintains the tunnel automatically should it ever terminate. The tunnel would terminate for network related reasons or system restarts but does survive TWS/IBGW restarts. A single ssh tunnel can serve several ports (say all ports for paper/live and TWS/IBGW) and multiple local clients can connect to the same TWS/IBGW through a single tunnel.
This is the command I use to connect my software development environment (on a Windows laptop) to the cloud based Linux TWS installations with live and paper accounts:
/bin/autossh -f -a -M 20100 -C -L 7496:127.0.0.1:7496 -L 7497:127.0.0.1:7497 -N user@systemwithTWS
Depending on how you perform ssh authentication on the system that runs TWS/IBGW, another option might be necessary. I use certificate/key based authentication and provide the caller's identity via -i.
There is no TWS/IBGW configuration necessary and you leave the "localhost only" option selected. Connection requests from your client software look to TWS/IBGW as if it they come from the local system (connections via SSH tunnels arrive at TWS.IBGW from 127.0.0.1/localhost).
I prefer the transparent ssh tunnel connection over allowing TWS/IBGW to communicate directly with external systems. Granted, you can add security by limiting the permitted systems to certain IP addresses, but keep in mind that the TWS/IBGW port can still be reached from any system and TWS API communication takes place in clear text. SSH tunnels are encrypted (and compressed if you'd like) and you have to manage only one entry point into your TWS/IBGW system.
´³¨¹°ù²µ±ð²Ô
?
On Wed, Aug 7, 2024 at 01:15 PM, Richard L King wrote:
No, the only way to do it is via the UI.
However, I believe you're a Linux user? Many Linux users of IBC use SSH
tunnelling to connect remotely to TWS/Gateway, with the tunnel set up so
that the connection appears to be from localhost: then the Trusted IPs list
is not needed.
I'm not sufficiently familiar with this method to spell it out without
having to look it up, and you may already be familiar with how to do it, so
I'll leave it to you to figure out.
Richard
|
Re: Accessing the gateway from another system on my local network
No, the only way to do it is via the UI.
However, I believe you're a Linux user? Many Linux users of IBC use SSH
tunnelling to connect remotely to TWS/Gateway, with the tunnel set up so
that the connection appears to be from localhost: then the Trusted IPs list
is not needed.
I'm not sufficiently familiar with this method to spell it out without
having to look it up, and you may already be familiar with how to do it, so
I'll leave it to you to figure out.
Richard
|
Re: Accessing the gateway from another system on my local network
Hi Richard and all,
<snip For non-FIX Gateways, use the Trusted IPs list in the Gateway's API
configuration .settings
PL] Is there any way to get to this setting by editing a configuration file?
My screen reader does not work too well with the gateway though I'll do some
experimenting.
Pranav
|
Re: Accessing the gateway from another system on my local network
Yes, that is still true.
For non-FIX Gateways, use the Trusted IPs list in the Gateway's API
configuration .settings
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of Pranav Lal Sent: Wednesday, August 7, 2024 11:26 AM To: [email protected]Subject: [ibc] Accessing the gateway from another system on my local network Hi all, I need to access my ib gateway from another machine on my lan. I see a setting for trusted IP addresses in the ibc configuration file. Is it still the case that this setting applies only if the fixed setting is set to true? Pranav
|
Pranav Lal