Could not find second factor device 'IB Key Security via IBKR Mobile' in the list

[tomer-ds]

Hi,

I am configuring the Second Factor Device Name in the config.ini.tmpl and then allowing the run.sh to configure the rest for me.
My CUSTOM_CONFIG is set to "no".

I have the following configurations resulting in my container

# Note that in the comments in this file, TWS refers to both the Trader
# Workstation and the IB Gateway, unless explicitly stated otherwise.
#
# When referred to below, the default value for a setting is the value
# assumed if either the setting is included but no value is specified, or
# the setting is not included at all.
#
# IBC may also be used to start the FIX CTCI Gateway. All settings
# relating to this have names prefixed with FIX.
#
# The IB API Gateway and the FIX CTCI Gateway share the same code. Which
# gateway actually runs is governed by an option on the initial gateway
# login screen. The FIX setting described under IBC Startup
# Settings below controls this.



# =============================================================================
# 1.   IBC Startup Settings
# =============================================================================


# IBC may be used to start the IB Gateway for the FIX CTCI. This
# setting must be set to 'yes' if you want to run the FIX CTCI gateway. The
# default is 'no'.

FIX=no



# =============================================================================
# 2.   Authentication Settings
# =============================================================================

# TWS and the IB API gateway require a single username and password.
# You may specify the username and password using the following settings:
#
#       IbLoginId
#       IbPassword
#
# Alternatively, you can specify the username and password in the command
# files used to start TWS or the Gateway, but this is not recommended for
# security reasons.
#
# If you don't specify them, you will be prompted for them in the usual
# login dialog when TWS starts (but whatever you have specified will be
# included in the dialog automatically: for example you may specify the
# username but not the password, and then you will be prompted for the
# password via the login dialog). Note that if you specify either
# the username or the password (or both) in the command file, then
# IbLoginId and IbPassword settings defined in this file are ignored.
#
#
# The FIX CTCI gateway requires one username and password for FIX order
# routing, and optionally a separate username and password for market
# data connections. You may specify the usernames and passwords using
# the following settings:
#
#       FIXLoginId
#       FIXPassword
#       IbLoginId       (optional - for market data connections)
#       IbPassword      (optional - for market data connections)
#
# Alternatively you can specify the FIX username and password in the
# command file used to start the FIX CTCI Gateway, but this is not
# recommended for security reasons.
#
# If you don't specify them, you will be prompted for them in the usual
# login dialog when FIX CTCI gateway starts (but whatever you have
# specified will be included in the dialog automatically: for example
# you may specify the usernames but not the passwords, and then you will
# be prompted for the passwords via the login dialog). Note that if you
# specify either the FIX username or the FIX password (or both) on the
# command line, then FIXLoginId and FIXPassword settings defined in this
# file are ignored; he same applies to the market data username and
# password.

# IB API Authentication Settings
# ------------------------------

# Your TWS username:

IbLoginId=redacted


# Your TWS password:

IbPassword=redacted


# FIX CTCI Authentication Settings
# --------------------------------

# Your FIX CTCI username:

FIXLoginId=


# Your FIX CTCI password:

FIXPassword=


# Second Factor Authentication Settings
# -------------------------------------

# If you have enabled more than one second factor authentication
# device, TWS presents a list from which you must select the device
# you want to use for this login. You can use this setting to
# instruct IBC to select a particular item in the list on your
# behalf. Note that you must spell this value exactly as it appears
# in the list. If no value is set, you must manually select the
# relevant list entry.

SecondFactorDevice='IB Key Security via IBKR Mobile'


# If you use the IBKR Mobile app for second factor authentication,
# and you fail to complete the process before the time limit imposed
# by IBKR, this setting tells IBC whether to automatically restart
# the login sequence, giving you another opportunity to complete
# second factor authentication.
#
# Permitted values are 'yes' and 'no'.
#
# If this setting is not present or has no value, then the value
# of the deprecated ExitAfterSecondFactorAuthenticationTimeout is
# used instead. If this also has no value, then this setting defaults
# to 'no'.
#
# NB: you must be using IBC v3.14.0 or later to use this setting:
# earlier versions ignore it.

ReloginAfterSecondFactorAuthenticationTimeout=yes


# This setting is only relevant if
# ReloginAfterSecondFactorAuthenticationTimeout is set to 'yes',
# or if ExitAfterSecondFactorAuthenticationTimeout is set to 'yes'.
#
# It controls how long (in seconds) IBC waits for login to complete
# after the user acknowledges the second factor authentication
# alert at the IBKR Mobile app. If login has not completed after
# this time, IBC terminates.
# The default value is 60.

SecondFactorAuthenticationExitInterval=180


# This setting specifies the timeout for second factor authentication
# imposed by IB. The value is in seconds. You should not change this
# setting unless you have reason to believe that IB has changed the
# timeout. The default value is 180.

SecondFactorAuthenticationTimeout=180


# DEPRECATED SETTING
# ------------------
#
# ExitAfterSecondFactorAuthenticationTimeout - THIS SETTING WILL BE
# REMOVED IN A FUTURE RELEASE. For IBC version 3.14.0 and later, see
# the notes for ReloginAfterSecondFactorAuthenticationTimeout above.
#
# For IBC versions earlier than 3.14.0: If you use the IBKR Mobile
# app for second factor authentication, and you fail to complete the
# process before the time limit imposed by IBKR, you can use this
# setting to tell IBC to exit: arrangements can then be made to
# automatically restart IBC in order to initiate the login sequence
# afresh. Otherwise, manual intervention at TWS's
# Second Factor Authentication dialog is needed to complete the
# login.
#
# Permitted values are 'yes' and 'no'. The default is 'no'.
#
# Note that the scripts provided with the IBC zips for Windows and
# Linux provide options to automatically restart in these
# circumstances, but only if this setting is also set to 'yes'.

ExitAfterSecondFactorAuthenticationTimeout=yes


# Trading Mode
# ------------
#
# This indicates whether the live account or the paper trading
# account corresponding to the supplied credentials is to be used.
# The allowed values are 'live' (the default) and 'paper'.
#
# If this is set to 'live', then the credentials for the live
# account must be supplied. If it is set to 'paper', then either
# the live or the paper-trading credentials may be supplied.

TradingMode=live


# Paper-trading Account Warning
# -----------------------------
#
# Logging in to a paper-trading account results in TWS displaying
# a dialog asking the user to confirm that they are aware that this
# is not a brokerage account. Until this dialog has been accepted,
# TWS will not allow API connections to succeed. Setting this
# to 'yes' (the default) will cause IBC to automatically
# confirm acceptance. Setting it to 'no' will leave the dialog
# on display, and the user will have to deal with it manually.

AcceptNonBrokerageAccountWarning=yes


# Login Dialog Display Timeout
#-----------------------------
#
# In some circumstances, starting TWS may result in failure to display
# the login dialog. Restarting TWS may help to resolve this situation,
# and IBC does this automatically.
#
# This setting controls how long (in seconds) IBC waits for the login
# dialog to appear before restarting TWS.
#
# Note that in normal circumstances with a reasonably specified
# computer the time to displaying the login dialog is typically less
# than 20 seconds, and frequently much less. However many factors can
# influence this, and it is unwise to set this value too low.
#
# The default value is 60.

LoginDialogDisplayTimeout=60



# =============================================================================
# 3.   TWS Startup Settings
# =============================================================================

# Path to settings store
# ----------------------
#
# Path to the directory where TWS should store its settings. This is
# normally the folder in which TWS is installed. However you may set
# it to some other location if you wish (for example if you want to
# run multiple instances of TWS with different settings).
#
# It is recommended for clarity that you use an absolute path. The
# effect of using a relative path is undefined.
#
# Linux and macOS users should use the appropriate path syntax.
#
# Note that, for Windows users, you MUST use double separator
# characters to separate the elements of the folder path: for
# example, IbDir=C:\\IBLiveSettings is valid, but
# IbDir=C:\IBLiveSettings is NOT valid and will give unexpected
# results. Linux and macOS users need not use double separators,
# but they are acceptable.
#
# The default is the current working directory when IBC is
# started, unless the TWS_SETTINGS_PATH setting in the relevant
# start script is set.
#
# If both this setting and TWS_SETTINGS_PATH are set, then this
# setting takes priority. Note that if they have different values,
# auto-restart will not work.
#
# NB: this setting is now DEPRECATED. You should use the
# TWS_SETTINGS_PATH setting in the relevant start script.

IbDir=


# Store settings on server
# ------------------------
#
# TWS only: if you wish to store a copy of your TWS settings on
# IB's servers as well as locally on your computer, set this to
# 'yes': this enables you to run TWS on different computers
# with the same configuration, market data lines, etc. If set
# to 'no', running TWS on different computers will not share the
# same settings. If no value is specified, TWS will obtain its
# settings from the same place as the last time this user logged
# in (whether manually or using IBC).
#
# Note that this setting does not apply to Gateway, which does not
# provide this capability.

StoreSettingsOnServer=


# Minimize TWS on startup
# -----------------------
#
# Set to 'yes' to minimize TWS when it starts:

MinimizeMainWindow=no


# Existing Session Detected Action
# --------------------------------
#
# When a user logs on to an IBKR account for trading purposes by any means, the
# IBKR account server checks to see whether the account is already logged in
# elsewhere. If so, a dialog is displayed to both the users that enables them
# to determine what happens next. The 'ExistingSessionDetectedAction' setting
# instructs TWS how to proceed when it displays this dialog:
#
#   * If the new TWS session is set to 'secondary', the existing session continues
#     and the new session terminates. Thus a secondary TWS session can never
#     override any other session.
#
#   * If the existing TWS session is set to 'primary', the existing session
#     continues and the new session terminates (even if the new session is also
#     set to primary). Thus a primary TWS session can never be overridden by
#     any new session).
#
#   * If both the existing and the new TWS sessions are set to 'primaryoverride',
#     the existing session terminates and the new session proceeds.
#
#   * If the existing TWS session is set to 'manual', the user must handle the
#     dialog.
#
# The difference between 'primary' and 'primaryoverride' is that a
# 'primaryoverride' session can be overriden over by a new 'primary' session,
# but a 'primary' session cannot be overriden by any other session.
#
# When set to 'primary', if another TWS session is started and manually told to
# end the 'primary' session, the 'primary' session is automatically reconnected.
#
# The default is 'manual'.

ExistingSessionDetectedAction=primary


# Override TWS API Port Number
# ----------------------------
#
# If OverrideTwsApiPort is set to an integer, IBC changes the
# 'Socket port' in TWS's API configuration to that number shortly
# after startup (but note that for the FIX Gateway, this setting is
# actually stored in jts.ini rather than the Gateway's settings
# file). Leaving the setting blank will make no change to
# the current setting. This setting is only intended for use in
# certain specialized situations where the port number needs to
# be set dynamically at run-time, and for the FIX Gateway: most
# non-FIX users will never need it, so don't use it unless you know
# you need it.

OverrideTwsApiPort=


# Override TWS Master Client ID
# -----------------------------
#
# If OverrideTwsMasterClientID is set to an integer, IBC changes the
# 'Master Client ID' value in TWS's API configuration to that
# value shortly after startup. Leaving the setting blank will make
# no change to the current setting. This setting is only intended
# for use in certain specialized situations where the value needs to
# be set dynamically at run-time: most users will never need it,
# so don't use it unless you know you need it.

OverrideTwsMasterClientID=


# Read-only Login
# ---------------
#
# If ReadOnlyLogin is set to 'yes', and the user is enrolled in IB's
# account security programme, the user will not be asked to perform
# the second factor authentication action, and login to TWS will
# occur automatically in read-only mode: in this mode, placing or
# managing orders is not allowed.
#
# If set to 'no', and the user is enrolled in IB's account security
# programme, the second factor authentication process is handled
# according to the Second Factor Authentication Settings described
# elsewhere in this file.
#
# If the user is not enrolled in IB's account security programme,
# this setting is ignored. The default is 'no'.

ReadOnlyLogin=no


# Read-only API
# -------------
#
# If ReadOnlyApi is set to 'yes', API programs cannot submit, modify
# or cancel orders. If set to 'no', API programs can do these things.
# If not set, the existing TWS/Gateway configuration is unchanged.
# NB: this setting is really only supplied for the benefit of new TWS
# or Gateway instances that are being automatically installed and
# started without user intervention (eg Docker containers). Where
# a user is involved, they should use the Global Configuration to
# set the relevant checkbox (this only needs to be done once) and
# not provide a value for this setting.

ReadOnlyApi=false


# API Precautions
# ---------------
#
# These settings relate to the corresponding 'Precautions' checkboxes in the
# API section of the Global Configuration dialog.
#
# For all of these, the accepted values are:
# - 'yes' sets the checkbox
# - 'no' clears the checkbox
# - if not set, the existing TWS/Gateway configuration is unchanged
#
# NB: thess settings are really only supplied for the benefit of new TWS
# or Gateway instances that are being automatically installed and
# started without user intervention, or where user settings are not preserved
# between sessions (eg some Docker containers). Where a user is involved, they
# should use the Global Configuration to set the relevant checkboxes and not
# provide values for these settings.

BypassOrderPrecautions=

BypassBondWarning=

BypassNegativeYieldToWorstConfirmation=

BypassCalledBondWarning=

BypassSameActionPairTradeWarning=

BypassPriceBasedVolatilityRiskWarning=

BypassUSStocksMarketDataInSharesWarning=

BypassRedirectOrderWarning=

BypassNoOverfillProtectionPrecaution=



# Market data size for US stocks - lots or shares
# -----------------------------------------------
#
# Since IB introduced the option of market data for US stocks showing
# bid, ask and last sizes in shares rather than lots, TWS and Gateway
# display a dialog immediately after login notifying the user about
# this and requiring user input before allowing market data to be
# accessed. The user can request that the dialog not be shown again.
#
# It is recommended that the user should handle this dialog manually
# rather than using these settings, which are provided for situations
# where the user interface is not easily accessible, or where user
# settings are not preserved between sessions (eg some Docker images).
#
# - If this setting is set to 'accept', the dialog will be handled
#   automatically and the option to not show it again will be
#   selected.
#
#   Note that in this case, the only way to allow the dialog to be
#   displayed again is to manually enable the 'Bid, Ask and Last
#   Size Display Update' message in the 'Messages' section of the TWS
#   configuration dialog. So you should only use 'Accept' if you are
#   sure you really don't want the dialog to be displayed again, or
#   you have easy access to the user interface.
#
# - If set to 'defer', the dialog will be handled automatically (so
#   that market data will start), but the option to not show it again
#   will not be selected, and it will be shown again after the next
#   login.
#
# - If set to 'ignore', the user has to deal with the dialog manually.
#
# The default value is 'ignore'.
#
# Note if set to 'accept' or 'defer', TWS also automatically sets
# the API settings checkbox labelled 'Send market data in lots for
# US stocks for dual-mode API clients'. IBC cannot prevent this.
# However you can change this immmediately by setting
# SendMarketDataInLotsForUSstocks (see below) to 'no' .

AcceptBidAskLastSizeDisplayUpdateNotification=accept


# This setting determines whether the API settings checkbox labelled
# 'Send market data in lots for US stocks for dual-mode API clients'
# is set or cleared. If set to 'yes', the checkbox is set. If set to
# 'no' the checkbox is cleared. If defaulted, the checkbox is
# unchanged.

SendMarketDataInLotsForUSstocks=


# Trusted API Client IPs
# ----------------------
#
# NB: THIS SETTING IS ONLY RELEVANT FOR THE GATEWAY, AND ONLY WHEN FIX=yes.
# In all other cases it is ignored.
#
# This is a list of IP addresses separated by commas. API clients with IP
# addresses in this list are able to connect to the API without Gateway
# generating the 'Incoming connection' popup.
#
# Note that 127.0.0.1 is always permitted to connect, so do not include it
# in this setting.

TrustedTwsApiClientIPs=


# Reset Order ID Sequence
# -----------------------
#
# The setting resets the order id sequence for orders submitted via the API, so
# that the next invocation of the `NextValidId` API callback will return the
# value 1. The reset occurs when TWS starts.
#
# Note that order ids are reset for all API clients, except those that have
# outstanding (ie incomplete) orders: their order id sequence carries on as
# before.
#
# Valid values are 'yes', 'true', 'false' and 'no'. The default is 'no'.

ResetOrderIdsAtStart=


# This setting specifies IBC's action when TWS displays the dialog asking for
# confirmation of a request to reset the API order id sequence.
#
# Note that the Gateway never displays this dialog, so this setting is ignored
# for a Gateway session.
#
# Valid values consist of two strings separated by a solidus '/'. The first
# value specifies the action to take when the order id reset request resulted
# from setting ResetOrderIdsAtStart=yes. The second specifies the action to
# take when the order id reset request is a result of the user clicking the
# 'Reset API order ID sequence' button in the API configuration. Each value
# must be one of the following:
#
#    'confirm'
#        order ids will be reset
#
#    'reject'
#        order ids will not be reset
#
#    'ignore'
#        IBC will ignore the dialog. The user must take action.
#
#    The default setting is ignore/ignore

# Examples:
#
#    'confirm/reject' - confirm order id reset only if ResetOrderIdsAtStart=yes
#                       and reject any user-initiated requests
#
#    'ignore/confirm' - user must decide what to do if ResetOrderIdsAtStart=yes
#                       and confirm user-initiated requests
#
#    'reject/ignore'  - reject order id reset if  ResetOrderIdsAtStart=yes but
#                       allow user to handle user-initiated requests

ConfirmOrderIdReset=



# =============================================================================
# 4.   TWS Auto-Logoff, Auto-Restart and Cold Restart
# =============================================================================
#
# TWS and Gateway insist on being restarted every day. Two alternative
# automatic options are offered:
#
#    - Auto-Logoff: at a specified time, TWS shuts down tidily, without
#      restarting. The user must make their own arrangements for restarting
#      as required.
#
#    - Auto-Restart: at a specified time, TWS shuts down and then restarts
#      without the user having to re-authenticate (in particulaar this avoids
#      the need for second factor authentication after the initial login). Make
#      sure to read the section on Auto-Restart limitations and Cold Restart
#      below for important further information.
#
# The normal way to configure the time at which this happens is via the Lock
# and Exit section of the Configuration dialog. Once this time has been
# configured in this way, the setting persists until the user changes it again.
#
# However, there are situations where there is no user available to do this
# configuration, or where there is no persistent storage (for example some
# Docker images). In such cases, the auto-restart or auto-logoff time can be
# set whenever IBC starts with the settings below.
#
# The value, if specified, must be a time in HH:MM AM/PM format, for example
# 08:00 AM or 10:00 PM. Note that there must be a single space between the
# two parts of this value; also that midnight is "12:00 AM" and midday is
# "12:00 PM".
#
# If no value is specified for either setting, the currently configured
# settings will apply. If a value is supplied for one setting, the other
# setting is cleared. If values are supplied for both settings, only the
# auto-restart time is set, and the auto-logoff time is cleared.
#
# Note that for a normal TWS/Gateway installation with persistent storage
# (for example on a desktop computer) the value will be persisted as if the
# user had set it via the configuration dialog.
#
# If you use the "RESTART" command via the IBC command server, and IBC is
# running any version of the Gateway, note that this will set the Auto-Restart
# time in Gateway's configuration dialog to the time at which the restart
# actually happens (which may be up to a minute after the RESTART command is
# issued). To prevent future auto-restarts at this time, you must make sure you
# have set AutoLogoffTime or AutoRestartTime in this file to your desired value
# before running IBC again.

AutoLogoffTime=

AutoRestartTime=


# Auto-Restart limitations and Cold Restart
# -----------------------------------------
#
# If you choose to use auto-restart, you should take note of the considerations
# described at the link below. Note that where this information mentions
# 'manual authentication', closing down and restarting IBC will do the job
# (IBKR does not recognise the existence of IBC in its docuemntation). IBC
# calls this procedure a Cold Restart.
#
#     https://www.ibkrguides.com/tws/usersguidebook/configuretws/auto_restart_info.htm?Highlight=auto-restart
#
# To assist in complying with the requirement to fully shut down TWS on
# Sundays, IBC can be configured with a Cold Restart Time, which is a time
# (specified in your local timeframe) that is after 01:00 US/Eastern. When
# this time is reached on Sundays, IBC tidily closes TWS, and the script then
# reloads IBC thus starting a new instance of TWS and initiating the usual full
# logon. There is thus no need to make any other arrangements for closing and
# restarting at the weekend. For a live account, the time chosen should be
# convenient for you to handle 2FA alerts.
#
# When deciding what time to use for Cold Restart, bear in mind that the offset
# between your timezone and US/Eastern may vary if transitions to and from
# Daylight Saving Time occur on different days. For example in the UK, this
# offset can vary between 4 hours and 6 hours, so in this case it would be
# reasonable to set the Cold Restart time to, for example, 07:05, which is
# always after 01:00 US/Eastern. However if you're not an early riser on
# Sundays you might prefer a more sociable time such as 13:00.
#
# To initiate Cold Restart on Sundays, set this value to <hh:mm>, this being a
# time in your local timezone that is after 01:00 US/Eastern:

ColdRestartTime=



# =============================================================================
# 5.   TWS Tidy Closedown Time
# =============================================================================
#
# Specifies a time at which TWS will close down tidily, with no restart.
#
# This is similar to AutoLogoffTime, but can include a day-of-the-week, whereas
# AutoLogoffTime applies every day. So for example you could use ClosedownAt in
# conjunction with AutoRestartTime to keep TWS running during the week, and to
# shut down on Friday evenings after the markets close, without it running on
# Saturday as well.
#
# To tell IBC to tidily close TWS at a specified time every day, set this value
# to <hh:mm>, for example:
# ClosedownAt=22:00
#
# To tell IBC to tidily close TWS at a specified day and time each week, set
# this value to <dayOfWeek hh:mm>, for example:
# ClosedownAt=Friday 22:00
#
# Note that the day of the week must be specified using your
# default locale. Also note that Java will only accept
# characters encoded to ISO 8859-1 (Latin-1). This means that
# if the day name in your default locale uses any non-Latin-1
# characters you need to encode them using Unicode escapes
# (see http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.3
# for details). For example, to tidily close TWS at 12:00 on
# Saturday where the default locale is Simplified Chinese,
# use the following:
# #ClosedownAt=\u661F\u671F\u516D 12:00

ClosedownAt=



# =============================================================================
# 6.   Other TWS Settings
# =============================================================================

# Accept Incoming Connection
# --------------------------
#
# If set to 'accept', IBC automatically accepts incoming
# API connection dialogs. If set to 'reject', IBC
# automatically rejects incoming API connection dialogs. If
# set to 'manual', the user must decide whether to accept or reject
# incoming API connection dialogs. The default is 'manual'.
# NB: it is recommended to set this to 'reject', and to explicitly
# configure which IP addresses can connect to the API in TWS's API
# configuration page, as this is much more secure (in this case, no
# incoming API connection dialogs will occur for those IP addresses).

AcceptIncomingConnectionAction=


# Allow Blind Trading
# -------------------
#
# If you attempt to place an order for a contract for which
# you have no market data subscription, TWS displays a dialog
# to warn you against such blind trading.
#
#   yes   means the dialog is dismissed as though the user had
#         clicked the 'Ok' button: this means that you accept
#         the risk and want the order to be submitted.
#
#   no    means the dialog remains on display and must be
#         handled by the user.

AllowBlindTrading=no


# Save Settings on a Schedule
# ---------------------------
#
# You can tell TWS to automatically save its settings on a schedule
# of your choosing. You can specify one or more specific times,
# like this:
#
# SaveTwsSettingsAt=HH:MM [ HH:MM]...
#
# for example:
# SaveTwsSettingsAt=08:00   12:30 17:30
#
# Or you can specify an interval at which settings are to be saved,
# optionally starting at a specific time and continuing until another
# time, like this:
#
#SaveTwsSettingsAt=Every n [{mins | hours}] [hh:mm] [hh:mm]
#
# where the first hh:mm is the start time and the second is the end
# time. If you don't specify the end time, settings are saved regularly
# from the start time till midnight. If you don't specify the start time.
# settings are saved regularly all day, beginning at 00:00. Note that
# settings will always be saved at the end time, even if that is not
# exactly one interval later than the previous time. If neither 'mins'
# nor 'hours' is specified, 'mins' is assumed. Examples:
#
# To save every 30 minutes all day starting at 00:00
#SaveTwsSettingsAt=Every 30
#SaveTwsSettingsAt=Every 30 mins
#
# To save every hour starting at 08:00 and ending at midnight
#SaveTwsSettingsAt=Every 1 hours 08:00
#SaveTwsSettingsAt=Every 1 hours 08:00 00:00
#
# To save every 90 minutes starting at 08:00 up to and including 17:43
#SaveTwsSettingsAt=Every 90 08:00 17:43

SaveTwsSettingsAt=


# Confirm Crypto Currency Orders Automatically
# --------------------------------------------
#
# When you place an order for a cryptocurrency contract, a dialog is displayed
# asking you to confirm that you want to place the order, and notifying you
# that you are placing an order to trade cryptocurrency with Paxos, a New York
# limited trust company, and not at Interactive Brokers.
#
#   transmit    means that the order will be placed automatically, and the
#               dialog will then be closed
#
#   cancel      means that the order will not be placed, and the dialog will
#               then be closed
#
#   manual      means that IBC will take no action and the user must deal
#               with the dialog

ConfirmCryptoCurrencyOrders=transmit



# =============================================================================
# 7.   Settings Specific to Indian Versions of TWS
# =============================================================================

# Indian versions of TWS may display a password expiry
# notification dialog and a NSE Compliance dialog. These can be
# dismissed by setting the following to yes. By default the
# password expiry notice is not dismissed, but the NSE Compliance
# notice is dismissed.

# Warning: setting DismissPasswordExpiryWarning=yes will mean
# you will not be notified when your password is about to expire.
# You must then take other measures to ensure that your password
# is changed within the expiry period, otherwise IBC will
# not be able to login successfully.

DismissPasswordExpiryWarning=no
DismissNSEComplianceNotice=yes



# =============================================================================
# 8.   IBC Command Server Settings
# =============================================================================

# Do NOT CHANGE THE FOLLOWING SETTINGS unless you
# intend to issue commands to IBC (for example
# using telnet). Note that these settings have nothing to
# do with running programs that use the TWS API.

# Command Server Port Number
# --------------------------
#
# The port number that IBC listens on for commands
# such as "STOP". DO NOT set this to the port number
# used for TWS API connections.
#
# The convention is to use 7462 for this port,
# but it must be set to a different value from any other
# IBC instance that might run at the same time.
#
# The default value is 0, which tells IBC not to start
# the command server

#CommandServerPort=7462
CommandServerPort=0


# Permitted Command Sources
# -------------------------
#
# A comma separated list of IP addresses, or host names,
# which are allowed addresses for sending commands to
# IBC.  Commands can always be sent from the
# same host as IBC is running on.

ControlFrom=


# Address for Receiving Commands
# ------------------------------
#
# Specifies the IP address on which the Command Server
# is to listen. For a multi-homed host, this can be used
# to specify that connection requests are only to be
# accepted on the specified address. The default is to
# accept connection requests on all local addresses.

BindAddress=


# Command Prompt
# --------------
#
# The specified string is output by the server when
# the connection is first opened and after the completion
# of each command. This can be useful if sending commands
# using an interactive program such as telnet. The default
# is that no prompt is output.
# For example:
#
# CommandPrompt=>

CommandPrompt=


# Suppress Command Server Info Messages
# -------------------------------------
#
# Some commands can return intermediate information about
# their progress. This setting controls whether such
# information is sent. The default is that such information
# is not sent.

SuppressInfoMessages=yes



# =============================================================================
# 9.   Diagnostic Settings
# =============================================================================
#
# IBC can log information about the structure of windows
# displayed by TWS. This information is useful when adding
# new features to IBC or when behaviour is not as expected.
#
# The logged information shows the hierarchical organisation
# of all the components of the window, and includes the
# current values of text boxes and labels.
#
# Note that this structure logging has a small performance
# impact, and depending on the settings can cause the logfile
# size to be significantly increased. It is therefore
# recommended that the LogStructureWhen setting be set to
# 'never' (the default) unless there is a specific reason
# that this information is needed.


# Scope of Structure Logging
# --------------------------
#
# The LogStructureScope setting indicates which windows are
# eligible for structure logging:
#
#    - (default value) if set to 'known', only windows that
#      IBC recognizes are eligible - these are windows that
#      IBC has some interest in monitoring, usually to take
#      some action on the user's behalf;
#
#    - if set to 'unknown', only windows that IBC does not
#      recognize are eligible. Most windows displayed by
#      TWS fall into this category;
#
#    - if set to 'untitled', only windows that IBC does not
#      recognize and that have no title are eligible. These
#      are usually message boxes or similar small windows,
#
#    - if set to 'all', then every window displayed by TWS
#      is eligible.
#

LogStructureScope=known


# When to Log Window Structure
# ----------------------------
#
# The LogStructureWhen setting specifies the circumstances
# when eligible TWS windows have their structure logged:
#
#     - if set to 'open' or 'yes' or 'true', IBC logs the
#       structure of an eligible window the first time it
#       is encountered;
#
#     - if set to 'openclose', the structure is logged every
#       time an eligible window is opened or closed;
#
#    - if set to 'activate', the structure is logged every
#      time an eligible window is made active;
#
#    - (default value) if set to 'never' or 'no' or 'false',
#      structure information is never logged.
#

LogStructureWhen=never


# DEPRECATED SETTING
# ------------------
#
# LogComponents - THIS SETTING WILL BE REMOVED IN A FUTURE
# RELEASE
#
# If LogComponents is set to any value, this is equivalent
# to setting LogStructureWhen to that same value and
# LogStructureScope to 'all': the actual values of those
# settings are ignored. The default is that the values
# of LogStructureScope and LogStructureWhen are honoured.

Note that the field SecondFactorDevice has been configured before deployment.
I have tried both the name of the device as it appears in the portal as well as the "Device ID" from the portal, but neither seem to work and both give me this error

2024-09-04 15:06:10:681 IBC: Setting user name
2024-09-04 15:06:10:682 IBC: Setting password
2024-09-04 15:06:10:688 IBC: Login attempt: 4
2024-09-04 15:06:10:689 IBC: trading mode from settings: tradingMode=live
2024-09-04 15:06:10:721 IBC: Click button: Log In
java.lang.InterruptedException
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:998)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
	at com.sun.javafx.application.PlatformImpl.waitForStart(PlatformImpl.java:256)
	at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:277)
	at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:268)
	at com.sun.javafx.application.PlatformImpl.checkIdle(PlatformImpl.java:392)
	at com.sun.javafx.application.PlatformImpl.setImplicitExit(PlatformImpl.java:346)
	at javafx.application.Platform.setImplicitExit(Platform.java:138)
	at twslaunch.gstat.j.a(j.java:88)
	at twslaunch.gstat.a.d(a.java:215)
	at twslaunch.gstat.a.g(a.java:117)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
2024-09-04 15:06:11:261 IBC: detected frame entitled: Authenticating...; event=Activated
2024-09-04 15:06:11:262 IBC: detected frame entitled: Authenticating...; event=Focused
2024-09-04 15:06:11:661 IBC: detected frame entitled: Authenticating...; event=Lost focus
2024-09-04 15:06:11:661 IBC: detected frame entitled: Authenticating...; event=Deactivated
2024-09-04 15:06:11:663 IBC: detected dialog entitled: Second Factor Authentication; event=Activated
2024-09-04 15:06:11:664 IBC: detected dialog entitled: Second Factor Authentication; event=Focused
2024-09-04 15:06:11:664 IBC: detected dialog entitled: Second Factor Authentication; event=Opened
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2024-09-04 15:06:11:665 IBC: could not find second factor device ''IB Key Security via IBKR Mobile'' in the list
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

So what value can I put there?
What am I missing?

[tomer-ds]

Just to note that I tried also without the single quotes that you see there...
This was a last attempt to try something when all other attempts had already failed

[gnzsnz]

this looks like something to solve with ibgateway/IBC, if you make it work manually it will work with docker

if you find that this setting can be useful here you have a sample PR with changes to incudel a new env var #147

[tomer-ds]

So I discovered that the name of the device is the one that shows in the pop-up when logging in and not the one that shows in the IB Portal UI.
In my case it was IB Key, so problem solved.

I did open a fork with a PR to add the environment variable for the SecondFactorDevice configuration.
tomer-ds#1

[gnzsnz]

solved with #162