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
44 matches
Mail list logo
