?

Hi Richard,

Apologies for the delay. Yes we are using ib_insync on a ubuntu AWS server. Since we initiated it from ib_insync we don't have the logs requested. Your previous comment triggered the idea in our minds that there was a conflict with watchdog and IBC and the auto-restart by TWS. In the meantime we have been researching discussion threads here and on the ib_insync group to understand that before responding further. We have discovered that a clean install of TWS on the ubuntu AWS box results in the freezing/crashing behavior with no involvement with IBC so clearly IBC is not related to our problem.

We see your comments on this thread:?/g/ibcalpha/topic/98487448#2079?that makes us think that perhaps the AWS box has a limited ubuntu installation and we need additional libraries. You mention installing those libraries on AWS, but any chance you can point us to a resource on what libraries would be beneficial to try installing in our ubuntu instance? Any other recommendations?

Best regards,

Brian

?

Can you try with a fresh instance of Gateway (ie no prior configuration except the jts.ini) and see if it still works? I don’t see how it possibly can from what I’m observing, so I suispect that yours is working because at some point you’ve cleared the ‘Allow connections from localhost only’ checkbox.

?

Thanks for that. A couple of points that might be of interest:

?

First, are you aware that you can configure IBC to save the TWS/Gateway settings at times of your choosing? See SaveTwsSettingsAt in config.ini.

?

This difficulty of configuring Docker images has been an issue for a long time. I’m not a Docker user (though I’ve toyed with it), but I presume it would be possible to pay for persistent storage on the Docker host machine and store settings on that volume. But it seems people don’t want that extra cost (or maybe there is some reason I’m not aware of why that is not a viable option?).

?

One thing ‘ve suggested in the past is to configure your TWS/Gateway locally (ie on a computer under your control), then build the settings folder into the Docker image. That would at least give you a predictable starting configuration when you run the image. But any change needed to the configuration would require rebuilding the image. And of course any changes made during the session would not be persisted between sessions.

?

Somewhat better is something I’ve been considering, but haven’t got round to trying to implement. This is where you, again, configure TWS/Gateway locally and save those settings somewhere they can be downloaded over the internet using curl. Then config.ini would have a new setting that contains the URL for this data, and IBC would simply download the whole lot before running TWS/Gateway. Changes could be made ‘offline’ between sessions. This still doesn’t enable changes during the session to be saved, and has the overhead of having to download it all every time you start TWS/Gateway (though that’s pretty much what happens if you use the ‘StoreSettingsOnServer’ option does). An enhancement to this would allow the settings to be stored back in the specified location, but that’s sounding like a lot of hard work.

?

Finally, I was under the impression that the TrustedIPs in jts.ini was only used by the FIX Gateway. So I just tried it and indeed it doesn’t seem to work for me with TWS or the standard Gateway. Are you sure it worked for you?

?

Richard

?

?

?

From: [email protected] <[email protected]> On Behalf Of Bart D via groups.io
Sent: Sunday, October 22, 2023 10:40 PM
To: [email protected]; Richard L King via groups.io <rlking@...>; Bart D via groups.io <bart@...>
Subject: Re: [ibc] does IB block API connections when there have been too many missed authentication attempts?

?

I found the root cause of this and it was something totally different.

When you run a dockerized multi-container app, each container gets an IP address from a local gateway on the docker host that allows communication between the containers (the default docker bridge network). You can set these IP addresses in the docker-compose.yml so they are fixed. So they communicate via this IP address on port 4000, not via localhost:4001.?

I knew this and had entered 'StoreSettingsOnServer=yes' in ibc.ini, and had manually entered the correct IP address for my client upon first startup of IBGW in the container (via a VNC UI connection) using IBGW's API settings, relying on the fact it would get stored on server for any subsequent startup.

However that is not the case for one or both of these reasons:

• IBGW only stores settings when you close down the app gracefully. But when you stop the container from a docker command that is not the case and settings don't get saved.?
• Even if settings are saved, unless you have a docker volume mounted, the next startup will be from a clean slate i.e. without the saved settings file on prior run

Bottomline: it reverted each time to allow a localhost connection only, and so didn't work. Not quite clear how I got the 'client ID in use' error message but this was the reason it didn't connect.?
Solution is just to specify the IP address in the jts.ini file:
TrustedIPs=127.0.0.1;<your extra IP address>

?

rgds, Bart

?

Richard, thanks for reply and the excellent IBC. It seems you're the sole person who has made unatttended operation with IB possible!

The situation was "repeatedly starting TWS/Gateway, logging in successfully, and then restarting after a short time" as I manually stopped and restarted the dockerized system (that has IBGW + IBC in 1 container, and my client in another, working together in a multi-container app) during development, sometimes with and sometimes without completing login (always with 2FA).?
The strange thing is that when I did complete login, the error was a "client ID in use" error rather than a "too many failed login attempts" error, and the client got disconnected. The client does try to re-connect with 60s interval but it kept getting disconnected with the same error msg.

I switched off the whole thing on Friday, and waited until this morning to re-start the application. Now it works normal again.

Anyway problem resolved, at least for now.

rgds, Bart

On Oct 22, 2023 at 11:16?AM -0700, Richard L King via groups.io <rlking@...>, wrote:

I’m a bit unclear about the situation here. In the subject, you mention ‘too many missed authentication attempts’, but you don’t explain what you mean by this in the message.

?

If you keep trying and failing to login to TWS/Gateway, eventually a dialog will pop up with a message like this: “Too many failed login attempts. Please wait 4 minutes & 47 seconds before attempting to re-login again.”. ?This situation can occur if you’re handling 2FA via IBC and IBKR Mobile app, and IBC deals with it automatically. Note that during the specified wait, TWS/Gateway is just sitting there with the login dialog on display, waiting for the next login attempt to be initiated, which IBC does after the specified delay. So during this period, if the API client program tries to connect, it will fail because it won’t accept API connections until login is completed successfully (obviously).

?

Even if you’re not doing 2FA, just repeatedly starting TWS/Gateway, logging in successfully, and then restarting after a short time, I suppose it’s possible that IB might put up the “Too many failed login attempts”, because they might reasonably think that something fishy is going on, though if the logins are successful I don’t really see why they should complain.

?

Could this be your situation? If so, then you should consider modifying your API client so that if connection fails, it attempts again after a suitable delay. All my API clients are configured to do this (this means I can start them at any time and it doesn’t matter If TWS/Gateway isn’t running at the time:when it is started later, they will soon connect again and succeed.

?

If not, then I don’t know what to suggest. I’ve certainly never seen anything to suggest that IB will ever block API connections after a successful login. In fact I think API connections are purely local to TWS/Gateway, in the sense that the IB servers seem to have no knowledge of them: TWS/Gateway acts as a proxy for them in everything they do.

?

Come to think of it, the scenario described above would account for the fact that it works when you run manually: in this case, your Docker instance is sitting waiting for the next login attempt after the requested delay, your API client has failed to connect because login hasn’t completed, but when you start a new instance manually login succeeds immediately, so the API client can now connect.

?

I hope all this makes sense!

?

Richard

I’m a bit unclear about the situation here. In the subject, you mention ‘too many missed authentication attempts’, but you don’t explain what you mean by this in the message.

?

If you keep trying and failing to login to TWS/Gateway, eventually a dialog will pop up with a message like this: “Too many failed login attempts. Please wait 4 minutes & 47 seconds before attempting to re-login again.”. ?This situation can occur if you’re handling 2FA via IBC and IBKR Mobile app, and IBC deals with it automatically. Note that during the specified wait, TWS/Gateway is just sitting there with the login dialog on display, waiting for the next login attempt to be initiated, which IBC does after the specified delay. So during this period, if the API client program tries to connect, it will fail because it won’t accept API connections until login is completed successfully (obviously).

?

Even if you’re not doing 2FA, just repeatedly starting TWS/Gateway, logging in successfully, and then restarting after a short time, I suppose it’s possible that IB might put up the “Too many failed login attempts”, because they might reasonably think that something fishy is going on, though if the logins are successful I don’t really see why they should complain.

?

Could this be your situation? If so, then you should consider modifying your API client so that if connection fails, it attempts again after a suitable delay. All my API clients are configured to do this (this means I can start them at any time and it doesn’t matter If TWS/Gateway isn’t running at the time:when it is started later, they will soon connect again and succeed.

?

If not, then I don’t know what to suggest. I’ve certainly never seen anything to suggest that IB will ever block API connections after a successful login. In fact I think API connections are purely local to TWS/Gateway, in the sense that the IB servers seem to have no knowledge of them: TWS/Gateway acts as a proxy for them in everything they do.

?

Come to think of it, the scenario described above would account for the fact that it works when you run manually: in this case, your Docker instance is sitting waiting for the next login attempt after the requested delay, your API client has failed to connect because login hasn’t completed, but when you start a new instance manually login succeeds immediately, so the API client can now connect.

?

I hope all this makes sense!

?

Richard

?

Hi Richard,

Thanks for pointing that out. I can see the Title "IbcTws" and if I click on About a small widow pops out.

Please see the image attached.

We appreciate your help and guidance immensely. Let me know how to look further to locate the actual log files.

Chen

?

Hi Richard,

We really appreciate your help here. Your willingness to help directly with users like us is commendable.

The ubuntu box has already been on 3.18.0 and I've attached the launcher logs for the past 2 days from the ubuntu box. I'll be so happy when I can get this running flawlessly through the week until Sunday like it should. :-)

**Note we had IBC working flawlessly on a previous ubuntu box. We migrated to a box with more processor and RAM. After the migration to the new box is when the crashing behavior started. I'll state again just for clarification that TWS runs fine on the box without crashing behavior until its run by IBC and then it become crash prone. We've reinstalled TWS to see if that was a factor. We haven't yet attempted a complete redeployment of IBC to see if we just missed something during the initial setup of IBC.

Best regards,

Brian

?

@All,

Chen and I have been working on this issue together prior to coming to this group for further insight and let me expound on what it seems is happening. We install TWS on both a ubuntu server and a macOS environment and if we run TWS manually it runs perfectly fine, however after the first run of TWS under IBC control TWS fires up, but has now become crash prone. Once TWS crashes then IBC does a hard restart of the application. It appears that its crashing during the daily restart hence the 2FA issue because of the hard restart it needs 2FA to relogin since if TWS was functioning properly it would only need 2FA once a week. In the macOS environment its more stable than in ubuntu, but in ubuntu once IBC has run TWS then TWS will crash during a number of actions on the application. It crashes not only during restart but it also crashes upon order submission, when changing the contract shown on the graph or on the order entry screen, etc.

Running TWS manually after the first run by IBC is still crash prone. Our theory is perhaps there are some settings in the IBC installation/configuration that we are missing so that when it alters the TWS files during its initial run it isn't altering the TWS files properly.

Hopefully this helps clarify what we are experiencing.

Thanks,

Brian