libpcap
Suggestions what would it take to make libpcap included in the FreeBSD distribution stop tweaking BPF buffer size by default? tcpdump.org people have been nonresponsive about changing it there, so I would suggest it should be patched in FreeBSD to allow applications to control buffer size. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: libpcap
On Fri, Dec 13, 2002 at 12:25:42PM +0200, Petri Helenius wrote: > > Suggestions what would it take to make libpcap included in the FreeBSD > distribution > stop tweaking BPF buffer size by default? > > tcpdump.org people have been nonresponsive about changing it there, so I > would suggest > it should be patched in FreeBSD to allow applications to control buffer > size. Sure, fix the code starting at src/contrib/libpcap/pcap-bpf.c:236, which even says (complete with outdated assumption that 32768 is big): /* * Try finding a good size for the buffer; 32768 may be too * big, so keep cutting it in half until we find a size * that works, or run out of sizes to try. * * XXX - there should be a user-accessible hook to set the * initial buffer size. */ The problem is, you can't add it as a parameter to any of the existing functions without royally breaking existing code. You could add another function for setting it, but that would still produce freebsd specific code. You could just remove that code completely, and let the sysctl specified default take over, but where one libpcap application might have use for a 1MB buffer another might be wasting it completely. But changing stuff like this in FreeBSD pretty much defeats the purpose of having a portable lib. I'd suggest either clubbing them over the head with the need to fix it, modifying your local copy to suit your needs, or better yet (since you obviously don't mind a fbsd specific hack) just use bpf yourself (and you get bpf write functionality too :P). -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: libpcap
On Fri, 13 Dec 2002, Petri Helenius wrote: > Suggestions what would it take to make libpcap included in the FreeBSD > distribution stop tweaking BPF buffer size by default? I use "sysctl debug.dbf_bufsize=131072" on my appliances to increase the BPF buffer size to something more reasonable without having to directly modify libpcap. Guy -- Guy Helmer, Ph.D. http://www.palisadesys.com/~ghelmer Sr. Software Engineer, Palisade Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: libpcap
Richard A Steenbergen wrote: On Fri, Dec 13, 2002 at 12:25:42PM +0200, Petri Helenius wrote: Suggestions what would it take to make libpcap included in the FreeBSD distribution stop tweaking BPF buffer size by default? tcpdump.org people have been nonresponsive about changing it there, so I would suggest it should be patched in FreeBSD to allow applications to control buffer size. Sure, fix the code starting at src/contrib/libpcap/pcap-bpf.c:236, which even says (complete with outdated assumption that 32768 is big): That's what we have done, the problem is that every time the source tree is brought up to RELENG_4_7 or RELENG_4 the change needs to be reapplied, so that's why the appeal to fix it at the source. /* * Try finding a good size for the buffer; 32768 may be too * big, so keep cutting it in half until we find a size * that works, or run out of sizes to try. * * XXX - there should be a user-accessible hook to set the * initial buffer size. */ The problem is, you can't add it as a parameter to any of the existing functions without royally breaking existing code. You could add another function for setting it, but that would still produce freebsd specific code. You could just remove that code completely, and let the sysctl specified default take over, but where one libpcap application might have use for a 1MB buffer another might be wasting it completely. I think the libpcap code should not touch a parameter: - which has a system settable default - which is accessible to an application Specifically since it cannot be set either before or after the pcap stuff initialized. But changing stuff like this in FreeBSD pretty much defeats the purpose of having a portable lib. I'd suggest either clubbing them over the head with the need to fix it, modifying your local copy to suit your needs, or better yet (since you obviously don't mind a fbsd specific hack) just use bpf yourself (and you get bpf write functionality too :P). If I do move somewhere, moving away from bpf (and libpcap) would only improve performance. It's more work but eventually a must. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: libpcap
Guy Helmer wrote: I use "sysctl debug.dbf_bufsize=131072" on my appliances to increase the BPF buffer size to something more reasonable without having to directly modify libpcap. Hope you're not disappointed to find out that modifying that parameter has no effect when using applications which use libpcap since libpcap always sets the buffer size to 32768. (which is exactly the problem I'm complaining about) Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: libpcap
Petri Helenius wrote: > Guy Helmer wrote: > >I use "sysctl debug.dbf_bufsize=131072" on my appliances to increase the > >BPF buffer size to something more reasonable without having to directly > >modify libpcap. > > > Hope you're not disappointed to find out that modifying that parameter has > no effect when using applications which use libpcap since libpcap always > sets the buffer size to 32768. (which is exactly the problem I'm complaining about) You are right - I misremembered how the BIOCSBLEN ioctl worked. My appliances do have a private copy of libpcap with a larger buffer size because of this problem. IMHO, it would be better for the libpcap code to query the default BPF buffer size (BIOCGLEN) and use it if it is larger than the libpcap default size (32768). Then libpcap would obey the buffer size set by the sysctl. Guy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Static routes at startup
Hi, I wonder if I can put stuff in rc.conf to add static routes when my machine boots. Is that possible? I mean, currently I'm adding those routes in rc.local, but I'd really like to see them in rc.conf. Best regards, Carlos. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Static routes at startup
Oh, please disregard. man rc.conf is my friend. Thanks, Carlos. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
IPv6 udp socket bind: EADDRNOTAVAIL?
I have a long running IPv6 daemon that uses both tcp and udp. It accepts requests on a tcp socket, and then performs an action on a udp socket using the same local address that the tcp request came in on. (I am calling bind on the udp socket to allocate a port number to return to the client over the tcp connection.) My problem is that I get intermittent bind failures for the udp socket. I'm trying to understand what is going on here. The udp bind is for the same address as the local address of the tcp socket. (Although the tcp socket was originally bound using the wildcard.) I have tracked this down to the following lines in the kernel code: in6_pcb.c:129 if (!in6_ifaddr) /* XXX broken! */ return (EADDRNOTAVAIL); It looks like the kernel's list of v6 interfaces is empty for some reason. Is that correct, or is there some other reason this list would be empty? Questions: 1. The comment says broken. Anyone know why the comment says that? (The IPv4 version of bind says the same thing...) 2. This system is auto configuring this address... Is it possible that I'm just having this problem because the system is reconfiguring the address at this time? (I must admit that I have not looked at the auto configuration stuff.) Thanks, jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Raw sockets and splnet()
Is there any particular reason that the raw socket implementation in
net/raw_usrreq.c does not require splnet() protection? It seems as though
adding splnet()/splx() calls to the various raw_* routines would greatly
reduce the size of net/rtsock.c, in which many of the routines simply wrap
their raw_ counterparts with splnet()/splx().
Currently, it appears that routing sockets are the only consumer of the raw
socket interface at the moment, but if another consumer were to exist then
they would have to do the same splnet()/splx() hackery I imagine. Wouldn't it
make sense to just put the logic into net/raw_usrreq.c and be done with it?
Any insight would be appreciated. Thanks,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Visit the BSD driver database: http://www.posi.net/freebsd/drivers/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Raw sockets and splnet()
On Fri, 13 Dec 2002, Kelly Yancey wrote:
>
> Is there any particular reason that the raw socket implementation in
> net/raw_usrreq.c does not require splnet() protection? It seems as though
> adding splnet()/splx() calls to the various raw_* routines would greatly
> reduce the size of net/rtsock.c, in which many of the routines simply wrap
> their raw_ counterparts with splnet()/splx().
> Currently, it appears that routing sockets are the only consumer of the raw
> socket interface at the moment, but if another consumer were to exist then
> they would have to do the same splnet()/splx() hackery I imagine. Wouldn't it
> make sense to just put the logic into net/raw_usrreq.c and be done with it?
>
> Any insight would be appreciated. Thanks,
>
> Kelly
>
Actually, as a follow-up to my own question, I don't see how the
splnet()/splx() calls in rtsock.c are necessary at all as all of the pru_*
hooks are called at splnet(). Being that rtsock's pru_* hooks are called at
splnet(), is there any reason not to just extern the various raw_* pru hooks
and reference them directly from route_usrreqs?
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
FreeBSD, The Power To Serve: http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Raw sockets and splnet()
On Fri, 13 Dec 2002, Kelly Yancey wrote:
> Actually, as a follow-up to my own question, I don't see how the
> splnet()/splx() calls in rtsock.c are necessary at all as all of the pru_*
> hooks are called at splnet(). Being that rtsock's pru_* hooks are called at
> splnet(), is there any reason not to just extern the various raw_* pru hooks
> and reference them directly from route_usrreqs?
>
> Kelly
For a better idea of what I am talking about, a diff against 4.7 is
attached. I've confirmed that it compiles and will leave a machine running
with this patch up over the weekend. Any comments would be appreciated,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
FreeBSD, The Power To Serve: http://www.freebsd.org/
Index: raw_cb.h
===
RCS file: /home/cvs/acs/base/src/sys/net/raw_cb.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 raw_cb.h
--- raw_cb.h22 Mar 2002 04:11:00 - 1.1.1.1
+++ raw_cb.h14 Dec 2002 04:17:55 -
@@ -71,6 +71,19 @@ void raw_input __P((struct mbuf *,
struct sockproto *, struct sockaddr *, struct sockaddr *));
extern struct pr_usrreqs raw_usrreqs;
+
+int raw_uabort __P((struct socket *));
+int raw_uattach __P((struct socket *, int, struct proc *));
+int raw_ubind __P((struct socket *, struct sockaddr *, struct proc *));
+int raw_uconnect __P((struct socket *, struct sockaddr *, struct proc *));
+int raw_udetach __P((struct socket *));
+int raw_udisconnect __P((struct socket *));
+int raw_upeeraddr __P((struct socket *, struct sockaddr **));
+int raw_usend __P((struct socket *, int, struct mbuf *, struct sockaddr *,
+ struct mbuf *, struct proc *));
+int raw_ushutdown __P((struct socket *));
+int raw_usockaddr __P((struct socket *, struct sockaddr **));
+
#endif
#endif
Index: raw_usrreq.c
===
RCS file: /home/cvs/acs/base/src/sys/net/raw_usrreq.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 raw_usrreq.c
--- raw_usrreq.c22 Mar 2002 04:11:00 - 1.1.1.1
+++ raw_usrreq.c14 Dec 2002 04:17:55 -
@@ -135,7 +135,7 @@ raw_ctlinput(cmd, arg, dummy)
/* INCOMPLETE */
}
-static int
+int
raw_uabort(struct socket *so)
{
struct rawcb *rp = sotorawcb(so);
@@ -150,7 +150,7 @@ raw_uabort(struct socket *so)
/* pru_accept is EOPNOTSUPP */
-static int
+int
raw_uattach(struct socket *so, int proto, struct proc *p)
{
struct rawcb *rp = sotorawcb(so);
@@ -163,13 +163,13 @@ raw_uattach(struct socket *so, int proto
return raw_attach(so, proto);
}
-static int
+int
raw_ubind(struct socket *so, struct sockaddr *nam, struct proc *p)
{
return EINVAL;
}
-static int
+int
raw_uconnect(struct socket *so, struct sockaddr *nam, struct proc *p)
{
return EINVAL;
@@ -178,7 +178,7 @@ raw_uconnect(struct socket *so, struct s
/* pru_connect2 is EOPNOTSUPP */
/* pru_control is EOPNOTSUPP */
-static int
+int
raw_udetach(struct socket *so)
{
struct rawcb *rp = sotorawcb(so);
@@ -190,7 +190,7 @@ raw_udetach(struct socket *so)
return 0;
}
-static int
+int
raw_udisconnect(struct socket *so)
{
struct rawcb *rp = sotorawcb(so);
@@ -207,7 +207,7 @@ raw_udisconnect(struct socket *so)
/* pru_listen is EOPNOTSUPP */
-static int
+int
raw_upeeraddr(struct socket *so, struct sockaddr **nam)
{
struct rawcb *rp = sotorawcb(so);
@@ -224,7 +224,7 @@ raw_upeeraddr(struct socket *so, struct
/* pru_rcvd is EOPNOTSUPP */
/* pru_rcvoob is EOPNOTSUPP */
-static int
+int
raw_usend(struct socket *so, int flags, struct mbuf *m,
struct sockaddr *nam, struct mbuf *control, struct proc *p)
{
@@ -267,7 +267,7 @@ release:
/* pru_sense is null */
-static int
+int
raw_ushutdown(struct socket *so)
{
struct rawcb *rp = sotorawcb(so);
@@ -278,7 +278,7 @@ raw_ushutdown(struct socket *so)
return 0;
}
-static int
+int
raw_usockaddr(struct socket *so, struct sockaddr **nam)
{
struct rawcb *rp = sotorawcb(so);
Index: rtsock.c
===
RCS file: /home/cvs/acs/base/src/sys/net/rtsock.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 rtsock.c
--- rtsock.c23 Aug 2002 04:10:27 - 1.1.1.2
+++ rtsock.c14 Dec 2002 04:17:55 -
@@ -88,15 +88,6 @@ static void rt_setmetrics __P((u_long,
* It really doesn't make any sense at all for this code to share much
* with raw_usrreq.c, since its functionality is so restricted. XXX
*/
-static int
-rts_abort(struct socket *so)
-{
- int s, error;
- s = splnet();
- error = raw_usrreqs.pru_abort(so);
- splx(s);
- return error;
-}
/* pru_accept
Re: IPv6 udp socket bind: EADDRNOTAVAIL?
> On Fri, 13 Dec 2002 11:27:25 -0700, > "Jeff W. Boote" <[EMAIL PROTECTED]> said: > Questions: > 1. The comment says broken. Anyone know why the comment says that? (The > IPv4 version of bind says the same thing...) I don't know...perhaps this comment was copied from the IPv4 code. > 2. This system is auto configuring this address... Is it possible that > I'm just having this problem because the system is reconfiguring the > address at this time? (I must admit that I have not looked at the auto > configuration stuff.) I don't think so. Even if the system is reconfiguring global addresses, it should have other stable addresses, such as link-local and loopback ones. So the address list starting at in6_ifaddr should rarely be empty. I suspect the EADDRNOTAVAIL error comes from a different part of the kernel (or the kernel has a serious bug). If you give us more information, we may be able to diagnose the problem. The information can include: - the result of ifconfig -a inet6 - the result of netstat -anl -f inet6 - the IPv6 address (and port) being bound in the error case - the (related part of the) source code of the daemon In any case, you should provide the FreeBSD version of your system. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
