Re: pcap_inject() fails with rc 0 on HP-UX

["Harley Stenzel" <hstenzel () gmail com>]

[ I really can't seem to set the proper account for these
responses.... Here's to fooling the duplicate message detector ]

On 4/4/06, Guy Harris <guy () alum mit edu> wrote:
> Harley Stenzel wrote:
> > 2) It's not clear under what circumstances a rc 0 could ever be
> > returned.  Only on retrun from write() or dlrawdatareq() could rc be
> > 0.
>
> dlrawdatareq() returns the return value of putmsg(), and putmsg()
> returns 0 on success.
>
> I've checked into the main and x.9 branches a change to, on HP-UX, have
> the inject routine return, on success, the number of bytes it was asked
> to write.  That should at least fix that problem.  (Workaround: use
> pcap_sendpacket(), which is defined to return 0 on success.)

OK, that seems to be working well.

> > 3) I ported libnet's transmission code into pcap_inject_dlpi().  It
> > still does not work, but the failure mode is different -- it reports
> > the number of octets written correctly, but the frame is still not on
> > the wire.
>
> I infer from "still not on the wire" that the frame didn't appear on the
> wire with standard libpcap, either.  Is that the case?  If so, my change
> won't fix that - it just changes what's returned to match the
> pcap_inject() API.

I've dug into this deeper, and it it's working now.  I'm still haven't
determined exactly what the problem was; I've changed too many
variables.

It's now working on a different HP-UX 11.23 ia64 box that is not
multihomed using CVS libpcap.  There's also some (ethernet) port
security measures in my environment that was being triggered because
of a bug in my code.  Therefore, I no longer believe that this is a
general packet transmit bug (aside from the already-fixed retrun
code).  I will report if I discover anything of general interest as I
continue my port.

Thank you.

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