PHP Report Maker v2.0.0.0 serial key or number

BIG-IP Release Information

Version: 15.1.0.3
Build: 12.0

Cumulative fixes from BIG-IP v15.1.0.2 that are included in this release
Cumulative fixes from BIG-IP v15.1.0.1 that are included in this release
Known Issues in BIG-IP v15.1.x

Functional Change Fixes

TMOS Fixes

Local Traffic Manager Fixes

Global Traffic Manager (DNS) Fixes

Access Policy Manager Fixes

Cumulative fixes from BIG-IP v15.1.0.2 that are included in this release


Vulnerability Fixes

Functional Change Fixes

TMOS Fixes

Local Traffic Manager Fixes

Global Traffic Manager (DNS) Fixes

Application Security Manager Fixes

Application Visibility and Reporting Fixes

Access Policy Manager Fixes

Service Provider Fixes

Cumulative fixes from BIG-IP v15.1.0.1 that are included in this release


Functional Change Fixes

None


TMOS Fixes

Local Traffic Manager Fixes

Cumulative fix details for BIG-IP v15.1.0.3 that are included in this release

903905-2 : Default configuration of security mechanism causes memory leak in TMM

Component: Access Policy Manager

Symptoms:
Over time, memory is allocated by the TMM processes for use as 'xdata' buffers, yet this memory is never de-allocated; it is leaked and becomes unusable. Eventually a disruption of service occurs.

Conditions:
-- The BIG-IP system has been running for 8 weeks or longer without a system restart.

-- The BIG-IP system's internal risk-policy subsystem (used by the security feature modules) has not been configured to communicate with an external risk-policy server.

-- In a vCMP configuration, the BIG-IP 'host' instance is always susceptible, since no security features can be configured in its context.

Impact:
Traffic disrupted while tmm restarts.

Workaround:
None.

Fix:
Default configuration of security mechanism no longer causes memory leak in TMM.

889505 : Added SNMP OIDs for gathering total number of PBAs and percentage of PBAs available

Component: Advanced Firewall Manager

Symptoms:
Several SNMP OIDs need to be added to provide the total number of port block allocations (PBAs) and the percentage of PBAs that are available.

Conditions:
Attempting to retrieve total number of PBAs and percentage of PBAs that are available.

Impact:
Need to manually calculate the values.

Workaround:
Make manual calculations from the current stats or configuration.

Fix:
-- Can now directly gather the total number of PBA and percentage of ports available.

There are new SNMP OIDs from which to pull this data directly. Although there is way to get this information from the current stats or configuration by making some calculations, the SNMP OIDs enables pulling these values directly.

Behavior Change:
The following new MIBs are now available:

F5-BIGIP-LOCAL-MIB::ltmLsnPoolStatTotalPortBlocks
F5-BIGIP-LOCAL-MIB::ltmLsnPoolStatPercentFreePortBlocksSnmp

F5-BIGIP-LOCAL-MIB::ltmFwNatDynamicPoolStatPbaTotalPortBlocks
F5-BIGIP-LOCAL-MIB::ltmFwNatDynamicPoolStatPbaPercentFreePortBlocksSnmp

889477-1 : Modern customization does not enforce validation at password changing

Component: Access Policy Manager

Symptoms:
You can change the password even if there are different values in the fields 'New Password' and 'Confirm Password' or if 'Confirm Password' is empty.

Conditions:
-- Access Policy with 'Modern' customization.
-- Configure an access policy with 'Logon Page' and 'AD Auth' agents.
-- When forced to change passwords, type different values in 'New Password' and 'Confirm Password', or leave 'Confirm Password' empty.

Impact:
The system allows the password change, even though the 'New Password' and 'Confirm Password' do not match.

Workaround:
None.

888569 : Added PBA stats for total number of free PBAs, and percent free PBAs

Component: Advanced Firewall Manager

Symptoms:
There are several port block allocation (PBA) statistics that need to be added.

Conditions:
Attempting to retrieve total number of PBAs and percentage of PBAs that are available.

Impact:
Need to manually calculate the values.

Workaround:
Make manual calculations from the current stats or configuration.

Fix:
The first and second item described are available using the 'tmsh show' command, and the third item is available in the tmstat tables (e.g., reported in response to the command 'tmctl lsn_pool_pba_stat' as total_port_blocks).

-- Total number of port blocks available:
The total amount of port blocks available according to the PBA configuration. For example, if you have 3 IP addresses for NAT pool/source translation and blocks of 128 ports, and ports from 1024 to 65535, then this stat indicates that you have a total of 1509 port blocks. This number is the result of (64511 (ports available) / 128 (ports per block)) * 3 (number of IP addresses)).

-- Percentage of port available (percentage is available in TMSH only):
Using the same example, where there are 1509 total blocks and currently are assigned 600 blocks, then there are 909 blocks free. This stat show that are 60.23% of ports available. (100*free ports / total ports).

-- Directly gather the values.
There are new SNMP OIDs from which to pull this data directly. Although there is way to get this information from the current stats or configuration by making some calculations, the SNMP OIDs enables pulling these values directly.

Behavior Change:
The following new tmstat value is now available, in both 'tmctl fw_lsn_pool_pba_stat' and 'tmctl lsn_pool_pba_stat:

    total_port_blocks

The relevant TMSH show commands have been updated to include these new values:

-- Total Port Blocks
-- Percent Free Port Blocks

883513-1 : Support for QUIC and HTTP/3 draft-27

Component: Local Traffic Manager

Symptoms:
The BIG-IP system supports QUIC and HTTP/3 draft-24 and draft-25. IETF released draft-27 in February 2020, and major browser vendors have announced they intend to widely deploy support for it, unlike previous drafts.

Conditions:
Browser requests draft-27.

Impact:
Connection downgrades to an older version, or fails if the browser cannot downgrade.

Workaround:
None.

Fix:
The BIG-IP system now supports draft-27. (The QUIC community skipped draft-26), has deleted draft-24 support from the implementation, and deprecates support for draft-25.

879025-2 : When processing server-side TLS traffic, LTM may not enforce certificate chain restrictions

Component: Local Traffic Manager

Symptoms:
When processing server-side TLS traffic, LTM may not enforce certificate chain restrictions as expected. TLS traffic is encrypted as expected but under certain conditions certificate authentication restrictions are not enforced

Conditions:
-Server-side SSL profile.
-Certificate chain validation enabled.

Impact:
LTM may not enforce TLS certificate chain restrictions as expected.

Workaround:
None.

Fix:
LTM now processes server-side TLS traffic as expected.

876393-1 : General database error while creating Access Profile via the GUI

Component: Access Policy Manager

Symptoms:
While trying to create an Access profile, the GUI reports a general database error. There are errors in /var/log/tomcat:

profiles.ProfileUtils$SettingsHandler:error - java.sql.SQLException: Column not found: SOURCE in statement [INSERT into
profile_access

Conditions:
This occurs when you try to create an Access Profile of type SSO from the GUI.

Impact:
You are unable to create the profile using the GUI.

Workaround:
You can create the Access Profile using TMSH.

tmsh create access access_test_sso type sso accept-languages add { en } sso-name sso_test1

Fix:
Access Profile of type SSO can now be created and edited from the GUI.

873469-2 : APM Portal Access: Base URL may be set to incorrectly

Solution Article:K24415506

872965-1 : HTTP/3 does not support draft-25

Component: Local Traffic Manager

Symptoms:
Clients attempting to connect with QUIC version 25 and ALPN h3-25 are unable to connect.

Conditions:
An end user client attempts to connect using QUIC version 25 and ALPN h3-25.

Impact:
Attempts to use HTTP/3 with some clients may fail.

Workaround:
None.

Fix:
The BIG-IP system now supports draft-24 and draft-25.

871761-1 : Unexpected FIN from APM virtual server during Access Policy evaluation if XML profile is configured for VS

Component: Access Policy Manager

Symptoms:
APM virtual server user's GUI (e.g., 'Logon page') cannot be rendered by browsers.

Conditions:
This issue is encountered when an XML profile is configured for the APM virtual server.

Impact:
APM end users are unable to get a logon page.

Workaround:
Disable the XML profile for the APM virtual server.

Fix:
There is no unexpected traffic interruption from the APM virtual server when the XML profile is configured for the virtual server.

871653-1 : Access Policy cannot be created with 'modern' customization

Component: Access Policy Manager

Symptoms:
Per-Request Policy (PRP) Access Policy with Customization Type set to Modern cannot be created due to internal error.

Conditions:
Creating a PRP Access Policy with Customization Type set to Modern.

Impact:
Administrator cannot use modern customization.

Workaround:
1. In bigip.conf find the following line:

     apm policy customization-source /Common/standard { }

2. Add the following line:

     apm policy customization-source /Common/modern { }

3. Save the changes.

4. Load the config:

     tmsh load sys config

Fix:
Now modern customization can be used for any Access Policy.

871633-1 : TMM may crash while processing HTTP/3 traffic

Solution Article:K61367237

870957-4 : "Security ›› Reporting : ASM Resources : CPU Utilization" shows TMM has 100% CPU usage

Component: Application Visibility and Reporting

Symptoms:
TMM CPU utilization around 100 percent under Security ›› Reporting : ASM Resources : CPU Utilization.

Conditions:
No special conditions. Only viewing at the stats of TMM CPU in 'Security ›› Reporting : ASM Resources : CPU Utilization'. They will always be in wrong scale, but when the TMM has ~1% CPU usage, it will be presented as 100% CPU usage.

Impact:
Wrong scale is presented and might cause machine's state to be interpreted wrongly.

Workaround:
1. Backup /etc/avr/monpd/monp_asm_cpu_info_measures.cfg file.
2. Run the following:
    $ sed -i 's|tmm_avg_cpu_util)/(count(distinct time_stamp)|tmm_avg_cpu_util)/(count(distinct time_stamp)*100|g' /etc/avr/monpd/monp_asm_cpu_info_measures.cfg
3. Compare the backup file to /etc/avr/monpd/monp_asm_cpu_info_measures.cfg:
    Make sure that there are two lines modified, and that the modification is multiplying with 100 the denominator (i.e., actually dividing the TMM value with 100).
4. To make those changes take affect, run the following command:
    $ bigstart restart monpd

Fix:
Dividing the TMM value with 100 to fit correct scale.

870389-3 : Increase size of /var logical volume to 1.5 GiB for LTM-only VE images

Component: TMOS

Symptoms:
The /var logical volume size of 950 MiB for LTM-only BIG-IP Virtual Edition (VE) images may be too small for some deployments. This can result in result in loss of SSH access.

Conditions:
This applies to deployments that use declarative onboarding for configuration.

Impact:
Complex declarative onboarding configurations may fill the /var logical volume. You are locked out because of the too-small volume.

Workaround:
The workaround is to manually extend the /var logical volume.

For more information, see K14952: Extending disk space on BIG-IP VE :: https://support.f5.com/csp/article/K14952.

Fix:
The size of the /var logical volume was increased from 950 MiB to 1.5 GiB for LTM-only VE images.

Behavior Change:
The size of the /var logical volume was increased from 950MiB to 1.5GiB for LTM-only Virtual Edition images.

868097-3 : TMM may crash while processing HTTP/2 traffic

Solution Article:K58494243

866925-5 : The TMM pages used and available can be viewed in the F5 system stats MIB

Component: TMOS

Symptoms:
The memory pages available and in use are tracked with system statistics. Previously those statistics were available only with the tmctl command in the shell.

Conditions:
When system resource decisions are being made, the information about memory usage is important.

Impact:
It is not feasible to query each BIG-IP device separately.

Workaround:
None.

Fix:
You can query these statistics with SNMP through the F5-BIGIP-SYSTEM-MIB::sysTmmPagesStat table.

866685-1 : Empty HSTS headers when HSTS mode for HTTP profile is disabled

Component: Access Policy Manager

Symptoms:
HTTP Strict-Transport-Security (HSTS) headers have an empty value for some APM Access Policy-generated responses.

Conditions:
This occurs when the following conditions are met:
-- HTTP profile is configured with HSTS mode=disabled (which it is by default).
-- HTTP requests for APM renderer content, including CSS, JS, and image files from the webtop.

Impact:
Some audit scanners can consider the empty value of Strict-Transport-Security headers as a vulnerability. For browsers, the empty HSTS value equals no HSTS in response.

Workaround:
1. Enable HSTS mode for the HTTP profile.
2. Use an iRule to remove the empty HSTS header from responses:

when HTTP_RESPONSE_RELEASE {
    if { [HTTP::header value "Strict-Transport-Security"] eq "" } {
        HTTP::header remove "Strict-Transport-Security"
    }
}

Fix:
When the HTTP profile is configured with HSTS mode=disabled, responses from APM renderer content are now sent without an HSTS header.

866161-1 : Client port reuse causes RST when the security service attempts server connection reuse.

Component: Access Policy Manager

Symptoms:
If the security service attempts server connection reuse, client port reuse causes RST on new connections.

Conditions:
-- Service profile is attached to virtual server.
   or
-- SSL Orchestrator (SSLO) is licensed and provisioned and Service chain is added in the security policy.
-- Security service reuses server-side connection.
-- Client reuses the source port.

Impact:
The BIG-IP system or SSLO rejects new connection from clients when a client reuses the port.

Workaround:
None.

Fix:
The BIG-IP system or SSLO no longer rejects the client connection when the service tries to the reuse server connection and the client reuses the port.

865225-1 : Finisar QSFP28 OPT-0039 modules may not work properly in i15000 and i15800 platforms

Component: TMOS

Symptoms:
The tuning values programmed in the switch are not correct for Finisar OPT-0039 QSFP28 modules.

Conditions:
-- Using Finisar OPT-0039 QSFP28 modules.
-- Running on i15000 and i15800 platforms.

Note: Use 'tmsh list net interface vendor-partnum', to identify the optic modules installed.

Impact:
You might see traffic drop.

Note: Potential issues related to incorrect tuning values come from F5-internal sources and have not been reported in production configurations.

Workaround:
None.

865053-3 : AVRD core due to a try to load vip lookup when AVRD is down

Component: Application Visibility and Reporting

Symptoms:
AVRD cores during startup.

Conditions:
Avrd receives a SIGTERM while it is starting.

Impact:
This can lead to an AVRD core.

Fix:
Added some more checks while loading new configuration. Suppose to reduce the frequent of these occurrences. Still can happen in very rare occasions.

864109-1 : APM Portal Access: Base URL may be set to incorrectly

Solution Article:K24415506

863161-1 : Scheduled reports are sent via TLS even if configured as non encrypted

Component: Application Visibility and Reporting

Symptoms:
The scheduled report email is sent from BIG-IP using TLS even if configured to not use encryption. When the mail server TLS is outdated it may lead to failure of the mail delivery.

Conditions:
The scheduled reports are enabled and configured to use a mail server which reports TLS capability.

Impact:
The minor impact is unexpected behaviour. In rare cases it may lead to malfunction of the scheduled reports.

Fix:
The automatic TLS connection was introduced via udate of the phpmailer module. The current fix disables automatic behaviour such that encryption will be used according to BIG-IP configuration.

863069-1 : Avrmail timeout is too small

Component: Application Visibility and Reporting

Symptoms:
AVR report mailer times out prematurely and reports errors:

AVRExpMail|ERROR|2019-11-26 21:01:08 ECT|avrmail.php:325| PHPMailer exception while trying to send the report: SMTP Error: data not accepted.

Conditions:
Configure reports, which will be sent to e-mail

Impact:
Error response from SMTP server, and the report is not sent

Workaround:
Increase timeout in avrmail.php via bash commands

Fix:
The timeout was increased in avrmail.php

862597-7 : Improve MPTCP's SYN/ACK retransmission handling

Component: Local Traffic Manager

Symptoms:
- MPTCP enabled TCP connection is in SYN_RECEIVED state.
- TMM cores.

Conditions:
- MPTCP is enabled.
- SYN/ACK (with MP_JOIN or MP_CAPABLE) sent by the BIG-IP is not ACKed and needs to be retransmitted.

Impact:
Traffic disrupted while tmm restarts.

Workaround:
Disable MPTCP option in the TCP profile.

Fix:
MPTCP's SYN/ACK retransmission handling is improved.

862557-1 : Client-ssl profiles derived from clientssl-quic fail validation

Component: Local Traffic Manager

Symptoms:
After configuring a clientssl-quic profile, you get a validation error:

01b40001:3: A cipher group must be configured when TLS 1.3 is enabled (validation failed for profile /Common/clientssl-f5quic-udp).

Conditions:
This can occur when using the clientssl-quic built-in profile to build a profile that can serve HTTP/3 over QUIC.

Impact:
You are unable to configure a clientssl profile to work with HTTP/3 + QUIC that is also customized to serve the right certificate, etc.

Workaround:
Modify the clientssl-quic profile to have the following properties:
    cipher-group quic
    ciphers none
This requires the following additional config objects:
ltm cipher group quic {
    allow {
        quic { }
    }
}
ltm cipher rule quic {
    cipher TLS13-AES128-GCM-SHA256,TLS13-AES256-GCM-SHA384
    description "Ciphers usable by QUIC"
}

Fix:
Update the built-in configuration to pass validation.

860881-3 : TMM can crash when handling a compressed response from HTTP server

Component: Local Traffic Manager

Symptoms:
TMM crashes while handling HTTP response

Conditions:
HTTP virtual server performing decompression of response data from a server, e.g. because a rewrite profile is attached to the virtual server.

Impact:
Traffic disrupted while tmm restarts.

Workaround:
Disable compression on the server.

859721-1 : Using GENERICMESSAGE create together with reject inside periodic after may cause core

Component: Service Provider

Symptoms:
In iRules, when "GENERICMESSAGE::message create" is called after "reject" command inside "after -periodic", it may cause core. Below is an example iRules.

when CLIENT_ACCEPTED {
    ... omitted ...
    after 1000 -periodic {
        ... omitted ...
        reject
        GENERICMESSAGE::message create "test"
    }
}

This relates to ID 859113.

Conditions:
GENERICMESSAGE::message create" is called after "reject" inside "after -periodic

Impact:
Traffic disrupted while tmm restarts.

Workaround:
There are 2 possible work-arounds
- use "return" command after "reject" to exit after script immediately after "reject" command is invoked
- add routine to cancel the after in CLIENT_CLOSED event

Fix:
Using GENERICMESSAGE create together with reject inside periodic after no longer cause core

859113-1 : Using "reject" iRules command inside "after" may causes core

Component: Local Traffic Manager

Symptoms:
In iRules, when "reject" is used inside "after -periodic" and it is followed by "GENERICMESSAGE::message create". It may trigger a tmm core. Below is an example iRule.

when CLIENT_ACCEPTED {
    ... omitted ...
    after 1000 -periodic {
        ... omitted ...
        reject
        GENERICMESSAGE::message create "test"
    }
}

This relates to ID 859721

Conditions:
- "reject" is used inside "after -periodic"
- it is followed by "GENERICMESSAGE::message create"

Impact:
Traffic disrupted while tmm restarts.

Workaround:
There are 2 possible work-arounds
- use "return" command after "reject" to exit after script immediately after "reject" command is invoked
- add routine to cancel the after in CLIENT_CLOSED event

Fix:
Using "reject" iRules command inside "after" no longer cause core.

858229-5 : XML with sensitive data gets to the ICAP server

Component: Application Security Manager

Symptoms:
XML with sensitive data gets to the ICAP server, even when the XML profile is not configured to be inspected.

Conditions:
XML profile is configured with sensitive elements on a policy.
ICAP server is configured to inspect file uploads on that policy.

Impact:
Sensitive data will reach the ICAP server.

Workaround:
No immediate workaround except policy related changes

Fix:
An internal parameter, send_xml_sensitive_entities_to_icap was added. It's default is 1 as this is the expected behavior. To disable this functionality, change the internal parameter value to 0.

Behavior Change:
An internal parameter has been added, called send_xml_sensitive_entities_to_icap, and the default value is 1.

When this is changed to 0 (using this command):
 /usr/share/ts/bin/add_del_internal add send_xml_sensitive_entities_to_icap 0
XML requests with sensitive data will not be sent to ICAP.

858025-1 : Proactive Bot Defense does not validate redirected paths

Component: Application Security Manager

Symptoms:
Under certain conditions, Proactive Bot Defense may redirect clients to an unvalidated path.

Conditions:
-Proactive Bot Defense enabled.

Impact:
Clients may be redirected to an unvalidated path.

Workaround:
None.

Fix:
Proactive Bot Defense now validates redirected paths as expected.

854493-5 : Kernel page allocation failures messages in kern.log

Component: TMOS

Symptoms:
Despite having free memory, the BIG-IP system frequently logs kernel page allocation failures to the /var/log/kern.log file. The first line of the output appears similar to the following example:

swapper/16: page allocation failure: order:2, mode:0x104020

After that, a stack trace follows. Note that the process name in the line ('swapper/16', in this example) varies. You may see generic Linux processes or processes specific to F5 in that line.

Conditions:
This issue is known to occur on the following VIPRION blade models:

- B2250 (A112)
- B4300 (A108)
- B4340N (A110)
- B4450 (A114)

Please note the issue is known to occur regardless of whether or not the system is running in vCMP mode, and regardless of whether the system is Active or Standby.

Impact:
As different processes can experience this issue, the system may behave unpredictably. For example, it is possible for a TMOS installation to fail as a result of this issue. Other processes may not exhibit any side effect as a result of this issue. The exact impact depends on which process becomes affected and how this process is designed to handle such a failure to allocate memory.

Workaround:
You can work around this issue by increasing the value of the min_free_kbytes kernel parameter. This controls the amount of memory that is kept free for use by special reserves.

It is recommend to increase this as follows:
-- 64 MB (65536 KB for 2250 blades)
-- 48 MB (49152 KB for B4300 blades)
-- 128 MB (131072 KB for 4450 blades)

You must do this on each blade installed in the system.

When instantiating this workaround, you must consider whether you want the workaround to survive only reboots, or to survive reboots, upgrades, RMAs, etc. This is an important consideration to make, as you should stop using this workaround when this issue is fixed in a future version of BIG-IP software. So consider the pros and cons of each approach before choosing one.

-- If you want the workaround to survive reboots only, perform the following procedure:

1) Log on to the advanced shell (BASH) of the primary blade of the affected VIPRION system.

2) Run the following commands (with the desired amount in KB):

# clsh "sysctl -w vm.min_free_kbytes=131072"
# clsh "echo -e '\n# Workaround for ID753650' >> /etc/sysctl.conf"
# clsh "echo 'vm.min_free_kbytes = 131072' >> /etc/sysctl.conf"

-- If you want the workaround to survive reboots, upgrades, RMAs, etc., perform the following procedure:

1) Log on to the advanced shell (BASH) of the primary blade of the affected VIPRION system.

2) Run the following commands (with the desired amount in KB):

# clsh "sysctl -w vm.min_free_kbytes=131072"
# echo -e '\n# Workaround for ID753650' >> /config/startup
# echo 'sysctl -w vm.min_free_kbytes=131072' >> /config/startup

Note that the last two commands are not wrapped inside 'clsh' because the /config/startup file is already automatically synchronized across all blades.

Once the issue is fixed in a future BIG-IP version, remove the workarounds:

-- To remove the first workaround:

1) Edit the /etc/sysctl.conf file on all blades, and remove the added lines at the bottom.

2) Reboot the system by running 'clsh reboot'. This will restore the min_free_kbytes kernel parameter to its default value for the BIG-IP version you are running.

-- To remove the second workaround:

1) Edit the /config/startup file on the primary blade only, and remove the extra lines at the bottom.

2) Reboot the system by running 'clsh reboot'. This restores the min_free_kbytes kernel parameter to its default value for the BIG-IP version you are running.

To verify the workaround is in place, run the following command (this should return the desired amount in KB):

# clsh "cat /proc/sys/vm/min_free_kbytes"

Fix:
The BIG-IP system no longer experiences kernel page allocation failures.

853613-4 : Improve interaction of TCP's verified accept and tm.tcpsendrandomtimestamp

Component: Local Traffic Manager

Symptoms:
A TCP connection hangs occasionally.

Conditions:
-- The TCP connection is on the clientside.
-- sys db tm.tcpsendrandomtimestamp is enabled (default is disabled).
-- A virtual server's TCP's Verified Accept and Timestamps are both enabled.

Impact:
TCP connections hangs, and data transfer cannot be completed.

Workaround:
You can use either of the following workarounds:
-- Disable tm.tcpsendrandomtimestamp.
-- Disable either the TCP's Verified Accept or Timestamps option.

Fix:
This release provides improved interaction between TCP's Verified Accept and Timestamps options and the tm.tcpsendrandomtimestamp setting.

853545-1 : MRF GenericMessage: Memory leaks if messages are dropped via iRule during GENERICMESSAGE_INGRESS event

Component: Service Provider

Symptoms:
For each message dropped during GENERICMESSAGE_INGRESS, memory is leaked.

Conditions:
Usage of GENERICMESSAGE::message drop iRule command during GENERICMESSAGE_INGRESS event will leak memory.

Impact:
As more memory is leaked, less memory is available for message processing, eventually leading to a core.

Workaround:
Use MR::message drop during MR_INGRESS event instead to drop a message.

Fix:
Usage of GENERICMESSAGE::message drop iRule command no longer leaks memory.

853325-1 : TMM Crash while parsing form parameters by SSO.

Component: Access Policy Manager

Symptoms:
When a form is received in the response, TMM crashes when SSO identifies the form parameter, and logs the Form parameter value and type in SSOv2 form-based passthrough log.

Conditions:
-- When any of the form parameters that SSO receives in the response does not have a value.
-- Passthrough mode is enabled in SSO.

Impact:
TMM crash when Passthrough mode is enabled in SSO. Traffic disrupted while tmm restarts.

Workaround:
Do not use Passthrough mode with SSO.

Fix:
TMM does not crash when Passthrough mode is enabled in SSO, and SSO receives any valid form in a response.

852873-2 : Proprietary Multicast PVST+ packets are forwarded instead of dropped

Component: Local Traffic Manager

Symptoms:
Since BIG-IP does not recognize proprietary multicast MACs like PVST+ (01:00:0c:cc:cc:cd) & STP (01:80:c2:00:00:00) when STP is disabled it won't be able to drop those frames. Instead it would treat those as L2 multicast frames and forward between 2 interfaces.

Conditions:
STP disabled
All platforms except 2000 series, 4000 series, i2000 series, i4000 series and i850

Impact:
PVST+ (01:00:0c:cc:cc:cd), a proprietary multicast MAC will be forwarded instead of discarded even though when STP is disabled

Workaround:
Not available

Fix:
Traffic with Destination MAC as PVST+(01:00:0c:cc:cc:cd) or STP (01:80:c2:00:00:00)is sent to BIG-IP, egress traffic is monitored to check such that MAC is dropped when either or both db variables bcm56xxd.rules.badpdu_drop, bcm56xxd.rules.lldp_drop is enabled and vice-versa

852861-1 : TMM cores intermittently when HTTP/3 tries to use uni-directional streams in 0-RTT scenario

Component: Local Traffic Manager

Symptoms:
TMM cores intermittently when HTTP/3 tries to use uni-directional streams in 0-RTT scenario.

Conditions:
-- Virtual server with QUIC, HTTP/3, HTTP, SSL and httprouter profiles.
-- 0-RTT connection resumption in progress.

Impact:
TMM cores intermittently.

Workaround:
No workaround.

Fix:
Defer sending of early keys from SSL to QUIC. This results in delaying of ingress decryption. HTTP/3 is initialized before receiving decrypted data.

852437-3 : Overly aggressive file cleanup causes failed ASU installation

Solution Article:K25037027

Component: Application Security Manager

Symptoms:
Directory cleanup for for failed Attack Signature Updates (ASU) is too aggressive and may delete needed files in the middle of installation itself, which causes the update to fail.

Conditions:
An ASU runs at the same time as the file cleanup task.

Impact:
The ASU fails to complete successfully.

Workaround:
The default clean interval is 300 seconds (5 minutes).

1. Run the following command to monitor the clean activity:
#tailf /var/log/ts/asmcrond.log | grep CleanFiles

2. Watch for following message in the log:
asmcrond|INFO|Mar 20 21:54:44.389|24036|F5::PeriodicTask::Base::run,,Running Task: CleanFiles

3. Upgrade the ASU immediately.


If 5 minutes is not enough, you can increase the clean interval.

1. Adjust the interval in the /etc/ts/tools/asmcrond.cfg file:

From:
[CleanFiles]
Interval=300

To:
[CleanFiles]
Interval=3000

Important: Do not set Interval too high. 50 minutes (3000 seconds) should be enough.

2. Restart the asmcrond by killing the process. It respawns after several seconds.
ps -ef | grep asmcrond
kill <pid>

3. Monitor the asmcrond.log until you see another Cleanfiles log message.
# tailf /var/log/ts/asmcrond.log | grep CleanFiles

4. Install the ASU; the temp files can stay in the folder for 50 minutes.

5. After the ASU is installed, change the interval back to 300 and restart asmcrond.

6. Make sure asmcrond has been started correctly.
# ps -ef | grep asmcrond
# tailf /var/log/ts/asmcrond.log

Fix:
The directory cleanup does not clean up files that are being actively used for an installation.

852313-4 : VMware Horizon client cannot connect to APM after some time if 'Kerberos Authentication' is configured

Component: Access Policy Manager

Symptoms:
VMware Horizon clients cannot ,connect to APM and /var/log/apm contains hte following error:
... err tmm3[12345]: 01490514:3: (null):Common:00000000: Access encountered error: ERR_BOUNDS. File: ../modules/hudfilter/access/access.c, Function: access_do_internal_retry, Line: 16431

Conditions:
-- Access Policy has 'VMware View Logon Page' agent configured with 'Kerberos Authentication'.
-- The policy has been in use for some time.

Impact:
VMware Horizon client cannot connect to APM after some time.

Workaround:
None.

Fix:
Fixed an issue, where 'VMware View Logon Page' agent configured with 'Kerberos Authentication' does not process logon requests after some time.

852001-1 : High CPU utilization of MCPD when adding multiple devices to trust domain simultaneously

Component: TMOS

Symptoms:

The port settings configuration is the same as with the Device Server – the section called “Device Server” except the Advanced settings called MTU and Idle size.

MTU

An incoming frame is closed at this size even if the stream of bytes continues. Consequently, a permanent data stream coming to the serial interface results in a sequence of MTU-sized frames sent over the network. The default value is set to 1400 bytes.

Idle size

Received frames on COM are closed when the gap between bytes is longer than the Idle value. This parameter defines the maximum gap (in milliseconds) in the received data stream. If the gap exceeds this value, the link is considered idle, the received frame is closed and forwarded to the network.

The default Idle size differs based on the serial baud rate configuration. Remember that the default Idle sizes are set to the minimal possible values:

Each SCADA protocol like Modbus, DNP3, IEC101, DF1 etc. has its unique message format, most importantly its unique way of addressing the remote units. The following text is valid for all M!DGE/RipEX units (further in this the section called “Protocol Server” referred to as a “Unit”) – the special properties for mobile cellular networks (e.g. limitation of broadcasting) are mentioned here. The basic task for the protocol server is to check whether a received frame is within the protocol format and is not corrupted. Most of the SCADA protocols are using some type of Error Detection Code (Checksum, CRC, LRC, BCC, etc.) for data integrity control, so each Unit calculates this code and checks it against the received one.

Cellular mobile network operates in IP environment, so the basic task for the Protocol server is to convert SCADA serial packets to UDP datagrams. The Address translation settings are used to define the destination IP address and UDP port. Then these UDP datagrams are sent to the M!DGE router, processed there and are forwarded as unicasts through the mobile network to their destination. When the gateway defined in the Routing table belongs to the Ethernet LAN, UDP datagrams are instead forwarded to the Ethernet interface. After reaching the gateway, the datagram is forwarded according to the Routing table.

When the UDP datagram reaches its final IP destination, it should be in a M!DGE or RipEX router again. It is processed further according to its UDP port. It can be delivered to the Protocol server where where the datagram is decapsulated and the data received on the serial interface of the source unit are forwarded to COM. The UDP port can also be that of a Terminal server (RipEX) or any other special protocol daemon on Ethernet like Modbus TCP etc. The datagram is then processed according to the respective settings.

	Note
	All timeouts in the parameters described below are derived from the time when the packet is sent into the COM driver, i.e. it includes the transfer time of the packet. Take this into account especially when there is a low Baud rate set in the COM settings.

	Important
	If configuring the Protocol server together with VPN tunnels the “Poll response control” protocol specific parameter must be turned off.

For any SCADA protocol, the Transport protocol and the specific port can be chosen. The default values is UDP port 8882. The unit listens on this port for incoming messages and forwards them to the Protocol server itself.

	Note
	Only UDP protocol is currently implemented.

The parameters described in this section are typical of most protocols.
There is only a link to them in description of the respective Protocol.

Mode of Connected device
List box: Master, Slave
Default = Master
The typical SCADA application follows the Master–Slave scheme where the structure of the message is different for the Master and Slave SCADA units. Because of that, it is necessary to set which type of SCADA unit is connected to the Unit.

	Important
	For the SCADA Master, set Master, for the SCADA Slave, set Slave.

• Master
  The SCADA Master always sends addressed messages to Slaves. Addressing is different for each SCADA protocol, so this is one of the main reasons why an individual Protocol server in each Unit for each SCADA protocol has to be used.

  • Broadcast
    List box: On, Off
    Default = Off
    Some Master SCADA units send broadcast messages to all Slave units. SCADA applications typically use a specific address for such messages. RipEX (Protocol utility) converts such messages into a customized IP broadcast and broadcasts it to all RipEX units resp. to all SCADA units within the network.

    	Note
    	Broadcasts in the cellular network are not possible, thus setting of broadcast functionality is not allowed with M!DGE units.

    If On, the address for broadcast packets in the SCADA protocol has to be defined:

    • Broadcast address format – List box Hex, Dec – format in which the broadcast address is defined.

    • Broadcast address – address in the defined format (Hex, Dec)

  • Address translation
    List box: Table, Mask
    Default = Mask
    In a SCADA protocol, each SCADA unit has a unique address, a “Protocol address”. In a cellular mobile network, each SCADA unit is represented by an IP address (typically that of the ETH interface) and a UDP port (that of the protocol daemon or the COM port server to which the SCADA device is connected via serial interface).
    A translation between the “Protocol address” and the IP address & UDP port pair has to be done. It can be done either via Table or Mask.
    Hence, a SCADA message received from the serial interface is encapsulated into a UDP/IP datagram, where the destination IP address and the destination UDP port are defined according to the settings of the Address translation.

    • Mask
      

      Translation using the Mask is simpler to set, however it has some limitations:
      − all IP addresses used have to be within the same network, which is defined by this Mask
      −the same UDP port is used for all the SCADA units, which results in the following:
      − SCADA devices on all sites have to be connected to the same interface
      − only one SCADA device can be connected to one COM port

      • Base IP
        Default = IP address of the ETH interface
        When creating the IP destination address of UDP datagram, in which the serial SCADA message received from COM is encapsulated, this is created, this Base IP is taken as the basis and only the part defined by the Mask is replaced by the ‘Protocol address’.

      • Mask
        Default = 255.255.255.0
        A part of the Base IP address defined by this Mask is replaced by the ‘Protocol address’. The SCADA protocol address is typically 1 byte, so Mask 255.255.255.0 is most frequently used.

      • UDP port (Interface)
        List box: COM, Manual
        This UDP port is used as the destination UDP port in the UDP datagram in which the serial SCADA packet received from COM1 is encapsulated. The default UDP port for COM can be used or the UDP port can be set manually. If the destination IP address belongs to a Unit and the UDP port is not assigned to COM (COM1(2) or to a Terminal server in case of RipEX) or to any special daemon running in the destination address, the packet is discarded.

        	Note
        	M!DGE use UDP port 8882 for its COM port.

    • Table
      The Address translation is defined in a table. There are no limitations such as when the Mask translation is used. If there are more SCADA units on the RS485 (e.g. with RipEX COM2) their interface, their “Protocol addresses” should be translated to the same IP address and UDP port pair, where the multiple SCADA units are connected. There are 3 possibilities how to fill in the line in the table:
      − One “Protocol address” to one “IP address” (e.g.: 56 −−> 192.168.20.20)
      − Range of “Protocol addresses” to one “IP address” (e.g.: 56 – 62 ===> 192.168.20.20)
      − Range of “Protocol addresses” to range of “IP addresses” (e.g.: 56 – 62 ===> 192.168.20.20 – 26). One option is to write only the start IP and a dash, the system will add the end address itself.

      • Protocol address
        This is the address which is used by the SCADA protocol. It may be set either in Hexadecimal or Decimal format according to the List box value.
        Protocol address length can be 1 byte, but for the DNP3 and UNI protocols support 2 bytes addresses.

      • IP
        The IP address to which Protocol address will be translated. This IP address is used as the destination IP address in the UDP datagram in which serial SCADA packet received from COM is encapsulated.

      • UDP port (Interface)
        This is the UDP port number which is used as the destination UDP port in the UDP datagram in which the serial SCADA message, received from COM, is encapsulated.

      • Note
        You may add a note to each address up to 16 characters long for your convenience. (E.g. “Remote unit #1”).

      • Active
        You may tick/un-tick each translation line in order to make it active/not active.

      • Modify
        Edit, Delete Add buttons allow to edit or to add or to delete a line. The lines can be sorted using up and down arrows.

• Slave
  The SCADA Slave typically only responds to Master requests, however in some SCADA protocols it can communicate spontaneously.
  Messages from the serial interface are processed in a similar way as the Master site, i.e. they are encapsulated in UDP datagrams, processed by the router inside the M!DGE unit and forwarded to the respective interface, typically to the mobile network.

  • Broadcast accept
    List box: On, Off
    Default = Off
    If On, broadcast messages from the Master SCADA device to all Slave units are accepted and sent to connected Slave SCADA unit.

    	Important
    	Broadcasting is not supported with mobile networks.