DL_ATTACH_REQ fails on a "virtual" PPA

[Enrico Venturi]

Hello colleagues,
I've installed HP APA on a machine;
then I run a proprietary stack which issues a DL_ATTACH_REQ on the nmid related to the link aggregated generated by the HP APA; the command fails and the return message isn't understandable....

Of course the stack properly runs on any other LAN card (btlan driver) since many many years!!

What can I do?

regards
Enrico

[Xianjie Zhang]

Hi, Enrico,

What is the OS version and APA version?
(Run "what /usr/conf/lib/libhp_apa.a").
The DL_ATTACH_REQ should use PPA number instead of nmid. The PPA number of link aggregation should be 900-949 if your OS is 11i. (It is 100-149 for 11.0).
Can you please post the error messages and the code related to DL_ATTACH_REQ?
Can you use "ifconfig" to configure an IP address on the linkagg successfully? If IP is correctly configured, that means the link aggregation handles "DL_ATTACH_REQ" correctly, because "ifconfig" also uses "DL_ATTACH_REQ".

Regards,

Xianje

[Enrico Venturi]

We successfully configured the IP address on that link aggregate, so I guess "our" DL_ATTACH_REQ doesn't work (even if we use PPA 900 as input) ...
I believe the DL_ATTACH_REQ usually works :-)...
maybe there's something not appropriate in our code.

tlrhdq,sys,root # what libhp_apa.a
libhp_apa.a:
HP Auto-Port Aggregation (APA): hp_apa.c: PHNE_28778 B.11.11.11 Apr 1 2003 16:04:53

About the error code: we receive from the stream device a control buffer (buf_len > 0) while data buffer is empty, but I can't decode the buffer content....

[rick jones]

I beleive that something similar has come-up elsewhere in the forums, or perhaps in comp.sys.hp.hpux. APA does not do _all_ the things a normal DLPI provider might, and some third-party code was doing stuff that it really didn't need to or should - something about trying to reset the interface.

You might provide the entire contents of the return message so someone else might try to understand it. errno, and dl_errno and the works.

[Xianjie Zhang]

Hi, Enrico,

The "ACK" for "DL_ATTACH_REQ" only contains control info, no data. You just need to cast the control data as "dl_ok_ack_t" and decode it. If "dl_ok_ack_t->dl_primitive" is DL_OK_ACK, then the "DL_ATTACH_REQ" is successful.

Please check the DLPI programmer guide for example programs.

http://docs.hp.com/en/B2355-90139/index.html

HTH,

Xianjie

[Enrico Venturi]

see the reply mesage received after my DL_ATTACH_REQ:
(gdb) print *err_ack
$2 = {dl_primitive = 3197999093, dl_error_primitive = 3711907495, dl_errno = 2101030891, dl_unix_errno = 3121141789}


(gdb) ptype *err_ack
type = struct {
uint32_t dl_primitive;
uint32_t dl_error_primitive;
uint32_t dl_errno;
uint32_t dl_unix_errno;
}

[rick jones]

OK, I can see what you meand by being indecipherable. Those numbers are no where near where one would expect them to be.

It has been a long time since I've done DLPI stuff so be kind :) - you are certain of the structure definition, and that it is indeed a DL_ERROR_ACK that comes-back and not something else?

[Xianjie Zhang]

Hi, Enrico,

Did your program issue a DL_GET_PPA_REQ just before the DL_ATTACH_REQ?
You mentioned that the stack properly runs on any other LAN card (btlan driver) since many many years, but did you try the same program on a btlan interface AFTER APA is installed?

I suspect that the data buffer of DL_GET_PPA_REQ is not big enough. (After APA installed, the returned data size of DL_GET_PPA_REQ inceased substantially.) If your data buffer is not big enough, there will still be control data left on the stream heard after the DL_GET_PPA_REQ is acked. When you try to read back the control data for DL_ATTACH_REQ, it actually reads the remaining data for DL_GET_PPA_REQ, which will NOT be understandable when you try to decode it as a DL_OK_ACK_T.

The same problem happened for the older version of tcpdump. It works fine before APA installed. But after APA is installed, tcpdump failed due to failure of DL_ATTACH_REQ.

I suspect you hit the same problem as the older tcpdump did.

Xianjie