Subject: Goofyness w/ llc & netatalk
To: None <tech-net@NetBSD.ORG>
From: Bill Studenmund <wrstuden@loki.stanford.edu>
List: tech-net
Date: 02/08/1997 18:44:06
Howdy!

I've been trying to get NetAtalk working on netbsd, and have had
some level of success. It works great on my office i386. But the
folks who've tried it on mac68k's ran into HUGE problems.

So I put ethernet cards in both macs I have at home, and (after
6 hours of fun) found the problem.

On port-i386, sizeof(struct llc) == 8, while on port-mac68k
sizeof(struct llc) == 10 !!!!!

struct llc is used in forming 802.2 SNAP headers, which EtherTalk
uses. Lots of code calls M_PREPEND(mbuff chain, sizeof(struct llc),...
to add headers to a packet. When the size != 8, the packet's lost
before it ever leaves the computer.

I'm using 1.2 source.

Here's the definition of struct llc from net/if_llc.h:

struct llc {
        u_int8_t llc_dsap;
        u_int8_t llc_ssap;
        union {
            struct {
                u_int8_t control;
                u_int8_t format_id;
                u_int8_t class;
                u_int8_t window_x2;
            } type_u;
            struct {
                u_int8_t num_snd_x2;
                u_int8_t num_rcv_x2;
            } type_i;
            struct {
                u_int8_t control;
                u_int8_t num_rcv_x2;
            } type_s;
            struct {
                u_int8_t control;
                struct frmrinfo {
                        u_int8_t rej_pdu_0;
                        u_int8_t rej_pdu_1;
                        u_int8_t frmr_control;
                        u_int8_t frmr_control_ext;
                        u_int8_t frmr_cause;
                } frmrinfo;
            } type_frmr;
            struct {
                u_int8_t  control;
                u_int8_t  org_code[3];
                u_int16_t ether_type;
            } type_snap;
            struct {
                u_int8_t control;
                u_int8_t control_ext;
            } type_raw;
        } llc_un;
};



The weird thing was that the code always generated a correct
snap header, just adding two extra bytes onto the end.

How can we fix this?

Take care,

Bill