Criticism of solaris2.x tcp/ip stack

Criticism of solaris2.x tcp/ip stack

Post by Slavcho Nikol » Sat, 22 Apr 1995 04:00:00



How would you go about customizing the operation of the
tcp/ip driver in a Solaris 2.x kernel, such as illustrated by
the following 2 fictitious examples

ex.1 -  all outgoing ip packets shall have the "high priority" and
        "low delay" bits set, and in addition, time-to-live shall be
        incremented by 4 unless wrap-around would be caused.
ex.2 -  all outgoing ip packets on interface le1 shall be subject
        to loose source routing before being allowed to proceed.

The idea is that you want to exercise greater control over the ip
layer from user level processes.

Restrictions: kernel sources are presumed unavailable (pricey!!),
therefore, non-standard solutions that make use of new ioctl's or
newly defined system calls do not count.
Solutions using data link access, and a user-level tcp/ip stack
cannot be accepted, either.
Why do I get the impression that solaris 2.x leaves little space for
maneuver when it comes to tcp/ip network management?
--
S.N.

 
 
 

Criticism of solaris2.x tcp/ip stack

Post by Bruce Barne » Wed, 26 Apr 1995 04:00:00



> ex.1 -  all outgoing ip packets shall have the "high priority" and
>         "low delay" bits set, and in addition, time-to-live shall be
>         incremented by 4 unless wrap-around would be caused.

Well, you can do that at an application level (e.g. using
        int tos = 0; /* or whatever */
        setsockopt(sockfd,IPPROTO_IP, IP_TOS,
                           (char *)&tos, sizeof(tos)) < 0)
                SysFail("setsockopt output TOS %d", tos);

This makes more sense to me.  If you make everything high priority,
what advantage is it?  Clearly some applications do not need the same
characteristics.  It would be like making your default priority of -20.

The Type of Service has specific purposes. (See RFC1458, RFC1716, RFC1349)
I suspect you may not be using it the right way.

Quote:> Why do I get the impression that solaris 2.x leaves little space for
> maneuver when it comes to tcp/ip network management?

Do many UNIX stacks allow this? Why would you want to do this for ALL
applications on a system? What does this have to do with network management?
If PC stacks do this, then maybe it is done on a stack by stack basis,
instead of a application by application basis.

Why exactly do you need this? What problem are you trying to solve?
This is not a flame. We're just trying to understand exactly the problem you
are trying to solve. Flaming solaris only relieves frustration. It
doesn't solve problems.

There may be ways to do SOME of what you want by modifying the kernal.

For instance, the command

        ndd /dev/ip ip_def_ttl

returns the value of 255 - which I suspect is the default TTL value.
Perhaps you can type

        ndd /dev/ip ip_def_ttl 512

to make it larger, although I have never tried it.

--


 
 
 

Criticism of solaris2.x tcp/ip stack

Post by Casper H.S. Dik - Network Security Engine » Thu, 27 Apr 1995 04:00:00



>    ndd /dev/ip ip_def_ttl
>returns the value of 255 - which I suspect is the default TTL value.

It is also the maximum value.  The TTL is a one-byte unsigned
quantity in the IP header.

If the original poster really wanted to icnrease the TTL of each passing
package, I'd suggest *DON'T*.  The TTL is there to prevent packets
from travelling around the net forever, among other things, bumping
the TTL of passing packets may cause melted wires.

Casper

 
 
 

1. Solaris 2.5.1 TCP/IP faces Solaris2.6 TCP/IP

Hi,All.

I need an advice on the following:
I'm porting a tcp/ip client server application from Solaris2.5.1 to
Solaris2.6
On Solaris2.6 I'm getting different sockets behavior than on
Solaris2.5.1 , For example
accept function failed, or connection refused.

As there any change in the TCP/IP layer between those two operating
systems ?

Any help/suggestions will be appreciate
Eyal.

--
Eyal Haviv.
Product Manager.
Computer Associates.
Phone : +972-4-9592101.

2. ATI Mach 64 CT264 and XFree86

3. Packets from bottom of TCP/IP stack direct to application bypassing stack

4. ppp, determing on line status.

5. Solaris2.6 TCP/IP faces Solaris2.5.1.

6. Slow backups with fssnap

7. tcp / ip stack and ip forwarding questions

8. Dial-in TTY HELP!

9. How to tell an application to use a custom tcp/ip stack instead of tcp/ip stack from linux?

10. linux tcp/ip stack as a module...insmod problems

11. TCP/IP stack for Wabi 2.2

12. TCP/IP - stacks?

13. TCP/IP Stack for SCO Unix V/386 Release 3.2?