Re: [networking-discuss] socket lib in solaris?
On 4/8/06, Xie Gang [EMAIL PROTECTED] wrote: I wrote a socket program and compiled it on solaris. I found it quite different from linux. The gcc did not search for the socket lib automatically. The -lsocket must be given. I don't know why this happens. On Linux the socket calls are in (g)libc so it's not that the linux linker magically searches for libsocket.so - such a library simply does not exist on Linux. However, I do sympathise - the fact that one needs to add -lsocket to the linker flags trips up many an open source app. when building it on Solaris and it gets annoying after a while. Paul -- Paul Durrant http://www.linkedin.com/in/pdurrant ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] socket lib in solaris?
James Carlson wrote: Paul Durrant writes: On 4/8/06, Xie Gang [EMAIL PROTECTED] wrote: I wrote a socket program and compiled it on solaris. I found it quite different from linux. The gcc did not search for the socket lib automatically. The -lsocket must be given. I don't know why this happens. On Linux the socket calls are in (g)libc so it's not that the linux linker magically searches for libsocket.so - such a library simply does not exist on Linux. However, I do sympathise - the fact that one needs to add -lsocket to the linker flags trips up many an open source app. when building it on Solaris and it gets annoying after a while. True, but the deeper issue is that we have at least two[1] competing and incompatible sockets interfaces -- one is the 3SOCKET old-BSD style family and the other is the 3XNET standards-compliant family. In most cases, folks really want 3XNET (one example issue: this is the only way to get ancillary data) and yet they stumble into libsocket first. The few things 3XNET doesn't offer (*_r, r*, and ether_* functions) are seldom needed. I never even knew about 3XNET...why would I want it? What does the standards compliance give me besides the tags words standards compliance? Why is 3XNET what other folks want when we don't? (Using ldd on /usr/bin is very disappointing.) And how does anyone learn about 3XNET if man socket, etc, will show 3SOCKET first and using it gives them either 100% of what they want or very close to it? I suspect the easiest way to get more people using 3XNET would be to submit a patch to the maintainers of autoconf to search for and use -lxnet on SunOS 5 before -lsocket/-lnsl. So long as they don't want to use any of the functions that aren't in it. As for *_r being seldom needed, we need to be more forward thinking than that, especially considering niagara and threads. Darren ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] socket lib in solaris?
Darren Reed writes: I never even knew about 3XNET...why would I want it? Ancillary data doesn't work in 3SOCKET. It does in 3XNET. That's the big reason. What does the standards compliance give me besides the tags words standards compliance? I don't care a whit about buzzword compliance of any sort. However, the existence of the standards is intended to provide for *better* portability of applications. And how does anyone learn about 3XNET if man socket, etc, will show 3SOCKET first and using it gives them either 100% of what they want or very close to it? Agreed; it's a real mess. As for *_r being seldom needed, we need to be more forward thinking than that, especially considering niagara and threads. You have to have a multithreaded application that is walking the name service databases in multiple threads at the same time (setprotoent/ getprotoent/endprotoent in each) for it to matter much, which is why I claim it's seldom needed. The rest of the functionality is likely better handled by getaddrinfo/getnameinfo, which are already thread-safe. I think it'd be better just to make the ordinary lookup functions thread-safe. Special *_r entry points are pretty ugly to me and make coding for multithreaded applications much harder than necessary. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] socket lib in solaris?
Darren Reed writes: James Carlson wrote: Darren Reed writes: I never even knew about 3XNET...why would I want it? Ancillary data doesn't work in 3SOCKET. It does in 3XNET. That's the big reason. Ok, so there are no compelling reasons to use 3XNET unless someone needs to interact with ancillary data (whatever that is - there are no man page references to this on sendmsg/recvmsg.) It's all the things you can receive and send as special socket options. See all of the IP_RECV* flags, for a start. So my conclusion is that ancillary data is rare and the need for 3XNET rarer still - but all the same, we provide for it - and thus there is no reason not to tell people to use libsocket unless they come back and say where is my ancillary data? If you feel compelled to use libsocket for some reason (e.g., dragging in libnsl as well because libsocket is incomplete is a good thing, the crufty old struct msghdr definition you get that has msg_accrights is comforting), then I won't bother to argue the point. Both are supported. The point is that having two is confusing, and of the two, 3XNET is better for modern applications (i.e., those attempting to use socket options), so I'd recommend it first. The other one seems to have little going for it but the well-known name and prestige location in the man page search path. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] socket lib in solaris?
On Mon, Apr 10, 2006 at 07:29:46AM -0700, Darren Reed wrote: man -s 3xnet recvmsg Ok, I've just installed a Solaris 10 Update 2 beta and that man page text is not present on my box. Is your text from nevada? (btw, I checked the man page before making the above comment and checked again upon reading your comments and it isn't there.) Ooof. I am using Nevada (build 36), and apparently the man page must've been fixed in that timeframe. I saw your results on an S10 box... $ man -s 3xnet recvmsg 2/dev/null | col -b | grep -i ancill | wc 0 0 0 But on mine... $ man -s 3xnet recvmsg 2/dev/null | col -b | grep -i ancill | wc 3 29 197 $ uname -a SunOS everywhere 5.11 snv_36 i86pc i386 i86pc $ So you may wish to check the bugs under manpage/section3xnet for the appropriate bug that is fixed in Nevada, but not in S10 Update N. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] socket lib in solaris?
Darren Reed writes: Ok, I've just installed a Solaris 10 Update 2 beta and that man page text is not present on my box. Is your text from nevada? (btw, I checked the man page before making the above comment and checked again upon reading your comments and it isn't there.) The feature has been there for a long time, but the man pages were only recently updated. See CR 6353020. -- James Carlson, KISS Network[EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] socket lib in solaris?
James Carlson wrote: The point is that having two is confusing, and of the two, 3XNET is better for modern applications (i.e., those attempting to use socket options), so I'd recommend it first. The other one seems to have little going for it but the well-known name and prestige location in the man page search path. So why are there two different libraries? Isn't the xnet functionality a proper superset of libsocket? - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] socket lib in solaris?
On Mon, Apr 10, 2006 at 10:09:31AM -0700, Bart Smaalders wrote: James Carlson wrote: The point is that having two is confusing, and of the two, 3XNET is better for modern applications (i.e., those attempting to use socket options), so I'd recommend it first. The other one seems to have little going for it but the well-known name and prestige location in the man page search path. So why are there two different libraries? Isn't the xnet functionality a proper superset of libsocket? libxnet is a filter on libsocket and libnsl... The 3SOCKET and 3XNET manpages reference the same header files, and no -D... pre-processor options, and the libxnet socket functions are just filters on the libsocket socket functions. So, what specifically about libxnet allows ancilliary data to work and what about libsocket prevents it? Nico -- ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] socket lib in solaris?
On Mon, Apr 10, 2006 at 02:46:53PM -0400, James Carlson wrote: Nicolas Williams writes: The 3SOCKET and 3XNET manpages reference the same header files, and no -D... pre-processor options, and the libxnet socket functions are just filters on the libsocket socket functions. That's not true. Look at this in socket.h: Ah, there's a reference to the standards(5) man page in the 3XNET man pages, and that in turn describes what pre-processor symbols should be defined in order to get ancilliary data in socket.h: #if defined(_XPG4_2) || defined(_KERNEL) void*msg_control; /* ancillary data */ socklen_t msg_controllen; /* ancillary data buffer len */ int msg_flags; /* flags on received message */ #else caddr_t msg_accrights; /* access rights sent/received */ int msg_accrightslen; #endif/* defined(_XPG4_2) || defined(_KERNEL) */ I find the standards(5) reference a tad oblique, considering that there's no text anywhere in the man page about the need to get the right compilation environment... There's not even the name of the standards, if any, beyond X/Open that 3XNET conforms to. Worse, the 3XNET man pages only mention X/Open in the page header, and don't mention any version numbers, so looking at the 3XNET and standards(5) man pages how is the reader supposed to know that ancilliary data only works with libxnet in the XPG4v2 environment? (Or am I misreading socket.h and ancilliary data works with XPG3 also?) Nico -- ___ networking-discuss mailing list networking-discuss@opensolaris.org
re: [networking-discuss] IPMP visibility with ifconfig
On Wed, 5 Apr 2006, Peter Memishian wrote: Right, I don't think it does -- and ifconfig is already hopeless. I think it would be better to come up with a new program (ipadm?) which provided a sane way to view and administer IP interfaces. As a data-point. Another system abandoned ifconfig too and provided a new tool for configuring IP. That new tool is indeed more consistent in interface and better. However, the backwards compatibility issues don't go away. Some proportion of end-users will continue to use (the bitrotting) ifconfig rather than the new tool - which sometimes leads to subtle problems due to one tool configuring things slightly differently to the other - particularly with respect to features whose configuration is more refined with the newer tool. I.e.: A new tool only avoids backward-compatibility problems in the syntax, but not always in how the system ends up being configured (unless you remove the old tool completely, or /don't/ abandon it). Hence there /may/ be some value in considering rehabilitating the syntax of the existing tool instead.. regards, -- Paul Jakma, Network Approachability, KISS. http://quagga.ireland.sun.com/ Sun Microsystems, Dublin, Ireland. tel: EMEA x19190 / +353 1 819 9190 ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Re: Clearview: Nemo MAC-Type Plugin Architecture
On Thu, 6 Apr 2006, Darren Reed wrote: perpetuating that design badness, unless we are going to use it as a model for others to deliver logical interfaces into Solaris? Hmm, please no. If logical interfaces are ever reformed, please reform them as additional addresses. :) If Solaris, today, didn't have any IPMP functionality and someone came to you and said they wanted to build something into Solaris that delivers what IPMP does today, how would you recommend they go about it? ECMP in the routing path - IPMP but more general. I think 'Surya' have ECMP on their 'possible TODO items' list. regards, -- Paul Jakma, Network Approachability, KISS. http://quagga.ireland.sun.com/ Sun Microsystems, Dublin, Ireland. tel: EMEA x19190 / +353 1 819 9190 ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] Re: Code review request for Surya (due by 3/27/06)
Thiru, Many thanks for your insighful comments, and the alternative radix treelocking scheme that you provided. It is much appreciated. Attached is a txt file that contains all your comments and our responses. Please go over them. Also we need clarification on these: thiru-10a, thiru-30, thiru-31, thiru-33 Sangeeta Comments thiru-1a- 4 are related to radix tree lookup/add/walk/delete locking The add, delete, lookup, and walk need a mutually consistent locking mechanism. A suggested scheme is given in the attachment. RESP: thiru-1a- 4 will be addressred correctly via implementation of the suggested locking schme. thiru-1a ire_add_v4 - ire_get_bucket - returns rt-rt_irb after dropping the global radix node lock. Now the radix node is not protected henceforth and can disappear any time before the ire is actually linked in to the radix node. To see how it can happen consider the following sequence. T1. route add dst = 192.168/16, ipif = bge0 Thread T1 starts off, creates and links the radix node for 192.168/16 into the tree and returns the irb. Let us suspend this thread at L3266 ip_ire.c. T2. route add dst = 192.168/16, ipif = bge1 Now T2 starts off, tries to add a duplicate (route,netmask) pair, fails and uses the radix node that T1 added, and links in the ire into the irb. and finishes to completion. T3. route delete dst = 192.168/16, ipif = bge1 T4. netstat walker on the above bucket. T4 walks the above bucket. Now T3 - ire_delete locates the ire and removes the radix node from the tree and marks the irb as DEAD and finishes the deletion actions. The walker finishes eventually and IRB_REFRELE ends up deleting the radix node. Now T1 resumes and finds a freed radix node. RESP: ACCEPT Will try alternative locking scheme that you suggested thiru-1b. (We had to consider T4 a walker thread due to another bug. The radix node free only happens in IRB_REFRELE. If there is no walker during the deletion of an ire, the radix node is leaked.) RESP: ACCEPT Will try alternative locking scheme that you suggested thiru-2. In rn_walktree(), the global radix lock is held while doing the traversal. But that is not sufficient. After dropping the lock at L1129 radix.c the access to the node in the block in L1121 - L1134 is unprotected and could be accessing freed memory. Similarly we get a pointer to the next radix node at L1124 and then use it much later at L1139 while we have dropped the lock in the interrugnum. The walker callbacks rtfunc and ire_ihandle_onlink_match do IRB_REFHOLD to walk the list, but there is nothing to prevent the list from vanishing even before IRB_REFHOLD is called or even before the callbacks are called. In both 1. and 2. we need to increment a refcount on the radix node before dropping the global radix tree lock. (could use the irb_cnt as the refcount under the irb_lock). RESP: ACCEPT Will try alternative locking scheme that you suggested thiru-3a In ire_delete(), we check for irb_ire_cnt of 1 and if so we remove the radix node from the tree. irb_ire_cnt is protected by the irb_lock and it can increase now, if another thread is in ire_add_v4. Note that the the thread in ire_add_v4 is not holding the global radix lock, but just the irb_lock while it is adding the ire to the irb list. RESP: ACCEPT Will try alternative locking scheme that you suggested thiru-3b Another issue is that the radix node deletion may never happen. Consider that we have 2 ires in the bucket ire1, ire2 and consider 2 threads T1 trying to delete ire1, and T2 trying to delete ire2 simultaneously. T1 - ire_delete(ire1), grabs radix tree lock, finds irb_ire_cnt is 2 and does not remove the radix node from the tree. Drops the radix tree lock and calls ire_delete_common(ire1). Let us suspend this thread now. T2 - ire_delete(ire2), grabs radix tree lock, finds irb_ire_cnt is 2 and does not remove the radix node from the tree. Drops the radix tree lock and calls ire_delete_common(ire2). Proceeds to completion. Now let T1 also complete. Both ires are deleted, but radix node remains. RESP: ACCEPT Will try alternative locking scheme that you suggested thiru-3c The other issue is that if the radix node that is being removed from the tree is the 'next' in the tree walker, then even if the node itself is not freed (due to non-zero irb_cnt due to other walkers) the walk will be truncated, and that is bad. A truncated walk may cause unplumb to hang. RESP: ACCEPT Will try alternative locking scheme that you suggested thiru-3d L3857 ip_ire.c should never happen. RESP: ACCEPT thiru-4 The last thread that brings the irb_refcnt to 0 frees the radix node
Re: [networking-discuss] ESP Authentication failed occasionally
On Mon, Apr 10, 2006 at 03:04:58PM -0700, Andrew Wenlang Zhu wrote: (Re-post from security discuession) I must not be getting [EMAIL PROTECTED] mail. Odd... We have systems using manual key IPSEC on Solaris 8. IPsec works fine, and the traffic can go through with IPsec. Mar 14 20:45:04 ipsecah: [ID 800123 kern.error] ESP Authentication failed for spi 0x64f6644e, dst xx. Mar 14 20:50:09 last message repeated 3 times I checked the configuration on two peer systems, the configurations matches, and the traffic between them flows well. What could cause this error message, and how to get rid of them? There are several causes: 1.) Packet corruption. It happens, and sometimes it passes the Ethernet CRC or is introduced by a buggy router. ESP's authentication will catch such corruption and drop the bug. 2.) Attacker of some kind -- often someone will send you ESP traffic with the same SPI in the hopes of something happening. Authentication failing is one of the most common causes of this. 3.) Corner-case bug on your receiving system. It's possible that the corruption is after your machine gets the bits on the wire. Buggy drivers, buggy IP code, it could be anything. You should upgrade to Solaris 10 or later, where the ipdrop kstats and other supporting functions can help you determine more about such buggy packets. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
