Guy Harris wrote:
sagun shakya wrote:
When the features mentioned above integrate into Solaris, an
extensible way to open DLPI links under different directories will be
required. The libdlpi(3LIB) library provides an interface that
provides an abstraction around this so that DLPI applications
sagun shakya wrote:
When the features mentioned above integrate into Solaris, an extensible
way to open DLPI links under different directories will be required. The
libdlpi(3LIB) library provides an interface that provides an abstraction
around this so that DLPI applications do not need to kno
Guy Harris wrote:
sagun shakya wrote:
Being new to the process of submitting patches here, do I need to
provide a patch via the patch tracker in sourceforge.net or uploading
the diff and new files to the bugid will suffice? Please let me know.
So what license/copyright should be applied to p
sagun shakya wrote:
Being new to the process of submitting patches here, do I need to
provide a patch via the patch tracker in sourceforge.net or uploading
the diff and new files to the bugid will suffice? Please let me know.
So what license/copyright should be applied to pcap-libdlpi.c? A l
Hi,
I've added the new files and diffs on for the changes needed in libpcap
for :
1882884 Add libpcap support for new Solaris features
https://sourceforge.net/tracker/?func=detail&atid=469577&aid=1882884&group_id=53067
Being new to the process of submitting patches here, do I need to
provid
I've updated the webrev that fixes your commets.
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
Guy Harris wrote:
It says, in a comment you added to configure.in:
+ # Due to a gcc bug (6619485), the default search path for 32-bit
+ # libraries d
sagun shakya wrote:
I agree, I'll add this to the configure script of tcpdump. This would
also be applicable for wireshark then?
Yes, and probably Snort and other apps using libpcap.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
On Feb 13, 2008, at 6:14 PM, sagun shakya wrote:
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
Why did you add a
AC_CHECK_HEADERS(sys/bufmod.h)
check to configure.in after the check for libdlpi? It's checked for
later in the case
Guy Harris wrote:
On Feb 13, 2008, at 6:14 PM, sagun shakya wrote:
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
It says, in a comment you added to configure.in:
+ # Due to a gcc bug (6619485), the default search path for 32-bit
+
On Feb 13, 2008, at 6:14 PM, sagun shakya wrote:
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
It says, in a comment you added to configure.in:
+ # Due to a gcc bug (6619485), the default search path for 32-bit
+ # libraries does not inclu
On Feb 13, 2008, at 6:14 PM, sagun shakya wrote:
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
Why did you add a
AC_CHECK_HEADERS(sys/bufmod.h)
check to configure.in after the check for libdlpi? It's checked for
later in the case statement if
sagun shakya wrote:
Sebastien Roy wrote:
sagun shakya wrote:
pcap-int.h:
* 71-98: These only apply when compiling with DLPI support.
Perhaps Guy can answer this: Should there be some sort of #ifdef
to make sure that these symbols don't pollute the namespace when
compiled on other platform
sagun shakya wrote:
sagun shakya wrote:
Sebastien Roy wrote:
pcap-int.h:
* 71-98: These only apply when compiling with DLPI support. Perhaps
Guy can answer this: Should there be some sort of #ifdef to make sure
that these symbols don't pollute the namespace when compiled on other
platform
Sebastien Roy wrote:
sagun shakya wrote:
pcap-int.h:
* 71-98: These only apply when compiling with DLPI support.
Perhaps Guy can answer this: Should there be some sort of #ifdef
to make sure that these symbols don't pollute the namespace when
compiled on other platforms?
* 376-385: Same
sagun shakya wrote:
Sebastien Roy wrote:
Sorry, I hadn't generated the webrev. Here are the diffs against my
previous updates.
http://cr.opensolaris.org/~sagun/webrev-seb-comments/
The webrev against the libpcap source are here:
http://cr.opensolaris.org/~sagun/libpcap-review2/
Gr
sagun shakya wrote:
Sebastien Roy wrote:
Thanks Sagun; do you have a webrev that diffs against your previous
updates?
Sorry, I hadn't generated the webrev. Here are the diffs against my
previous updates.
http://cr.opensolaris.org/~sagun/webrev-seb-comments/
The webrev against the libpcap s
sagun shakya wrote:
Hi Seb and Guy,
I've generated a new webrev that incorporates your comments. The webrev
can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
Thanks Sagun; do you have a webrev that diffs against your previous updates?
-Seb
-
This is the tcpdump-workers lis
Sebastien Roy wrote:
Sorry, I hadn't generated the webrev. Here are the diffs against my
previous updates.
http://cr.opensolaris.org/~sagun/webrev-seb-comments/
The webrev against the libpcap source are here:
http://cr.opensolaris.org/~sagun/libpcap-review2/
Great. Only a couple of nits:
Sebastien Roy wrote:
sagun shakya wrote:
Hi Seb and Guy,
I've generated a new webrev that incorporates your comments. The
webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
Thanks Sagun; do you have a webrev that diffs against your previous
updates?
Sorry, I hadn'
Hi Seb and Guy,
I've generated a new webrev that incorporates your comments. The webrev
can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
In the changes, I have not added the support for consumers of libpcap to
have access to raw WIFI frames. I will be sending those changes
> With an 802.11 device, does turning DLPI_NATIVE on put the device into
> monitor mode, or does it just cause it to supply 802.11 headers?
It just causes it to supply 802.11 headers. We may later add support to
monitor.
> Is there a way to query whether a device supports DLPI_NATIVE
>
Guy Harris wrote:
On Feb 1, 2008, at 12:47 PM, sagun shakya wrote:
Sebastien Roy wrote:
* 118-123: I would think that in 2008, most compilers can do a
better job at assigning register use than this (making every single
variable a "register" variable.) You don't have to fix this; th
On Feb 1, 2008, at 12:47 PM, sagun shakya wrote:
Sebastien Roy wrote:
* 118-123: I would think that in 2008, most compilers can do a
better job at assigning register use than this (making every single
variable a "register" variable.) You don't have to fix this; this
is more a question
On Feb 1, 2008, at 10:10 AM, Sebastien Roy wrote:
* 118-123: I would think that in 2008, most compilers can do a
better job at assigning register use than this (making every single
variable a "register" variable.) You don't have to fix this; this
is more a question for those more knowledg
Thanks Seb. I Will send out an updated webrev. My comments are below:
Sebastien Roy wrote:
http://cr.opensolaris.org/~sagun/libpcap/
aclocal.m4 and configure.in
* The macros and code in these files seem to be going out of their way
to support old versions of the public libdlpi library that d
>
> * 101: Perhaps this is a good time to ask about DLPI_NATIVE. For those
> not familiar with the concept, the idea is that some DLPI providers
> masquerade as a well-known media type by default, but can morph into
> their "native" types on-demand. Recent Solaris WiFi DLPI devices behav
sagun shakya wrote:
I've addressed all the comments from below and updated the webrev.
http://cr.opensolaris.org/~sagun/libpcap/
While testing the changes I found out that my changes didn't work on a Solaris
system that had libdlpi.h version
that existed before the public libdlpi.h was integra
I've addressed all the comments from below and updated the webrev.
http://cr.opensolaris.org/~sagun/libpcap/
While testing the changes I found out that my changes didn't work on a Solaris
system that had libdlpi.h version
that existed before the public libdlpi.h was integrated. Some changes had
sagun shakya wrote:
Guy Harris 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. I've undone such changes and
posted a new webrev at:
http://cr.opensolaris.org/~
Thank you for reviewing the changes Guy!
FYI, I've also filed bug # 1882884 " Add libpcap support for new Solaris
features".
Guy Harris 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 reviewi
sagun shakya 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. I've undone such changes and posted a new
webrev at:
http://cr.opensolaris.org/~sagun/libpcap/
pcap
> It does? :-)
>
> Most files mostly use something akin to ANSI C-ified KNF (not
> surprising, given that LBL is run by UCB :-)), which was the Sun style
> back when I was there (in the days when dinosaurs^WSun-3's walked the
> earth).
>
> That's largely the style I use, but I've gott
Guy Harris wrote:
That's largely the style I use, but I've gotten into the habit of
leaving parentheses out of the value in a return statement, but I
might've let that creep into stuff I've written in libpcap - on the
other hand, there was a mix of "return x;" and "return (x);" back in
libpcap
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
It
> 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 must not be changed to c
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/
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/
If you'd like to see the
Thanks Meem for your comments. I'll look at the comments and revise as
needed.
sagun
Peter Memishian wrote:
> As there are some clearview team members planning on reviewing the
> changes and currently there are other high priority work ongoing, I am
> extending the code review timer for ano
As there are some clearview team members planning on reviewing the
changes and currently there are other high priority work ongoing, I am
extending the code review timer for another two weeks. I'm setting the
timer to December 13th, 2007.
The webrev can be found at:
http://cr.opensolaris.org/
Peter Memishian wrote:
> I'll update the webrev after I hear back from others as well.
Personally, I'd prefer to review the version with those changes applied,
since the cruft Guy pointed out is distracting.
I thought it would be more annoying to update the changes if people has
already sta
> I'll update the webrev after I hear back from others as well.
Personally, I'd prefer to review the version with those changes applied,
since the cruft Guy pointed out is distracting.
--
meem
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
I forgot to mention that I would like to hear feedback by November
28th, considering it is holidays for most in the US between November
22-23rd.
Thank you for reviewing the changes. See my responses inline.
Guy Harris wrote:
sagun shakya wrote:
I have developed a prototype with the option
sagun shakya wrote:
I have developed a prototype with the option 1 proposed. I would like to
hear from you if you have any comments or feedback.
The changes made to the libpcap library can be seen at the link below:
http://cr.opensolaris.org/~sagun/libpcap/
Unless you expect there to be syste
Hi,
I would like to hear from you for suggestions on how libpcap can be
updated to libdlpi. I have a couple of possible approaches to make
this addition but they may not necessarily be the best approach:
1) Introduce a new pcap-libdlpi-solaris.c file which will handle all the
versions of Solar
[Reposting as I had the put the wrong mailing list.]
Thank you for your response. Please see my responses inline.
Guy Harris wrote:
Improvements after adding support to libpcap:
-
* Observe all IP layer network traffic, including loopback, IPMP
gro
On Oct 5, 2007, at 3:35 PM, sagun shakya wrote:
Improvements after adding support to libpcap:
-
* Observe all IP layer network traffic, including loopback, IPMP
group, IP tunnel traffic and IP layer network traffic flowing to and
from a zone.
Th
Scope:
--
Add libpcap support for upcoming Solaris features such as vanity naming,
IP Tunneling and IP observability.
Reason for changes:
---
When the features mentioned above integrate into Solaris, an extensible
way to open DLPI links under different directories will be r
49 matches
Mail list logo
