FreeBSD 8.2, MPD5 - crash when net.isr.bindthreads=0
Hi, I always get a kernel crash when "net.isr.bindthreads=0" and around 4700 l2tp sessions. With "net.isr.bindthreads=1" the system is stable and I manage to get around 6500 sessions. If somebody is interested here are the crash details: http://pluto.stsisp.ro/crash-isr/ -- Best regards, Adrian Minta ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
(TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow?
Hello.
Iv faced some problem and seems don't realize the mechanincs why does it
occures.
First of all i'd like to notice that my freebsd knowledge and expirience is
limited, especially in such "strange" cases.
In details(code example ill be at the end):
System:
# uname -spr
FreeBSD 7.2-RELEASE amd64
We have simple TCP client and server.
Server is very casual, it listens on some port in while->select->accept
loop.
Client knocks on server port and sends some data and closes the port.
First it was designed for sending data 3-5/times per minute. But once during
test I'v noticed that if client sends data very fast (more precisely it
opens and closes socket to server very fast) there is
"54 - Connection reset by peer" error on call to "connect".(on client side
ofc)
Some illustration from tcpdump:
(test on localhost.server side is port 10002.i'v cuted other fields for
simplicity)
<...>
13:48:58.491229 IP 127.0.0.1.56677 > 127.0.0.1.10002: S
13:48:58.491255 IP 127.0.0.1.10002 > 127.0.0.1.56677: S ack
13:48:58.491266 IP 127.0.0.1.56677 > 127.0.0.1.10002: . ack
13:48:58.491300 IP 127.0.0.1.56677 > 127.0.0.1.10002: P
13:48:58.491346 IP 127.0.0.1.56677 > 127.0.0.1.10002: F
13:48:58.491365 IP 127.0.0.1.10002 > 127.0.0.1.56677: . ack
13:48:58.491466 IP 127.0.0.1.55238 > 127.0.0.1.10002: S//
13:48:58.491490 IP 127.0.0.1.10002 > 127.0.0.1.55238: S ack // handshake
13:48:58.491503 IP 127.0.0.1.55238 > 127.0.0.1.10002: . ack //
13:48:58.491536 IP 127.0.0.1.55238 > 127.0.0.1.10002: P <--data
13:48:58.491580 IP 127.0.0.1.55238 > 127.0.0.1.10002: F <-- client
closes session
13:48:58.491599 IP 127.0.0.1.10002 > 127.0.0.1.55238: . ack // OK
13:48:58.491701 IP 127.0.0.1.60212 > 127.0.0.1.10002: S
13:48:58.491726 IP 127.0.0.1.10002 > 127.0.0.1.60212: S ack
13:48:58.491738 IP 127.0.0.1.60212 > 127.0.0.1.10002: . ack
13:48:58.491745 IP 127.0.0.1.10002 > 127.0.0.1.60212: R<-- this is
strange answer.Why?
13:48:58.491887 IP 127.0.0.1.60804 > 127.0.0.1.10002: S
13:48:58.491914 IP 127.0.0.1.10002 > 127.0.0.1.60804: S ack
13:48:58.491924 IP 127.0.0.1.60804 > 127.0.0.1.10002: . ack
13:48:58.491931 IP 127.0.0.1.10002 > 127.0.0.1.60804: R
<...>
Some connections were OK but then server application begin to send RST right
after handshake.
Tuning listen backlog parameter doesn't help much, BUT what really solves
the "problem" is increasing time interval between client
requests.egusleep(1) solves the "problem" at all.
Iv maned for some tuning like syncache and syncookies but nothing usefull,
or i missed something.But here they are:
# sysctl -a | grep syncache
net.inet.tcp.syncache.rst_on_sock_fail: 1
net.inet.tcp.syncache.rexmtlimit: 3
net.inet.tcp.syncache.hashsize: 512
net.inet.tcp.syncache.count: 0
net.inet.tcp.syncache.cachelimit: 15360
net.inet.tcp.syncache.bucketlimit: 30
ipfw rules allows any from any, nothing special.
QUESTION:
So the question is why such thing happening?Is this is some freebsd defense
from syn flood?(to be honest don't think so because seems there is no fixed
"ALLOWED syn/syn-ack/ack per seconds"). It more looks like some queue
overflow,but I don't know what queue and how it can be enlarged.
If i can provide some more info to clear some aspects I will!
Thanks in advance, Vladimir.
I'v wrote some simplified(as simply as possible imho:)) small client and
server example which reproduses the situation (at least on our test stend),
here is the code. its not perfect, but i think its easy to read as example:
NOTICE: it writes logs to local0 level.
//--
//client.c
//--
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
uint8_t progname[]="client";
#define MAX_ITER 300
int send_msg();
int main(int argc,char **argv){
int res=0;
uint16_t counter=0;
openlog(progname,LOG_NDELAY,LOG_LOCAL0);
syslog(LOG_DEBUG,"Started");
while( counter<=MAX_ITER ){
syslog(LOG_DEBUG,"Attemp #%d",counter);
send_msg();
counter++;
}
return res;
}
int
send_msg(){
int sock;
int res;
struct sockaddr_in src_addr;
struct sockaddr_in dst_addr;
struct timeval tv;
uint8_t target_addr[]="127.0.0.1";
uint8_t target_port[]="10002";
sock=socket(AF_INET,SOCK_STREAM,0);
if(sock<0){
syslog(LOG_ERR,"ERROR on socket: %s\n",strerror(errno));
return -1;
}
src_addr.sin_family = AF_INET;
src_addr.sin_port = htons(INADDR_ANY);
src_addr.sin_addr.s_addr = INADDR_ANY;
res=bind(sock,(struct sockaddr*)&src_addr,sizeof(struct sockaddr_in));
if(res<0){
syslog(LOG_ERR,"ERROR on bind: %s\n",strerror(errno));
close(sock);
return -1;
}
dst_addr.sin_family = AF_INET;
dst_addr.si
Re: (TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow?
On Wednesday, July 13, 2011 6:37:26 am Vladimir Budnev wrote: > Hello. > > Iv faced some problem and seems don't realize the mechanincs why does it > occures. > First of all i'd like to notice that my freebsd knowledge and expirience is > limited, especially in such "strange" cases. > > In details(code example ill be at the end): > > System: > # uname -spr > FreeBSD 7.2-RELEASE amd64 > > We have simple TCP client and server. > > Server is very casual, it listens on some port in while->select->accept > loop. > > Client knocks on server port and sends some data and closes the port. > First it was designed for sending data 3-5/times per minute. But once during > test I'v noticed that if client sends data very fast (more precisely it > opens and closes socket to server very fast) there is > "54 - Connection reset by peer" error on call to "connect".(on client side > ofc) > > Some illustration from tcpdump: > (test on localhost.server side is port 10002.i'v cuted other fields for > simplicity) > <...> > 13:48:58.491229 IP 127.0.0.1.56677 > 127.0.0.1.10002: S > 13:48:58.491255 IP 127.0.0.1.10002 > 127.0.0.1.56677: S ack > 13:48:58.491266 IP 127.0.0.1.56677 > 127.0.0.1.10002: . ack > 13:48:58.491300 IP 127.0.0.1.56677 > 127.0.0.1.10002: P > 13:48:58.491346 IP 127.0.0.1.56677 > 127.0.0.1.10002: F > 13:48:58.491365 IP 127.0.0.1.10002 > 127.0.0.1.56677: . ack > > 13:48:58.491466 IP 127.0.0.1.55238 > 127.0.0.1.10002: S// > 13:48:58.491490 IP 127.0.0.1.10002 > 127.0.0.1.55238: S ack // handshake > 13:48:58.491503 IP 127.0.0.1.55238 > 127.0.0.1.10002: . ack // > 13:48:58.491536 IP 127.0.0.1.55238 > 127.0.0.1.10002: P <--data > 13:48:58.491580 IP 127.0.0.1.55238 > 127.0.0.1.10002: F <-- client > closes session > 13:48:58.491599 IP 127.0.0.1.10002 > 127.0.0.1.55238: . ack // OK > > 13:48:58.491701 IP 127.0.0.1.60212 > 127.0.0.1.10002: S > 13:48:58.491726 IP 127.0.0.1.10002 > 127.0.0.1.60212: S ack > 13:48:58.491738 IP 127.0.0.1.60212 > 127.0.0.1.10002: . ack > 13:48:58.491745 IP 127.0.0.1.10002 > 127.0.0.1.60212: R<-- this is > strange answer.Why? > > 13:48:58.491887 IP 127.0.0.1.60804 > 127.0.0.1.10002: S > 13:48:58.491914 IP 127.0.0.1.10002 > 127.0.0.1.60804: S ack > 13:48:58.491924 IP 127.0.0.1.60804 > 127.0.0.1.10002: . ack > 13:48:58.491931 IP 127.0.0.1.10002 > 127.0.0.1.60804: R > <...> > > Some connections were OK but then server application begin to send RST right > after handshake. > Tuning listen backlog parameter doesn't help much, BUT what really solves > the "problem" is increasing time interval between client > requests.egusleep(1) solves the "problem" at all. > > Iv maned for some tuning like syncache and syncookies but nothing usefull, > or i missed something.But here they are: > > # sysctl -a | grep syncache > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 512 > net.inet.tcp.syncache.count: 0 > net.inet.tcp.syncache.cachelimit: 15360 > net.inet.tcp.syncache.bucketlimit: 30 > > > ipfw rules allows any from any, nothing special. > > QUESTION: > So the question is why such thing happening?Is this is some freebsd defense > from syn flood?(to be honest don't think so because seems there is no fixed > "ALLOWED syn/syn-ack/ack per seconds"). It more looks like some queue > overflow,but I don't know what queue and how it can be enlarged. > > If i can provide some more info to clear some aspects I will! > > Thanks in advance, Vladimir. Do you have any of these in your netstat -s -p tcp output: 6186 embryonic connections dropped 63889 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 63889 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 63889 cookies sent 0 cookies received It is normal for syncache entries added == completed == cookies sent, I'm mostly curious about anything else besides that. It is possible when using the syncache to have the network stack decide it can't create a connection until it gets to the end of the 3-way handshake due to resource limits, etc. In that case the end of the 3-way handshake will get a RST in response. However, if your app just sends data and calls close() without doing any reads, it might close() succesfully while the data is in flight before the client machine sees the RST, so the client app will not see any errors. If the RST arrives before you finish calling write() and close() then you will get ECONNRESET errors from write() and close(). You can try turning off the syncache and syncookies as a test. This will probably trigger more ECONNRESET errors in connect() (which your app will need to retry on). However, the better fix is to track down what is cau
Re: (TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow?
First of all thanks for response! It is normal for syncache entries added == completed == cookies sent, I'm > mostly curious about anything else besides that. It is possible when using > the syncache to have the network stack decide it can't create a connection > until it gets to the end of the 3-way handshake due to resource limits, > etc. > In that case the end of the 3-way handshake will get a RST in response. > statistics i have: (cutted from netstat -s -p tcp) 89514 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 50220 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 39294 aborted 0 badack 0 unreach 0 zone failures 89514 cookies sent According to your hint I see nonzero aborted field, but dont know how to get the reason/interpret this. > However, if your app just sends data and calls close() without doing any > reads, it might close() succesfully while the data is in flight before the > client machine sees the RST, so the client app will not see any errors. If > the RST arrives before you finish calling write() and close() then you will > get ECONNRESET errors from write() and close(). > Hm..hope i get your idea, the difference is that client application recieve ECONNRESET as result to _connect_ call not as result from write/read/close, at that point i cant ignore it. I can spin/wait and try again, but that way every N iterations when problem occures there will be this "problem". As i mentioned(and in code example) client on every iteration makes connect/close, and those come very fast. Mb i misunderstood smth. You can try turning off the syncache and syncookies as a test. This will > probably trigger more ECONNRESET errors in connect() (which your app will > need > to retry on). Spin idea...yeah it sounds friendly but i dont think sy/syn-ack/ack/rst flood would be great:( > However, the better fix is to track down what is causing your > connections to be dropped in the first place, e.g. if you are hitting the > limit on inpcbs (look for failures in vmstat -z output) and fix that. > # vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES <...> inpcb:288,25610,6, 5155, 142849,0 tcpcb:728,25600,6, 454, 142849,0 <...> Those ones looks ok? > > -- > John Baldwin > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: (TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow?
On Wednesday, July 13, 2011 8:37:24 am Vladimir Budnev wrote: > statistics i have: > (cutted from netstat -s -p tcp) > 89514 syncache entries added > 0 retransmitted > 0 dupsyn > 0 dropped > 50220 completed > 0 bucket overflow > 0 cache overflow > 0 reset > 0 stale > 39294 aborted > 0 badack > 0 unreach > 0 zone failures > 89514 cookies sent > According to your hint I see nonzero aborted field, but dont know how to get > the reason/interpret this. Yep, the aborted entries are likely your resets. > > However, if your app just sends data and calls close() without doing any > > reads, it might close() succesfully while the data is in flight before the > > client machine sees the RST, so the client app will not see any errors. If > > the RST arrives before you finish calling write() and close() then you will > > get ECONNRESET errors from write() and close(). > > > > Hm..hope i get your idea, the difference is that client application recieve > ECONNRESET as result to _connect_ call not as result from write/read/close, > at that point i cant ignore it. I can spin/wait and try again, but that way > every N iterations when problem occures there will be this "problem". As i > mentioned(and in code example) client on every iteration makes > connect/close, and those come very fast. > Mb i misunderstood smth. Ah, when I was tracking down a similar issue I was only seeing errors on write (or sometimes not at all) not on connect(). A bit odd you are getting errors on connect(). Maybe the RST is arriving so fast the kernel notices it and marks the socket error before the process asleep in connect() gets a chance to run after it is awakened by the SYN/ACK processing. > You can try turning off the syncache and syncookies as a test. This will > > probably trigger more ECONNRESET errors in connect() (which your app will > > need > > to retry on). > > Spin idea...yeah it sounds friendly but i dont think sy/syn-ack/ack/rst > flood would be great:( Yes, fixing it for real would be better. > > However, the better fix is to track down what is causing your > > connections to be dropped in the first place, e.g. if you are hitting the > > limit on inpcbs (look for failures in vmstat -z output) and fix that. > > > # vmstat -z > ITEM SIZE LIMIT USED FREE REQUESTS > FAILURES > <...> > inpcb:288,25610,6, 5155, > 142849,0 > tcpcb:728,25600,6, 454, > 142849,0 > <...> > Those ones looks ok? Hmm, perhaps compare the 'kern.ipc.numopensockets' and 'kern.ipc.maxsockets' tunables under load on the server? -- John Baldwin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/158873: When I launch pf daemon, I have a kernel panic
Synopsis: When I launch pf daemon, I have a kernel panic Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: pluknet Responsible-Changed-When: Wed Jul 13 19:45:29 UTC 2011 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=158873 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/158873: When I launch pf daemon, I have a kernel panic
The following reply was made to PR kern/158873; it has been noted by GNATS. From: Sergey Kandaurov To: bug-follo...@freebsd.org, gobl...@gmail.com Cc: Subject: Re: kern/158873: When I launch pf daemon, I have a kernel panic Date: Wed, 13 Jul 2011 23:50:24 +0400 I think we need to merge net/if_pfsync.c 1.113 from vendor. Below is a more complete crash info. panic: _mtx_lock_sleep: recursed on non-recursive mutex pf task mtx @ /usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:3163 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x802db93a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x8047f407 = kdb_backtrace+0x37 panic() at 0x80448017 = panic+0x187 _mtx_lock_sleep() at 0x80437513 = _mtx_lock_sleep+0x343 _mtx_lock_flags() at 0x8043768c = _mtx_lock_flags+0x16c pfsync_send_plus() at 0x81072eda = pfsync_send_plus+0xaa pfsync_clear_states() at 0x81072ffe = pfsync_clear_states+0x6e pfioctl() at 0x8106024b = pfioctl+0x1c0b devfs_ioctl_f() at 0x803c442a = devfs_ioctl_f+0x7a kern_ioctl() at 0x8049984e = kern_ioctl+0xbe ioctl() at 0x80499aed = ioctl+0xfd syscallenter() at 0x8048e30b = syscallenter+0x1cb syscall() at 0x806bd630 = syscall+0x60 Xfast_syscall() at 0x806a853d = Xfast_syscall+0xdd --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800da70ac, rsp = 0x7fffd528, rbp = 0 --- KDB: enter: panic [ thread pid 48453 tid 100192 ] Stopped at 0x8047f01b = kdb_enter+0x3b:movq $0,0x6eeb82(%rip) -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/158873: When I launch pf daemon, I have a kernel panic
The following reply was made to PR kern/158873; it has been noted by GNATS. From: Sergey Kandaurov To: bug-follo...@freebsd.org, gobl...@gmail.com Cc: Subject: Re: kern/158873: When I launch pf daemon, I have a kernel panic Date: Thu, 14 Jul 2011 00:50:38 +0400 --000e0cd4c08e974e9704a7f99174 Content-Type: text/plain; charset=ISO-8859-1 Something like this will probably fix the panic (attached). -- wbr, pluknet --000e0cd4c08e974e9704a7f99174 Content-Type: text/x-patch; charset=US-ASCII; name="if_pfsync.diff" Content-Disposition: attachment; filename="if_pfsync.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gq2rgfnx0 SW5kZXg6IHN5cy9jb250cmliL3BmL25ldC9pZl9wZnN5bmMuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv Y29udHJpYi9wZi9uZXQvaWZfcGZzeW5jLmMJKHJldmlzaW9uIDIyMzgyMikKKysrIHN5cy9jb250 cmliL3BmL25ldC9pZl9wZnN5bmMuYwkod29ya2luZyBjb3B5KQpAQCAtMSw0ICsxLDUgQEAKIC8q CSRPcGVuQlNEOiBpZl9wZnN5bmMuYyx2IDEuMTEwIDIwMDkvMDIvMjQgMDU6Mzk6MTkgZGxnIEV4 cCAkCSovCisvKgkkT3BlbkJTRDogaWZfcGZzeW5jLmMsdiAxLjExMyAyMDA5LzAzLzAxIDEwOjM0 OjM4IGRsZyBFeHAgJAkqLwogCiAvKgogICogQ29weXJpZ2h0IChjKSAyMDAyIE1pY2hhZWwgU2hh bGF5ZWZmCkBAIC01OTAsOSArNTkxLDYgQEAKIHBmc3luY19pZl9kZXF1ZXVlKHN0cnVjdCBpZm5l dCAqaWZwKQogewogCXN0cnVjdCBtYnVmICptOwotI2lmbmRlZiBfX0ZyZWVCU0RfXwotCWludCBz OwotI2VuZGlmCiAKICNpZmRlZiBfX0ZyZWVCU0RfXwogCUlGX0xPQ0soJmlmcC0+aWZfc25kKTsK QEAgLTYwMCw5ICs1OTgsNyBAQAogCV9JRl9ERVFVRVVFKCZpZnAtPmlmX3NuZCwgbSk7CiAJSUZf VU5MT0NLKCZpZnAtPmlmX3NuZCk7CiAjZWxzZQotCXMgPSBzcGxuZXQoKTsKIAlJRl9ERVFVRVVF KCZpZnAtPmlmX3NuZCwgbSk7Ci0Jc3BseChzKTsKICNlbmRpZgogCiAJcmV0dXJuIChtKTsKQEAg LTYxNSwxMyArNjExLDE3IEBACiBwZnN5bmNzdGFydChzdHJ1Y3QgaWZuZXQgKmlmcCkKIHsKIAlz dHJ1Y3QgbWJ1ZiAqbTsKKwlpbnQgczsKIAorCXMgPSBzcGxuZXQoKTsKKwogCXdoaWxlICgobSA9 IHBmc3luY19pZl9kZXF1ZXVlKGlmcCkpICE9IE5VTEwpIHsKICNpZm5kZWYgX19GcmVlQlNEX18K IAkJSUZfRFJPUCgmaWZwLT5pZl9zbmQpOwogI2VuZGlmCiAJCW1fZnJlZW0obSk7CiAJfQorCXNw bHgocyk7CiB9CiAKIGludApAQCAtMTc4MCw3ICsxNzgwLDcgQEAKIAlzdHJ1Y3QgcGZzeW5jcmVx IHBmc3luY3I7CiAJc3RydWN0IGlmbmV0ICAgICpzaWZwOwogCXN0cnVjdCBpcCAqaXA7Ci0JaW50 IHMsIGVycm9yOworCWludCBlcnJvcjsKIAogCXN3aXRjaCAoY21kKSB7CiAjaWYgMApAQCAtMTgw NiwxNyArMTgwNiw4IEBACiAJCQlyZXR1cm4gKEVJTlZBTCk7CiAJCWlmIChpZnItPmlmcl9tdHUg PiBNQ0xCWVRFUykgLyogWFhYIGNvdWxkIGJlIGJpZ2dlciAqLwogCQkJaWZyLT5pZnJfbXR1ID0g TUNMQllURVM7Ci0JCWlmIChpZnItPmlmcl9tdHUgPCBpZnAtPmlmX210dSkgewotCQkJcyA9IHNw bG5ldCgpOwotI2lmZGVmIF9fRnJlZUJTRF9fCi0JCQlQRl9MT0NLKCk7Ci0jZW5kaWYKKwkJaWYg KGlmci0+aWZyX210dSA8IGlmcC0+aWZfbXR1KQogCQkJcGZzeW5jX3NlbmRvdXQoKTsKLSNpZmRl ZiBfX0ZyZWVCU0RfXwotCQkJUEZfVU5MT0NLKCk7Ci0jZW5kaWYKLQkJCXNwbHgocyk7Ci0JCX0K IAkJaWZwLT5pZl9tdHUgPSBpZnItPmlmcl9tdHU7CiAJCWJyZWFrOwogCWNhc2UgU0lPQ0dFVFBG U1lOQzoKQEAgLTE4ODMsMTAgKzE4NzQsNiBAQAogCQkJcmV0dXJuIChFSU5WQUwpOwogCiAjaWZk ZWYgX19GcmVlQlNEX18KLQkJUEZfTE9DSygpOwotI2VuZGlmCi0JCXMgPSBzcGxuZXQoKTsKLSNp ZmRlZiBfX0ZyZWVCU0RfXwogCQlpZiAoc2lmcC0+aWZfbXR1IDwgc2MtPnNjX2lmcC0+aWZfbXR1 IHx8CiAjZWxzZQogCQlpZiAoc2lmcC0+aWZfbXR1IDwgc2MtPnNjX2lmLmlmX210dSB8fApAQCAt MTg5OCwxMyArMTg4NSw3IEBACiAJCXNjLT5zY19zeW5jX2lmID0gc2lmcDsKIAogCQlpZiAoaW1v LT5pbW9fbnVtX21lbWJlcnNoaXBzID4gMCkgewotI2lmZGVmIF9fRnJlZUJTRF9fCi0JCQlQRl9V TkxPQ0soKTsKLSNlbmRpZgogCQkJaW5fZGVsbXVsdGkoaW1vLT5pbW9fbWVtYmVyc2hpcFstLWlt by0+aW1vX251bV9tZW1iZXJzaGlwc10pOwotI2lmZGVmIF9fRnJlZUJTRF9fCi0JCQlQRl9MT0NL KCk7Ci0jZW5kaWYKIAkJCWltby0+aW1vX211bHRpY2FzdF9pZnAgPSBOVUxMOwogCQl9CiAKQEAg LTE5MTgsMTAgKzE4OTksNiBAQAogCiAJCQlpZiAoIShzYy0+c2Nfc3luY19pZi0+aWZfZmxhZ3Mg JiBJRkZfTVVMVElDQVNUKSkgewogCQkJCXNjLT5zY19zeW5jX2lmID0gTlVMTDsKLSNpZmRlZiBf X0ZyZWVCU0RfXwotCQkJCVBGX1VOTE9DSygpOwotI2VuZGlmCi0JCQkJc3BseChzKTsKIAkJCQly ZXR1cm4gKEVBRERSTk9UQVZBSUwpOwogCQkJfQogCkBAIC0xOTMxLDE4ICsxOTA4LDExIEBACiAJ CQlhZGRyLnNfYWRkciA9IElOQUREUl9QRlNZTkNfR1JPVVA7CiAjZW5kaWYKIAotI2lmZGVmIF9f RnJlZUJTRF9fCi0JCQlQRl9VTkxPQ0soKTsKLSNlbmRpZgogCQkJaWYgKChpbW8tPmltb19tZW1i ZXJzaGlwWzBdID0KIAkJCSAgICBpbl9hZGRtdWx0aSgmYWRkciwgc2MtPnNjX3N5bmNfaWYpKSA9 PSBOVUxMKSB7CiAJCQkJc2MtPnNjX3N5bmNfaWYgPSBOVUxMOwotCQkJCXNwbHgocyk7CiAJCQkJ cmV0dXJuIChFTk9CVUZTKTsKIAkJCX0KLSNpZmRlZiBfX0ZyZWVCU0RfXwotCQkJUEZfTE9DSygp OwotI2VuZGlmCiAJCQlpbW8tPmltb19udW1fbWVtYmVyc2hpcHMrKzsKIAkJCWltby0+aW1vX211 bHRpY2FzdF9pZnAgPSBzYy0+c2Nfc3luY19pZjsKIAkJCWltby0+aW1vX211bHRpY2FzdF90dGwg PSBQRlNZTkNfREZMVFRMOwpAQCAtMTk5MywxMCArMTk2Myw2IEBACiAjZW5kaWYKIAkJCXBmc3lu Y19yZXF1ZXN0X3VwZGF0ZSgwLCAwKTsKIAkJfQotI2lmZGVmIF9fRnJlZUJTRF9fCi0JCVBGX1VO TE9DSygpOwotI2VuZGlmCi0JCXNwbHgocyk7CiAKIAkJYnJlYWs7CiAKQEAgLTIxNDIsMTIgKzIx MDgsNiBAQAogCWludCBvZmZzZXQ7CiAJaW50IHEsIGNvdW50ID0gMDsKIAotI2lmZGVmIF9fRnJl ZUJTRF9fCi0JUEZfQVNTRVJUKE1BX09XTkVEKTsKLSNlbHNlCi0Jc3BsYXNzZXJ0KElQTF9ORVQp OwotI2VuZGlmCi0KIAlpZiAoc2MgPT0gTlVMTCB8fCBzYy0+c2NfbGVuID09IFBGU1lOQ19NSU5Q S1QpCiAJCXJldHVybjsKIApAQCAtMjM0MiwyNyArMjMwMiwxMCBAQAogCXNjLT5zY19pZi5pZl9v Ynl0ZXMgKz0gbS0+bV9wa3RoZHIubGVuOwogI2VuZGlmCiAKLSNpZmRlZiBfX0ZyZWVCU0RfXwot CVBGX1VOTE9DSygpOwotI2VuZGlmCiAJaWYgKGlwX291dHB1
Re: kern/138029: [bpf] [panic] periodically kernel panic and reboot
Old Synopsis: [panic][bpf] periodically kernel panic and reboot New Synopsis: [bpf] [panic] periodically kernel panic and reboot State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Thu Jul 14 01:53:36 UTC 2011 State-Changed-Why: Most likely not amd64-specific. To submitter: is this still a problem? Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 14 01:53:36 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=138029 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/158880: [bpf] bpf_filter() can leak kernel stack contents
Old Synopsis: bpf_filter() can leak kernel stack contents New Synopsis: [bpf] bpf_filter() can leak kernel stack contents Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 14 01:54:35 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158880 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/158873: [pf] [panic] When I launch pf daemon, I have a kernel panic
Old Synopsis: When I launch pf daemon, I have a kernel panic New Synopsis: [pf] [panic] When I launch pf daemon, I have a kernel panic Responsible-Changed-From-To: freebsd-net->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 14 01:55:42 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158873 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154831: [arp] [patch] arp sysctl setting log_arp_permanent_modify has no effect
Synopsis: [arp] [patch] arp sysctl setting log_arp_permanent_modify has no effect State-Changed-From-To: patched->closed State-Changed-By: ae State-Changed-When: Thu Jul 14 04:21:55 UTC 2011 State-Changed-Why: Merged to stable/8. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=154831 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154831: commit references a PR
The following reply was made to PR kern/154831; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/154831: commit references a PR
Date: Thu, 14 Jul 2011 04:21:36 + (UTC)
Author: ae
Date: Thu Jul 14 04:21:27 2011
New Revision: 223995
URL: http://svn.freebsd.org/changeset/base/223995
Log:
MFC r223840:
Add again the checking for log_arp_permanent_modify that was by accident
removed in the r186119.
PR:kern/154831
Modified:
stable/8/sys/netinet/if_ether.c
Directory Properties:
stable/8/sys/ (props changed)
stable/8/sys/amd64/include/xen/ (props changed)
stable/8/sys/cddl/contrib/opensolaris/ (props changed)
stable/8/sys/contrib/dev/acpica/ (props changed)
stable/8/sys/contrib/pf/ (props changed)
Modified: stable/8/sys/netinet/if_ether.c
==
--- stable/8/sys/netinet/if_ether.cThu Jul 14 03:16:43 2011
(r223994)
+++ stable/8/sys/netinet/if_ether.cThu Jul 14 04:21:27 2011
(r223995)
@@ -680,11 +680,13 @@ match:
bcmp(ar_sha(ah), &la->ll_addr, ifp->if_addrlen)) {
if (la->la_flags & LLE_STATIC) {
LLE_WUNLOCK(la);
- log(LOG_ERR,
- "arp: %*D attempts to modify permanent "
- "entry for %s on %s\n",
- ifp->if_addrlen, (u_char *)ar_sha(ah), ":",
- inet_ntoa(isaddr), ifp->if_xname);
+ if (log_arp_permanent_modify)
+ log(LOG_ERR,
+ "arp: %*D attempts to modify "
+ "permanent entry for %s on %s\n",
+ ifp->if_addrlen,
+ (u_char *)ar_sha(ah), ":",
+ inet_ntoa(isaddr), ifp->if_xname);
goto reply;
}
if (log_arp_movements) {
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
