Re: ipsec packets apparently not getting to destination

* Jimmy Olgeni, 2013-12-03 : > I cannot imagine any obvious reason for packets getting "lost" after enc0, > so any hint would be much appreciated :) Chances are "netstat -s -p udp" will show you an increasing count of packets with bad checksum. See PRs kern/145737 and kern/146190. Thomas. _

Re: RFReview: remove aync IO from yppush

* Thomas Quinot, 2006-08-11 : > unsafe and unnecessary use of asynchronous I/O (F_ASYNC, SIGIO) on RPC This is now PR bin/102143. > Index: yppush_main.c > === > RCS file: /space/mirror/ncvs/src/usr.sbin/yppush/ypp

RFReview: remove aync IO from yppush

All, Our implementation of yppush is severely flawed, in that it makes unsafe and unnecessary use of asynchronous I/O (F_ASYNC, SIGIO) on RPC sockets. This specifically causes incorrect behaviour when pushing maps to multiple server, and SIGIO occurs while a memory allocation operation is in progr

RSVP on recent FreeBSD?

All, Is anyone running any RSVP daemon on a FreeBSD release >= 5? I would like to do RSVP with ALTQ, but the KOM RSVP daemon (3.0f) won't compile under 5.4-REL (many C++ problems). Thomas. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.o

Re: yppush going into an endless loop

* Thomas Quinot, 2004-10-19 : > On a 5.2.1-REL NIS server where NIS maps are updated every hour from a > crontab, I often see yppush going into an endless loop: Here is more information. I was able to capture the output of yppush on one of these occurrences: yppush: transfer of map netid.

yppush going into an endless loop

On a 5.2.1-REL NIS server where NIS maps are updated every hour from a crontab, I often see yppush going into an endless loop: 0x281220dc in __vfprintf () from /lib/libc.so.5 (gdb) bt #0 0x281220dc in __vfprintf () from /lib/libc.so.5 #1 0x28121b3f in strchr () from /lib/libc.so.5 #2 0x28122173

Re: freeaddrinfo(NULL)

* JINMEI Tatuya / [EMAIL PROTECTED]@C#:H, 2004-09-21 : > (or is valid for freeaddrinfo). It's the caller's responsibility to > ensure that this is a valid pointer. But consider the case where the Exactly. And it is the callee's responsibility to enforce the invariants he expects. If freeaddrinf

Re: freeaddrinfo(NULL)

* Hajimu UMEMOTO, 2004-09-21 : > Because, the behavior of freeaddrinfo (NULL) is undefined in RFC 2553 > nor RFC 3493. Having such an assumption is a potentially bug and > lose portability. That a construct has no defined meaning does not imply that we must make every effort to break application

freeaddrinfo(NULL)

Currently a call to freeaddrinfo (NULL) causes a segfault. Is there any reason why we should not make that a no-op? This would make freeaddrinfo behave in a manner consistent with free(3), and also with what happens on Linux. Thomas. -- [EMAIL PROTECTED] _

Userland ppp hung in Ack-Rcvd

I observed a peculiar situation today on an ADSL link using pptpclient and the userland ppp daemon: the LCP negociation hunk in state Ack-Rcvd for almost 3 hours (until I killed it) without any progress, but without timing out, either. Here is an excerpt from the log: Apr 3 05:25:02 melusine pp