========================== R E L E A S E N O T E S ========================== Broadcom ASF IP Monitor for Windows and Linux Copyright (c) 2000-2007 Broadcom Corporation All rights reserved. --------------------------- Version 7.2.3 (May 1, 2007) --------------------------- Fixes: ====== 1. Problem (CQ 27289): When shutting down Windows, ASFIpMon could log the following error in the NT event log: "Error 2 Refreshing BMAPI data". Cause: BmapiRefreshData() can fail if executed while the operating system is shutting down. Change: Ignore (don't log) any errors from BmapiRefreshData() if ASFIpMon has already received the "STOP" or "SHUTDOWN" service control message from the Windows Service Control Manager. Impact: None. No other action was taken (besides logging the message) when this condition occurred in previous versions of ASFIpMon. -------------------------------- Version 7.2.2 (October 23, 2006) -------------------------------- Fixes: ====== 1. Problem (CQ 27229): When run as a Windows service, ASF IP Monitor would create an Application Event Log entry indicating "ERROR 227 Counting ASF Mailboxes" when the service was started on systems with Broadcom ASF-enabled network controllers with no ASF Offline Mailboxes in the controller's NVRAM. Cause: ASF IP Monitor v7.2.0 and later attempts to store the system's SMBIOS structure table (i.e. "hardware inventory") in the Broadcom ASF-enabled network controller's SMBIOS Offline Mailbox, if one exists in the network controller's NVRAM. The ASF IP Monitor service logs errors as Application Event messages with an "event type" of EVENTLOG_ERROR_TYPE. This particular condition (BmapiGetASFMailboxCount returning something other than BMAPI_OK) was considered an error condition and logged accordingly. Change: The log level (severity) for this particular failure condition (failure to count the number of ASF offline mailboxes) has been reduced from "ERROR" to "INFO". This log message will not meet the default log level of ASF IP Monitor (when run as a service), so the message will not be logged. The log/event message can still be seen if the service is run with an elevated log level (e.g. for debugging purposes). -------------------------------- Version 7.2.1 (October 17, 2006) -------------------------------- Fixes: ====== 1. Problem (CQ 26658): When there are multiple ASF-capable Broadcom network adapters in a system, ASF IP Monitor would only recognize the first enumerated adapter (as discovered by BMAPI). If this adapter had ASF disabled, then no ASF IP configuration propagation would occur. Cause: The BRCMASF library function brcmASF_GetAdapterHandle() would only return the first discovered ASF-capable network adapter, regardless of whether ASF was enabled on this adapter or not. Change: brcmASF_GetAdapterHandle() now (optionally) returns the first ASF-capable and ASF-enabled network adapter. ----------------------------- Version 7.2.0 (July 05, 2006) ----------------------------- Fixes: ====== 1. Problem (CQ 25052): On Windows, a "blank" default gateway or subnet mask value would be ignored, leaving the "current" value in the ASF Configuration Table in NVRAM, even when using a static IP address with no default gateway. Cause: ASFIpMon ignored "blank" default gateway and subnet mask values, assuming DHCP was in progress, even if DHCP was not enabled on the adapter. Change: Do not ignore "blank" default gateway and subnet mask values unless DHCP is enabled on the adapter. This results in a default gateway IP address or subnet mask of "0.0.0.0" being propagated to the ASF Configuration Table in the NVRAM under such circumstances (rather than leaving the previously configured value). Enhancements: ============= 1. Change: Added ASF SMBIOS Mailbox support: If the system has an SMBIOS v2.4 compatible structure table and the Broadcom ASF-network controller has an ASF SMBIOS Mailbox in its NVRAM, this program will propagate the SMBIOS structure table to the SMBIOS Mailbox so it may be remotely queried and read, regardless of the operating/power state of the system. If the SMBIOS structure table has not changed since it was last written to the SMBIOS mailbox, it will not unduly write to the NVRAM, wasting valuable write cycles. Note: Use the "-nosmbios" command-line option to disable SMBIOS Mailbox support. See the readme.txt for more details. Impact: Requires BMAPI for Windows, v7.4.0 or later. ------------------------------ Version 7.1.4 (March 17, 2006) ------------------------------ Fixes: ====== 1. Problem (CQ 23766): On Windows with an ASF-enabled network adapter, the Windows DHCP client service running, and the ASFIpMon service running, changing the IP address of the adapter from one static IP address to another static IP address could result in the adapter being stuck "Acquiring Network IP" and the operating system reporting the adapter's IP address as 0.0.0.0. Cause: When the user changes the static IP address, the Windows network stack will interact with the NDIS driver (adjusting wakeup patterns). At the same time, ASFIpMon is notified of the IP configuration change and interacts with the NDIS Driver to store the new IP address in the adapter's NVRAM. When these two activities occur at the same time, under some conditions, it appears the Windows network stack is not processing a "Link Up" notification from the driver. Change: Added a configurable "write delay" (defaults to 4 seconds) to allow ample time for the interaction between the OS and the driver to settle down before ASFIpMon interacts with the NDIS driver (via the BMAPI BmapiSetASFTable() function). Our tests found the problem was no longer observed with a 2 second write delay. However, we made the default delay 4 seconds for insurance. This "write delay" can be modified (or removed) using the "-wrdelay" command-line option. Impact: The "-wrdelay" option was added to the Linux version as well, but the default value is 0 (no delay) since this problem has only been reported on Windows. -------------------------------- Version 7.1.3 (October 18, 2005) -------------------------------- Fixes: ====== 1. Problem (CQ 14403): If a Windows system running ASFIpMon had DHCP enabled on a Broadcom ASF-enabled network adapter, the network adapter could lose Ethernet link when the DHCP-negotiated IP settings were renegotiated, even though the renegotiated IP settings were ultimately unchanged. The link would be reestablished in a matter of seconds. Under some conditions, another link loss/reestablishment event would occur. Under rare conditions, a continuous Ethernet link loss/reestablishment loop could occur. Cause: If the DHCP configuration lease was released or renewed, ASFIpMon would detect the IP address configuration change from Windows and BMAPI would report the *previous* IP address (from the registry) rather than the *current* IP address ("0.0.0.0" when DHCP is in progress). BMAPI for Windows, v7.3.10, fixes this problem by reporting the IP address as "0.0.0.0" if DHCP is enabled and in progress. Additionally, if the subnet mask or default gateway values were blank (as sometimes may be the case if DHCP is in progress), ASFIpMon would propagate those values down to the network adapter (causing a reset and another link loss event) and then soon after, discover the configured ASF settings do not match the ultimate DHCP-negotiated values and propagate the correct values down to the network adapter, resulting in another reset and another link loss event. Even if a link loss loop did not occur, 2 to 3 losses of link could easily occur in some conditions, depending on the timing of the DHCP negotiation and Windows. Change: If an invalid IP address is returned from BMAPI (e.g. "0.0.0.0" or "169.254.*.*"), DHCP negotiation is assumed to be in progress and the remaining IP configuration settings (subnet mask and default gateway) are also ignored. If a blank (empty) default gateway or subnet mask value is returned from BMAPI, those values will also be ignored. By refusing to propagate invalid intermediate IP settings to the network adapter, ASFIpMon avoids unnecessary adapter resets (resulting in link loss). Additionally, a configurable "configuration delay" (default of 10 seconds) is enforced after any IP configuration changes are propagated to the network adapter. This prevents ASFIpMon from propagating multiple spurious IP configuration changes to the adapter's NVRAM resulting in potentially numerous unnecessary NVRAM write cycles, adapter resets, and losses of Ethernet link. Also, the first BMAPI "ASF configuration change" event received after ASFIpMon calls BmapiSetASFTable is ignored. Since ASFIpMon knows it was the entity to last change the ASF configuration, there is no need to re-load the configuration table and compare for changes. Note: It is normal, and "as designed" for an ASF-enabled network adapter to lose Ethernet link when the IP address configuration (including subnet mask and default gateway) is legitimately changed. Examples: changing a static IP address configuration, changing from a static to a dynamic IP address, or obtaining a *new* (i.e. different) IP address configuration via DHCP. Impact: Requires BMAPI for Windows, v7.3.10 for complete fix. Enhancements: ============= 1. Change: The ASFIpMon Windows NT Service now support the "pause" and "continue" service control codes. This allows the ASFIpMon service to be paused for testing purposes and later resumed, without reverting to stopping and restarting the service. Additionally, when the service is resumed, the ASFIpMon "service loop" is forced to cycle. This is the equivalent of sending the "HUP" signal to ASFIpMon for Linux and is a useful debugging technique (i.e. "net continue asfipmon" on Windows is equivalent to "killall -HUP asfipmon" on Linux). ------------------------------ Version 7.1.2 (April 06, 2005) ------------------------------ Fixes: ====== 1. Problem (CQ 12589): If a system has more than one Broadcom network adapter installed with ASF firmware and configuration tables in each adapter's NVRAM, ASFIpMon will only attempt to synchronize the IP configuration of the first such adapter (which is normal, as-designed behavior). Disabling ASF operation for the adapter or unloading the device driver for the adapter would not prevent ASFIpMon from selecting it as the adapter to use for IP configuration synchronization. If the device driver of the first such adapter was not loaded, ASFIpMon would fail with an error of "!ERROR 20 getting ASF configuration table". Error 20 is the BMAPI "Driver not loaded" result code returned from BmapiGetASFTable(). This makes it difficult for QA engineers to test ASFIpMon functionality on systems with multiple ASF-capable Broadcom network adapters. Cause: ASFIpMon did not skip an ASF-capable adapter if BmapiGetASFTable() returned BMAPI_DRIVER_NOT_LOADED (as happens when the adapter is disabled in Windows), and it did not skip adapters lacking the "ASF enabled" bit in the ASF configuration table enable flags. Change: ASFIpMon now skips ASF-disabled adapters or adapters that do not have their corresponding device driver loaded. Impact: ASF-disabled network adapters will no longer have their IP configuration settings automatically synchronized by ASFIpMon. -------------------------------------- Version 7.1.1-Windows (March 08, 2005) -------------------------------------- Fixes: ====== 1. Problem (CQ 12361): AsfIpMon would hang while loading during system boot. The Windows Service Control Manager (SCM) would timeout after 2 minutes waiting for the service to start, create an event log entry stating "The Broadcom ASF IP Monitor service hung on starting.", continue loading other services at this point, and then AsfIpMon would start successfully. Cause: During start-up, AsfIpMon calls BmapiInitializeEx(). BmapiInitializeEx (from BMAPI v7.2.11) would block on a call to the Win32 API CreateService function, which would wait indefinitely for the SCM database to become unlocked. After a 2 minute timeout, the SCM would continue to load the other services and then release the lock, allowing BmapiInitializeEx() to complete and AsfIpMon to continue starting. Change: AsfIpMon now sets the service status to "running" if BmapiInitializeEx returns BMAPI_SCM_LOCKED (or BMAPI_CAN_NOT_LOCK_NETCFG) before retrying after 10 seconds. This allows the Windows SCM to continue loading services immediately and release the SCM database lock, thus allowing BmapiInitializeEx() to complete successfully. Impact: Requires BMAPI v7.2.13 or later for this fix. ----------------------------------------- Version 7.1.0-Windows (December 15, 2004) ----------------------------------------- This release is a complete re-write of "BAsfIpM" (now known as simply "AsfIpMon") and shares the same source code as AsfIpMon-Linux. It includes the following enhancements (over BAsfIpM): 1. Greatly simplified operation should provide a much higher level of reliability and compatibility. 2. May be run manually and interactively from the command-line, or as a background system (NT) service. 3. Configurable log levels provides easy debugging and error reporting (to the console, system debug log, or NT event log). 4 When run as an NT service with the "-notice" log level option, initialization and termination events are logged to the NT event log, along with any IP configuration change events detected (CQ enhancement request 11317). 5. Configurable scanning interval (defaults to 60 minutes) - much longer than AsfIpMon-Linux due to the facilities provided on Windows to detect IP setting and ASF configuration changes immediately. An infinite (-1) interval timeout may be optionally used. 6. Using Windows IP Helper API and BMAPI-Windows AsfConfigChangeCallback for immediate detection of IP/ASF configuration changes without waiting for an interval timeout. 7. The adapter's PCI device number may be specified for use on systems with multiple ASF-capable Broadcom network adapters. --------------------------------------- Version 7.1.0-Linux (December 15, 2004) --------------------------------------- Fixes: ====== 1. Problem: If the IP settings were changed, it could take 30 seconds (or more depending on the configured scan interval) for the new IP settings to be detected after initialization of AsfIpMon. If the IP settings were changed and the system was shutdown before the scan interval timeout, the new IP settings would not be propagated to the adapter's NVRAM for use by the ASF firmware. Cause: Did not scan for IP changes immediately upon initialization or during termination/shutdown. Change: AsfIpMon now scans for IP settings changes immediately after initialization and when terminating/shutting-down. 2. Problem: It was possible for AsfIpMon to set the IP address to 169.254.*.* (a "link local" IP address per RFC 3330) if the IP setting change was detected while DHCP was in progress or after a failed DHCP attempt. Cause: There was no verification that the IP address was not a "link local" address. Change: Do not use the IP address returned from BMAPI if it is a "link local" address. Note: BAsfIpM-Windows already treated "link local" IP addresses as invalid. This problem had not actually been reported in AsfIpMon-Linux (yet). Enhancements: ============= 1. Change: When IP setting changes are detected and propagated to the adapter, the corresponding log entry includes the IP setting details (both old and new). -------------------------------- Version 7.0.1 (November 2, 2004) -------------------------------- Fixes: ====== 1. Problem: (CQ 11160) Init script and RPM issues on SUSE Linux 9. Cause: SUSE Linux uses the SUSE/LSB (Linux Standards Base) init style, so it stores system service run scripts in /etc/init.d (not /etc/rc.d/init.d) and run scripts must use "rc.status" functions for starting daemons, checking/saving status, etc. Change: Changed init.d/asfipmon to auto-detect SUSE/LSB init style and use the appropriate directories and rc functions (e.g. startproc, checkproc, rc_status, etc.). Impact: ASF IP Monitor RPM should now install and run on SUSE Linux systems. Enhancements: ============= 1. Change: Init script (init.d/asfipmon) now supports passing command-line arguments to the daemon (e.g. "service asfipmon start -debug"). Impact: Passing additional configuration information to the daemon no longer requires editing of the run script (init.d/asfipmon). 2. Change: Treat BMAPI errors while scanning for ASF configuration changes as non-fatal (but logged) errors. Impact: If there is a BMAPI error while scanning for IP configuration changes or saving changes to the adapter's ASF configuration table, the daemon will not be terminated. 3. Change: If inet_addr() fails to parse the IP address, subnet mask, or default gateway from the BMAPI adapter info structure (returns INADDR_NONE), don't use the parsed value. Impact: If BMAPI or the driver ever returns an invalid IP address in one of these fields, the value will not be propagated to the adapter's ASF configuration table. 4. Change: When IP configuration changes are detected, use a lower syslog level (LOG_NOTICE) which *is* printed to the log by default. Impact: This allows easier debugging of (normally infrequent) IP configuration changes without forcing the daemon to log text with "verbose" (i.e. LOG_INFO) or "debug" (LOG_DEBUG) log levels. -------------------------------- Version 7.0.0 (October 25, 2004) -------------------------------- This release is a complete re-write of "basfipmlnxd" (now known as simply "asfipmon"). It includes the following enhancements: 1. Greatly simplified operation should provide a much higher level of reliability and compatibility. 2. May be run manually and interactively from the command-line, or as a background system service (daemon) using the supplied run script. 3. Configurable log levels provides easy debugging (either to the console or system log). 4. Configurable scanning interval (defaults to 30 seconds). 5. Handles the reload (HUP) signal correctly, forcing an immediate re-scan of the adapter's IP settings. 6. The adapter's PCI device number may be specified for use on systems with multiple ASF-capable Broadcom network adapters. 7. Completely portable for future use with other Linux distributions and other UNIX and UNIX-like operating systems (dependant on BMAPI support). 8. Includes support for both manual and RPM-based installation.Download Driver Pack
After your driver has been downloaded, follow these simple steps to install it.
Expand the archive file (if the download file is in zip or rar format).
If the expanded file has an .exe extension, double click it and follow the installation instructions.
Otherwise, open Device Manager by right-clicking the Start menu and selecting Device Manager.
Find the device and model you want to update in the device list.
Double-click on it to open the Properties dialog box.
From the Properties dialog box, select the Driver tab.
Click the Update Driver button, then follow the instructions.
Very important: You must reboot your system to ensure that any driver updates have taken effect.
For more help, visit our Driver Support section for step-by-step videos on how to install drivers for every file type.