In message <[EMAIL PROTECTED]>,
Guy Helmer writes:
>I have also suggested this (a sysctl knob) within the past few weeks and
>had no negative responses. However, since I have not received any
>messages saying "this exists for such-and-such a reason", I vote for (a).
>If you don't do it soon,
In message <[EMAIL PROTECTED]>, Boris Popo
v writes:
> Before starting import process for smbfs, I would like to
>introduce new API which greatly simplifies process of packaging data into
>mbufs and fetching it back (in fact, similar API already presented in the
>tree, but it is private to t
In message <[EMAIL PROTECTED]>, Boris Popo
v writes:
> No, in the current implementation mb_get* functions will work
>properly. But mb_put* will fail. This can be avoided by implementing
>alignment-safe set* macros (which can be written in two variants - first
>form is for aligned objects an
The RPC client code in libc performs UDP RPC calls with sendto()
and recvfrom() using an unconnected socket. When a reply arrives,
the library code checks only that the XID of the reply matches that
of the request; it does not check that the reply came from the
address to which the request was se
In message <[EMAIL PROTECTED]>, Barney Wolff writes:
>1. Multi-homed hosts are in fact very common, especially in
>corporate environments. To get the right source addr in
>its reply, the server must open separate sockets on each
>of its host's addresses - as named and ntpd do. And t
In message <[EMAIL PROTECTED]>, Thomas Moestl writes:
>
>I have a patch that does just that (although it just overloads
>IP_RECVDSTADDR for sendmsg instead of creating a new flag). I wrote it
>some time ago for a DNS server (the standard requires the source
>address to be the address the packet we
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>
>I would like to change the RPC client code to use connect() for
>UDP sockets. I think this would be a more modern behaviour; it is
As a first step to achieve this goal, I would like to commit the
following patch to the RPC libr
In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>> Our getaddrinfo(3) doesn't support AF_UNIX.
>
>Arg - I looked into src/contrib/bin/lib/irs/getaddrinfo.c
>The one in libc is different...
I'd very much like to see PF_LOCAL support added to our getaddrinfo()
and getnameinfo(). I know that PF
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>
>I'd very much like to see PF_LOCAL support added to our getaddrinfo()
>and getnameinfo(). I know that PF_LOCAL sockets have semantics that
Here is quick and simple implementation - any comments welcome. It
probably needs a
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>
>I think that might be due to a bug in the shared interrupt code that
>Ian Dowse sent me about earlier today.
Just to add a few details - there is a bug in the update_masks()
function in i386/isa/intr_machdep.c that can cause
I came across a problem recently when using Etherboot with FreeBSD's
bootpd. Etherboot was specifying a "Maximum DHCP Message Size" of
1500, which caused bootpd to generate a reply larger than the MTU,
and Etherboot can't handle fragments.
As pointed out by Ken Yap on the Etherboot mailing list,
In message <[EMAIL PROTECTED]>, David Malone writes:
>
>So the M_LEADINGSPACE macro should probaly read:
>
>#defineM_LEADINGSPACE(m)
> \
> (!M_WRITABLE(m) ? 0 : \
> (m)->m_flags & M_EXT ?
In message <8BA878388251D311B08200508B449FD10D0E3F4A@BEHDEVEX1>, Rudi Mathijsse
n writes:
>---
>Fatal trap 12: page fault while in kernel mode
>fault virtual address = 0x79c02812
This is caused by a bug in ip_icmp.c relating to the generation of
ICMP redirect messages that was fixed just before
[a rather delayed response to this posting]
In message <[EMAIL PROTECTED]>, Garrett Wollman write
s:
>In looking over mbuf handling for TCP some more, I noticed a puzzling
>omission. When sosend() is handed an mbuf chain rather than a uio, it
>makes no effort to check whether the chain would ac
I was just trying to track down a weird behaviour I had observed
involving VNC and sshd. When a user logs in via sshd, their $DISPLAY
would often end up being the same as that of an existing Xvnc
session:
> sockstat | grep 6013 |grep '\*'
root sshd 257107 tcp4 *:6013
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>Now since the default ruleset is to deny everything, the client
>locks up spewing 'nfsd send error 13'.
>
>Now give it two or three shots and you may get the server
>to lock up as well! (seems to run out of mbufs)
I must have forgotten to
In message <[EMAIL PROTECTED]>, Josef Karthauser writes:
>The revision level of what? Every file has it's own revision level, and
>there isn't a global revision number for the whole system. How are you
>getting the p28 number?
He means RELENG_4_3 patch level 28, which is the most recent securit
It was discussed here some time ago that we should have an
IP_SENDSRCADDR ancillary data type to match the IP_RECVDSTADDR
socket option. This permits a server process binding to a wildcard
UDP socket to select the IP address from which outgoing packets are
sent on a per-datagram basis. When combi
In message <[EMAIL PROTECTED]>, Mike Silb
ersack writes:
>
>I haven't looked at the implementation, but I think that it would be wise
>to include the patch before 5.0-release so that there's a clear cutoff
>where the feature became available.
Ok - I'll see what the reaction here is first and then
In message <[EMAIL PROTECTED]>, Archie Cobbs wri
tes:
>Oops, you're right.. sorry for the misinformation.
>
>Sounds like a bug to me (did Iasen file a PR?)
kern/38872 already exists, and I'm sure there is a much older PR
that also describes this problem. Basically it is hard to fix because
the err
In message <[EMAIL PROTECTED]>, Jul
ian Elischer writes:
>the local fwd command is only implemented for TCP
Here is a patch against -stable that I did a while ago, but I never
got around to doing a -current version - the code there is quite
different.
Ian
Index: udp_usrreq.c
In message <[EMAIL PROTECTED]>, Sam Leffler writes:
>uipc_socket.c has a KASSERT in soreceive that I think is wrong. It dates from
>
>a long time ago but I can't tell exactly who created it since some
>intermediate munging buggered the CVS logs.
It was there in revision 1.1 as:
m = so-
22 matches
Mail list logo
