release.txt Driver File Contents (

                         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)
   1. Problem (CQ 27289):
      When shutting down Windows, ASFIpMon could log the following error
      in the NT event log: "Error 2 Refreshing BMAPI data".

      BmapiRefreshData() can fail if executed while the operating system
      is shutting down.

      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.

      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)
   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.

      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.

      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)
   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

      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.

      brcmASF_GetAdapterHandle() now (optionally) returns the first
      ASF-capable and ASF-enabled network adapter.

Version 7.2.0 (July 05, 2006)
   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.

      ASFIpMon ignored "blank" default gateway and subnet mask values,
      assuming DHCP was in progress, even if DHCP was not enabled on the 

      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 "" being propagated to the ASF
      Configuration Table in the NVRAM under such circumstances (rather
      than leaving the previously configured value).

   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.

      Requires BMAPI for Windows, v7.4.0 or later.

Version 7.1.4 (March 17, 2006)
   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

      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.

      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.

      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)
   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

      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 ("" when DHCP is in progress). BMAPI for
      Windows, v7.3.10, fixes this problem by reporting the IP address as
      "" 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.

      If an invalid IP address is returned from BMAPI (e.g. "" 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

      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.

      Requires BMAPI for Windows, v7.3.10 for complete fix.

   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)

   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.

      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.

      ASFIpMon now skips ASF-disabled adapters or adapters that do not have
      their corresponding device driver loaded.

      ASF-disabled network adapters will no longer have their IP
      configuration settings automatically synchronized by ASFIpMon.

Version 7.1.1-Windows (March 08, 2005)

   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.
      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.

      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.

      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

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)

   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.

      Did not scan for IP changes immediately upon initialization or during

      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.

      There was no verification that the IP address was not a "link local"

      Do not use the IP address returned from BMAPI if it is a "link local"

      BAsfIpM-Windows already treated "link local" IP addresses as invalid.
      This problem had not actually been reported in AsfIpMon-Linux (yet).


   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)
   1. Problem: (CQ 11160)
      Init script and RPM issues on SUSE Linux 9.
      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.

      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.).

      ASF IP Monitor RPM should now install and run on SUSE Linux systems.

   1. Change:
      Init script (init.d/asfipmon) now supports passing command-line
      arguments to the daemon (e.g. "service asfipmon start -debug").

      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.

      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.

      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.

      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

How To Update Drivers Manually

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.

server: web1, load: 0.96