Tftpd and TCP wrappers

I'm unable to wrap the tftpd service on our system. The server is not denying tftp (get) requests from arbitrary Internet hosts, in spite of:
/etc/hosts.deny:
in.tftpd: ALL
TCP wrappers is enabled for tftpd:
# inetadm -l svc:/network/tftp/udp6:default
SCOPE NAME=VALUE
name="tftp"
endpoint_type="dgram"
proto="udp6"
isrpc=FALSE
wait=TRUE
exec="/usr/sbin/in.tftpd -s /tftpboot"
user="root"
default bind_addr=""
default bind_fail_max=-1
default bind_fail_interval=-1
default max_con_rate=-1
default max_copies=-1
default con_rate_offline=-1
default failrate_cnt=40
default failrate_interval=60
default inherit_env=TRUE
default tcp_trace=TRUE
tcp_wrappers=TRUE
TCP wrappers is working properly for other services like sshd. The system is also up-to-date on all Solaris 10 patches.
Any suggestions?

Note sshd has libwrap, and tftpd doesn't:
% ldd /usr/sbin/in.tftpd
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libmd5.so.1 => /usr/lib/libmd5.so.1
libscf.so.1 => /usr/lib/libscf.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
libm.so.2 => /usr/lib/libm.so.2
/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1
% ldd /usr/lib/ssh/sshd
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libz.so.1 => /usr/lib/libz.so.1
libpam.so.1 => /usr/lib/libpam.so.1
libbsm.so.1 => /usr/lib/libbsm.so.1
libwrap.so.1 => /usr/sfw/lib/libwrap.so.1
libcrypto.so.0.9.7 => /usr/sfw/lib/libcrypto.so.0.9.7
libgss.so.1 => /usr/lib/libgss.so.1
libcmd.so.1 => /usr/lib/libcmd.so.1
libcontract.so.1 => /usr/lib/libcontract.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libmd5.so.1 => /usr/lib/libmd5.so.1
libscf.so.1 => /usr/lib/libscf.so.1
libsecdb.so.1 => /usr/lib/libsecdb.so.1
libnvpair.so.1 => /usr/lib/libnvpair.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
libm.so.2 => /usr/lib/libm.so.2
/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1
My suggestion is to use the tcpd program. I don't think it comes with the default install (I can't find it) but it is in the Sun Freeware packages (/usr/sfw/sbin/tcpd) and it's easly to compile on your own. Then old school it into inetd:
tftp dgram udp6 wait root /usr/sfw/sbin/tcpd in.tftpd -s /tftpboot
Then inetconv it.

Similar Messages

  • X11vnc-0.9.6 (version update and tcp wrappers support)

    # $Id$
    # Maintainer: unmaintained
    pkgname=x11vnc
    pkgver=0.9.6
    pkgrel=1
    pkgdesc="a VNC server for real X displays"
    arch=("i686" "x86_64")
    license=("GPL2")
    #source=(http://dl.sourceforge.net/sourceforge/libvncserver/$pkgname-$pkgver.tar.gz)
    url="http://www.karlrunge.com/x11vnc/"
    source=("$url/$pkgname-$pkgver.tar.gz")
    depends=('openssl' 'libjpeg' 'zlib' 'libx11' 'libxtst' 'libxinerama' 'libxdamage' 'libxrandr' 'avahi')
    build() {
    cd $startdir/src/$pkgname-$pkgver
    env CPPFLAGS=-DUSE_LIBWRAP LDFLAGS=-lwrap ./configure
    make || return 1
    make prefix=$startdir/pkg/usr install || return 1
    md5sums=('2d5a80271a11230ab8b26d10f0c5b563')
    the daemon name for /etc/hosts.deny /etc/hosts.allow is vnc
    Last edited by metalfan (2008-12-13 18:40:14)

    Tea2 wrote:
    graysky wrote:@Tea2 - I think it's due to the staleness of the package as well as the need for the devs to provide extra work just to keep the rest of the packages functional working around it.  I think ufw is a pretty good alternative.
    Forgive my ignorance but what sort of work are you talking about? Surely, the work needed to keep a package working with another is upstream work, with the package maintainers ensuring that the dependencies are in order?
    On the issue of alternatives, personally I hate iptables. It's more complex than it needs to be; the process of adding a single rule is a little bit tricky. Then there's no assurance it actually worked, since the syntax of a single command is a little bit confusing. I have no real issue with iptables other than it's ugly. Since Arch is based on the KISS philosophy, should we not keep the hosts files based on their simplicity? I have not used ufw, but I've checked it out in the wiki and it actually looks pretty good and I think I'll get it installed on my VPS asap so I can start experimenting with it.
    I can understand removing tcp_wrappers from the default installation stack, but completely removing the option is going too far. I'm sure it can be quite comfortable in [extra] or something.
    I imagine that there are many users that feel the same way that you do, so I recommend putting it into the AUR.

  • Veritas and Solaris 9 bulitin tcp wrappers

    Does anyone know if the tcp wrappers that is bulitin to the
    Solaris 9 OS will work on non-Sun products?
    We use veritas to backup our servers, each host has a number
    of entries in the /etc/inet/inetd.conf file to execute portions of
    the veritas backup suite.
    Once we enabled tcp-wrappers on Solaris 9 systems
    veritas would not run, disabling tcp-wrappers veritas
    executes as it did before.
    NOTE: we were using Wietsmans' tcp-wrappers self compiled and
    executed from a non-standard location but the veritas
    services lists in the /etc/inet/inetd.conf file were not wrapped
    Comments/suggestions appreciated
    John

    If ENABLE_TCPWRAPPERS is on in /etc/default/inetd then all tcp connections get wrapped automatically. Even without a specific "tcpd" entry in /etc/inetd.conf...
    So you will need to add specific entries for netbackup in /etc/hosts.allow and /etc/hosts.deny to allow the netbackup connections.

  • Tcp wrappers and ipv6?

    Hi,
    (Sorry for the [probably] duplicate thread; does anyone know how to search 'as a phrase' with PHPBB so I can find it if this has been mentioned before?)
    TCP-wrappers (pacman package tcp_wrappers 7.6-6) does not seem to have IPv6 support. It kept saying "refused connect from 0.0.0.0" and after googling that (which does support phrase searching everything pointed to it being an IPv6/v4 issue. So, I disabled IPv6 in sshd (the service that was giving me trouble), and sure enough I started getting proper hostnames instead of 0.0.0.0 .
    Pacman says my tcp_wrappers is up-to-date; is there another package source somewhere from which I can easily get the IPv6 version?
    ~Felix.

    Well, it's not on any of the Arch repos, if that's what you mean. You'd need to get the source tarball and build it yourself. Alternatively, you could post a request for it in the AUR Package Requests forum - someone might do a PKGBUILD for it.

  • How to define tcp wrappers for a new service in Solaris 10?

    Hi all, I need to setup tcp wrappers for a third-party software product with /etc/hosts.allow.
    I installed Trillium software on a new Solaris 10 server. It added this entry to /etc/inetd.conf:
    dscserv0_rel1300 stream tcp nowait tsadmin /usr/bin/env env -i HOME=/home/tsadmin LOGNAME=tsadmin /opt/trilv13/TrilliumSoftware/server/metabase/bin/mtb_server
    After the install, I ran inetconv and this new SMF service was created:
    *# svcs -a|grep dsc*
    online         13:22:57 svc:/network/dscserv0_rel1300/tcp:default
    Here's the problem: After this, all new connections were denied by default. I had to disable tcp wrappers with this command:
    inetadm -m svc:/network/dscserv0_rel1300/tcp:default tcp_wrappers=FALSE
    I would prefer to enable tcp wrappers, and put an entry into /etc/hosts.allow, but I can't figure out what service name to put into /etc/hosts.allow. I've read through the man pages but I can't identify the service name to use for this new service, and it won't accept the FMRI or an abbreviation of it either.
    How do I identify the service name to put into /etc/hosts.allow?

    At OS level, before entering Sql*Plus, do :
    $ EDITOR=vi; export EDITOR
    $ sqlplus ......
    Message was edited by:
    Paul M.
    Ciao Nicolas :-)

  • How to enable TCP Wrappers with SMF services?

    I am using a site.xml file to enable/disable services during a Jumpstart configuration. This works great.
    However, I can't yet figure out how to configure the various properties of those services, such as enabling TCP Wrappers for a service. I can set the properties of a service and verify that they are set, but a "svccfg extract" does not capture that information.
    Is this a short coming of svccfg extract? Or are the properties of a service stored and configured elsewhere?

    That will work, as will any path underneath
    /var/svc/manifest.Got it working...Exported the inetd configuration, set tcp_wrappers to false, dropped inetd.xml into my jumpstart tree, jumped a box, and tcp_wrappers came up enabled by default for my inetd services!
    What is the difference between the /var/svcs/profile and /var/svcs manifest directory? Is profile for enabling/disabling services and manifest for service configuration?
    Does /var/svcs/profile/site.xml and /var/svcs/manifest/whatever.xml get read on every system boot? If not, what is the appropriate procedure to "reinitialize" smf if you want to change the existing behaviour by having it reread those files?
    Hmm. The defaults get written on the inetd serviceI believe, so exporting that would give you the
    fragment
    you want.It did, and I was able to accomplish what I needed to do.
    Sorry that it's such a slog in the meanwhile.Will there be something before FCS in a couple weeks?
    I can definetly see the managability and robustness of SMF. It's just going to take time to learn it, and documentation is needed for that.
    Thanks for all your help!

  • Securing RPC services with TCP Wrappers

    Hello All,
    I have two node cluster running solaris 10. Since SVM needs few rpc services like metad,metamedd and metamhd, I dont want to disable them. But at the same time, wants to block them from outside world.
    But readme page of TCP Wrappers (http://www.sunfreeware.com/README.tcpwrappers) says "The wrappers do not work with RPC services over TCP. These services are registered as rpc/tcp in the inetd configuration file". And other internet sources says same. So my question is this valid still?. Or it is possible to filter RPC services using TCP Wrappers.
    When I tested this with following entries in /etc/hosts.allow and /etc/hosts.deny, my two nodes did not give any trouble after couple of reboots. SVM is working fine. So I wonder whether RPC services area really blocked (other than the local host) or not.
    Content of /etc/hosts.deny
    ===========================
    rpcbind: ALL : severity debug
    rpc.metad: ALL : severity debug
    rpc.metamhd: ALL : severity debug
    rpc.metamedd: ALL : severity debug
    rpc.metacld: ALL : severity debug
    Content of /etc/hosts.allow
    =======================================
    rpcbind: KNOWN : severity debug
    rpc.metad: localhost : severity debug
    rpc.metamhd: localhost : severity debug
    rpc.metamedd: localhost : severity debug
    rpc.metacld: localhost : severity debug
    Any hints/information regarding this will be really appreciated.

    Hello Mark,
    Sorry that I missed to thank you in your last post.
    If I get it right, The RPC bind program is used to maintain a table of dynamically allocated ports for RPC-based services.
    From internet, "The file /etc/rpc contains a list of network services. Typically, when a remote machine wants to connect to one of those services on your machine, it first issues a query to the rpcbind program running on your computer. It knows the name of the services it wants to connect with, but doesn't know what port number to use. Your rpcbind will respond with a port number. The remote host will then attempt a connection to the specified port."
    Also, Note that blocking rpcbind doesn't block access to the/etc/rpc services altogether. It does block access for those programs which do an rpcinfo query in order to reach those services. So other possible ways also exist to make remote connection without querying. Here lies the problem. I wanted to secure RPC services completely.
    Coming to metad, it is true that ldd will result nothing related to libwrap*. But inetadm tells different story
    inetadm -l /network/rpc/meta | grep -i wrap
    default tcp_wrappers=TRUE
    So encapsulating with tcpd should work for metad and other RPC services, I believe.
    What is your opinion on this?.

  • Get rid of tcp wrappers?

    Hi!
    I'm not sure this is the right forum, but I'll go with it anyways.
    The first thing I noticed when beginning to fill up my newly installed Arch linux with software was that most of the networkrelated packages was compiled with tcp wrappers (ssh for example, but several others aswell).
    I really don't like the usage of tcp wrappers. If I want security, I use iptables.
    Is there a way to get rid of the entire tcp wrappers thing and still use the packages, or do I have to compile everything on my own?
    Regards
    /Diddi

    Daenyth wrote:Click
    In other words, you'd have to recompile the packages.

  • TCP Wrappers not working

    I want to block all traffic except those rules listed in /etc/hosts.allow.
    And I don't want nfs clients from anywhere to connect to my server.
    But for some reason both of my configuration files are totally ignored  by arch:
    /etc/hosts.allow
    /etc/hosts.deny
    # /etc/hosts.allow
    sshd: ALL
    nfsd : 192.168.10.
    portmap: ALL
    mountd: ALL
    httpd: ALL
    mysqld: ALL : ALLOW
    tor: ALL
    # End of file
    # /etc/hosts.deny
    ALL: ALL: DENY
    # End of file
    Last edited by yassin (2008-04-10 20:43:45)

    #archlinux @ Freenode
    [20:23] < yassin> http://bbs.archlinux.org/viewtopic.php?id=46907
    [20:23] < yassin> any suggestions?
    [20:26] < tomkx> yassin - yes. For those who can't/won't click your link, ask an intelligent question that
              summarises your problem as briefly as possible, but with enough detail to enable anyone who's
              interested to answer you without asking for more information
    [20:26] < yassin> ok
    [20:26] < yassin> my TCP wrappers isn't working, /ets/hosts.deny & /etc/hosts.allow are totally ignored
    [20:29] < yassin> tomkx: well the problem is everyone can connect to every port
    [20:29] < yassin> like as if TCP wrappers wouldn't be running
    [20:30] < yassin> tomkx: for example I have in hosts.allow - nfsd : 192.168.10.
    [20:31] < yassin> and in hosts.deny - ALL: ALL: DENY
    [17:32] < yassin> tomkx: any ideas?
    [17:35] < tomkx> yassin - I was expecting something like "but nfs clients from anywhere can connect to my
              server". In other words, you haven't actually described a specific problem yet (and that includes
              your forum post)
    [17:36] < yassin> tomkx: good point there
    [17:36] < yassin> well yes, that is pretty much the problem
    [17:39] < yassin> tomkx: I updated the post now
    [17:42] < yassin> tomkx: that's not really the problem if we are specific, since I've got the right
              configurations, the problem is they are being ignored by arch
    [17:43] < yassin> tomkx: so I'd say my problem description was correct: "TCP Wrappers not working"
    Last edited by yassin (2008-04-10 20:50:57)

  • TCP wrappers not logging?

    I recently opened up my SSH server to the world (so i can log in from outside my home network to my server). Did some reading up, found out TCP wrappers acts as an intermediary to decide whether or not a request for a given application gets acknowledged.
    SSH logs authentication attempts to /var/log/auth.log. So far, so good. I tried logging in from work, got bounced. Found the entries in that file.
    Today, I tried to log in again, got bounced (again ), however, no sign of it in auth.log. I wanted to check what TCP wrappers had to tell me about this, only to find out it (tcpd) does not seem to log anywhere? /etc/syslog-ng.conf has no tcpd entries.
    Since the contents of syslog-ng.conf look a bit complicated, can someone enlighten me on how to add tcpd logging facilities to it, and also tell why is it not enabled by default?
    The tcpd manual refers to the system logging utility for further info on its logs, and since it has no own config file, there doesn't seem to be a way to set up tcpd independently to log its activities somewhere.

    B wrote:The thing is: i see the sshd entry in auth.log, which means tcp_wrappers allowed the connection to pass through (if not it should have never reached sshd, right?).
    No. Sshd checks hosts.* rules by itself (via libwrap functions), and tcpd is never run. So, it is sshd which logs the connection, successful or not. See, there's an exempt from auth.log; the connection was refused because of hosts.* settings:
    Jun 13 21:42:06 kreml sshd[19994]: refused connect from 87.207.23.75
    B wrote:Last night there weren't even any entries in auth.log, so that's why I'd like to have tcp_wrappers logging the
    attempts it bounces (if possible).
    Maybe the connection wasn't refused by wrapper (leaving alone how called), but by some other means? Anyway, you won't find tcpd entries in logs nor syslogd configuration, it is rarely used nowadays, in favor of direct linking with libwrap.
    Of course, I'm talking about Arch defaults here, you can arrange your config to make use of tcpd.

  • Tcp wrappers /etc/hosts.allow format

    since most of the services that were originally run from
    the /etc/inet/inetd.conf file on pre-Solaris 10 systems
    are now run from smf, what are the "in.*" service names
    that should be placed in the /etc/hosts.allow file?
    also is there a "safe_finger" available for use that can
    be used in the /etc/hosts.deny file or should the
    "standard" Solaris 10 finger be used?
    Thanks

    elasticdog wrote:So should our package not have the ListenAddress 0.0.0.0 line uncommented by default?  My guess would be that since it listens on all local addresses by default, we're just overwriting that when specifying 0.0.0.0, which isn't valid.  That was users don't have to specify their local IP address.  Unless I'm wrong, shouldn't this be a bug/feature request for the packager?
    This doesn't seem to be a package bug... IMHO, sshd must respect all the settings in hosts.deny and hosts.allow, regardless the IP address it listens on. The behaviour I noticed seems to be much more complicated. Basic settings (daemon name mentioned in hosts.*) worked, as far as I didn't want a "per IP" configuration. For example, including the daemon in hosts.allow really enabled remote connections, but any closer specifications (subdomains, EXCEPT operator...) were ignored. Access was simply granted without further evaluation. Excluding sshd from hosts.allow worked as one would assume. When I specified ListenAddress, everything started to work properly. This is mysterious. There are millions of computers using tcp wrappers and ssh, so it's hard to believe there could be a bug.

  • TCP wrappers not supported in sshd?

    It seems that support for tcp wrappers is not compiled into the sshd service for Mountain Lion. sshd ignores the contents of the "/etc/hosts.deny" file, that for example "denyhosts" produces. Why is this do you think, and is there some workaround? Seems like tcp wrappers have been supported forever, before Mountain Lion.

    I consider this a really cheesy and hopefully very temporary workaround. It may not be recommended, use at your own risk, your universe may collapse into a black hole, etc., etc.  But it worked.
    If you still have a 10.7 install on another volume, you can copy the old sshd binary and missing libwrap library file to your 10.8 boot disk and run it. Quick and dirty run down (this is not detailed for those not versed in command line):
    Pre) Make sure you stop the default sshd daemon via the sharing control panel. (Uncheck "Remote login.) Otherwise you will have a conflict on port 22 when you try to start the old.
    1) Mount the 10.7 volume. For my example I'll call mine "Mac 10.7 HD"
    2) sudo cp /Volumes/"Mac 10.7 HD"/usr/lib/libwrap.7.dylib /usr/lib/.
    3) sudo cp /Volumes/"Mac 10.7 HD"/usr/sbin/sshd /usr/sbin/sshd2 (or "sshd-old" or whatever you like, just don't overwrite the exisitng sshd or you won't be able to revert later.)
    4) sudo /usr/sbin/sshd2 (start the daemon)
    Note you can't use the sharing control panel to control this version and if you wanted it start between reboots you would have to create a separate launchctl script for it.
    Linc, another good lead, thanks. I probably should be spending my time looking around for alternatives than hacking away at my install. 

  • [solved] problems with timeouts and tcp retransmission

    I've recently upgraded my archlinux and am having real problems with the network.
    I have checked the configuation and all seems ok.
    Everything like DNS/Gateways/IPs all seem to be setup (not changed anything from when it was working before)
    I read about setting the MTU manually
    ifconfig eth0 mtu 1492
    I tried this but it doesn't seem to make any difference
    Looking at the packetflow on wireshark it seems that there are a huge amount of TCP Dup ACK and TCP Retransmission when trying to POST
    If I boot into windows everything is fine so unfortunately it seems that it might be something with linux
    Everything in linux seemed to be working ok before I upgraded
    Last edited by equilibrium (2009-12-05 15:13:14)

    seems that I am still unable to post from my arch system
    $ dmesg | grep sky2
    sky2 driver version 1.23
    sky2 0000:02:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
    sky2 0000:02:00.0: setting latency timer to 64
    sky2 0000:02:00.0: Yukon-2 EC chip revision 2
    sky2 0000:02:00.0: irq 29 for MSI/MSI-X
    sky2 eth0: addr xx:xx:xx:xx:xx:xx
    sky2 eth0: enabling interface
    sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both
    $ ifconfig
    eth0 Link encap:Ethernet HWaddr 00:17:31:F4:ED:A2
    inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:1170 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1362 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:1101154 (1.0 Mb) TX bytes:197742 (193.1 Kb)
    Interrupt:19
    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:4595 errors:0 dropped:0 overruns:0 frame:0
    TX packets:4595 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:541498 (528.8 Kb) TX bytes:541498 (528.8 Kb)
    /etc/rc.conf
    eth0="eth0 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255"
    INTERFACES=(eth0)
    gateway="default gw 192.168.1.1"
    ROUTES=(gateway)

  • Errors/warnings occurred when generating the local proxy dll and VI wrappers for web service

    Hello,
    I'm new to web services - trying to import a WSDL that was created by an outside vendor and placed on a company server.  I imported a previous version successfully.  The error I'm getting doesn't make a lot of sense to me, here it is:
    The following errors/warnings occurred when generating the local proxy dll and VI wrappers for this web service.
    Can't generate files.
    Possible reasons are:
    1. The output file(s) might be read-only.
    Remove the read-only attribute and import the Web service again.
    2. A proxy DLL that LabVIEW created under the same file path exists in memory.
    Restart LabVIEW and import the Web service again.
    I don't see any read-only attributes on the output files and I've tried restarting LabVIEW - no luck.  Any help is greatly appreciated.
    Thanks,
    Al Rauch
    Merck & Co., Inc.

    Aaron,
    I was able to successfully import and run the web services from the WSDL file in question in LV2009 on a different computer than the one on which I had the original problem.  Unfortunately I am still having the original problem on the project computer and will need to get it working there . . . still looking for a solution to that.  Apparently LV2009 is perfectly capable of importing and running this WSDL file, but there is something still in the way on the project PC.
    Thanks,
    Al

  • Solaris Kernel and TCP/IP Tuning Parameters (Continued)

    This page describes some configuration optimizations for Solaris hosts running ATG Page Serving instances (application servers) that will increase server efficiency.
    Note that these changes are specific to Solaris systems running ATG application servers (+page serving+ instances). Do not use these on a web server or database server. Those systems require entirely different settings.
    h3. Solaris 10 Kernel
    Adjust /etc/system (parameters below) and reboot the system.
    set rlim_fd_cur=4096
    set rlim_fd_max=4096
    set tcp:tcp_conn_hash_size=32768
    set shmsys:shminfo_shmmax=4294967295
    set autoup=900
    set tune_t_fsflushr=1h4. Set limits on file descriptors
    {color:blue}set rlim_fd_max = 4096{color}
    {color:blue}set rlim_fd_cur = 4096{color}
    Raise the file-descriptor limits to a maximum of 4096. Note that this tuning option was not mentioned in the "Sun Performance And Tuning" book.
    [http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-32/index.html]
    h4. Increase the connection hash table size
    {color:blue}set tcp:tcp_conn_hash_size=8192{color}
    Increase the connection hash table size to make look-up's more efficient. The connection hash table size can be set only once, at boot time.
    [http://download.oracle.com/docs/cd/E19455-01/816-0607/chapter4-63/index.html]
    h4. Increase maximum shared memory segment size
    {color:blue}set shmsys:shminfo_shmmax=4294967295{color}
    Increase the maximum size of a system V shared memory segment that can be created from roughly 8MB to 4GB.
    This provides an adequate ceiling; it does not imply that shared memory segments of this size will be created.
    [http://download.oracle.com/docs/cd/E19683-01/816-7137/chapter2-74/index.html]
    h4. Increase memory allocated for dirty pages
    {color:blue}set autoup=900{color}
    Increase the amount of memory examined for dirty pages in each invocation and frequency of file system synchronizing operations.
    The value of autoup is also used to control whether a buffer is written out from the free list. Buffers marked with the B_DELWRI flag (which identifies file content pages that have changed) are written out whenever the buffer has been on the list for longer than autoup seconds. Increasing the value of autoup keeps the buffers in memory for a longer time.
    [http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-16/index.html]
    h4. Specify the time between fsflush invocations
    Specifies the number of seconds between fsflush invocations.
    {color:blue}set tune_t_fsflushr=1{color}
    [http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-105/index.html]
    Again, note that after adjusting any of the preceding kernel parameters you will need to reboot the Solaris server.
    h3. TCP
    ndd -set /dev/tcp tcp_time_wait_interval 60000
    ndd -set /dev/tcp tcp_conn_req_max_q 16384
    ndd -set /dev/tcp tcp_conn_req_max_q0 16384
    ndd -set /dev/tcp tcp_ip_abort_interval 60000
    ndd -set /dev/tcp tcp_keepalive_interval 7200000
    ndd -set /dev/tcp tcp_rexmit_interval_initial 4000
    ndd -set /dev/tcp tcp_rexmit_interval_max 10000
    ndd -set /dev/tcp tcp_rexmit_interval_min 3000
    ndd -set /dev/tcp tcp_smallest_anon_port 32768
    ndd -set /dev/tcp tcp_xmit_hiwat 131072
    ndd -set /dev/tcp tcp_recv_hiwat 131072
    ndd -set /dev/tcp tcp_naglim_def 1h4. Tuning the Time Wait Interval and TCP Connection Hash Table Size
    {color:blue}/usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000{color}
    The tcp_time_wait_interval is how long a connection stays in the TIME_WAIT state after it has been closed (default value 240000 ms or 4 minutes). With the default setting, this socket will remain for 4 minutes after you have closed the FTP connection. This is normal operating behavior. It is done to ensure that any slow packets on the network will arrive before the socket is completely shutdown. As a result, a future program that uses the same socket number won't get confused upon receipt of packets that were intended for the previous program.
    On a busy Web server a large backlog of connections waiting to close could build up and the kernel can become inefficient in locating an available TCP data structure. Therefore it is recommended to change this value to 60000 ms or 1 minute.
    h4. Tuning the maximum number of requests per IP address per port
    {color:blue}ndd -set /dev/tcp tcp_conn_req_max_q 16384{color}
    {color:blue}ndd -set /dev/tcp tcp_conn_req_max_q0 16384{color}
    The {color:blue}tcp_conn_req_max_q{color} and {color:blue}tcp_conn_req_max_q0{color} parameters are associated with the maximum number of requests that can be accepted per IP address per port. tcp_conn_req_max_q is the maximum number of incoming connections that can be accepted on a port. tcp_conn_req_max_q0 is the maximum number of “half-open” TCP connections that can exist for a port. The parameters are separated in order to allow the administrator to have a mechanism to block SYN segment denial of service attacks on Solaris.
    The default values are be too low for a non-trivial web server, messaging server or directory server installation or any server that expects more than 128 concurrent accepts or 4096 concurrent half-opens. Since the ATG application servers are behind a DMZ firewall, we needn't starve these values to ensure against DOS attack.
    h4. Tuning the total retransmission timeout value
    {color:blue}ndd -set /dev/tcp tcp_ip_abort_interval 60000{color}
    {color:blue}tcp_ip_abort_interval{color} specifies the default total retransmission timeout value for a TCP connection. For a given TCP connection, if TCP has been retransmitting for tcp_ip_abort_interval period of time and it has not received any acknowledgment from the other endpoint during this period, TCP closes this connection.
    h4. Tuning the Keep Alive interval value
    {color:blue}ndd -set /dev/tcp tcp_keepalive_interval 7200000{color}
    {color:blue}tcp_keepalive_interval{color} sets a probe interval that is first sent out after a TCP connection is idle on a system-wide basis.
    If SO_KEEPALIVE is enabled for a socket, the first keep-alive probe is sent out after a TCP connection is idle for two hours, the default value of the {color:blue}tcp_keepalive_interval{color} parameter. If the peer does not respond to the probe after eight minutes, the TCP connection is aborted.
    The {color:blue}tcp_rexmit_interval_*{color} values set the initial, minimum, and maximum retransmission timeout (RTO) values for a TCP connections, in milliseconds.
    h4. Tuning the TCP Window Size
    {color:blue}/usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 65535{color}
    {color:blue}/usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 65535{color}
    Setting these two parameters controls the transmit buffer and receive window. We are tuning the kernel to set each window to 65535 bytes. If you set it to 65536 bytes (64K bytes) or more with Solaris 2.6, you trigger the TCP window scale option (RFC1323).
    h4. Tuning TCP Slow Start
    {color:blue}/usr/sinb/ndd -set /dev/tcp tcp_slow_start_initial 4{color}
    tcp_slow_start_initial is the number of packets initially sent until acknowledgment, the congestion window limit.
    h4. Tuning the default bytes to buffer
    {color:blue}ndd -set /dev/tcp tcp_naglim_def 1{color}
    {color:blue}tcp_naglim_def{color} is the default number of bytes to buffer. Each connection has its own copy of this value, which is set to the minimum of the MSS for the connection and the default value. When the application sets the TCP_NODELAY socket option, it changes the connection's copy of this value to 1. The idea behind this algorithm is to reduce the number of small packets transmitted across the wire by introducing a short (100ms) delay for packets smaller than some minimum.
    Changing the value of tcp_naglim_def to 1 will have the same effect (on connections established after the change) as if each application set the TCP_NODELAY option.
    {note}
    The current value of any of the TCP parameters can be displayed with the command ndd get. So to retrieve the current setting of the {color:blue}tcp_naglim_def parameter{color}, simply execute the command:\\
    {color:blue}ndd -get /dev/tcp tcp_naglim_def{color}
    {note}
    h3. References
    Solaris Tunable Parameters Reference Manual
    [http://download.oracle.com/docs/cd/E19455-01/816-0607/index.html]
    WebLogic Server Performance and Tuning
    [http://download.oracle.com/docs/cd/E11035_01/wls100/perform/OSTuning.html]

    For example,
    Socket.setSoTimeout() sets SO_TIMEOUT option and I
    want to what TCP parameter this option corresponds in
    the underlying TCP connection.This doesn't correspond to anything in the connection, it is an attribute of the API.
    The same questions
    arises fro other options from SocketOptions class.setTcpNoDelay() controls the Nagle algorithm. set{Send,Receive}BufferSize() controls the local socket buffers.
    Most of this is quite adequately described in the javadoc actually.

Maybe you are looking for