Re: Unexpected primitive ack DL_UNITDATA_IND

[Guy Harris <guy () alum mit edu>]

On Jun 9, 2004, at 2:55 PM, Rick Jones wrote:

> Guy Harris wrote:
> > Well, we *are* doing an info request after binding, so perhaps it 
> > might happen then.
> > I'm not sure why we're doing that; it dates back to libpcap 0.4.  Do 
> > you know of any reason why the "dl_mac_type" from an info request 
> > before binding to a SAP might be different from the "dl_mac_type" 
> > from a request after binding to a SAP?
>
> I cannot think of one - of course, DLPI being what it is...

I'll experiment (time permitting) with getting rid of the second one on 
Solaris 7 (that's what I have access to); any idea whether any of HP-UX 
{9.x,10.x,11.x} would need the link-layer type to be fetched after the 
bind?

> I thought though that the SAP selected was rather, um, obscure?

Well, on Solaris it's just 0, with DL_PROMISC_SAP requested.

HP-UX 11.x is a bit weird, with INSAP (22) being used to receive and 
OUTSAP (24) being used to send.  It looks as if we use 0 *after* 
requesting DL_PROMISC_SAP (in non-promiscuous mode) or DL_PROMISC_PHYS 
(in promiscuous mode) on 9.x and 10.20.

AIX is a bit annoying - it looks as if you have to select *some* value 
> 0x600 on standard Ethernet and 2 on Token Ring.

> I suppose one thing to consider would be to have some sort of 
> bugcatcher in the code that displayed the entire contents of the 
> unexpected message - say simply in hex. Then one could determin if it 
> matches the bound SAP.

...except that we're trying to run in "SAP promiscuity" mode, so that 
we should get packets from all SAPs.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.