Peter Memishian wrote:
> I mostly fixed the comment changes, thinking they were trivial and left
> other Sun cstyle error alone. I can see how it is distracting while
> reviewing the actual changes.
It's more than distracting -- it's incorrect. Code for libpcap follows
its own style and
> Due to other work priority I wasn't able to work on fixing and
> addressing these comments. I have finally addressed the comments from
> Meem and made a few other changes. My comments are inline and please
> find an update webrev at:
>
> http://cr.opensolaris.org/~sagun/libpcap/
I see a
Peter Memishian wrote:
> Due to other work priority I wasn't able to work on fixing and
> addressing these comments. I have finally addressed the comments from
> Meem and made a few other changes. My comments are inline and please
> find an update webrev at:
>
> http://cr.opensolaris.org/
Alfred E. Heggestad wrote:
I am wondering if there is a libpcap option to do automatic
reassembly of UDP/IP packets inside the library?
No. Libpcap is, by design and intent, a low-level library for capturing
and sending raw link-layer packets.
If not then
I guess the solution is to implem
Hi
I am using libpcap to sniff UDP packets in a production network,
and analyse the content of certain UDP packets.
Some of the UDP packets are larger than MTU, and split into two
or more IP fragmented packets. I would like to receive the complete
UDP packet in my application..
I am wondering i
Hello,
BTW, I wrote a small module which checks the features member of the
8139 RTL net device.
(see: include/linux/netdevice.h in the kernel tree).
I found out the followoing :
NETIF_F_VLAN_CHALLENGED is not set => VLANs is supported
NETIF_F_HW_VLAN_RX is NOT set => no HW VLAN RX acceleration