IP source address problem/V4.0F/PK7/patch patched?

[Derek Haining]

Configuration: Tru64 UNIX V4.0F w/ PK7.
Two DS20s using ASE clustering.
Each node has a "box" IP address.
Alias IP addresses defined for "services".

The primary problem:
An application attempts to connect to
a second system via a TCP/IP connection.
The second system is behind a firewall that
allows packets from the box's specific IP
address to pass through the firewall.

For some reason the source IP address that
the application gets is sometimes NOT the
box IP address, but an alias address. As
a result the application cannot connect to
the second system.

Note that there are several V4.0F clusters
configured in this manner, and this problem
has only recently surfaced on a particular
system.

The secondary problem:
In the release notes for patch kit 7 there
are several notes which seems to indicate
that this problem has been fixed. To wit:

- Fixes a problem when a default IP
address and a cluster virtual IP address
are interchanged after a network
restart. The defaylt interface address
is used by all outgoing traffic and the
alias address is only usable for the
incoming packets. (Patch 859.00)
- Fixes a problem when using multiple
subnets on a network interface; APR
request packets sent by the system will
contain the IP alias address in the
sender field when that alias is in the
same subnet as the requeted IP address.
(Also Patch 859.00)
- Fixes a problem that sometimes caused
the system to select the incorrect IP
source address for out-going connections
when using IP aliases and subnetting on
a network interface. (Sounds >really<
good, and also in Patch 859.00)

The problem is that PK7 is installed.
I looked at the Patch Kit 8 Release Notes
and saw these same patch descriptions for
Patch 1493.00 and thought "it's fixed",
but when I saw them in the PK7 Release
Notes I began to wonder.

How do I tell if the PK7 patch has been
patched in PK8?

PK8 >also< has this additional note that
appears to be relevant.

- Corrects a problem which could result in
an alias IP address being incorrectly
promoted to being the primary adddress
when another alias is removed. (Patch
1493.00 also.)

The problem is that we have not yet figured
out if there is a specific set of actions
that results in the alias address being
used, so we don't know if this description
fits our problem.

Now this problem was seen once before about 2
months ago on one member of another cluster.
The member was rebooted and the problem has
not been since since it showed up on this
cluster.

So the questions are: what is the likely
cause of this problem. (I know, a bug in the
TCP/IP stack.) Has the fix in PK7 been fixed
in PK8? (I don't know.) Help!

[Joris Denayer]

Derek,

Can you verify that the patch (859.00) is really installed.

Try this

# dupatch -track -type patch | grep 00859

Joris

[Derek Haining]

Joris,

This is what dupatch says:

# dupatch -track -type patch | grep 00859
Patch 00859.00 - Security (SSRT0563U, SSRT0676U, SSRT0742U)

#

[Derek Haining]

I just found out that my query may have been misunderstood. I'll try to restate it.

Suppose there is a bug in the operating system, which we'll call "B". Bug "B" is reported to HP, and it works its way back to the an engineering team. (UBPG or USEG) Someone takes a look at the bug and the code and sees "the problem", and so a fix ("F") is produced to correct bug "B". This fix is released as a patch, and is later incorporated into a Patch Kit ("PK.A"). Wonderful....

Except that bug "B" continues to show up. Bug again is reported to HP. After ascertaining that "F" was already applied to the system, the bug is reported (again) to the engineering team. Again the code is examined, and a new and different fix is created ("F2") to correct bug "B". This fix is incorporated into the next Patch Kit ("PK.B"). Wonderful also.

The problem is that the release notes for PK.B may not mention the fact that the previous fix wasn't a complete fix.

So the question is, how does one tell if a fix was re-fixed? In the situation at hand, the applied patch says that it has fixed the problem, but it clearly has not. The next patch kit *also* says that it fixes the problem. Is this merely a re-packaging of the fix that doesn't fix things, or is this fix one that actually does the job?

[Ralf Puchner]

So the answer is easy:

call HP, ask if the previous escalation number is still fixed in the given patchkit.

The release notes nor the patch description doesn't list all fixes in detail!

[Derek Haining]

OK Ralf, I could do that, but I don't know what the original escalation number is. Do you?

[Ralf Puchner]

but you can use the previous patch id, right?

[Derek Haining]

Well, I'm not sure. These patch IDs don't normally seem to refer to a single patch, but rather to a whole bunch of patches that are combined together. (I never did learn why that was being done. Similarly I never figured out why one group of patches would get a new patch number in the next aggregate patch kit. Note that in my original posting I mentioned that Patch 859.00 seems to have been renamed to Patch 1493.00. I can only guess that the patches are "related", perhaps by virtue of the patched files all belonging to the same base OS subset.)

Since Patch 859.00 contains so many fixes, I suspect that there were a lot of QARs and/or IPMTs that were filed against the components that comprise Patch 859.00. I assumed you meant *that* number, rather than the "packaging" number, and I have no idea was the QAR/IPMT number is.

[Ralf Puchner]

the patch description contains a number for each patch. A patch contains one or more fixes which are listed with each single number and with a list of the replaced modules and their checksum.

If the checksums of the kernel modules in both patches or on your machines are identically then it contains the same release/version.

Btw. using the command "what" on the requested modules will give you a clue if the releases are identically.

And if this will not answer your question, open a case within the HP support center and they will help you finding a solution.

[Derek Haining]

OK. Thanks Ralf!