Looks nice, just what I needed two weeks ago and partly had
to implement myself :-)
But, I would recommend to stick with the ususal naming of size dependend
things, by appending a numeric suffix. Something like:
int mb_get8(struct mbdata *mbp, u_int8_t *x);
int mb_get16(struct mbdata *mbp, u_
On Wed, Feb 07, 2001 at 11:42:57AM +0530, Madhavi Suram wrote:
> Is there any function in 'C' to get ethernet hardware address from IP
> address (not only for interfaces on the same machine... For any IP
> address), equivalent to 'arp' command on FreeBSD? If there isn't any such
> function, can yo
On Tue, 6 Feb 2001, Bosko Milekic wrote:
> > Since currently there isn't many consumers of this code I can
> > suggest to define an option LIBMBUF in the kernel configuration file
> and
> > add KLD libmbuf (with interface libmbuf), so kernel footprint will
> not be
>
> I am in favor of such
On Wed, 7 Feb 2001, Harti Brandt wrote:
> But, I would recommend to stick with the ususal naming of size dependend
> things, by appending a numeric suffix. Something like:
>
> int mb_get8(struct mbdata *mbp, u_int8_t *x);
> int mb_get16(struct mbdata *mbp, u_int16_t *x);
> int mb_get16le(stru
On Wed, 7 Feb 2001, Boris Popov wrote:
BP>> Using 'word' and 'doubleword' is rather confusing (when speeking of words
BP>> I would think of 32 bit nowadays).
BP>
BP> Well, it depends. For me 'word', 'dword' and 'qword' are clear
BP>from the good old 8bit days :)
BP>
BP> If numbers in the
If a "dmesg | grep fxp2" does not show any messages at all, does it means
that the interface is not existing ?
If yes how it comes I can see this interface fully configured by
"ifconfig fxp2" ?
fxp2: flags=8843 mtu 1500
inet xx.xx.xx.104 netmask 0xfe00 broadcast xx.xx.xx.255
Jean-Christophe Varaillon wrote:
> If a "dmesg | grep fxp2" does not show any messages at all, does it means
> that the interface is not existing ?
No, try: grep fxp2 /var/run/dmesg.boot
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
"Rogier R. Mulhuijzen" wrote:
> At 23:42 6-2-01 -0800, Alfred Perlstein wrote:
> >* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [010206 22:19] wrote:
> > > Hi
> > > Could you tell me how to implement the callback mechanism in FreeBSD?
> >
> >see the signal manpage for an example of how to specify a call
Hi.
I would like to install a pptp server on a FreeBox 4.2 firewall.
I have to allow remote connections from windows clients (Win 98 - 2k) to
this firewall. This firewall runs IPF and IPNat.
I tried mpd 3.2
(ftp://ftp.freebsd.org/pub/FreeBSD/branches/-current/ports/net/mpd-netgraph/
pkg-descr).
Olivier Cherrier wrote:
>
> Hi.
>
> I would like to install a pptp server on a FreeBox 4.2 firewall.
> I have to allow remote connections from windows clients (Win 98 - 2k) to
> this firewall. This firewall runs IPF and IPNat.
>
> I tried mpd 3.2
> (ftp://ftp.freebsd.org/pub/FreeBSD/branches/-c
> Has someone succeed in using mpd as pptp server with windows
>clients ?
>
>yes many many have..
>
>I have done it but not here. It was relatively easy..
>wait for archie to come on line (He's in California)
>to help find your problem..
>
Yes, I've already asked him I am a little bit confu
Hi,
just occurred to me that there exists the following feature of
send/sendmsg and probably also write on UDP sockets, and it would
be worth documenting.
When you attempt to send() to an udp socket, the socket buffer
(which has no function other than bounding the max message size
for UDP socket
* Luigi Rizzo <[EMAIL PROTECTED]> [010207 09:14] wrote:
> Hi,
>
> just occurred to me that there exists the following feature of
> send/sendmsg and probably also write on UDP sockets, and it would
> be worth documenting.
Yes it is.
[snip]
> When you attempt to send() to an udp socket, the socke
> > When you attempt to send() to an udp socket, the socket buffer
> > (which has no function other than bounding the max message size
> > for UDP sockets) is just bypassed, and the low-level routine gets
> > called. The latter (typically ip_output() or ether_output()) can
> > return an ENOBUFS me
Alfred Perlstein wrote:
>
> * Luigi Rizzo <[EMAIL PROTECTED]> [010207 09:14] wrote:
> > Hi,
> >
> > just occurred to me that there exists the following feature of
> > send/sendmsg and probably also write on UDP sockets, and it would
> > be worth documenting.
>
> Yes it is.
>
> [snip]
> > When y
> > ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS
>
> Or perhaps ENOBUFS == E_SYSTEM_NEEDS_TO_RAISE_NMBCLUSTERS_ALL_ON_ITS_OWN?
it is not an NMBCLUSTERS problem, it is just the device queue
which is filling up, and this is a perfectly normal and desired
behaviour. One would just want that to be ha
Luigi Rizzo wrote:
>
> Hi,
>
> just occurred to me that there exists the following feature of
> send/sendmsg and probably also write on UDP sockets, and it would
> be worth documenting.
>
> When you attempt to send() to an udp socket, the socket buffer
> (which has no function other than boundi
* Luigi Rizzo <[EMAIL PROTECTED]> [010207 09:57] wrote:
>
> not really. The problem is not running out of mbufs, is that the
> interface queue (usually limited to net.inet.ip.intr_queue_maxlen)
> fills up, and this has nothing to do with NMBCLUSTERS. This used
> not to be a problem in the past pr
> Since this is UDP, I'm not sure much should be done, perhaps
> just document the return value, but honestly since it's _U_DP
exactly -- documenting is the only thing we can do.
There are far too many apps that might break if we
change this behaviour.
Ideally one could add a setsockopt to implem
Can anyone comment on this patch?
http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c
Kris
- Forwarded message from [EMAIL PROTECTED] -
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: accept(2) behavior with tcp RST rig
< said:
> ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS
BT! Wrong, but thanks for playing.
ENOBUFS is returned in many more circumstances than simply ``out of
mbufs''.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Garret,
on a similar subject (UDP sockets), i notice that
socket buffers do not have a pointer to the end of
the queued mbufs, so sbappend*() routines have to scan the
list of queued bufs. As you can imagine this is
causing some nasty effect when a receiver is slow.
Is it worthhwile to fix this
< said:
> A starting point, increment, and ceiling
NMBCLUSTERS *is* the ceiling. No memory is actually allocated
(although virtual address space is) until those clusters are actually
requested.
> based on the memory size of the system
That would be an improvement, but recall that many of thes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
< said:
> Can anyone comment on this patch?
> http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c
I don't necessarily agree that the previous behavior was wrong, but
I'm willing to bet that a lot of programs don't bother to chec
< said:
> on a similar subject (UDP sockets), i notice that
> socket buffers do not have a pointer to the end of
> the queued mbufs, so sbappend*() routines have to scan the
> list of queued bufs. As you can imagine this is
> causing some nasty effect when a receiver is slow.
I've thought about
Won't comment on the implementation as I have't had a chance to review it
yet, but the description sounds right, and compatible with
http://www.opengroup.org/orc/DOCS/XNS/text/accept.htm
http://www.fifi.org/cgi-bin/man2html/usr/share/man/man2/accept.2.gz
There are some interesting comments
> I've thought about this problem before, in the context of a TCP
> sender, where the best solution is both (a) hard and (b) significantly
> different. I had not thought about it in the case of UDP, but yes,
> that could be a significant issue, particularly since UDP packets on
> the receive queu
In article [EMAIL PROTECTED]> you write:
>-=-=-=-=-=-
>
>Can anyone comment on this patch?
>
>http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c
Looks good to me (although the patch is mixed in with a bunch
of other crud). I've tested it out locally and will commit it
unless
>
>Yes, I've already asked him I am a little bit confused
>that I don't
>succeed ... :(
>Maybe it is my fuc... windows 2k which is the problem
>
Ho, I think that I found my problem ... maybe
In fact, the "mppe encryption" is included in the MS-Chap protocol, isn't it
?
The encryption,
> 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 the netncp code and it will be really nice to
> sha
>>Looks good to me (although the patch is mixed in with a bunch
>>of other crud). I've tested it out locally and will commit it
>>unless there are any objections.
>
> it is because of cvs issue. the important portion is below.
Looks good to me as well.
-DG
David Greenman
Co-founder,
>>Looks good to me (although the patch is mixed in with a bunch
>>of other crud). I've tested it out locally and will commit it
>>unless there are any objections.
> it is because of cvs issue. the important portion is below.
oops, need some change in uipc_syscalls.c side... hold
Current updated patch for comments is below.
Jayanth did make one point that an application could assume that
the error return from accept was in regards to the listening socket
instead of the new socket, so that may be a concern.
--
Jonathan
Index: uipc_socket.c
==
>>>Looks good to me (although the patch is mixed in with a bunch
>>>of other crud). I've tested it out locally and will commit it
>>>unless there are any objections.
>> it is because of cvs issue. the important portion is below.
> oops, need some change in uipc_syscalls.c side... hol
>Looks good to me (although the patch is mixed in with a bunch
>of other crud). I've tested it out locally and will commit it
>unless there are any objections.
it is because of cvs issue. the important portion is below.
itojun
@@ -320,11 +359,8 @@ soaccept(so, nam)
so->so_s
Hi Luigi, -net:
There seems to be a problem with the BRIDGE-specific
"optimization" in if_ed.c. What it does is avoid getting a packet from
the card if bridge_in() says that we're going to drop it. However, the
code is broken and something eventually leads to a page fault.
Disactivating this
> Hi Luigi, -net:
just one thing, before posting details could you verify that the
problem still occurs with the code that is in -STABLE as of today ?
I have done a bunch of changes to this and related code over the
last couple of weeks, including testing on an "ed" card, and have
not seen any p
Hi,
I would be grateful if someone could test the attached patch which
deals with the following problem:
on all *BSD version, socket buffers contain a list of
incoming and/or outgoing mbufs. Unfortunately the list only
has a pointer to the head, meaning that all append op
Luigi wrote:
> Just one thing, before posting details could you verify that
> the problem still occurs with the code that is in -STABLE as
> of today? I have done a bunch of changes to this and related
> code over the last couple of weeks, including testing on an
> "ed" card,
> i believe you will want to merge this.
> scenario:
> - you are listening to tcp port
> - someone comes in, handshake (SYN, SYNACK, ACK)
> - someone sends RST
> - your server issues accept(2)
> previous behavior: accept(2) returns successful result with
Jonathan Lemon writes:
> Jayanth did make one point that an application could assume that
> the error return from accept was in regards to the listening socket
> instead of the new socket, so that may be a concern.
Yes I have always assumed this to be true. If the connection is
already broken be
Olivier Cherrier writes:
> Ho, I think that I found my problem ... maybe
> In fact, the "mppe encryption" is included in the MS-Chap protocol, isn't it
MPPE encryption piggybacks on MPPC compression. You can have
either or both of 'E' and/or 'C'. Mpd only supports 'E' because
'C' requires proprie
>> Jayanth did make one point that an application could assume that
>> the error return from accept was in regards to the listening socket
>> instead of the new socket, so that may be a concern.
>Yes I have always assumed this to be true. If the connection is
>already broken before I get it, why
Hi Yusuf,
As described by cvsweb, the patches to IPFW did not change the behavior
with log messages. To be more exactly, either netinet/ip_fw.c either
kern/subr_prf.c should be changed to match each other. In my local setup I
use a patch script after cvsup to fix ip_fw.c, removing all insta
interesting dump... because it shows a bogus "length" parameter
passed to ed_pio_readmem()
Can you by chance find out what is the "len" value passed
to ed_get_packet ? The printout in line #10 below
is partially deleted by some error message.
Now, NE2000 clones if you look at the driver are know
45 matches
Mail list logo
