Subject: |
RE: long standing problem with cipe finally resolved... |
From: |
"Jan De landtsheer" <Jan.delandtsheer,AT,dct-mail,DOT,com> |
Date: |
Wed, 14 Nov 2001 16:24:58 +0100 |
Yes, I had the same problem, having ciped-cb's running properly and not
working with PKCIPE :o(
(I didn't test the removal of the disconnect() ) , I just started to
work with ciped-cb.
I was hoping some movement around pkcipe, but apparently not many people
are using it.
I too am having 2 ethernet interfaces (one outside, one inside) so the
problem can effectively be a multiple interface assignment problem, as I
did not have these problems when I used only 1 interface.
Jan
> -----Original Message-----
> From: Nathan Neulinger [mailto:nneul,AT,umr,DOT,edu
> Sent: Wednesday, November 14, 2001 1:50 PM
> To: cipe-l,AT,inka,DOT,de
> Subject: Re: long standing problem with cipe finally resolved...
>
>
> 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
>
> --
> 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>
>