Very Computer

by **Victor Anoutchin** » Thu, 11 Oct 2001 11:01:36

Dear All,

I'm writing communication software over X.25 LAPB under Solaris 7 sparc
64-bit. I'm using SUN's implementation of X.25 - Solstice 9.2 and DLPI
interface over LAPB. Workshop 6u1 compilers. At some stage I need to get
information about DLPI provider and issuing DL_INFO_REQ request on the
stream. In response I expect DL_INFO_ACK structure, which is defined in
sys/dlpi.h as
typedef struct {
t_uscalar_t dl_primitive; /* set to DL_INFO_ACK */
t_uscalar_t dl_max_sdu; /* Max bytes in a DLSDU */
...
t_uscalar_t dl_growth; /* set to zero */

Quote:} dl_info_ack_t;

All members are 32-bit integers in both - 32 and 64-bit compilations. So
according to sparc allignment rules, I expect no holes between structure
members. Totally there is 19 members and sizeof(dl_info_ack_t) = 4 * 19 = 76
(32 and 64 bit).

So my problem is: when I get response from the driver via getmsg call,
providing buffer of 76 bytes, getmsg reports that some data remains
unretrieved. Next getmsg returns more 4 bytes, that look like a garbage. So
totally driver return 80 bytes instead of expected 76. First 76 bytes of 80
is valid dl_info_ack_t response for this DLPI provider, while tailing 4
bytes don't have stable structure from execution to execution.

Does anyone have an idea why this kind of padding may occur ?

Many thanks in advance,
Victor.

by **Victor Anoutchin** » Fri, 12 Oct 2001 13:59:12

> #
> # So my problem is: when I get response from the driver via getmsg call,
> # providing buffer of 76 bytes, getmsg reports that some data remains
> # unretrieved. Next getmsg returns more 4 bytes, that look like a
garbage. So
> # totally driver return 80 bytes instead of expected 76. First 76 bytes
of 80
> # is valid dl_info_ack_t response for this DLPI provider, while tailing
4
> # bytes don't have stable structure from execution to execution.
> #
> # Does anyone have an idea why this kind of padding may occur ?

> Can you put up for retrieval somewhere both the
> local and remote X.25 configuration files?

Thanks for replying. Unfortunately I'm far from live testing and using
software loopback with default parameters.

Quote:> Are the last four bytes of the dl_info_ack_t received
> as zero, like the struct comments say it should be?

Yes, whole struct is filled correctly. The problem is beyond of the end of
the struct, i.e. I'm getting more information than I expect. And these extra
4 bytes don't have any predictable values.
Any clues ?

Victor.

Very Computer

STREAMS, DLPI, Structure padding ? problem

STREAMS, DLPI, Structure padding ? problem

STREAMS, DLPI, Structure padding ? problem