Re: rpc.statd
> Tyler K McGeorge wrote: > > After I set up my BIND name daemon, I started getting the following message: > > Jan 31 16:12:45 palisorrpc.statd: invalid hostname to sm_stat: (then a > whole bunch of gibberish, I would transcribe it, but it uses strange > characters that aren't available in Windows.) > > I assume this means that named isn't starting before an important process... > But I didn't change anything in the default rc... I am so very confused. > > Please help, > Ty This has been posted several times, somebody is trying to gain access to your computer using a weakness in Linux, it has no effectin FreeBSD, if you want to read more, check this page: http://www.cert.org/advisories/CA-2000-17.html saludos raymundo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
rpc.statd
After I set up my BIND name daemon, I started getting the following message: Jan 31 16:12:45 palisor rpc.statd: invalid hostname to sm_stat: (then a whole bunch of gibberish, I would transcribe it, but it uses strange characters that aren't available in Windows.) I assume this means that named isn't starting before an important process... But I didn't change anything in the default rc... I am so very confused. Please help, Ty
Re: Bridging and dummynet seems to destroy dmesg output
> I tried only removing DUMMYNET from config, and the bug continues. Should > I try the changes below? no-they only affect dummynet. But this seems to suggest that the problem is unrelated to my changes... cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bridging and dummynet seems to destroy dmesg output
Luigi Rizzo wrote: > > > Hi, > > > > I sent these files in private. But I remembered that I have another > > unusual config in this machine: is is multiprocessed, and has 10 SCSI disks > > and lots of SYSV shared memory. > > i think SMP might have something to do with it. Yusuf, are you also > using an SMP box ? > > Two things to try (which i also emailed you privately, but others might > be interested too): > + remove the SMP option and see if you still have the problem. Very strange! Removing SMP and APIC_IO options from my config, the kernel does not boot. It shows some errors in IDE interrupts, and panics after lots of errors while probing SCSI devices. Very strange, since GENERIC works without problems. Oh! This remembers me! The bug with ipfw and msgbuf also happens in GENERIC -stable! I tried only removing DUMMYNET from config, and the bug continues. Should I try the changes below? > + if you are not using bridging, keep the SMP option and change >splimp -> splnet in ip_dummynet.c >and see if the problem is still there. Jonny -- João Carlos Mendes Luís [EMAIL PROTECTED] Networking Engineer [EMAIL PROTECTED] Internet via Embratel [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
sendfile()
Hi, I don't want to bring flame war, but the following Linus' words may be right: - The fact I dislike about the HP-UX implementation is that it is so obviously stupid. And I have to say that I absolutely despise the BSD people. They did sendfile() after both Linux and HP-UX had done it, and they must have known about both implementations. And they chose the HP-UX braindamage, and even brag about the fact that they were stupid and didn't understand TCP_CORK (they don't say so in those exact words, of course - they just show that they were stupid and clueless by the things they brag about). Oh, well. Not everybody can be as goodlooking as me. It's a curse. - Also note how I said that it is the BSD people I despise. Not the HP-UX implementation. The HP-UX one is not pretty, but it works. But I hold open source people to higher standards. They are supposed to be the people who do programming because it's an art-form, not because it's their job. David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
On Thu, Feb 01, 2001 at 01:31:39PM +0800, bsddiy wrote: > I don't want to bring flame war, but the following Linus' words may > be right: Did you have a point to make here? If so, I missed it. Kris PGP signature
Re: rpc.statd
Tyler K McGeorge ([EMAIL PROTECTED]) wrote: > After I set up my BIND name daemon, I started getting the following message: > > Jan 31 16:12:45 palisorrpc.statd: invalid hostname to sm_stat: (then a whole >bunch of gibberish, I would transcribe it, but it uses strange characters that aren't >available in Windows.) > > I assume this means that named isn't starting before an important process... But I >didn't change anything in the default rc... I am so very confused. Don't worry, methinks you are merely being probed for Linux-bugs. rpc.statd was flawed in some popular Linux distributions; users of those distributions who failed to install the correct binary patch (what a stupid way to distribute bug fixes!) will eventually find their machines probed and exploited. FreeBSD is not vulnerable. I used to get that message several times a month until I firewalled the portmapper service. See http://www.cert.org/advisories/CA-2000-17.html for more details. -- Christopher Farley www.northernbrewer.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: Routes and tunnels
Hi Thanks for the replies. Sorry, I forgot to say that I was using to the tunnel to connect to the remote site with interface address of 132.146.113.1 and I am not using the tunnels to send the packets to the local address, 132.146.115.164. I am trying to use tunnels as point to point links for running routing over them. But the end result is that I do not see a packet destined for the end point of the tunnel, 132.146.113.1 on the wire. Parminder Mudhar __ [EMAIL PROTECTED] > -Original Message- > From: Mudhar,PS,Parminder,CEG2 R > Sent: Wednesday, January 31, 2001 5:02 PM > To: '[EMAIL PROTECTED]' > Subject: Routes and tunnels > > Hi > > I don't know if this is intentional or a bug, but if ifconfig is used to > configure a point to point device, such as 'tun' or the newer 'gif' > devices, then the kernel insists on installing a route where the > destination is the end point of the tunnel, the gateway is the source of > the tunnel and the interface is the device itself. I have checked this in > version 3.2+KAME, what I a using, and also on version 4.1. The effect of > the above is that the packet that uses the tunnel will never appear on the > wire. > > Here is an output > > the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 > the_swamp# netstat -rnf inet > Routing tables > > Internet: > DestinationGatewayFlags Netif Expire > default132.146.115.1 UGSc10 fxp1 > 127.0.0.1 127.0.0.1 UH 04 lo0 > 132.145.113.1 132.146.115.164UH 00 gif0 > 132.146.115/24 link#2 UC 00 fxp1 => > 132.146.115.1 0:30:19:9a:e4:71 UHLW20 fxp1 > 460 > > I am also interested in using gated with point to point tunnels, but gated > also insists on doing the above for point to point links. > > I thank you in advance for any advice you may have. > > Parminder Mudhar > __ > [EMAIL PROTECTED] > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bridging and dummynet seems to destroy dmesg output
CC: -stable, this seens not to be a -net related problem. Yusuf Goolamabbas wrote: > > > Hi, > > > > > > I sent these files in private. But I remembered that I have another > > > unusual config in this machine: is is multiprocessed, and has 10 SCSI disks > > > and lots of SYSV shared memory. > > > > i think SMP might have something to do with it. Yusuf, are you also > > using an SMP box ? > > No, I am using a "book-PC" type machine [small Celeron] dmesg attached > > I reinstalled my shaper box with 4.2 release today and cvsuped to > 4.2-stable. > > The strange thing is that if I turn on verbose logging (via sysctl) but > don't turn on verbose_limit, dmesg seems to get corrupted. If I have > verbose_limit set to say 10, dmesg works and does not get overridden > with log messages from ipfw [which goes to /var/log/security] > > This is what I have in my /etc/sysctl.conf > > net.link.ether.bridge_ipfw=1 > net.link.ether.bridge=1 > net.inet.ip.fw.verbose=1 > net.inet.ip.fw.verbose_limit=10 > > So, it seems some combination of verbose logging and non setting of > verbose limit [or the default setting of verbose limit] is causing this > problem Indeed, the problem does not start at the very first message. It takes some time, after I start the nmap attack, to corrupt the buffer. You observation may just mean that the number of messages needed to corrupt the buffer is greater than 10. Maybe even this is the reason Luigi does not see any problem with picobsd. The fact that GENERIC also shows this problem is banging on my head. Why nobody else has seen this? What kind of kernel messages create this problem? IIRC IPFW does not use any kind of printf, just log(9). What other kernels modules use this function? How could we generate such messages to test? Just in case nobody has yet noticed, this is for sure a case of lost pointer. And if the kernel is not yet crashing is just mere luck! Time to audit changes since -release? I'd love to help more, but I've been far from FreeBSD cvs lists for a long time now. Jonny -- João Carlos Mendes Luís [EMAIL PROTECTED] Networking Engineer [EMAIL PROTECTED] Internet via Embratel [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPComp question
> No, but the problem is that there was no increase (actually, no > record at all) under ipsec: IPComp. The number on the sending > side seemed right. The increase matched the ones I saw from > tcpdump. It looked like the IPComp packets either weren't > logged or were dropped for some reason. send the following items. - full tcpdump output - netstat -sn before, and after the test (on both ends) - full SA configuration on both sides (previous email may have included it) - ifconfig -a output, on both ends - netstat -rn output, on both ends - simple network diagram (like intermediate routers) between both ends itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: Routes and tunnels
On Thu, 1 Feb 2001 [EMAIL PROTECTED] wrote: > Hi > > Thanks for the replies. > > Sorry, I forgot to say that I was using to the tunnel to connect to the > remote site with interface address of 132.146.113.1 and I am not using the > tunnels to send the packets to the local address, 132.146.115.164. I am > trying to use tunnels as point to point links for running routing over them. > > But the end result is that I do not see a packet destined for the end point > of the tunnel, 132.146.113.1 on the wire. WHat do you mean on the wire? THe other side? Is the other side setup to tunnel? How did you configure the outside IP'w with gifconfig ? Need a tad more details to help you out. the behavior you described below about the kernel adding routes is correct as a 'gif' tunnel is a directly connect interface. Most OS's do the same thing with directly connect interfaces. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve " > > -Original Message- > > From: Mudhar,PS,Parminder,CEG2 R > > Sent: Wednesday, January 31, 2001 5:02 PM > > To: '[EMAIL PROTECTED]' > > Subject:Routes and tunnels > > > > Hi > > > > I don't know if this is intentional or a bug, but if ifconfig is used to > > configure a point to point device, such as 'tun' or the newer 'gif' > > devices, then the kernel insists on installing a route where the > > destination is the end point of the tunnel, the gateway is the source of > > the tunnel and the interface is the device itself. I have checked this in > > version 3.2+KAME, what I a using, and also on version 4.1. The effect of > > the above is that the packet that uses the tunnel will never appear on the > > wire. > > > > Here is an output > > > > the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 > > the_swamp# netstat -rnf inet > > Routing tables > > > > Internet: > > DestinationGatewayFlags Netif Expire > > default132.146.115.1 UGSc10 fxp1 > > 127.0.0.1 127.0.0.1 UH 04 lo0 > > 132.145.113.1 132.146.115.164UH 00 gif0 > > 132.146.115/24 link#2 UC 00 fxp1 => > > 132.146.115.1 0:30:19:9a:e4:71 UHLW20 fxp1 > > 460 > > > > I am also interested in using gated with point to point tunnels, but gated > > also insists on doing the above for point to point links. > > > > I thank you in advance for any advice you may have. > > > > Parminder Mudhar > > __ > > [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: FreeBSD Security Advisory: FreeBSD-SA-01:18.bind
< said: > server. If you think specifying multiple recursive servers in > /etc/resolv.conf will save a heavily loaded host, like a mail box, you > will be in for one hellofa surprise when your primary resolver goes down! A ``heavily loaded host'' should only have one nameserver entry in /etc/resolv.conf: 127.0.0.1. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: Routes and tunnels
Nick Thanks for taking the time to reply to query. Here is more information that may help you. Having created the tunnel, I create a route to a node that I know is on the other side of the tunnel. When I try to ping this site, or even the tunnel end, I get a 'sendto: Network is down' reply from ping. I then use tcpdump to monitor the packets that should appear on the ethernet, but I don't see any packets that have destination address of the tunnel end. It seems to me that what is happening is the following: I want to send a packet where the destination address is the tunnel end ip_output gets this packet and looks up a route for this destination this route contains the next hop gateway, and the interface to use (gif) ip_output places the packet in the output queue of the interface (gif) which then proceeds to append an outer header to the packet its been given. This outer header will have the source address set to the tunnel source address and the destination set to the address of the tunnel end. The packet gets given to ip_ouput to send it to the destination address, which is the address of the tunnel end, and the route contains a reference to the interface (gif), etc. In other words, since the route entries contain an entry to a destination address which is the address of the end point of the tunnel and the interface to use is the tunnel interface (gif), what you are doing is appending an outer IP packet to your packet all the time, and since the destination address of the outer header has a route that uses the tunnel interface (gif)then you end up in an infinite loop - the packet will never be placed in the queue for transmission. I could be wrong, but if you look at the route entries given below, and go through the motions of packet forwarding, then you may arrive at the above conclusion. the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 the_swamp# netstat -rnf inet Routing tables Internet: DestinationGatewayFlags Netif Expire default132.146.115.1 UGSc10 fxp1 127.0.0.1 127.0.0.1 UH 04 lo0 132.145.113.1 132.146.115.164UH 00 gif0 132.146.115/24 link#2 UC 00 fxp1 => 132.146.115.1 0:30:19:9a:e4:71 UHLW20 fxp1460 What you say about this being "correct behaviour" is interesting, but it may put a damper on me trying to use this pointopoint tunnels for this purpose. Again, thanks very much for replying to my request for help and I look forward to hearing from you soon. Parminder Mudhar __ [EMAIL PROTECTED] -Original Message- From: Nick Rogness [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 01, 2001 2:12 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Routes and tunnels On Thu, 1 Feb 2001 [EMAIL PROTECTED] wrote: > Hi > > Thanks for the replies. > > Sorry, I forgot to say that I was using to the tunnel to connect to the > remote site with interface address of 132.146.113.1 and I am not using the > tunnels to send the packets to the local address, 132.146.115.164. I am > trying to use tunnels as point to point links for running routing over them. > > But the end result is that I do not see a packet destined for the end point > of the tunnel, 132.146.113.1 on the wire. WHat do you mean on the wire? THe other side? Is the other side setup to tunnel? How did you configure the outside IP'w with gifconfig ? Need a tad more details to help you out. the behavior you described below about the kernel adding routes is correct as a 'gif' tunnel is a directly connect interface. Most OS's do the same thing with directly connect interfaces. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve " > > -Original Message- > > From: Mudhar,PS,Parminder,CEG2 R > > Sent: Wednesday, January 31, 2001 5:02 PM > > To: '[EMAIL PROTECTED]' > > Subject:Routes and tunnels > > > > Hi > > > > I don't know if this is intentional or a bug, but if ifconfig is used to > > configure a point to point device, such as 'tun' or the newer 'gif' > > devices, then the kernel insists on installing a route where the > > destination is the end point of the tunnel, the gateway is the source of > > the tunnel and the interface is the device itself. I have checked this in > > version 3.2+KAME, what I a using, and also on version 4.1. The effect of > > the above is that the packet that uses the tunnel will never appear on the > > wire. > > > > Here is an output > > > > the_swamp# ifconfig gif0 132.146.115.164 132.145.113.1 > > the_swamp# netstat -rnf inet > > Routing tables > > > > Internet: > > DestinationGatewayFlags Netif Expire > > default132.146.115.1 UGSc10 fxp1 > > 127.0.0.1 127.0.0
Re: sendfile()
Kris Kennaway <[EMAIL PROTECTED]> wrote: >On Thu, Feb 01, 2001 at 01:31:39PM +0800, bsddiy wrote: > >> I don't want to bring flame war, but the following Linus' words may >> be right: > >Did you have a point to make here? If so, I missed it. I've been discussing this with a few people recently (fortunately I didn't lose the mail from Linus when my laptop was stolen) after I stumbled across the TCP_NOPUSH option, which is superficially similar to TCP_CORK. Linus's argument against the HP/UX and BSD sendfile() is that, for example, in the presence of pipelined HTTP requests it isn't possible to avoid poor packet boundaries between responses. TCP_NOPUSH does help to solve this problem (it was designed to hack around problems with the interaction between mbuf sizes and sosend and tcp_output) but it introduces a new problem: at the end of a chain of HTTP responses you want the last segment to go out quickly rather than waiting for more data to fill the segment. For this reason turning off TCP_CORK pushes out queued data, but this isn't the case for TCP_NOPUSH. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] "And remember my friend, future events such as these will affect you in the future." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Socket Code problem.
Hello Freebsd-net,
The following code has a problem with it. After 16000 or so connections
the my tcp connections run out of buffer space, which does not allow me to
make any new TCP connections and the system locks up. an netstat -an
revieles that there are about 100 sockets in TIME_WAIT and an lsof -n shows
about 54000 TCP connections in TCP no PCB, CANTSENDMORE, CANTRECVMORE for
this program. Can someone point me in the right direction for clearing this
up.
/* code snippet
#define DEAMON_PORT2313
void main(){
sockaddr_in name;
int listen_socket;
// Create Socket
listen_socket = socket(PF_INET, SOCK_STREAM, TCP );
ioctl(listen_socket, SO_REUSEADDR);
if (listen_socket== -1 ){
printf("Socket Failed to Create listening socket\n
exiting\n");
exit (-1);
} else{
printf("Socket Created %d\n",listen_socket);
}
// Create socket info
name.sin_family = PF_INET;
name.sin_addr.s_addr = INADDR_ANY;
name.sin_port = htons(DEAMON_PORT);
//Bind Socket
if ( bind(listen_socket, (struct sockaddr *) &name, sizeof(name))
== -1){
printf("Socket could not be bound\n");
exit(-1);
}
// Listen on socket
if (listen(listen_socket, 5) == -1){
printf("Error Listening\n");
exit(-1);
}
while(1){
sockaddr incomming;
int in_sock;
int in_length;
int pid;
in_length = sizeof(incomming);
// Accept incomming socket
in_sock = accept(listen_socket, &incomming, &in_length);
printf("open:%d\n",in_sock);
if (in_sock == -1){
internal_log("Error Accepting\n");
exit(-1);
}
pid = fork();
// Fork a thread
if (pid == 0){
//printf("master Thread alive looping to listen\n");
} else {
//Close the Socket
printf("close %s\n", in_sock);
shutdown(in_sock,2);
close(in_sock);
exit(0);
}
}
}
end code snippet */
Greatly Appreciated,
Justin Booth
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Socket Code problem.
Justin Booth <[EMAIL PROTECTED]> wrote: > >The following code has a problem with it. After 16000 or so connections >the my tcp connections run out of buffer space, which does not allow me to >make any new TCP connections and the system locks up. an netstat -an >revieles that there are about 100 sockets in TIME_WAIT and an lsof -n shows >about 54000 TCP connections in TCP no PCB, CANTSENDMORE, CANTRECVMORE for >this program. Can someone point me in the right direction for clearing this >up. The child process that you fork needs to do something, and most particularly it should exit. You should check for errors from fork() -- they might have clued you into the problem. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] "Because all you of Earth are idiots!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
* David Greenman <[EMAIL PROTECTED]> [010201 11:07] wrote: > >I don't want to bring flame war, but the following Linus' words may be > >right: Really David (Xu), what part do you believe to be correct? >The FreeBSD API is the way it is after a collaboration with the Apache > folks. The sendfile() implementation in FreeBSD works just fine and I think > it has one of the most complete API's of any of them out there. Sounds like > typical Linus misinformation. >If you have a point to make, then make it. I would be happy to consider > any real shortcomings in sendfile(), but right now I don't know about any. David Greenman is right, I don't see how using the TCP_CORK option (more on that later) which basically turns the one-syscall sendfile method into a mess of: setsocktopt/ioctl +TCP_CORK writev (most likely required) linux-sendfile writev (possibly optional) setsocktopt/ioctl -TCP_CORK (or possibly close) Now to give Linux the benifit of the doubt (because everyone has to i guess), if TCP_CORK is inherited from the accept() socket, then you loose one syscall. If TCP_CORK is cleared and socket flushed in a timely manner at close() you ditch another syscall, but it's still at least one additional syscall and pretty obtuse API. Oh, and about TCP_CORK, it's a kewl name, and I commend the Linux camp on thier kewl named additions to the system, but to be honest they aren't really as brilliant (or goodlooking) as they think. TCP_CORK should have been made into a socket level option, not a protocol level option. For some reason I'm shocked Linus would have ranted like this on a public list, my guess is that this is a pretty old message dug up from the archives to stir a bit of flamage on the lists. When I first read it I was wondering what David Xu's point was, and I'm still wondering. > >- > >The fact I dislike about the HP-UX implementation is that it is so obviously stupid. > > > >And I have to say that I absolutely despise the BSD people. They did sendfile() > >after both Linux and HP-UX had done it, and they must have known about both > >implementations. And they chose the HP-UX braindamage, and even brag about > > the fact that they were stupid and didn't understand TCP_CORK (they don't > > say so in those exact words, of course - they just show that they were stupid > > and clueless by the things they brag about). > > > >Oh, well. Not everybody can be as goodlooking as me. It's a curse. > > > >- > > > >Also note how I said that it is the BSD people I despise. Not the HP-UX >implementation. > >The HP-UX one is not pretty, but it works. But I hold open source people to higher >standards. > >They are supposed to be the people who do programming because it's an art-form, not >because > >it's their job. > > > > > >David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
On Thu, 1 Feb 2001, David Greenman wrote: > >I don't want to bring flame war, but the following Linus' words may be > >right: > >The FreeBSD API is the way it is after a collaboration with the Apache > folks. The sendfile() implementation in FreeBSD works just fine and I think > it has one of the most complete API's of any of them out there. Sounds like > typical Linus misinformation. >If you have a point to make, then make it. I would be happy to consider > any real shortcomings in sendfile(), but right now I don't know about any. The most serious shortcoming I see is that it still requires a storm of syscalls for async operation. Take this for example, a daemon with 1000 open connections transfering data to dialups. The first pass through, sendfile() will fill the socket buffer and move on to the next fd. Then shortly thereafter, with the sockbuf only slightly drained, new write events will come up in whatever polling method you're using, and you get to fire off another 1000 syscalls just to add an extremely small amount of data. You must also either keep 1000 open fds for the source file, or open() and close() on every pass. You could have your event poller check the status of the sockbuf and make some intelligent determination of when to trigger a new write event, perhaps based on some knowledge of the rate at which the connected peer is draining information. This potentially restricts the amount of data in the snd sockbuf and thus the size of the tcp window which can be fast recovered in the event of packet loss, but if done correctly and with a semi accurate guess at the rate of drain it could be useful. kevent filter? If sendfile() was in effect aio_sendfile(), it would be even more useful. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
No Subject
unsubscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
< said: > For this reason turning off TCP_CORK pushes out queued data, but > this isn't the case for TCP_NOPUSH. This is a long-standing bug. You are welcome to fix it. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
< said: > Then shortly thereafter, with the sockbuf only slightly drained, new > write events will come up in whatever polling method you're using, > and you get to fire off another 1000 syscalls just to add an > extremely small amount of data. SO_SNDLOWAT -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: cvs commit: src/usr.sbin/arp arp.8 arp.c
Garrett Wollman writes: > > I apologize for not getting this.. I'll try another question: why > > doesn't "arp -d x.y.z.w" just delete whatever ARP entry there is > > for x.y.z.w no matter what kind it is? > > Because it doesn't know what kind is there. It could find out, but > then you'd have a race condition, and in any case the system > administrator is presumed to know what permanent ARP entries there are > and of which sort. (In most cases it doesn't matter.) OK.. could you provide a one sentence description that I can add to the man page? E.g. "... the proxy keyword is required when deleting published ARP entries" or whatever. Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
>I don't want to bring flame war, but the following Linus' words may be >right: The FreeBSD API is the way it is after a collaboration with the Apache folks. The sendfile() implementation in FreeBSD works just fine and I think it has one of the most complete API's of any of them out there. Sounds like typical Linus misinformation. If you have a point to make, then make it. I would be happy to consider any real shortcomings in sendfile(), but right now I don't know about any. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. >- >The fact I dislike about the HP-UX implementation is that it is so obviously stupid. > >And I have to say that I absolutely despise the BSD people. They did sendfile() >after both Linux and HP-UX had done it, and they must have known about both >implementations. And they chose the HP-UX braindamage, and even brag about > the fact that they were stupid and didn't understand TCP_CORK (they don't > say so in those exact words, of course - they just show that they were stupid > and clueless by the things they brag about). > >Oh, well. Not everybody can be as goodlooking as me. It's a curse. > >- > >Also note how I said that it is the BSD people I despise. Not the HP-UX >implementation. >The HP-UX one is not pretty, but it works. But I hold open source people to higher >standards. >They are supposed to be the people who do programming because it's an art-form, not >because >it's their job. > > >David Xu > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
a note on ipfw/bridge/dummynet changes
[Bcc to net and ipfw as relevant there -- if you want a reply to go to the lists you need to add them explicitly.] Hi, as some of you have noticed, i am trying to fix some long-standing problems that we have had with bridging and dummynet, so I'd like to comment on what I am doing and how. * i am working and doing testing on STABLE, as some of the problems that we had in the past (races) were peculiar to that version, at least until CURRENT uses Giant to protect critical sections. I am testing/putting the code in CURRENT as well, but i believe we can only have some significant testing on STABLE. So, you will see some quick MFC -- please be tolerant. (The other reason for this is that I do have a CURRENT box but it often dies in cpu_idle. The same hw seems to be more robust when using a PicoBSD floppy with STABLE, so i have no idea if it is bad hardware or what.) * some of the problems peple are experiencing appear to be related to memory corruption, which in turn derives from shared mbuf clusters being modified at different places in the stack. The approach i am following to track and fix them involves some changes to the interfaces of ether_input(), bdg_forward(), and the firewall check functions, so that these modules limit the amount of patching into shared mbufs. This means that some of the patches are rather extensive, and affect several files namely: net/if_ethersubr.c net/bridge.[ch] netinet/ip_dummynet.[ch] netinet/ip_fw.[ch] and to a much lesser degree netinet/ip_input.c netinet/ip_output.c src/sbin/ipfw/ipfw.c In some cases you will be required to update the userland program, ipfw. * check your system before reporting problems. While I can make mistakes, I do check my code before committing. Most of the "problems" reported recently were of the kind "cannot compile the kernel", "ipfw says invalid command", and they were just local error from people not updating the sources or header files properly. cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
>Kris Kennaway <[EMAIL PROTECTED]> wrote: >>On Thu, Feb 01, 2001 at 01:31:39PM +0800, bsddiy wrote: >> >>> I don't want to bring flame war, but the following Linus' words may >>> be right: >> >>Did you have a point to make here? If so, I missed it. > >I've been discussing this with a few people recently (fortunately I >didn't lose the mail from Linus when my laptop was stolen) after I >stumbled across the TCP_NOPUSH option, which is superficially similar >to TCP_CORK. > >Linus's argument against the HP/UX and BSD sendfile() is that, for >example, in the presence of pipelined HTTP requests it isn't possible >to avoid poor packet boundaries between responses. TCP_NOPUSH does >help to solve this problem (it was designed to hack around problems >with the interaction between mbuf sizes and sosend and tcp_output) but >it introduces a new problem: at the end of a chain of HTTP responses >you want the last segment to go out quickly rather than waiting for >more data to fill the segment. For this reason turning off TCP_CORK >pushes out queued data, but this isn't the case for TCP_NOPUSH. Thanks for the above - at least now I have something to comment on! If that is really Linus' argument "against" FreeBSD's sendfile(), then that's not an argument against it since any response aggregation should happen in the network stack and not at the sendfile() level. Linus is right about one thing, though: I've never heard of "TCP_CORK" and have very little idea of what it is supposed to do. The Linux sendfile() API was only looked at very superficially and I found it to be sorely lacking at the time. ...but unlike Linus about FreeBSD, I've never publically said that Linus or his team are idiots because of it, despite what I may think sometimes. That should count for something. :-) -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
transparent proxying through a separate machine
Hello! We have a single firewall machine and a _separate_ machine running squid proxy (both servers are on the same network wire). How do I catch all of the outgoing http requests and send them through squid? I tried ipfw add fwd squid,3128 tcp from any to any http but it does not seem to work -- squid never gets contacted. All of the recipes out there describe the setups with squid and the firewall being on the same machine. What else do I need to do? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
protosw kernel module
Hi there I am wondering if it is at all possible to somehow dynamically append a protocol to the protocol switch (table) mechanism with a kernel module. I am looking at the ipprotosw.h and in_proto.c files and it does not appear to be possible, as the inetsw[] array is declared to be a fixed size at compile time. I have written a protocol into the switch table with the necessary pr_input function and it would be helpful for me to be able to deploy this protocol as a binary .ko amongst many machines instead of distributing a complete kernel. I am willing to do some work to enable the kernel to do this, if it currently cannot, if a committer is interested in adding this feature to the kernel. However, I guess that this type of enhancement might not be wanted. Matthew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: transparent proxying through a separate machine
[EMAIL PROTECTED] wrote: > > Hello! > > We have a single firewall machine and a _separate_ machine running > squid proxy (both servers are on the same network wire). > > How do I catch all of the outgoing http requests and send them through > squid? > > I tried > > ipfw add fwd squid,3128 tcp from any to any http > > but it does not seem to work -- squid never gets contacted. All of the > recipes out there describe the setups with squid and the firewall being > on the same machine. What else do I need to do? Thanks! I assume squid is the name of the other machine? you need to have the same rule in the ipfw on that machine too. otherwise it will reflect the packet back at it's original destination as it still has headers saying it wants to go there. (It's unaltered). > > -mi > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: transparent proxying through a separate machine
[EMAIL PROTECTED] wrote: > > Hello! > > We have a single firewall machine and a _separate_ machine running > squid proxy (both servers are on the same network wire). > > How do I catch all of the outgoing http requests and send them through > squid? > > I tried > > ipfw add fwd squid,3128 tcp from any to any http > > but it does not seem to work -- squid never gets contacted. All of the > recipes out there describe the setups with squid and the firewall being > on the same machine. What else do I need to do? Thanks! Oh yeah, you need to make you rules only catch the packets from the clients, otherwise you will catch your own cache requests from squid. so you must allow the requests from 'squid' to avoid being forwarded back to squid.. > > -mi > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: protosw kernel module
* Matthew Luckie <[EMAIL PROTECTED]> [010201 13:13] wrote: > Hi there > > I am willing to do some work to enable the kernel to do this, if it > currently cannot, if a committer is interested in adding this feature to > the kernel. However, I guess that this type of enhancement might not be > wanted. It really depends on how you implement it. :) Give it a shot and submit patches. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bridging and dummynet seems to destroy dmesg output
> > > > > > > > I sent these files in private. But I remembered that I have another > > > > unusual config in this machine: is is multiprocessed, and has 10 SCSI disks > > > > and lots of SYSV shared memory. > > > > > > i think SMP might have something to do with it. Yusuf, are you also > > > using an SMP box ? > > > > The strange thing is that if I turn on verbose logging (via sysctl) but > > don't turn on verbose_limit, dmesg seems to get corrupted. If I have > > > > So, it seems some combination of verbose logging and non setting of > > verbose limit [or the default setting of verbose limit] is causing this > > problem > > Just in case nobody has yet noticed, this is for sure a case of lost > pointer. And if the kernel is not yet crashing is just mere luck! Time to > audit changes since -release? Eh no. I've experienced panic's at the end of /etc/rc, just before going multiuser. When I disable firewalling in /etc/rc.conf the system boots up fine. (although it isn't that useful anymore, because of the default deny everything policy of ipfw). This was on a SMP box with a Jan 30 cvsup, I'm currently downgrading it to an older 4.2-stable (dated 30 Dec 2000) Regards, Ruben -- ,-_ .. /() ) | Ruben van Staveren | Linux is for Microsoft Haters,|_o (__ ( | http://ruben.is.verweg.com | BSD is for Unix Lovers| #> =/ () `+---' 4 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Solved: Bridging and dummynet seems to destroy dmesg output
Luigi Rizzo wrote: > > > I tried only removing DUMMYNET from config, and the bug continues. Should > > I try the changes below? > > no-they only affect dummynet. But this seems to suggest that > the problem is unrelated to my changes... > > cheers > luigi Hi, I found the problem! I started searching for the point where ipfw writes to the msgbuf, and like all other kernel modules, it uses the log(9) function. But differently from the other modules, ip_fw.c uses a LOG_SECURITY argument. I removed it, recompiled, reboot, and BINGO! Probably the log(9) function does not expect a facility parameter, as it is assumed to be LOG_KERNEL. Searching the cvsweb tree, I assume the changes that made it fail were made to kern/subr_prf.c, and not directly to netinet/ip_fw.c. Probably a longer search should be made to detect if any other call to log(9) uses this approach. (CC: to phk, who made the change to kern/subr_prf.c, 1.61.2.1, at 2000.01.16) Hoping this is the final solution and waiting for the cvs commit, thanks to everybody, Jonny -- João Carlos Mendes Luís [EMAIL PROTECTED] Networking Engineer [EMAIL PROTECTED] Internet via Embratel [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
Garrett Wollman <[EMAIL PROTECTED]> wrote:
>Tony Finch <[EMAIL PROTECTED]> wrote:
>>
>> For this reason turning off TCP_CORK pushes out queued data, but
>> this isn't the case for TCP_NOPUSH.
>
>This is a long-standing bug. You are welcome to fix it.
I've been looking at this and it seems to me to be simply a case of
calling tcp_output() from tcp_ctloutput() if TF_NOPUSH is cleared.
But I'm not certain I have my head properly around the code...
Index: tcp_usrreq.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v
retrieving revision 1.51
diff -u -r1.51 tcp_usrreq.c
--- tcp_usrreq.c2000/01/09 19:17:28 1.51
+++ tcp_usrreq.c2001/02/01 23:03:35
@@ -896,7 +896,6 @@
switch (sopt->sopt_name) {
case TCP_NODELAY:
case TCP_NOOPT:
- case TCP_NOPUSH:
error = sooptcopyin(sopt, &optval, sizeof optval,
sizeof optval);
if (error)
@@ -921,6 +920,20 @@
tp->t_flags |= opt;
else
tp->t_flags &= ~opt;
+ break;
+
+ case TCP_NOPUSH:
+ error = sooptcopyin(sopt, &optval, sizeof optval,
+ sizeof optval);
+ if (error)
+ break;
+
+ if (optval)
+ tp->t_flags |= opt;
+ else {
+ tp->t_flags &= ~opt;
+ error = tcp_output(tp);
+ }
break;
case TCP_MAXSEG:
Tony.
--
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
"Well, as long as they can think we'll have our problems.
But those whom we're using cannot think."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: transparent proxying through a separate machine
On 1 Feb, Julian Elischer wrote: = > We have a single firewall machine and a _separate_ machine running = > squid proxy (both servers are on the same network wire). = > = > How do I catch all of the outgoing http requests and send them = > through squid? = > = > I tried = > = > ipfw add fwd squid,3128 tcp from any to any http = > = > but it does not seem to work -- squid never gets contacted. All of = > the recipes out there describe the setups with squid and the = > firewall being on the same machine. What else do I need to do? = = I assume squid is the name of the other machine? you need to have the = same rule in the ipfw on that machine too. Yes. Ok. This is what I just added to the squid-machine: ipfw add allow ip from any to any out ipfw add fwd localhost,3128 log tcp from any to any 3128 in = otherwise it will reflect the packet back at it's original destination = as it still has headers saying it wants to go there. (It's unaltered). The firewall machine logs ipfw: 3000 Forward to squid.ip:3128 TCP client.ip:3977 web.server.ip:80 in via dc0 But the client still talks to the web-server directly :( The squid's log is quiet... Anything I'm missing? Perhaps, I need a user-space program of some sort to run on the firewall to do the tunneling? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPComp question
Hi,
It turned out that the problem is in netinet/in_proto.c.
(It might have been fixed in -stable long ago, but not
in 4.2 release. :-)
yushun.
--- /usr/src/sys/netinet/in_proto.c Thu Feb 1 14:56:45 2001
+++ /usr/src/sys/netinet/in_proto.c.ORIGThu Feb 1 14:38:25 2001
@@ -72,7 +72,6 @@
#ifdef IPSEC
#include
#include
-#include
#ifdef IPSEC_ESP
#include
#endif
@@ -149,12 +148,6 @@
ah4_input, 0, 0, 0,
0,
0, 0, 0, 0,
- &nousrreqs
-},
-{ SOCK_RAW,&inetdomain,IPPROTO_IPCOMP, PR_ATOMIC|PR_ADDR,
- ipcomp4_input,0, 0, 0,
- 0,
- 0,0, 0, 0,
&nousrreqs
},
#ifdef IPSEC_ESP
Yu-Shun Wang <[EMAIL PROTECTED]> Information Sciences Institute
University of Southern California
On Thu, 1 Feb 2001, Jun-ichiro itojun Hagino wrote:
>
> > No, but the problem is that there was no increase (actually, no
> > record at all) under ipsec: IPComp. The number on the sending
> > side seemed right. The increase matched the ones I saw from
> > tcpdump. It looked like the IPComp packets either weren't
> > logged or were dropped for some reason.
>
> send the following items.
> - full tcpdump output
> - netstat -sn before, and after the test (on both ends)
> - full SA configuration on both sides (previous email may have included
> it)
> - ifconfig -a output, on both ends
> - netstat -rn output, on both ends
> - simple network diagram (like intermediate routers) between both ends
>
> itojun
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: pseudo interface and ioctls
On Wed, Jan 31, 2001 at 11:50:01PM -0800, Julian Elischer wrote: > "Geoffrey Crompton (RMIT Guest)" wrote: > > why are you doing this? > there are already 4 pseudo interfaces in the system of varying types.. > > netgraph(2 types), divert, tap, tun. > > what do you need to do? > I need to do packet translation between different AF_ types. I haven't seen any interfaces that do that. (I haven't got too much experience though) Geoff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: protosw kernel module
I'm just wondering if someone on -net can offer some advice on how to go
about implementing something like this.
I am looking at the ip_input/ip_init functions now.
Assuming that it would be a good idea to maintain the protosw table as it
is now (i.e. statically declared), perhaps another way to go about this
would be to add a single entry to the protosw table that takes
care of protocols that are inserted dynamically.
the ip_protox table would then be modified dynamically to switch to this
pr_input function instead of the raw ip pr_input function that it would
otherwise do. the protosw->pr_input function would then delegate the call
to the appropriate pr_input function held in a seperate table
u_char kld_ip_protox[IPPROTO_MAX];
struct ipprotosw *kld_inetsw;
int ip_kld_input(struct mbuf *m, int off, int proto)
{
(*kld_inetsw[kld_ip_protox[proto]].pr_input)(m,off,proto);
}
i am rather ignorant of data structures, so what type of data structure
would be suited to this lookup task? Perhaps a pointer to a malloc'd
array would be good, and if a new protocol is to be inserted to the
kernel, then to re-allocate the necessary tables to accomodate a new
protocol. Given that the task of re-allocating tables would not happen
very often, I think this might be a good way to approach this task.
I appreciate any criticism anyone could offer on this approach to this
idea
Thanks
Matthew
On Thu, 1 Feb 2001, Alfred Perlstein wrote:
> * Matthew Luckie <[EMAIL PROTECTED]> [010201 13:13] wrote:
> > Hi there
> >
> > I am willing to do some work to enable the kernel to do this, if it
> > currently cannot, if a committer is interested in adding this feature to
> > the kernel. However, I guess that this type of enhancement might not be
> > wanted.
>
> It really depends on how you implement it. :) Give it a shot
> and submit patches.
>
> --
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> "I have the heart of a child; I keep it in a jar on my desk."
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: IPComp question
Hi,
Another (sort of) related question: I've got the bandwidth
measurements for different algorthms using netperf. I was
really surprised that IPComp did so bad. Any ideas?
TCP UDP(Mbps) Ping(ms)Key(bits)
-
Raw IP 79.56 94.59/87.98 0.213
des-cbc 40.60 46.51/36.88 0.38964
3des-cbc19.52 22.18/19.37 0.460 192
simple 78.53 93.44/86.93 0.29364
hmac-md572.86 93.86/44.57 0.398 128
blowfish-cbc23.24 55.18/42.12 1.06364
rc5-cbc 46.22 65.67/45.29 0.38364
hmac-sha1 45.30 64.04/49.69 0.440 160
IPComp-deflate 24.05 27.11/27.10 0.242
Setup: 2 identical freebsd 4.2 release boxes (PIII 733MHz,
256MB RDRAM) connected through Ethernet switch.
Thanks,
yushun.
Yu-Shun Wang <[EMAIL PROTECTED]> Information Sciences Institute
University of Southern California
On Thu, 1 Feb 2001, Yu-Shun Wang wrote:
> Hi,
>
> It turned out that the problem is in netinet/in_proto.c.
> (It might have been fixed in -stable long ago, but not
> in 4.2 release. :-)
>
> yushun.
>
>
> --- /usr/src/sys/netinet/in_proto.c Thu Feb 1 14:56:45 2001
> +++ /usr/src/sys/netinet/in_proto.c.ORIGThu Feb 1 14:38:25 2001
> @@ -72,7 +72,6 @@
> #ifdef IPSEC
> #include
> #include
> -#include
> #ifdef IPSEC_ESP
> #include
> #endif
> @@ -149,12 +148,6 @@
>ah4_input, 0, 0, 0,
>0,
>0, 0, 0, 0,
> - &nousrreqs
> -},
> -{ SOCK_RAW,&inetdomain,IPPROTO_IPCOMP, PR_ATOMIC|PR_ADDR,
> - ipcomp4_input,0, 0, 0,
> - 0,
> - 0,0, 0, 0,
>&nousrreqs
> },
> #ifdef IPSEC_ESP
>
>
>
> Yu-Shun Wang <[EMAIL PROTECTED]> Information Sciences Institute
>University of Southern California
>
> On Thu, 1 Feb 2001, Jun-ichiro itojun Hagino wrote:
>
> >
> > > No, but the problem is that there was no increase (actually, no
> > > record at all) under ipsec: IPComp. The number on the sending
> > > side seemed right. The increase matched the ones I saw from
> > > tcpdump. It looked like the IPComp packets either weren't
> > > logged or were dropped for some reason.
> >
> > send the following items.
> > - full tcpdump output
> > - netstat -sn before, and after the test (on both ends)
> > - full SA configuration on both sides (previous email may have included
> > it)
> > - ifconfig -a output, on both ends
> > - netstat -rn output, on both ends
> > - simple network diagram (like intermediate routers) between both ends
> >
> > itojun
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
> >
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
- Original Message - From: "Tony Finch" <[EMAIL PROTECTED]> To: "Kris Kennaway" <[EMAIL PROTECTED]> Cc: "bsddiy" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, February 02, 2001 2:00 AM Subject: Re: sendfile() > Kris Kennaway <[EMAIL PROTECTED]> wrote: > Linus's argument against the HP/UX and BSD sendfile() is that, for > example, in the presence of pipelined HTTP requests it isn't possible > to avoid poor packet boundaries between responses. TCP_NOPUSH does > help to solve this problem (it was designed to hack around problems > with the interaction between mbuf sizes and sosend and tcp_output) but > it introduces a new problem: at the end of a chain of HTTP responses > you want the last segment to go out quickly rather than waiting for > more data to fill the segment. For this reason turning off TCP_CORK > pushes out queued data, but this isn't the case for TCP_NOPUSH. > if TCP_NOPUSH can simulate TCP_CORK when TCP_NOPUSH is turned off and last data segment is sent, I'll be satisfied. but as I know, it seems TCP_NOPUSH is mainly used for TTCP, right? the idea behind TCP_CORK is it buffers any small data segment user program sending until these segments full fills a max TCP packet, then the packet is sent, web servers always send many very small HTTP headers, cause lots of small packets sent out, TCP_CORK can increase network performance. Regards, David Xu N '²æìr¸zǧvf¢Ú&j:+v¨· è® "¶§²æìr¸yúÞy» ëbØ^nr¡ûazg¬±¨
Re: IPComp question
> Another (sort of) related question: I've got the bandwidth > measurements for different algorthms using netperf. I was > really surprised that IPComp did so bad. Any ideas? thanks for measurements, it's good to see. i guess couple of reasons here. - because we compress short packets with IPComp, we cannot make a good use of compression history/dictionary. we always initialize everything on every packet, and it can consume cpu time. - zlib buffer management - it has ring buffer management on both in/output ends, because we will see data stream with different sizes. - zlib memory management - heavy use of malloc? itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
David Xu <[EMAIL PROTECTED]> wrote: > >but as I know, it seems TCP_NOPUSH is mainly used for TTCP, right? That's what it was designed for. >the idea behind TCP_CORK is it buffers any small data segment user >program sending until these segments full fills a max TCP packet, >then the packet is sent, TCP_NOPUSH is the same >web servers always send many very small HTTP headers, cause lots of >small packets sent out, TCP_CORK can increase network performance. No, web servers are very careful to reduce the number of packets required for a response. TCP_CORK exists to avoid two bad packet boundaries per request: one between the header and the body, and one between the body and the next response. FreeBSD's sendfile allows you to easily optimise the beginning of the response; optimising the transition from one response to the next is harder. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] "If I didn't see it with my own eyes I would never have believed it!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
* Tony Finch <[EMAIL PROTECTED]> [010201 16:52] wrote: > David Xu <[EMAIL PROTECTED]> wrote: > > > >but as I know, it seems TCP_NOPUSH is mainly used for TTCP, right? > > That's what it was designed for. > > >the idea behind TCP_CORK is it buffers any small data segment user > >program sending until these segments full fills a max TCP packet, > >then the packet is sent, > > TCP_NOPUSH is the same > > >web servers always send many very small HTTP headers, cause lots of > >small packets sent out, TCP_CORK can increase network performance. > > No, web servers are very careful to reduce the number of packets > required for a response. TCP_CORK exists to avoid two bad packet > boundaries per request: one between the header and the body, and one > between the body and the next response. FreeBSD's sendfile allows you > to easily optimise the beginning of the response; optimising the > transition from one response to the next is harder. I was going to say the same thing, but what about the header before a cgi response? Doesn't the webserver need to spit out a couple of short lines before exec'ing the CGI? Wouldn't the socket low water mark address this though as long as it was > size of the http header? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
proper uncorking for TCP_NOPUSH, was Re: sendfile()
Tony Finch <[EMAIL PROTECTED]> wrote:
>Garrett Wollman <[EMAIL PROTECTED]> wrote:
>>Tony Finch <[EMAIL PROTECTED]> wrote:
>>>
>>> For this reason turning off TCP_CORK pushes out queued data, but
>>> this isn't the case for TCP_NOPUSH.
>>
>>This is a long-standing bug. You are welcome to fix it.
>
>I've been looking at this and it seems to me to be simply a case of
>calling tcp_output() from tcp_ctloutput() if TF_NOPUSH is cleared.
OK, apart from my previous patch containing dumb cut&paste errors it
works :-)
I have a program (below) which forks; the parent listens for a
connection and then reads from it reporting the size of the reads; the
child connects to the parent, sets TCP_NOPUSH, writes 1 single
bytes, unsets TCP_NOPUSH, sleeps for 10 seconds, then exits.
On an upatched FreeBSD the following happens. Note that the
single-byte writes get coalesced nicely. Note also that there is a six
second delay between the writer finishing and the readere receiving
the data.
:; ./a.out
981075049.891658 reader init
981075050.898416 writer init
981075050.899179 reader go
981075050.902703 writer go
981075050.939887 write finished
981075055.898738 read 8192
981075055.899084 read 1808
981075060.948514 writer exit
981075060.949197 read 0
981075060.949237 reader exit
On a patched FreeBSD this happens. The reader gets the data as soon as
the writer turns off TCP_NOPUSH :-)
:; ./a.out
981075103.647630 reader init
981075104.654745 writer init
981075104.655310 reader go
981075104.655433 writer go
981075104.690353 write finished
981075104.690863 read 8192
981075104.691037 read 1808
981075114.695098 writer exit
981075114.695640 read 0
981075114.695761 reader exit
Proper patch below.
Tony.
--
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
"Dead! And yet there he stands!"
Index: tcp_usrreq.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v
retrieving revision 1.51
diff -u -r1.51 tcp_usrreq.c
--- tcp_usrreq.c2000/01/09 19:17:28 1.51
+++ tcp_usrreq.c2001/02/02 00:21:01
@@ -896,7 +896,6 @@
switch (sopt->sopt_name) {
case TCP_NODELAY:
case TCP_NOOPT:
- case TCP_NOPUSH:
error = sooptcopyin(sopt, &optval, sizeof optval,
sizeof optval);
if (error)
@@ -909,9 +908,6 @@
case TCP_NOOPT:
opt = TF_NOOPT;
break;
- case TCP_NOPUSH:
- opt = TF_NOPUSH;
- break;
default:
opt = 0; /* dead code to fool gcc */
break;
@@ -921,6 +917,20 @@
tp->t_flags |= opt;
else
tp->t_flags &= ~opt;
+ break;
+
+ case TCP_NOPUSH:
+ error = sooptcopyin(sopt, &optval, sizeof optval,
+ sizeof optval);
+ if (error)
+ break;
+
+ if (optval)
+ tp->t_flags |= TF_NOPUSH;
+ else {
+ tp->t_flags &= ~TF_NOPUSH;
+ error = tcp_output(tp);
+ }
break;
case TCP_MAXSEG:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define PORT_FOO 5
static void
report(const char *fmt, ...) {
struct timeval tv;
va_list ap;
char buf[80];
va_start(ap, fmt);
if(gettimeofday(&tv, NULL)) err(1, "gettimeofday");
vsnprintf(buf, sizeof(buf), fmt, ap);
printf("%ld.%06ld %s\n", tv.tv_sec, tv.tv_usec, buf);
va_end(ap);
}
int
main(void) {
int i, r, s;
struct sockaddr_in addr;
char buf[8192];
setbuf(stdout, NULL);
bzero(&addr, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_port = htons(PORT_FOO);
addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
switch(fork()) {
case(-1):
err(1, "fork");
case(0):
/* child */
sleep(1);
report("writer init");
s = socket(PF_INET, SOCK_STREAM, 0);
if(s < 0) err(1, "socket");
i = 1; r = setsockopt(s, IPPROTO_TCP, TCP_NOPUSH, &i, sizeof(i));
if(r < 0) err(1, "setsockopt");
r = connect(s, (struct sockaddr *)&addr, sizeof(addr));
if(r < 0) err(1, "connect");
report("writer go");
*buf = 0;
for(i = 0; i < 1; i++) {
Re: sendfile()
I have looked into tcp_usrreq.c and it seems when TCP_NOPUSH is turned off,
the last data segment is not sent immediately, need to add a tcp_output call?
I am not certain, in tcp_ctloutput(so, opt), I think the code should like this:
case TCP_NOPUSH:
...
if (optval)
tp->t_flags |= opt;
else
{
tp->t_flags &= ~opt;
if (opt == TF_NOPUSH)
error = tcp_output(tp);
}
--
Regards,
David Xu
- Original Message -
From: "Tony Finch" <[EMAIL PROTECTED]>
To: "David Xu" <[EMAIL PROTECTED]>
Cc: "Kris Kennaway" <[EMAIL PROTECTED]>; "bsddiy" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, February 02, 2001 8:50 AM
Subject: Re: sendfile()
> David Xu <[EMAIL PROTECTED]> wrote:
> >
> >but as I know, it seems TCP_NOPUSH is mainly used for TTCP, right?
>
> That's what it was designed for.
>
> >the idea behind TCP_CORK is it buffers any small data segment user
> >program sending until these segments full fills a max TCP packet,
> >then the packet is sent,
>
> TCP_NOPUSH is the same
>
> >web servers always send many very small HTTP headers, cause lots of
> >small packets sent out, TCP_CORK can increase network performance.
>
> No, web servers are very careful to reduce the number of packets
> required for a response. TCP_CORK exists to avoid two bad packet
> boundaries per request: one between the header and the body, and one
> between the body and the next response. FreeBSD's sendfile allows you
> to easily optimise the beginning of the response; optimising the
> transition from one response to the next is harder.
>
> Tony.
> --
> f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
> "If I didn't see it with my own eyes I would never have believed it!"
¡Iì¹» ®&Þ±éݨ¥¶Ý¢jçH:+éì¹» ®&Þ~·nÇgzا¶¡Ü¨~Ø^ë,j
Re: sendfile()
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>
>I was going to say the same thing, but what about the header
>before a cgi response? Doesn't the webserver need to spit out
>a couple of short lines before exec'ing the CGI?
No. The first line of the HTTP response ("HTTP/1.1 200 OK" or
whatever) depends on the headers that the CGI returns to the
server (e.g. "Status: 500 Database screwed again").
>Wouldn't the socket low water mark address this though as long
>as it was > size of the http header?
Ideally you want it to be the same as the path MTU. I don't know a
good way of finding that out in uerland though.
There remains the issue of the last partial packet in a response,
though: you want that to go out immediately after the rest of the
data.
Tony.
--
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
"You realize there's a government directive stating
that there is no such thing as a flying saucer?"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: IPComp question
On Thu, 1 Feb 2001, Yu-Shun Wang wrote: > Another (sort of) related question: I've got the bandwidth > measurements for different algorthms using netperf. I was > really surprised that IPComp did so bad. Any ideas? AFAIK, netperf TCP_STREAM test (and may be others) is extremely susceptible to network delays. For example, for a fast Ethernet connection with, say, 30msec packet delay, netperf may show less than 10Mbits/sec bandwidth instead of the usual 90+Mbits/sec. Clearly, bandwidth and response times are orthogonal measurements, but netperf design ties them together. Depending on your test environment and purposes, netperf throughput results may be very misleading. $0.02, Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
< said: > Wouldn't the socket low water mark address this though as long > as it was > size of the http header? No. TCP is (supposed to be) oblivious to the send low-water mark. The only code that looks at it is the code which determines whether a process blocked or selecting on the socket should be awakened to frob it. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: sendfile()
* Garrett Wollman <[EMAIL PROTECTED]> [010201 17:20] wrote: > < said: > > > Wouldn't the socket low water mark address this though as long > > as it was > size of the http header? > > No. TCP is (supposed to be) oblivious to the send low-water mark. > The only code that looks at it is the code which determines whether a > process blocked or selecting on the socket should be awakened to frob > it. How wonderfully obtuse. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Solved: Bridging and dummynet seems to destroy dmesg output
thanks for tracking this problem -- it also explains why i did not see it in my environment, as i have a mostly 4.2-R system with new code in net/ and netinet/ cheers luigi > Hi, > > I found the problem! > > I started searching for the point where ipfw writes to the msgbuf, and > like all other kernel modules, it uses the log(9) function. But differently > from the other modules, ip_fw.c uses a LOG_SECURITY argument. I removed it, > recompiled, reboot, and BINGO! Probably the log(9) function does not expect a > facility parameter, as it is assumed to be LOG_KERNEL. > > Searching the cvsweb tree, I assume the changes that made it fail were > made to kern/subr_prf.c, and not directly to netinet/ip_fw.c. Probably a > longer search should be made to detect if any other call to log(9) uses this > approach. (CC: to phk, who made the change to kern/subr_prf.c, 1.61.2.1, at > 2000.01.16) > > Hoping this is the final solution and waiting for the cvs commit, thanks > to everybody, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
