Configuring the TCP/IP stack in realtime

["Followup-To:" header set to comp.os.linux.networking.]
On 2009-11-09, karthikbalaguru <karthikbalaguru79.RemoveThis@gmail.com> wrote:
> Hi,
> I need this to verify the functionality of an application
> on a hardware board for various scenarios of TCP/IP.
> Is there any tool in linux that will help in
> configuring the TCP/IP stack of linux in realtime ?
>
man ifconfig
man route

karthikbalaguru <karthikbalaguru79 DeleteThis @gmail.com> writes:

> Hi,
> I need this to verify the functionality of an application
> on a hardware board for various scenarios of TCP/IP.
> Is there any tool in linux that will help in
> configuring the TCP/IP stack of linux in realtime ?

There's the shell commands:

ifconfig eth0 10.2.0.0 netmask 155.255.0.0 up
ifconfig eth0 down

On Nov 10, 1:23 am, Pascal Hambourg <boite-a-s....DeleteThis@plouf.fr.eu.org>
wrote:
> [Follow-up to comp.os.linux.networking]
>
> Hello,
>
> karthikbalaguru a écrit :
>
> > Hi,
> > I need this to verify the functionality of an application
> > on a hardware board for various scenarios of TCP/IP.
> > Is there any tool in linux that will help in
> > configuring the TCP/IP stack of linux in realtime ?
>
> What do you want to configure exactly ?
> - addresses : ifconfig, ip addr
> - routes : route, ip route
> - IP and TCP parameters : sysctl or echo (in /proc/sys/net/ipv4/)

I would like to configure for all kind of TCP OPTIONS mentionioned
in RFC 4413 under section 4.3.1 and all other TCP/IP fields.

Thx in advans,
Karthik Balaguru

karthikbalaguru a écrit :
>
> I would like to configure for all kind of TCP OPTIONS mentionioned
> in RFC 4413 under section 4.3.1 and all other TCP/IP fields.

I don't know if Linux supports all of the mentionned options. The MSS
value is automatically set from the path MTU to the destination. Other
options such as window scale, SACK and timestamp can be enabled or
disabled through sysctl parameters in net.ipv4 (see man 7 tcp) or its
filesystem counterpart /proc/sys/net/ipv4. Some options may be available
as socket options.

Some TCP/IP fields are under control of the socket (source/destination
addresses and ports...) or sysctl parameters, but other fields are fixed
or under direct control of the TCP/IP stack and cannot be configured by
the user AFAIK : protocol version, sequence number, ACK number,
checksums, fragmentation, TCP flags...

If you want to control every field in a TCP/IP packet, you have to use
an arbitrary packet generator.

On Nov 10, 2:58 pm, Pascal Hambourg <boite-a-s... DeleteThis @plouf.fr.eu.org>
wrote:
> karthikbalaguru a écrit :
>
>
>
> > I would like to configure for all kind of TCP OPTIONS mentionioned
> > in RFC 4413 under section 4.3.1 and all other TCP/IP fields.
>
> I don't know if Linux supports all of the mentionned options. The MSS
> value is automatically set from the path MTU to the destination. Other
> options such as window scale, SACK and timestamp can be enabled or
> disabled through sysctl parameters in net.ipv4 (see man 7 tcp) or its
> filesystem counterpart /proc/sys/net/ipv4. Some options may be available
> as socket options.

Great !
Yes, i did come across a link regarding this.
Also check -
http://www.frozentux.net/ipsysctl-tutorial/ipsysctl-tutorial.html
http://www.linuxweblog.com/blogs/sandip/20080331/tuning-tcp-sysctlconf

I find that they do not deal with all the TCP OPTIONS mentioned
in RFC 4413.

> Some TCP/IP fields are under control of the socket (source/destination
> addresses and ports...) or sysctl parameters, but other fields are fixed
> or under direct control of the TCP/IP stack and cannot be configured by
> the user AFAIK : protocol version, sequence number, ACK number,
> checksums, fragmentation, TCP flags...
>
> If you want to control every field in a TCP/IP packet, you have to use
> an arbitrary packet generator.

Thx for the info.
But, Is there any packet generator available that gives complete
control
over all the TCP OPTIONS mentioned in the RFC 4413 under
section 4.3.1 ?

Thx in advans,
Karthik Balaguru

Maxwell Lol <nospam.TakeThisOut@com.invalid> wrote:
+---------------
| karthikbalaguru <karthikbalaguru79.TakeThisOut@gmail.com> writes:
| > Is there any tool in linux that will help in
| > configuring the TCP/IP stack of linux in realtime ?
|
| There's the shell commands:
|
| ifconfig eth0 10.2.0.0 netmask 155.255.0.0 up
| ifconfig eth0 down
+---------------

Beware that in some (most?) versions of Linux "ifconfig" will set the
IP broadcast address *incorrectly* unless you specify it explicitly
[thus causing various protocols that use IP broadcast for initial
discovery to fail mysteriously!]. Plus, I think Maxwell probably
typo'd the netmask [as well as using the deprecated zero host address.]
Try this format instead:

ifconfig eth0 10.2.3.1 netmask 255.255.0.0 broadcast 10.2.255.255 up


-Rob

p.s. FreeBSD's "ifconfig" does reliably set broadcast from the information
contained in the host address and the netmask. I don't know why Linux has
trouble with this, but I have seen problems with it on multiple systems
running various versions of the Linux kernel from 2.4.21 to 2.6.22 or later.

-----
Rob Warnock <rpw3.TakeThisOut@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

In comp.protocols.tcp-ip Rob Warnock <rpw3 RemoveThis @rpw3.org> wrote:
(snip)

> Beware that in some (most?) versions of Linux "ifconfig" will set the
> IP broadcast address *incorrectly* unless you specify it explicitly
> [thus causing various protocols that use IP broadcast for initial
> discovery to fail mysteriously!].

I don't know what you mean by incorrect, but for all the years
I used SunOS it always set the broadcast address by default
to the zero host address. You just got used to overriding that.

-- glen

rpw3.RemoveThis@rpw3.org (Rob Warnock) writes:

> Plus, I think Maxwell probably
> typo'd the netmask [as well as using the deprecated zero host address.]

You'd be correct, Sir!

> Try this format instead:
>
> ifconfig eth0 10.2.3.1 netmask 255.255.0.0 broadcast 10.2.255.255 up

Thanks for the correction!

glen herrmannsfeldt <gah.TakeThisOut@ugcs.caltech.edu> wrote:
+---------------
| Rob Warnock <rpw3.TakeThisOut@rpw3.org> wrote:
| > Beware that in some (most?) versions of Linux "ifconfig" will set the
| > IP broadcast address *incorrectly* unless you specify it explicitly
| > [thus causing various protocols that use IP broadcast for initial
| > discovery to fail mysteriously!].
|
| I don't know what you mean by incorrect...
+---------------

I forget the exact scenario, but ISTR[1] if you did something like this:

ifconfig eth0 10.2.3.4 netmask 255.255.255.192

then the broadcast address came up with 10.255.255.255, which is
*definitely* the wrong value!! That is, it looked only at the
Class A nature of 10.2.3.4 and ignored the netmask. This hit us hard
since we were using network 10 (inside our firewall) and chopping it
up into hundreds of tiny subnets (for separate test server groups),
and if someone forgot to specify the broadcast address it messed up
not only their system but potentially spammed the whole lab net. You
had to be *very* careful to say, e.g.:

ifconfig eth0 10.2.3.4 netmask 255.255.255.192 broadcast 10.2.3.63

Not only that, but Linux's "ifconfig" didn't handle CIDR
notation correctly, whereas in FreeBSD all you have to say is
"ifconfig sis0 1.2.3.4/27" and *both* netmask & broadcast will
be set correctly [to 255.255.255.224 and 1.2.3.31, respectively,
in this example].


-Rob

[1] It was three or four years ago, and the company I was working for
at the time doesn't exist anymore so I can't try it on the actual
platform (there's no "there" there, to borrow from Gertrude Stein),
but I just checked with a former co-worker and he confirms the
scenario.

-----
Rob Warnock <rpw3.TakeThisOut@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

On Sun, 2009-11-15, Rob Warnock wrote:
> glen herrmannsfeldt <gah DeleteThis @ugcs.caltech.edu> wrote:
> +---------------
> | Rob Warnock <rpw3 DeleteThis @rpw3.org> wrote:
> | > Beware that in some (most?) versions of Linux "ifconfig" will set the
> | > IP broadcast address *incorrectly* unless you specify it explicitly
> | > [thus causing various protocols that use IP broadcast for initial
> | > discovery to fail mysteriously!].
> |
> | I don't know what you mean by incorrect...
> +---------------
>
> I forget the exact scenario, but ISTR[1] if you did something like this:
>
> ifconfig eth0 10.2.3.4 netmask 255.255.255.192
>
> then the broadcast address came up with 10.255.255.255, which is
> *definitely* the wrong value!! That is, it looked only at the
> Class A nature of 10.2.3.4 and ignored the netmask. This hit us hard
> since we were using network 10 (inside our firewall) and chopping it
> up into hundreds of tiny subnets (for separate test server groups),
> and if someone forgot to specify the broadcast address it messed up
> not only their system but potentially spammed the whole lab net. You
> had to be *very* careful to say, e.g.:
>
> ifconfig eth0 10.2.3.4 netmask 255.255.255.192 broadcast 10.2.3.63

But this looks correct, doesn't it?

tuva:/home/grahn# ifconfig eth0:1 10.2.3.4 netmask 255.255.255.192
tuva:/home/grahn# ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr 00:0d:93:60:7e:78
inet addr:10.2.3.4 Bcast:10.2.3.63 Mask:255.255.255.192
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:41 Base address:0xa400

tuva:/home/grahn# ifconfig --version
net-tools 1.60
ifconfig 1.42 (2001-04-13)

> Not only that, but Linux's "ifconfig" didn't handle CIDR
> notation correctly, whereas in FreeBSD all you have to say is
> "ifconfig sis0 1.2.3.4/27" and *both* netmask & broadcast will
> be set correctly [to 255.255.255.224 and 1.2.3.31, respectively,
> in this example].

Can't see that bug either:

tuva:/home/grahn# ifconfig eth0:1 10.2.3.4/27
tuva:/home/grahn# ifconfig eth0:1
eth0:1 Link encap:Ethernet HWaddr 00:0d:93:60:7e:78
inet addr:10.2.3.4 Bcast:10.2.3.31 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:41 Base address:0xa400

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
+---------------
| Rob Warnock wrote:
| > glen herrmannsfeldt <gah.TakeThisOut@ugcs.caltech.edu> wrote:
| > +---------------
| > | I don't know what you mean by incorrect...
| > +---------------
| >
| > I forget the exact scenario, but ISTR[1] if you did something like this:
| > ifconfig eth0 10.2.3.4 netmask 255.255.255.192
| > then the broadcast address came up with 10.255.255.255, which is
| > *definitely* the wrong value!! That is, it looked only at the
| > Class A nature of 10.2.3.4 and ignored the netmask.
....
| > You had to be *very* careful to say, e.g.:
| > ifconfig eth0 10.2.3.4 netmask 255.255.255.192 broadcast 10.2.3.63
|
| But this looks correct, doesn't it?
|
| tuva:/home/grahn# ifconfig eth0:1 10.2.3.4 netmask 255.255.255.192
| tuva:/home/grahn# ifconfig eth0:1
| eth0:1 Link encap:Ethernet HWaddr 00:0d:93:60:7e:78
| inet addr:10.2.3.4 Bcast:10.2.3.63 Mask:255.255.255.192
| UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
| Interrupt:41 Base address:0xa400
+---------------

Yup!

+---------------
| tuva:/home/grahn# ifconfig --version
| net-tools 1.60
| ifconfig 1.42 (2001-04-13)
|
| > Not only that, but Linux's "ifconfig" didn't handle CIDR
| > notation correctly, whereas in FreeBSD all you have to say is
| > "ifconfig sis0 1.2.3.4/27" and *both* netmask & broadcast will
| > be set correctly [to 255.255.255.224 and 1.2.3.31, respectively,
| > in this example].
|
| Can't see that bug either:
|
| tuva:/home/grahn# ifconfig eth0:1 10.2.3.4/27
| tuva:/home/grahn# ifconfig eth0:1
| eth0:1 Link encap:Ethernet HWaddr 00:0d:93:60:7e:78
| inet addr:10.2.3.4 Bcast:10.2.3.31 Mask:255.255.255.224
| UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
| Interrupt:41 Base address:0xa400
+---------------

Good! They've fixed it, then!

Sorry I can't be specific about which version(s) of the kernel and/or
distribution(s) we were having trouble with -- I do remember that one
of the problematic versions was 2.6.7 -- but it was quite a while ago
[circa 2004, though 2.6.7 was already old then IIRC].

In any case, I'm glad they've fixed it!


-Rob

-----
Rob Warnock <rpw3.TakeThisOut@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

karthikbalaguru a écrit :
> On Nov 10, 2:58 pm, Pascal Hambourg <boite-a-s....RemoveThis@plouf.fr.eu.org>
> wrote:
>>
>> If you want to control every field in a TCP/IP packet, you have to use
>> an arbitrary packet generator.
>
> Thx for the info.
> But, Is there any packet generator available that gives complete
> control over all the TCP OPTIONS mentioned in the RFC 4413 under
> section 4.3.1 ?

Any arbitrary packet generator should allow you to do that. Otherwise it
is not arbitrary. However it may be more or less convenient depending on
its features. If it does not handle the kind of option you want, you may
have to manually build the whole packet byte per byte.

Jorgen Grahn a écrit :
> On Sun, 2009-11-15, Rob Warnock wrote:
>>
>> ifconfig eth0 10.2.3.4 netmask 255.255.255.192
>>
>> then the broadcast address came up with 10.255.255.255, which is
>> *definitely* the wrong value!! That is, it looked only at the
>> Class A nature of 10.2.3.4 and ignored the netmask.
[...]
> But this looks correct, doesn't it?
>
> tuva:/home/grahn# ifconfig eth0:1 10.2.3.4 netmask 255.255.255.192
> tuva:/home/grahn# ifconfig eth0:1
> eth0:1 Link encap:Ethernet HWaddr 00:0d:93:60:7e:78
> inet addr:10.2.3.4 Bcast:10.2.3.63 Mask:255.255.255.192
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> Interrupt:41 Base address:0xa400
>
> tuva:/home/grahn# ifconfig --version
> net-tools 1.60
> ifconfig 1.42 (2001-04-13)

Don't just trust what ifconfig prints, check the actual broadcast routes
in the "local" routing table :

# ip route show table local type broadcast dev eth0
broadcast 10.2.3.63 proto kernel scope link src 10.2.3.4
broadcast 10.2.3.0 proto kernel scope link src 10.2.3.4
broadcast 10.255.255.255 proto kernel scope link src 10.2.3.4

Notes :
1) 10.2.3.0 is the old-style "all zeroes" subnet-directed broadcast
address still present for legacy purposes. It is correct with respect to
the netmask.

2) There are two "all ones" broadcast addresses. 10.2.3.63 is the
expected subnet-directed broadcast address and 10.255.255.255 is the now
deprecated all-subnets-directed broadcast address. The all-subnets
concept is meaningless in a classless environnment.

3) This is what I get with a Linux 2.4 recent version (2.4.36.6) or an
old 2.6 version (2.6.. With a more recent Linux 2.6 version (2.6.20)
and the same ifconfig 1.42 from net-tools 1.60 version, 10.255.255.255
is not present. So I guess the fix was made in the Linux 2.6 kernel
between versions 2.6.9 and 2.6.20, not in ifconfig.

> tuva:/home/grahn# ifconfig eth0:1 10.2.3.4/27
> tuva:/home/grahn# ifconfig eth0:1
> eth0:1 Link encap:Ethernet HWaddr 00:0d:93:60:7e:78
> inet addr:10.2.3.4 Bcast:10.2.3.31 Mask:255.255.255.224

Here things become strange. If the interface has no address and mask
yet, I get an error :

# ifconfig eth0 10.2.3.4/27
SIOCSIFNETMASK: Cannot assign requested address

# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 52:54:05:DE:25:90
inet addr:10.2.3.4 Bcast:10.255.255.255 Mask:255.0.0.0

It looks like ifconfig did not handle the CIDR notation properly and the
default classful mask was used.

If I run the same command again then there is no error, and the mask and
broadcast addresses are correct.

I personnally prefer the "ip" command from iproute over ifconfig and route.