IP stack question

IP stack question

[Bloch, Jack]

I am writing this e-mail at the recommendation of Alan Cox. I have an
embedded system running on cPCI HW which has two physical Ethernet
connections. This system is connected to an internal network and the IP
addresses are not made public. I use the IP addresses 10.1.1.4 and 10.1.1.5
respectively. The two physical ports are connected to two separate LAN
switches which are connected by an uplink. I want to periodically test this
uplink cable. My plan to do this is to send a simple test message (much like
a ping) from 10.1.1.4 to 10.1.1.5, however, the IP stack does not let me do
this. Is there any specific reason why not?

Jack Bloch
Siemens Carrier Networks
e-mail    : jack.bloch@icn.siemens.com
phone     : (561) 923-6550

Re: IP stack question

[jamal]

I tried to explain to you in private mail:
Both 10.1.1.4 and 10.1.1.5 are recognized to be local addresses
by the IP stack. It is legit that the stack limits the scope
to just that i.e _local_
 The only way to do what you want to do is bypass the IP stack.
Use packet socket to write your  test app.
(which actually probably defetas the whole purpose of what you may
be trying to do -- HA).

cheers,
jamal

On Mon, 24 Jun 2002, Bloch, Jack wrote:

> I am writing this e-mail at the recommendation of Alan Cox. I have an
> embedded system running on cPCI HW which has two physical Ethernet
> connections. This system is connected to an internal network and the IP
> addresses are not made public. I use the IP addresses 10.1.1.4 and 10.1.1.5
> respectively. The two physical ports are connected to two separate LAN
> switches which are connected by an uplink. I want to periodically test this
> uplink cable. My plan to do this is to send a simple test message (much like
> a ping) from 10.1.1.4 to 10.1.1.5, however, the IP stack does not let me do
> this. Is there any specific reason why not?
>
> Jack Bloch
> Siemens Carrier Networks
> e-mail    : jack.bloch@icn.siemens.com
> phone     : (561) 923-6550
>

Re: IP stack question

[Ben Greear]

jamal wrote:
> I tried to explain to you in private mail:
> Both 10.1.1.4 and 10.1.1.5 are recognized to be local addresses
> by the IP stack. It is legit that the stack limits the scope
> to just that i.e _local_
>  The only way to do what you want to do is bypass the IP stack.
> Use packet socket to write your  test app.
> (which actually probably defetas the whole purpose of what you may
> be trying to do -- HA).

It would not defeat the purpose of detecting at least one bad network
link of the two.

I wonder if a ping -I eth1 255.255.255.255 would accomplish the
goal as well?

I would actually like to be able to force a machine to not do local
routing as well, and force packets out over an interface even if
the destination is a local IP,  using source-based-routing,
or something similar.  There is no way to do this currently?

Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: IP stack question

[jamal]

On Mon, 24 Jun 2002, Ben Greear wrote:

> It would not defeat the purpose of detecting at least one bad network
> link of the two.
>

Unless i misunderstood:
He seems to be trying to do a loopback test from one of his interfaces to
the network and back on another of his interfaces.

> I wonder if a ping -I eth1 255.255.255.255 would accomplish the
> goal as well?
>

This would probably cause a broadcast storm if you are doing a loopback
test ;->

Actually now that i think about it, you could probably modify ping
to do setsockopt(fd,....,SO_DONTROUTE,...) and send it out on a specific
interface. Dont know if it would work.

> I would actually like to be able to force a machine to not do local
> routing as well, and force packets out over an interface even if
> the destination is a local IP,  using source-based-routing,
> or something similar.  There is no way to do this currently?
>

Try that SO_DONTROUTE and see if solves your problem; you probably have to
bind the socket to a specific device as well;
For all that trouble, i would suggest you may just as well write a sock
packet based  app.

cheers,
jamal

Re: IP stack question

[Ben Greear]

jamal wrote:
> 
> On Mon, 24 Jun 2002, Ben Greear wrote:

> Try that SO_DONTROUTE and see if solves your problem; you probably have to
> bind the socket to a specific device as well;
> For all that trouble, i would suggest you may just as well write a sock
> packet based  app.

I want to use normal TCP/IP stack as much as possible, so the sock-packet
(or raw) would not work for me, although it would work fine for the original
poster.

I'm also using source-based routing to send out the correct local
interface.  I'll have to look up more information on what SO_DONTROUTE
does, and thanks for the suggestion!

Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: IP stack question (how to force pkts to not route locally, but go out interfaces regardless of destination)

[Ben Greear]

jamal wrote:
> Ben Wrote:
>>I would actually like to be able to force a machine to not do local
>>routing as well, and force packets out over an interface even if
>>the destination is a local IP,  using source-based-routing,
>>or something similar.  There is no way to do this currently?
>>
> 
> 
> Try that SO_DONTROUTE and see if solves your problem; you probably have to
> bind the socket to a specific device as well;
> For all that trouble, i would suggest you may just as well write a sock
> packet based  app.

I am back to trying to figure out how to make this work.  I'm tried source
based routing, and it does not work (it routes internally).

I read the help on SO_DONTROUTE, but it seems to make the kernel not able
to send to a router.  I would like to be able to route, ie port a -> router -> port b

I already bind to a particular port and IP, and use policy based routing
(source based routing) to make sure the packet is sent out the correct
local interface.

I just need to find the routing logic that notices the destination IP is local
and tell it to quit looking (probably for a particular socket, as I can
see how this could break applications who didn't expect it)

I dug through the code once before looking for this, and didn't find
what I needed.  Can anyone suggest the right files and/or methods to
look in?

Thanks,
Ben

> 
> cheers,
> jamal
> 


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: IP stack question (how to force pkts to not route locally, but go out interfaces regardless of destination)

[James R. Leu]

Hello,

How about changing the preference of the 'local' table (kernel change required)
and inserting a new table (via iptables) that had rules like 
"if src is local, and dest = 192.168.1.1 then send out eth0"

Jim

On Tue, Aug 27, 2002 at 11:25:58PM -0700, Ben Greear wrote:
> 
> jamal wrote:
> > Ben Wrote:
> >>I would actually like to be able to force a machine to not do local
> >>routing as well, and force packets out over an interface even if
> >>the destination is a local IP,  using source-based-routing,
> >>or something similar.  There is no way to do this currently?
> >>
> > 
> > 
> > Try that SO_DONTROUTE and see if solves your problem; you probably have to
> > bind the socket to a specific device as well;
> > For all that trouble, i would suggest you may just as well write a sock
> > packet based  app.
> 
> I am back to trying to figure out how to make this work.  I'm tried source
> based routing, and it does not work (it routes internally).
> 
> I read the help on SO_DONTROUTE, but it seems to make the kernel not able
> to send to a router.  I would like to be able to route, ie port a -> router -> port b
> 
> I already bind to a particular port and IP, and use policy based routing
> (source based routing) to make sure the packet is sent out the correct
> local interface.
> 
> I just need to find the routing logic that notices the destination IP is local
> and tell it to quit looking (probably for a particular socket, as I can
> see how this could break applications who didn't expect it)
> 
> I dug through the code once before looking for this, and didn't find
> what I needed.  Can anyone suggest the right files and/or methods to
> look in?
> 
> Thanks,
> Ben
> 
> > 
> > cheers,
> > jamal
> > 
> 
> 
> -- 
> Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
> President of Candela Technologies Inc      http://www.candelatech.com
> ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear
> 
> 

-- 
James R. Leu

A question on RTT estimation of SACKed packet.

[Xiaoliang (David) Wei]

Hi Everyone,
    I am studying the Linux 2.4.19 TCP code. I have a question on the RTT
estimation.
    In the function tcp_clean_rtx_queue (tcp_input.c), all the packet before
snd_una is checked:
    1. When a packet was not SACKed before, we can calculate the seq_rtt
from its skb's timestamp (now - scb->when).
    2. When a packet was SACKed but not retransmitted, the linux also
calculate the seq_rtt from it when there is no unSACKed packet in the queue.
     I cannot understand the second situation: The packet was SACKed before,
that means it arrived the receiver and triggered a SACK sometime before. The
interval between when packet is sent and when the SACK is received should be
the RTT for experienced this packet. Even now the packet is ACKed, I don't
think this ACK is triggered by this packet. Why is it used to calculate the
RTT?
      Thanks.

-David

Xiaoliang (David) Wei             Graduate Student in CS@Caltech
http://www.cs.caltech.edu/~weixl
====================================================

Re: A question on RTT estimation of SACKed packet.

[kuznet]

Hello!

>     2. When a packet was SACKed but not retransmitted, the linux also
> calculate the seq_rtt from it when there is no unSACKed packet in the queue.
>      I cannot understand the second situation: The packet was SACKed before,
> that means it arrived the receiver and triggered a SACK sometime before. The
> interval between when packet is sent and when the SACK is received should be
> the RTT for experienced this packet. Even now the packet is ACKed, I don't
> think this ACK is triggered by this packet. Why is it used to calculate the
> RTT?

It is not used. When a segment fills a hole, tcp uses skb->when of the segment
which _filled_ the hole. See?

What's about using SACKs to give additional feed to rtt estimator,
even when ACK is duplicate, it is intersting idea, I even read about
this somewhere. But we do not use this.

Alexey

Re: A question on RTT estimation of SACKed packet.

[Xiaoliang (David) Wei]

Thanks, Alexey.
> >     2. When a packet was SACKed but not retransmitted, the linux also
> > calculate the seq_rtt from it when there is no unSACKed packet in the
queue.
>
> It is not used. When a segment fills a hole, tcp uses skb->when of the
segment
> which _filled_ the hole. See?

Yes, this is exactly my question: When this segment fills a hole, it may be
SACKed before.
If it's SACKed before, that means its "round trip" had already finished
before this ACK came-- Now it's filling the hole just because some strange
things (such as ack loss) happened. So, I don't think we should use its
skb->when to estimate RTT. But in Linux, such a packet (SACKed) may still
provide RTT estimation.

>
> What's about using SACKs to give additional feed to rtt estimator,
> even when ACK is duplicate, it is intersting idea, I even read about
> this somewhere. But we do not use this.
Actually, I am going to do that: Can I get a safe RTT estimation from SACK,
when the SACKed packet (in rtx queue) is never SACKed or Retransmitted?

-David

IP stack question

[Bloch, Jack]

I have the following situation.

I am running a SuSE 2.4.19 Kernel on an SMP machine. I am using the bonding
driver. I have a BOND1 device created with IP address 10.77.67.125 and MAC
address 00:10:18:06:CF:B8.  BOND1 consists of ETH2 and ETH6 in active
standby mode with ETH2 being the active slave and ETH6 being standby. I see
periods of duplicate messages being received by my application. I traced it
down to the fact that the messages are indeed being received by both ETH2
and ETH6 (since ETH6 has the same MAC/IP combination, it does pass messages
up the stack). Further analysis has shown that soem messages coming from the
active bond have a garbage sour address in the MAC header. The source
address seems to be an ASCII representation of the actual MAC address, that
is,   30303A31303A (00:10:). This causes the Ethernet switch to overwrite
its learning tables and subsequent messages for that MAC/IP are broadcast
and received by both chips. I put some tracepoints in the bonding drivers
transmit routine and see that the bad address is in the SKB at the time of
transmission. I would like to know if similar problems have been seen. My
assumtion is that this message arrives  at the bonding driver already "bad"
from the IP stack. The fat that I have bonding allows the error to be seen.
Without bonding, this error would not be noticed.

Please CC me directly on any responses.



Regards,


Jack Bloch


Siemens