<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: long standing problem with cipe finally resolved...
From: Nathan Neulinger <nneul,AT,umr,DOT,edu>
Date: Wed, 14 Nov 2001 14:02:20 +0100
In-reply-to: <3BED7873.3053D423@umr.edu>

I have not heard any feedback on this... Does anyone agree with the
problem/resolution?

> Nathan Neulinger wrote:
> 
> I've got a cipe server that has 10.0.0.254 as it's primary interface
> that it talks to to connect to the internet, but it has a real
> internet
> address. (The 10.0.0.x is our internal backbone.)
> 
> Anyway, the problem I was having is, with pkcipe, even with -r, I
> could
> never get cipe to use the correct interface address. It always rebound
> 
> to 10.0.0.254 even though pkcipe sent it a correctly bound socket.
> 
> (When I manually set up the cipe options files/etc. and run ciped
> directly, it worked fine. It was only with the automatic pkcipe setup
> where it wouldn't work right.)
> 
> I've tracked the problem down to the following. (This is sequence of
> steps in pkcipe/ciped)
> 
>         socket()
>         bind()
>         connect()
>         getsockname()
>                 everything is fine up to here, it binds correctly,
> etc.
>         execs ciped
>         connect()  (in ciped.c, where it does the connect to
> AF_UNSPEC)
>                 now the socket is rebound to *:oldport, and is where
> it falls apart.
>         ...
>         connect() - the real connect w/ the peers addr, which gets set
> up a
> 10.0.0.254:z <=> x.x.x.x:y
> 
> So basically, I'm not sure if a bind() is supposed to last through a
> connect(AF_UNSPEC). But, basically, it doesn't, at least on this
> box/kernel. The server is running 2.2.19 btw. Clients running 2.4.10.
> 
> Anyway, by commenting out the "dis"connect() code in opendev(), and
> just
> letting cipe continue to do another connect() on the socket (i.e.
> instead of conn/disconn/conn, just let it do conn/conn), it has
> started
> working fine for me.
> 
> Anyway, this would likely only impact someone who's default interface
> is
> not routable to the clients. (And yes, it's a pain in the butt that
> causes other problems as well, but it's a dedicated machine that just
> does routing/vpn tasks and it needs to sit on our backbone.)
> 
> -- Nathan
> 
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nneul,AT,umr,DOT,edu
> University of Missouri - Rolla         Phone: (573) 341-4841
> Computing Services                       Fax: (573) 341-4216
> 
> --
> Message sent by the cipe-l,AT,inka,DOT,de mailing list.
> Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body
> Other commands available with "help" in body to the same address.
> CIPE info and list archive:
> <URL:http://sites.inka.de/~bigred/devel/cipe.html>

-- 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul,AT,umr,DOT,edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216





<< | Thread Index | >> ]    [ << | Date Index | >> ]