On 2006-11-11 16:48, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> This patch still has some points which are in need of a slight
> modification or rearrangement, but it works fine here.
>
> My comments, and a proposed patch to replace it (after some style fixes
> and partial rewrite of the added
On 2006-11-07 10:51, Josh Carroll <[EMAIL PROTECTED]> wrote:
> Below is the patch using strsep instead. I also updated the
> gather_inet function to print a message that a protocol is not
> supported if it exists in /etc/protocols, but does not have a case in
> the gather_inet function.
>
> patch i
On 2006-11-10 11:15, Josh Carroll <[EMAIL PROTECTED]> wrote:
>> Below is the patch using strsep instead. I also updated the
>> gather_inet function to print a message that a protocol is not
>> supported if it exists in /etc/protocols, but does not have a case in
>> the gather_inet function.
>
> So,
Below is the patch using strsep instead. I also updated the
gather_inet function to print a message that a protocol is not
supported if it exists in /etc/protocols, but does not have a case in
the gather_inet function.
So, anyone interested in committing this? :) Do people think this
would be us
Below is the patch using strsep instead. I also updated the
gather_inet function to print a message that a protocol is not
supported if it exists in /etc/protocols, but does not have a case in
the gather_inet function.
patch is here if you'd rather just fetch it:
http://pflog.net/~floyd/sockstat
On other suggestion I'd have it to consider using strsep to parse the
string. I'm pretty the code will be smaller and more readable.
Good point. And yes, per the other mail I do need to fix the
MAX_PROTO_LEN checking, but I'll make sure that is proper when I
update it to use strsep.
Josh
On Mon, Nov 06, 2006 at 03:17:17PM -0800, Josh Carroll wrote:
> >I suggest you use /etc/protocols rather than hard code the protocols.
> >This will make the code future-proof. See getprotoent(3) for the
> >correct way to read /etc/protocols.
>
> Thanks Peter, that's a great idea. Below is a new p
Josh Carroll wrote:
I included a limitation on the maximum length of a proto (mostly to
avoid buffer overflows) and 20 is probably way too large, so I can
lower that if need be.
I'm not sure buffer overflows are prevented:
static int
parse_protos(const char *protospec)
{
...
char
I suggest you use /etc/protocols rather than hard code the protocols.
This will make the code future-proof. See getprotoent(3) for the
correct way to read /etc/protocols.
Thanks Peter, that's a great idea. Below is a new patch that uses
getprotoent(3). For now, to maintain backward compatibilit
* Josh Carroll <[EMAIL PROTECTED]> [04.11.2006 06:15]:
> Below is an initial attempt at the -P argument implementation.
[...]
> if (opt_4 || opt_6) {
> - gather_inet(IPPROTO_TCP);
> - gather_inet(IPPROTO_UDP);
> + if(protos[TCP_PROTO] == 1 || protos_defi
On Fri, 2006-Nov-03 15:50:10 -0800, Josh Carroll wrote:
>I'm not sure if the method used to parse out the protocol is "up to
>snuff" for the FreeBSD project, but I'm welcome to
>suggestions/advice/etc.
I suggest you use /etc/protocols rather than hard code the protocols.
This will make the code fu
Below is an initial attempt at the -P argument implementation.
I'm not sure if the method used to parse out the protocol is "up to
snuff" for the FreeBSD project, but I'm welcome to
suggestions/advice/etc.
I tested the previous behavior and given the exact command line,
sockstat works the same p
On 2006-11-02 20:48, Brooks Davis <[EMAIL PROTECTED]> wrote:
>On Fri, Nov 03, 2006 at 04:46:21AM +0200, Giorgos Keramidas wrote:
>>On 2006-11-02 18:34, Josh Carroll <[EMAIL PROTECTED]> wrote:
>>> >Can we have something that doesn't need one option letter for each
>>> >protocol, protocol family or s
On Fri, Nov 03, 2006 at 04:46:21AM +0200, Giorgos Keramidas wrote:
> On 2006-11-02 18:34, Josh Carroll <[EMAIL PROTECTED]> wrote:
> > >Can we have something that doesn't need one option letter for each
> > >protocol, protocol family or socket type, please? :)
> >
> > I'd be willing to modify it to
On 2006-11-02 18:34, Josh Carroll <[EMAIL PROTECTED]> wrote:
> >Can we have something that doesn't need one option letter for each
> >protocol, protocol family or socket type, please? :)
>
> I'd be willing to modify it to take a -P argument with one of:
>
> tcp
> udp
> tcp,udp
> udp,tcp
>
> If t
Can we have something that doesn't need one option letter for each
protocol, protocol family or socket type, please? :)
I'd be willing to modify it to take a -P argument with one of:
tcp
udp
tcp,udp
udp,tcp
If the consensus is to add -P, I'd be happy to make the changes. I
assume without -P we
On 2006-11-02 15:07, Josh Carroll <[EMAIL PROTECTED]> wrote:
> >I haven't tested yet, but I think in the options structure you
> >should use :
> >
> >+ {"ipv6", 0, NULL, '6'},
> >
> >instead of:
> >+ {"ipv6", 0, NULL, 0},
>
> Oops, th
I haven't tested yet, but I think in the options structure you
should use :
+ {"ipv6", 0, NULL, '6'},
instead of:
+ {"ipv6", 0, NULL, 0},
Oops, thanks for catching that. Fixed that in the new patch below.
also for portability yo
Hi,
I haven't tested yet, but I think in the options structure you
should use :
+ {"ipv6", 0, NULL, '6'},
instead of:
+ {"ipv6", 0, NULL, 0},
also for portability you should use:
no_argument or required_argument as a second field
19 matches
Mail list logo
