Re: CFR: Sequential mbuf read/write extensions
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_int16_t *x); int mb_get16le(struct mbdata *mbp, u_int16_t *x); int mb_get16be(struct mbdata *mbp, u_int16_t *x); int mb_get32(struct mbdata *mbp, u_int32_t *x); ... Using 'word' and 'doubleword' is rather confusing (when speeking of words I would think of 32 bit nowadays). harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: getting hardware address
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 you suggest me any other way of achieving this? You could check the source of arp of course, /usr/src/usr.sbin/arp/arp.c Edwin -- Edwin Groothuis | Interested in MUDs? Visit Fatal Dimensions: [EMAIL PROTECTED] | http://fataldimensions.nl.eu.org/ --+ telnet://fataldimensions.nl.eu.org:4000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Sequential mbuf read/write extensions
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 an option on the condition that it is > temporary. In other words, only until we decide "we have converted > enough code to use this code so we should remove the option now." The > reason is that otherwise, we will be faced with numerous "#ifdef > LIBMBUF ... #else ... #endif" code. I assume this is what you meant, Not exactly so. 'option LIBMBUF' will just connect the source file to kernel makefile. There is no need for any #ifdef's in the code. > #define M_TRYWAIT M_WAIT is not right. > (M_WAIT is no longer to be used in the mbuf code.) You omitted the surrounding "#ifndef M_TRYWAIT" which makes this code portable to RELENG_4 (mind you, this code taken from smbfs). Of course, this should be stripped before import. > The succesfull return values are 0, I don't have a problem with this, > specifically, but I would assume that this: > if (!mb_init(mbp)) ... would be more "logical" (I use the term > loosely) if it meant: "if initialization fails" (now it means "if > initialization is succesful"). I'm generally don't like such syntax if function or variable name do not clearly specify which value it should have/return on success. Nearly all functions in this file return zero or error code, so the correct syntax of the above will be: error = mb_init(mbp); if (!error) or if (error) return error; or if (mb_init(mbp) != 0) return ESOMETHINGEVIL; > > significantly affected. The names of source and header files are > > questionable too and I would appreciate good suggestions (currently > they > > are subr_mbuf.c and subr_mbuf.h). > > Hmmm. Maybe subr_mblib.c and libmb.h ? I don't want to turn this > into a bikeshed ( :-) ), so I suggest that you decide. Personally, I > would prefer that it be something other than "subr_mbuf.c" simply > because it may be a little misleading in some cases. Good point. > Boris, this is really a great interface and nice looking, clean code. I'm sure, this code can be significantly improved by mbuf gurus :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: CFR: Sequential mbuf read/write extensions
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(struct mbdata *mbp, u_int16_t *x); > int mb_get16be(struct mbdata *mbp, u_int16_t *x); > int mb_get32(struct mbdata *mbp, u_int32_t *x); > ... > > Using 'word' and 'doubleword' is rather confusing (when speeking of words > I would think of 32 bit nowadays). Well, it depends. For me 'word', 'dword' and 'qword' are clear from the good old 8bit days :) If numbers in the function names looks good I can live with it. Opinions ? -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: CFR: Sequential mbuf read/write extensions
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 function names looks good I can live with it. Well, I just looked back to the bus_space stuff and discovered, that they use suffixes of _[1234] to count the number of bytes the functions operate on. Perhaps this is a better variant? Anyway, I think, numbers are much clearer, than words in this case (As an example, what does ntohl operate on if longs are 64 bit??). As a side note: Someone told me that Mickeysoft is trying to persuade the C standardisation people to drop the requirement that longs should not be shorter than int's. This is, he said, because of their braindamage with DWORD in -zillions of header files... If I look how they continue to cripple C, this may also slip through :-( harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
- Interface Question -
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 ether media: autoselect (100baseTX) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP JC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: - Interface Question -
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
Re: What's the callback mechanism?
"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 callback > >paramter. > > When I read his question I thought he meant callbacks with modems... =) > > Can you be more specific in your question maybe? Nokia use an embedded FreeBSD kernel in their router product, I suspect he means something to do with the networking stack - possibly the socket upcall mechanism. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
pptp server
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). But, I don't success in establishing a vpn between a windows and my pptp server : windows don't accept the mpd encryption protocol. Has someone succeed in using mpd as pptp server with windows clients ? I would like to ask you whether someone knows a solution to do VPNs between a BSD and many windows clients (with or without mpd)? Thanks a lot in advance. Olivier Cherrier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: pptp server
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/-current/ports/net/mpd-netgraph/ > pkg-descr). > But, I don't success in establishing a vpn between a windows and my pptp > server : windows don't accept the mpd encryption protocol. > > 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.. > > I would like to ask you whether someone knows a solution to do VPNs between > a BSD and many windows clients (with or without mpd)? > > Thanks a lot in advance. > > Olivier Cherrier > > 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: pptp server
> 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 confused that I don't succeed ... :( Maybe it is my fuc... windows 2k which is the problem Olivier. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
send problem on udp socket...
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 sockets) is just bypassed, and the low-level routine gets called. The latter (typically ip_output() or ether_output()) can return an ENOBUFS message if some queue fills up down there (typically the interface queue), and the error message is passed up. Now, the send() manpage is technically correct as it only mentions the socket buffer full as the reason for blocking, but in my opinion the above is not _that_ obvious and it would be worth documenting. As a matter of fact, i wonder if it would be a good idea to try and improve this behaviour by letting sosend() do a tsleep() on the device/subsystem reporting the failure, and have the latter issue a wakeup when space frees again. The only thing is, i believe this has some odd ramifications with handling select/poll, and might break some software that does not handle blocking send() on UDP sockets. 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: send problem on 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 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 message if some queue fills up down there (typically > the interface queue), and the error message is passed up. > > Now, the send() manpage is technically correct as it only > mentions the socket buffer full as the reason for blocking, > but in my opinion the above is not _that_ obvious and it would > be worth documenting. > > As a matter of fact, i wonder if it would be a good idea to > try and improve this behaviour by letting sosend() do a tsleep() > on the device/subsystem reporting the failure, and have the > latter issue a wakeup when space frees again. The only thing > is, i believe this has some odd ramifications with handling > select/poll, and might break some software that does not > handle blocking send() on UDP sockets. ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS Sorry, basically you shouldn't see ENOBUFS unless you're doing something wrong, running a box that isn't set up to handle the amount of traffic you want to push through it. If you're unclear on how to fix it then leave it be. If you can fix it such that: In the non-block case: ENOBUFS translates into EWOULDBLOCK In the blocking case: ENOBUFS restarts the syscall But in both cases: It sets a callback such that the select()/poll()/kevent() filter gets a callback when the mbuf subsystem becomes free enough. The problem here, is that you still have a race, you can return "ready to send" but yet another subsystem decideds to chew mbufs before you get to restart your call. I guess we have to document that as well, but is it allowable via any spec out there? "_maybe_ ready for more data" ie. select() return ok, but write return not ok? -- -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: send problem on udp socket...
> > 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 message if some queue fills up down there (typically > > the interface queue), and the error message is passed up. ... > ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS > > Sorry, basically you shouldn't see ENOBUFS unless you're doing > something wrong, running a box that isn't set up to handle the > amount of traffic you want to push through it. 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 precisely because boxes were slower than ethernet cards. And trying to push through a device more than it can handle happens all the time with disks, and it is the reason why you want to have blocking behaviour. Re. the race that you mention below, again it happens all the times -- select tells you can do X, then someone else is faster and your X syscall fails. See the case of multiple servers trying to accept() on a socket. cheers luigi > The problem here, is that you still have a race, you can return > "ready to send" but yet another subsystem decideds to chew mbufs > before you get to restart your call. I guess we have to document > that as well, but is it allowable via any spec out there? > "_maybe_ ready for more data" ie. select() return ok, but write > return not ok? > > -- > -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: send problem on udp socket...
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 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 message if some queue fills up down there (typically > > the interface queue), and the error message is passed up. > > > > Now, the send() manpage is technically correct as it only > > mentions the socket buffer full as the reason for blocking, > > but in my opinion the above is not _that_ obvious and it would > > be worth documenting. > > > > As a matter of fact, i wonder if it would be a good idea to > > try and improve this behaviour by letting sosend() do a tsleep() > > on the device/subsystem reporting the failure, and have the > > latter issue a wakeup when space frees again. The only thing > > is, i believe this has some odd ramifications with handling > > select/poll, and might break some software that does not > > handle blocking send() on UDP sockets. > > ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS Or perhaps ENOBUFS == E_SYSTEM_NEEDS_TO_RAISE_NMBCLUSTERS_ALL_ON_ITS_OWN? A starting point, increment, and ceiling, based on the memory size of the system, might be a more reasonable design for a lot of these hard-coded parameters left over from the days of the VAX 750. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: send problem on udp socket...
> > 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 handled as in the case of writes to a disk or the like -- i.e. wait until the subsystem (in this case the network device) is ready. For disks and TCP the synchronization is achieved through the socket buffer and (presumably for disks as well, i am no expert on filesystems) explicit acks on write ops. For UDP sockets things are unfortunately a bit more complex as there is no ack nor socket buffers. Plus there might be around a ton of software which relies on the current behaviour... 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: send problem on udp socket...
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 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 message if some queue fills up down there (typically > the interface queue), and the error message is passed up. > > Now, the send() manpage is technically correct as it only > mentions the socket buffer full as the reason for blocking, > but in my opinion the above is not _that_ obvious and it would > be worth documenting. > > As a matter of fact, i wonder if it would be a good idea to > try and improve this behaviour by letting sosend() do a tsleep() > on the device/subsystem reporting the failure, and have the > latter issue a wakeup when space frees again. The only thing > is, i believe this has some odd ramifications with handling > select/poll, and might break some software that does not > handle blocking send() on UDP sockets. this is not just UDP but any packet based protocol. ping(8)(1?) uses this fact when you do a ping -f. if it get's a ENOBUFS, it does a usleep and backs off a bit. don't change it as it's teh expected behaviour. (well, at least I expect it) > > 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 -- __--_|\ 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: send problem on udp socket...
* 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 precisely because boxes were slower > than ethernet cards. > > And trying to push through a device more than it can handle > happens all the time with disks, and it is the reason why > you want to have blocking behaviour. > > exhaustion whereas the problem is elsewhere> Oh, sorry, I'm pretty used to seeing the issue I _thought_ you brought up so I instictively sent the pre-thought out message. :) > Re. the race that you mention below, again it happens all > the times -- select tells you can do X, then someone else > is faster and your X syscall fails. See the case of multiple > servers trying to accept() on a socket. Er, that I understand. But it's not that expected when you're the only one writing/accepting. I guess defensive coding is a good thing. :) 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 it could just easily fail silently as long as local datagrams are allowed to be lossy. -- -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: send problem on udp socket...
> 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 implement a truly blocking behaviour on sockets where there is not an explicit underlying flow control scheme, but flow control info can still be derived by other means. > it could just easily fail silently as long as local datagrams > are allowed to be lossy. i am not much concerned about this, but rather by the fact that those apps which want to send as fast as possible have no better way than looping around a non-blocking call, whereas it would be much more efficient to pass signals up. Next life... cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
[itojun@iijlab.net: accept(2) behavior with tcp RST right afterhandshake]
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 right after handshake X-Template-Reply-To: [EMAIL PROTECTED] X-Template-Return-Receipt-To: [EMAIL PROTECTED] X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: [EMAIL PROTECTED] Date: Wed, 07 Feb 2001 21:39:49 +0900 X-UIDL: aff7d2fbee72775e2137abcde0bef0d0 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 zero- length sockaddr. new behavior: return ECONNABORTED. effect: - if someone runs nmap against your machine, and you are unlucky, your server listening to tcp port (like BIND9) can get segv/abort due to unexpected zero-length sockaddr + successful error return on accept(2). itojun --- Forwarded Messages Return-Path: [EMAIL PROTECTED] Return-Path: <[EMAIL PROTECTED]> Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA00242 for <[EMAIL PROTECTED]>; Wed, 7 Feb 2001 21:35:16 +0900 (JST) Received: (from daemon@localhost) by orange.kame.net (8.9.3+3.2W/3.7W/smtpfeed 1.06) id VAA48429; Wed, 7 Feb 2001 21:35:16 +0900 (JST) Received: (from itojun@localhost) by orange.kame.net (8.9.3+3.2W/3.7W) id VAA48423; Wed, 7 Feb 2001 21:35:15 +0900 (JST) Date: Wed, 7 Feb 2001 21:35:15 +0900 (JST) From: Jun-ichiro itojun Hagino <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> To: cvs-kame:; Subject: kame cvs commit: kame/freebsd4/sys/kern uipc_socket.c kame/netbsd/sys/kern uipc_socket.c kame/openbsd/sys/kern uipc_socket.c Reply-to: [EMAIL PROTECTED] X-Filter: mailagent [version 3.0 PL68] for [EMAIL PROTECTED] itojun 2001/02/07 21:35:15 JST Modified files: freebsd4/sys/kernuipc_socket.c netbsd/sys/kern uipc_socket.c openbsd/sys/kern uipc_socket.c Log: return ECONNABORTED, if the socket (tcp connection for example) is disconnected by RST right before accept(2). fixes PR 10698/12027. checked with SUSv2, XNET 5.2, and Stevens (unix network programming vol 1 2nd ed) section 5.11. Revision ChangesPath 1.2 +243 -10 kame/freebsd4/sys/kern/uipc_socket.c 1.3 +1 -1 kame/netbsd/sys/kern/uipc_socket.c 1.3 +1 -1 kame/openbsd/sys/kern/uipc_socket.c --- Message 2 Return-Path: [EMAIL PROTECTED] Return-Path: <[EMAIL PROTECTED]> Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA00253 for <[EMAIL PROTECTED]>; Wed, 7 Feb 2001 21:35:20 +0900 (JST) Received: (from itojun@localhost) by orange.kame.net (8.9.3+3.2W/3.7W/smtpfeed 1.06) id VAA48466; Wed, 7 Feb 2001 21:35:19 +0900 (JST) Date: Wed, 7 Feb 2001 21:35:19 +0900 (JST) From: Jun-ichiro itojun Hagino <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: kame-local cvs commit: kame/bsdi4/sys/kern uipc_socket.c X-Filter: mailagent [version 3.0 PL68] for [EMAIL PROTECTED] itojun 2001/02/07 21:35:19 JST Modified files: bsdi4/sys/kern uipc_socket.c Log: return ECONNABORTED, if the socket (tcp connection for example) is disconnected by RST right before accept(2). fixes PR 10698/12027. checked with SUSv2, XNET 5.2, and Stevens (unix network programming vol 1 2nd ed) section 5.11. Revision ChangesPath 1.4 +1 -1 kame/bsdi4/sys/kern/uipc_socket.c --- End of Forwarded Messages - End forwarded message - PGP signature
Re: send problem on udp socket...
< 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
Re: send problem on udp socket...
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 (or maybe it has been done already) ? cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: send problem on udp socket...
< 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 these sorts of parameters are there in order to limit fragmentation of the kernel virtual address space. There's no safe way to GC kernel virtual space. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
[itojun@iijlab.net: accept(2) behavior with tcp RST right afterhandshake]
-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 check for that condition, and [ECONNABORTED] is a Standard-sanctioned error return for this case. (I'd prefer an interface which allowed the caller to find out the address of the peer who allegedly aborted, but that's not possible.) - -GAWollman -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6galwI+eG6b7tlG4RAq6FAJ9l+TNMAh3zDaBv3bf/ClhAR9uyFQCfVMuc vFqdTRrdWeTdVpURBi4ufhA= =opkE -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: send problem on udp socket...
< 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 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 queue can never be coalesced (so there's DoS potential). I think adding a (sort of) tail pointer to the socket buffer might be helpful. I think you want it to point to the mbuf before the last *record* in the socket buffer, in order for sbcompress() to do its work, which means that you may still have to traverse a chain of mbufs (hopefully just not as many). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake]
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 with noting in a quote in http://www.humanfactor.com/cgi-bin/cgi-delegate/apache-ML/nh/1997/Jan/1176.html I hope to take a look at the implementation this evening. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Wed, 7 Feb 2001, Kris Kennaway wrote: > 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 right after handshake > X-Template-Reply-To: [EMAIL PROTECTED] > X-Template-Return-Receipt-To: [EMAIL PROTECTED] > X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 > From: [EMAIL PROTECTED] > Date: Wed, 07 Feb 2001 21:39:49 +0900 > X-UIDL: aff7d2fbee72775e2137abcde0bef0d0 > > 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 zero- > length sockaddr. > new behavior: return ECONNABORTED. > > effect: > - if someone runs nmap against your machine, and you are unlucky, > your server listening to tcp port (like BIND9) can get > segv/abort due to unexpected zero-length sockaddr + successful > error return on accept(2). > > itojun > > --- Forwarded Messages > > Return-Path: [EMAIL PROTECTED] > Return-Path: <[EMAIL PROTECTED]> > Received: from orange.kame.net (orange.kame.net [203.178.141.194]) > by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA00242 > for <[EMAIL PROTECTED]>; Wed, 7 Feb 2001 21:35:16 +0900 (JST) > Received: (from daemon@localhost) > by orange.kame.net (8.9.3+3.2W/3.7W/smtpfeed 1.06) id VAA48429; > Wed, 7 Feb 2001 21:35:16 +0900 (JST) > Received: (from itojun@localhost) > by orange.kame.net (8.9.3+3.2W/3.7W) id VAA48423; > Wed, 7 Feb 2001 21:35:15 +0900 (JST) > Date: Wed, 7 Feb 2001 21:35:15 +0900 (JST) > From: Jun-ichiro itojun Hagino <[EMAIL PROTECTED]> > Message-Id: <[EMAIL PROTECTED]> > To: cvs-kame:; > Subject: kame cvs commit: kame/freebsd4/sys/kern uipc_socket.c kame/netbsd/sys/kern > uipc_socket.c kame/openbsd/sys/kern uipc_socket.c > Reply-to: [EMAIL PROTECTED] > X-Filter: mailagent [version 3.0 PL68] for [EMAIL PROTECTED] > > itojun 2001/02/07 21:35:15 JST > > Modified files: > freebsd4/sys/kernuipc_socket.c > netbsd/sys/kern uipc_socket.c > openbsd/sys/kern uipc_socket.c > Log: > return ECONNABORTED, if the socket (tcp connection for example) > is disconnected by RST right before accept(2). fixes PR 10698/12027. > checked with SUSv2, XNET 5.2, and Stevens (unix network programming > vol 1 2nd ed) section 5.11. > > Revision ChangesPath > 1.2 +243 -10 kame/freebsd4/sys/kern/uipc_socket.c > 1.3 +1 -1 kame/netbsd/sys/kern/uipc_socket.c > 1.3 +1 -1 kame/openbsd/sys/kern/uipc_socket.c > > --- Message 2 > > Return-Path: [EMAIL PROTECTED] > Return-Path: <[EMAIL PROTECTED]> > Received: from orange.kame.net (orange.kame.net [203.178.141.194]) > by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA00253 > for <[EMAIL PROTECTED]>; Wed, 7 Feb 2001 21:35:20 +0900 (JST) > Received: (from itojun@localhost) > by orange.kame.net (8.9.3+3.2W/3.7W/smtpfeed 1.06) id VAA48466; > Wed, 7 Feb 2001 21:35:19 +0900 (JST) > Date: Wed, 7 Feb 2001 21:35:19 +0900 (JST) > From: Jun-ichiro itojun Hagino <[EMAIL PROTECTED]> > Message-Id: <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: kame-local cvs commit: kame/bsdi4/sys/kern uipc_socket.c > X-Filter: mailagent [version 3.0 PL68] for [EMAIL PROTECTED] > > itojun 2001/02/07 21:35:19 JST > > Modified files: > bsdi4/sys/kern uipc_socket.c > Log: > return ECONNABORTED, if the socket (tcp connection for example) > is disconnected by RST right before accept(2). fixes PR 10698/12027. > checked with SUSv2, XNET 5.2, and Stevens (unix network programming > vol 1 2nd ed) section 5.11. > > Revision ChangesPath > 1.4 +1 -1 kame/bsdi4/sys/kern/uipc_socket.c > > --- End of Forwarded Messages > > > > - End forwarded message - > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: send problem on udp socket...
> 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 queue can never be coalesced (so there's DoS potential).
>
> I think adding a (sort of) tail pointer to the socket buffer might be
> helpful. I think you want it to point to the mbuf before the last
> *record* in the socket buffer, in order for sbcompress() to do its
oh yes, this is what i am actually implementing now:
struct sockbuf {
...
struct mbuf *sb_mb_head; /* the old sb_mb */
struct mbuf *sb_mb_tail; /* last record in chain */
...
the renaming of sb_mb is just a temporary thing to easily locate
where the field is used. sb_mb_tail is only significant if sb_mb_head!=NULL
and it is such that
sb_mb_tail->m_nextpkt is always NULL.
The change seems not too invasive, the only place which is
unclear to me is uipc_usrreq.c:unp_scan().
Does the above sounds right ?
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right afterhandshake]
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 there are any objections. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: pptp server
> >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, as mpd 3.2 calls it, isn't supported by windows clients. I tcpdumped a session between my pptp server and a windows client : I got : << ... 22:14:37.382601 193.190.156.147 > mirador.cediti.be: gre-proto-0x880B (gre encap) 22:14:37.383061 mirador.cediti.be > 193.190.156.147: gre-proto-0x880B (gre encap) 22:14:37.383187 193.190.156.147 > mirador.cediti.be: gre-proto-0x880B (gre encap) 22:14:37.383325 193.190.156.147 > mirador.cediti.be: gre-proto-0x880B (gre encap) 22:14:37.383667 193.190.156.147 > mirador.cediti.be: gre-proto-0x880B (gre encap) 22:14:37.383773 193.190.156.147 > mirador.cediti.be: gre-proto-0x880B (gre encap) 22:14:37.384508 mirador.cediti.be > 193.190.156.147: gre-proto-0x880B (gre encap) 22:14:37.384949 mirador.cediti.be > 193.190.156.147: gre-proto-0x880B (gre encap) ... >> Is this the proof that the communication is encrypted ? (sorry for this newbie question but I am't a guru not yet -:) It is surprising because on the windows client side, I set in the security option : _ Optional encryption (If I want "require encryption", the error "encryption not supported by server" occurs) _ Allow these protocols: MS-CHAP So, if I am right, MS-CHAP includes MPPE encryption even if encryption is not explicitely set; don't it ? Thanks a lot for your help. Olivier. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: CFR: Sequential mbuf read/write extensions
> 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 > share it). [ ... ] Please include the ability to determine the length of the current contents (as a marcro?) so that buffers can be padded, as necessary, since some hardware and some protocols require this. Also consider protecting the structure with a mutex, at least in kernel space (this would make the macro harder to write, which is why I put it into a parenthetical, question-marjed statement). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake]
>>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, 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
Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake]
>>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 on. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake]
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
===
RCS file: /ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.68.2.11
diff -u -r1.68.2.11 uipc_socket.c
--- uipc_socket.c 2000/12/22 10:25:21 1.68.2.11
+++ uipc_socket.c 2001/02/07 20:30:29
@@ -365,11 +365,8 @@
so->so_state &= ~SS_NOFDREF;
if ((so->so_state & SS_ISDISCONNECTED) == 0)
error = (*so->so_proto->pr_usrreqs->pru_accept)(so, nam);
- else {
- if (nam)
- *nam = 0;
- error = 0;
- }
+ else
+ error = ECONNABORTED;
splx(s);
return (error);
}
Index: uipc_syscalls.c
===
RCS file: /ncvs/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.65.2.6
diff -u -r1.65.2.6 uipc_syscalls.c
--- uipc_syscalls.c 2000/12/02 00:47:50 1.65.2.6
+++ uipc_syscalls.c 2001/02/07 21:27:03
@@ -283,7 +283,19 @@
nfp->f_ops = &socketops;
nfp->f_type = DTYPE_SOCKET;
sa = 0;
- (void) soaccept(so, &sa);
+ error = soaccept(so, &sa);
+ if (error) {
+ /*
+* return a namelen of zero for older code which might
+* ignore the return value from accept.
+*/
+ if (uap->name != NULL) {
+ namelen = 0;
+ (void) copyout((caddr_t)&namelen,
+ (caddr_t)uap->anamelen, sizeof(*uap->anamelen));
+ }
+ goto noconnection;
+ }
if (sa == NULL) {
namelen = 0;
if (uap->name)
@@ -307,6 +319,7 @@
error = copyout((caddr_t)&namelen,
(caddr_t)uap->anamelen, sizeof (*uap->anamelen));
}
+noconnection:
if (sa)
FREE(sa, M_SONAME);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake]
>>>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 on.
this diff is taken against 4.2-RELEASE (in kame tree), sorry.
also i need to say that i ran no tests (i have no environment).
uipc_syscalls.c change: make very sure to nuke file descriptor on errors
uipc_socket.c change: return ECONNABORTED
itojun
Index: kern/uipc_socket.c
===
RCS file: /cvsroot/kame/kame/freebsd4/sys/kern/uipc_socket.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -r1.1.1.3 -r1.3
--- kern/uipc_socket.c 2001/01/19 02:25:59 1.1.1.3
+++ kern/uipc_socket.c 2001/02/08 01:37:42 1.3
@@ -362,7 +362,7 @@
else {
if (nam)
*nam = 0;
- error = 0;
+ error = ECONNABORTED;
}
splx(s);
return (error);
Index: kern/uipc_syscalls.c
===
RCS file: /cvsroot/kame/kame/freebsd4/sys/kern/uipc_syscalls.c,v
retrieving revision 1.1.1.3
retrieving revision 1.2
diff -u -r1.1.1.3 -r1.2
--- kern/uipc_syscalls.c2001/01/19 02:26:00 1.1.1.3
+++ kern/uipc_syscalls.c2001/02/08 01:37:42 1.2
@@ -270,28 +270,22 @@
fp->f_ops = &socketops;
fp->f_type = DTYPE_SOCKET;
sa = 0;
- (void) soaccept(so, &sa);
- if (sa == 0) {
- namelen = 0;
- if (uap->name)
- goto gotnoname;
- splx(s);
- return 0;
- }
- if (uap->name) {
+ error = soaccept(so, &sa);
+ if (!error && uap->name) {
/* check sa_len before it is destroyed */
- if (namelen > sa->sa_len)
- namelen = sa->sa_len;
+ if (sa) {
+ if (namelen > sa->sa_len)
+ namelen = sa->sa_len;
#ifdef COMPAT_OLDSOCK
- if (compat)
- ((struct osockaddr *)sa)->sa_family =
- sa->sa_family;
+ if (compat)
+ ((struct osockaddr *)sa)->sa_family =
+ sa->sa_family;
#endif
- error = copyout(sa, (caddr_t)uap->name, (u_int)namelen);
- if (!error)
-gotnoname:
- error = copyout((caddr_t)&namelen,
- (caddr_t)uap->anamelen, sizeof (*uap->anamelen));
+ error = copyout(sa, (caddr_t)uap->name, (u_int)namelen);
+ } else
+ namelen = 0;
+ error = copyout((caddr_t)&namelen,
+ (caddr_t)uap->anamelen, sizeof (*uap->anamelen));
}
if (sa)
FREE(sa, M_SONAME);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake]
>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_state &= ~SS_NOFDREF;
if ((so->so_state & SS_ISDISCONNECTED) == 0)
error = (*so->so_proto->pr_usrreqs->pru_accept)(so, nam);
- else {
- if (nam)
- *nam = 0;
- error = 0;
- }
+ else
+ error = ECONNABORTED;
splx(s);
return (error);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Fw: if_ed.c && BRIDGE
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 portion of if_ed.c rids us of the problem, but doesn't "fix it" properly. Rich has some debugging information including, I believe, a crash dump. Rich, if you can please post that here (i.e. the backtraces and fault information) as I seemed to have lost it (gr, sorry about that). I would rather not just disable the BRIDGE section of if_ed.c to "mask out" the problem. Regards, Bosko. Rich Wales wrote: > Bosko -- > > That "if_ed.c" patch you had me try (commenting out the packet-dropping > optimization) seems to be quite solid. If you wanted to go ahead and > commit it into -STABLE . . . . > > Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/ > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Fw: if_ed.c && BRIDGE
> 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 panic on that lately (i did manage to produce a panic before some of these commits so i am not claiming that the problem never existed). cheers luigi > 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 portion of if_ed.c rids us of the problem, but > doesn't "fix it" properly. > > Rich has some debugging information including, I believe, a crash > dump. Rich, if you can please post that here (i.e. the backtraces and > fault information) as I seemed to have lost it (gr, sorry about > that). > > I would rather not just disable the BRIDGE section of if_ed.c to > "mask out" the problem. > > Regards, > Bosko. > > Rich Wales wrote: > > > Bosko -- > > > > That "if_ed.c" patch you had me try (commenting out the > packet-dropping > > optimization) seems to be quite solid. If you wanted to go ahead > and > > commit it into -STABLE . . . . > > > > Rich Wales [EMAIL PROTECTED] > http://www.webcom.com/richw/ > > > > > > 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
[patch] fast sbappend*, please try...
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 operations
require to scan the full list. The overhead can be very
bad in some cases (e.g. small UDP packets), and becomes
worse and worse as the socket buffer size increases (which
is what one would commonly do when expecting a lot of
traffic!).
The attached patch implements a tail pointer to the list, so that
you can append in constant time. By default, the code works exactly
as before -- the tail of the list is reached with the usual linear
scan, and the pointer to the tail is only used for comparison
purposes to make sure that it yields the same value.
If you enable the fast behaviour with
sysctl -w kern.ipc.fastscan=1
then the new code takes over and linear scans are replaced by
dereferences of the tail pointer.
Apart from the obvious benefits of using O(1) instead of O(n)
algorithms, your mileage may vary.
When the socket buffer is almost always empty (fast receivers) then
you have no gain. When the socket buffer is almost always full you
also have no gain, because the decision to drop the packet only
requires a comparison. However, this code can really avoid trashing
in those cases where the queue size oscillates.
I'd like to commit this (or similar) code after proper testing,
so i'd like people to try it out -- I am reasonably confident
about it, and have done a fair amount of testing under heavy
udp load, but want to be sure that there are no side effects.
The attached patch applies to 4.2 (and hopefully to CURRENT
as well).
cheers
luigi
Index: sys/socketvar.h
===
RCS file: /home/iguana/u0/rizzo/ncvs/src/sys/sys/socketvar.h,v
retrieving revision 1.46.2.4
diff -u -r1.46.2.4 socketvar.h
--- sys/socketvar.h 2000/11/26 02:30:08 1.46.2.4
+++ sys/socketvar.h 2001/02/08 00:58:31
@@ -93,6 +93,7 @@
u_long sb_mbmax; /* max chars of mbufs to use */
longsb_lowat; /* low water mark */
struct mbuf *sb_mb;/* the mbuf chain */
+ struct mbuf *sb_mb_tail; /* last pkt in chain (if sb_mb != NULL) */
struct selinfo sb_sel; /* process selecting read/write */
short sb_flags; /* flags, see below */
short sb_timeo; /* timeout for read/write */
Index: kern/uipc_socket.c
===
RCS file: /home/iguana/u0/rizzo/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.68.2.10
diff -u -r1.68.2.10 uipc_socket.c
--- kern/uipc_socket.c 2000/11/17 19:47:27 1.68.2.10
+++ kern/uipc_socket.c 2001/02/08 01:40:04
@@ -772,6 +772,12 @@
goto restart;
}
dontblock:
+ /*
+* On entry here, m points to the first record on the socket buffer.
+* While we process the initial mbufs containing address and control
+* info we save a copy of m->m_nextpkt into nextrecord. We do need
+* to take care of sb_mb_tail until later.
+*/
if (uio->uio_procp)
uio->uio_procp->p_stats->p_ru.ru_msgrcv++;
nextrecord = m->m_nextpkt;
@@ -815,9 +821,17 @@
controlp = &(*controlp)->m_next;
}
}
+ /*
+* If m is non-null, we have some data to read. From now on, make
+* sure to keep sb_mb_tail consistent when working on the last
+* packet on the chain (nextrecord==NULL) and we change m->m_nextpkt.
+*/
if (m) {
- if ((flags & MSG_PEEK) == 0)
+ if ((flags & MSG_PEEK) == 0) {
m->m_nextpkt = nextrecord;
+ if (nextrecord == NULL)
+ so->so_rcv.sb_mb_tail = m ;
+ }
type = m->m_type;
if (type == MT_OOBDATA)
flags |= MSG_OOB;
@@ -873,8 +887,11 @@
MFREE(m, so->so_rcv.sb_mb);
m = so->so_rcv.sb_mb;
}
- if (m)
+ if (m) {
m->m_nextpkt = nextrecord;
+ if (nextrecord == NULL)
+ so->so_rcv.sb_mb_tail = m ;
+ }
}
} else {
if (flags & MSG_PEEK)
@@ -931,8 +948,11 @@
(void) sbdroprecord(&so->so_rcv);
}
if ((flags & MSG_PEEK) == 0) {
- if (m == 0)
Re: Fw: if_ed.c && BRIDGE
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, and have not seen any panic on that lately (I did
> manage to produce a panic before some of these commits so I
> am not claiming that the problem never existed).
I built a new kernel from the -STABLE code (cvsup'ed last night, Tue.
2/6 at 20:26), and stress-tested it by downloading a large file over
a high-speed (1.3Mbit/sec) DSL line using a Compex NE2000-compatible
PCI NIC (ed0) as part of a bridge cluster. It crashed; see below for
a trace of the crash dump.
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
gateway# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) symbol-file kernel-d.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.3
(kgdb) core-file /var/crash/vmcore.3
IdlePTD 4284416
initial pcb at 374340
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc0947000
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02aa2b9
stack pointer = 0x10:0xc0342a7c
frame pointer = 0x10:0xc0342a88
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = net
dumping to dev #ad/0x30001, offset 53248
dump ata0: resetting devices .. done
24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at /big/4.2/usr/STABLE/src/sys/kern/kern_shutdown.c:469
469 if (dumping++) {
(kgdb) where
#0 dumpsys () at /big/4.2/usr/STABLE/src/sys/kern/kern_shutdown.c:469
#1 0xc013a495 in db_fncall (dummy1=0, dummy2=0, dummy3=0,
dummy4=0xc03428e8 "4)4À")
at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:532
#2 0xc013a2c1 in db_command (last_cmdp=0xc0345d1c, cmd_table=0xc0345b7c,
aux_cmd_tablep=0xc036f034)
at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:333
#3 0xc013a386 in db_command_loop ()
at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:455
#4 0xc013c493 in db_trap (type=12, code=0)
at /big/4.2/usr/STABLE/src/sys/ddb/db_trap.c:71
#5 0xc02be0ba in kdb_trap (type=12, code=0, regs=0xc0342a3c)
at /big/4.2/usr/STABLE/src/sys/i386/i386/db_interface.c:158
#6 0xc02cd2c0 in trap_fatal (frame=0xc0342a3c, eva=3230953472)
at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:946
#7 0xc02ccf99 in trap_pfault (frame=0xc0342a3c, usermode=0, eva=3230953472)
at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:844
#8 0xc02ccb0f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1064013824, tf_esi = 54272, tf_ebp = -1070323064,
tf_isp = -1070323096, tf_ebx = 16, tf_edx = 54288, tf_ecx = 27932,
tf_eax = -1061304128, tf_trapno = 12, tf_err = 2, tf_eip = -1070947655,
tf_cs = 8, tf_eflags = 66118, tf_esp = 6126, tf_ss = -1064017366})
at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:443
#9 0xc02aa2b9 in ed_pio_readmem (sc=0xc0bdda00, src=19456,
dst=0xc094622a
"ÔF·GõCÄ3\211ç\005®Ô\2004gÅ¡c\204H\2135Éÿ\023¬xog@\025\226ã¥z\a+Óþôt\217p¦upô",
amount=59406) at machine/cpufunc.h:213
#10 0xc02aa12b in ed_get_packet (sc=0xc0bdda00, buf=0x6804cannot read proc at 0
)
at /big/4.2/usr/STABLE/src/sys/dev/ed/if_ed.c:2587
#11 0xc02a9a2b in edintr (arg=0xc0bdda00)
at /big/4.2/usr/STABLE/src/sys/dev/ed/if_ed.c:2179
#12 0xc02d52a5 in intr_mux (arg=0xc08b64e0)
at /big/4.2/usr/STABLE/src/sys/i386/isa/intr_machdep.c:582
(kgdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake]
> 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 zero- > length sockaddr. > new behavior: return ECONNABORTED. > > effect: > - if someone runs nmap against your machine, and you are unlucky, > your server listening to tcp port (like BIND9) can get > segv/abort due to unexpected zero-length sockaddr + successful > error return on accept(2). FYI: 9.1.0 had assert() against sockaddr returned by accept(2). therefore BIND 9.1.0 will get killed (or go suicide) by remote nmap with "previous (kernel) behavior" presented above. (it will only happen you are very unlucky - it is timing issue) BIND 9.1.1rc1 now includes workaround (no assert). itojun > 727. [port] Work around OS bug where accept() succeeds but >fails to fill in the peer address of the accepted >connection, by treating it as an error rather than >an assertion failure. [RT #809] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right afterhandshake]
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 before I get it, why bother giving it to me?? -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: pptp server
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 proprietary files. MS-CHAP is required *for* MPPE encryption, in order to generate the keys. > 22:14:37.384949 mirador.cediti.be > 193.190.156.147: gre-proto-0x880B (gre > encap) > > Is this the proof that the communication is encrypted ? (sorry for this > newbie question but I am't a guru not yet -:) No, the encryption is only of the inner payload. > It is surprising because on the windows client side, I set in the security > option: > _ Optional encryption (If I want "require encryption", the error > "encryption not supported by server" occurs) > _ Allow these protocols: MS-CHAP > > So, if I am right, MS-CHAP includes MPPE encryption even if encryption is > not explicitely set; don't it ? No. -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: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake]
>> 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 bother giving it to me?? can we cancel sorwakeup() (happens on handshake completion)? I believed not. itojun 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
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 instances of "LOG_SECURITY |". Luigi/Poul, have you at least decided where the changes should be made? There's no log(9) man page to decide which one is the correct syntax. IMHO, -stable is not stable while this bug persists. Yusuf Goolamabbas wrote: > > Hi, I cvsupped today and got all of Luigi's commit [the one where he > does 1.16.2.13 of bridge.c alongwith a few others], I also have David > Malone's fix to syslogd.c [1.59.2.5] > > If I don't have the following sysctl > > net.inet.ip.fw.verbose_limit=10 > > then dmesg gets busted as mentioned earlier and if I do a sync;reboot > then I get a huge amount of ipfw messages scrolling on the console [It's > as if they were backlogged in some buffer somewhere] and after a few > seconds the syncing disk messages comes along > > I have the following in my kernel config > > options IPFIREWALL > options IPFIREWALL_DEFAULT_TO_ACCEPT > options BRIDGE > options DUMMYNET > > my /etc/sysctl.conf is as follows > > net.link.ether.bridge_ipfw=1 > net.link.ether.bridge=1 > net.inet.ip.fw.verbose=1 > net.inet.ip.fw.verbose_limit=10 > > > 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] > > -- > Yusuf Goolamabbas > [EMAIL PROTECTED] -- 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: Fw: if_ed.c && BRIDGE
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 known for
occasionally swapping the bytes of the length, but the driver was
supposed to take care of this. Evidently there is some odd
thing...
cheers
luigi
>
> > 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 panic on that lately (I did
> > manage to produce a panic before some of these commits so I
> > am not claiming that the problem never existed).
>
> I built a new kernel from the -STABLE code (cvsup'ed last night, Tue.
> 2/6 at 20:26), and stress-tested it by downloading a large file over
> a high-speed (1.3Mbit/sec) DSL line using a Compex NE2000-compatible
> PCI NIC (ed0) as part of a bridge cluster. It crashed; see below for
> a trace of the crash dump.
>
> Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
>
>
>
> gateway# gdb -k
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-unknown-freebsd".
> (kgdb) symbol-file kernel-d.debug
> Reading symbols from kernel.debug...done.
> (kgdb) exec-file /var/crash/kernel.3
> (kgdb) core-file /var/crash/vmcore.3
> IdlePTD 4284416
> initial pcb at 374340
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xc0947000
> fault code= supervisor write, page not present
> instruction pointer = 0x8:0xc02aa2b9
> stack pointer = 0x10:0xc0342a7c
> frame pointer = 0x10:0xc0342a88
> code segment = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = Idle
> interrupt mask= net
>
> dumping to dev #ad/0x30001, offset 53248
> dump ata0: resetting devices .. done
> 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
> ---
> #0 dumpsys () at /big/4.2/usr/STABLE/src/sys/kern/kern_shutdown.c:469
> 469 if (dumping++) {
> (kgdb) where
> #0 dumpsys () at /big/4.2/usr/STABLE/src/sys/kern/kern_shutdown.c:469
> #1 0xc013a495 in db_fncall (dummy1=0, dummy2=0, dummy3=0,
> dummy4=0xc03428e8 "4)4À")
> at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:532
> #2 0xc013a2c1 in db_command (last_cmdp=0xc0345d1c, cmd_table=0xc0345b7c,
> aux_cmd_tablep=0xc036f034)
> at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:333
> #3 0xc013a386 in db_command_loop ()
> at /big/4.2/usr/STABLE/src/sys/ddb/db_command.c:455
> #4 0xc013c493 in db_trap (type=12, code=0)
> at /big/4.2/usr/STABLE/src/sys/ddb/db_trap.c:71
> #5 0xc02be0ba in kdb_trap (type=12, code=0, regs=0xc0342a3c)
> at /big/4.2/usr/STABLE/src/sys/i386/i386/db_interface.c:158
> #6 0xc02cd2c0 in trap_fatal (frame=0xc0342a3c, eva=3230953472)
> at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:946
> #7 0xc02ccf99 in trap_pfault (frame=0xc0342a3c, usermode=0, eva=3230953472)
> at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:844
> #8 0xc02ccb0f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
> tf_edi = -1064013824, tf_esi = 54272, tf_ebp = -1070323064,
> tf_isp = -1070323096, tf_ebx = 16, tf_edx = 54288, tf_ecx = 27932,
> tf_eax = -1061304128, tf_trapno = 12, tf_err = 2, tf_eip = -1070947655,
> tf_cs = 8, tf_eflags = 66118, tf_esp = 6126, tf_ss = -1064017366})
> at /big/4.2/usr/STABLE/src/sys/i386/i386/trap.c:443
> #9 0xc02aa2b9 in ed_pio_readmem (sc=0xc0bdda00, src=19456,
> dst=0xc094622a
>"ÔF·GõCÄ3\211ç\005®Ô\2004gÅ¡c\204H\2135Éÿ\023¬xog@\025\226ã¥z\a+Óþôt\217p¦upô",
>amount=59406) at machine/cpufunc.h:213
> #10 0xc02aa12b in ed_get_packet (sc=0xc0bdda00, buf=0x6804cannot read proc at 0
> )
> at /big/4.2/usr/STABLE/src/sys/dev/ed/if_ed.c:2587
> #11 0xc02a9a2b in edintr (arg=0xc0bdda00)
> at /big/4.2/usr/STABLE/src/sys/dev/ed/if_ed.c:2179
> #12 0xc02d52a5 in intr_mux (arg=0xc08b64e0)
> at /big/4.2/usr/STABLE/src/sys/i386/isa/intr_machdep.c:582
> (kgdb)
>
>
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsu
