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

Subject: RE: CIPE 1.46 in LRP 298
From: "Norm Woodward" <normw,AT,njwtech,DOT,com>
Date: Wed, 3 Oct 2001 23:40:15 +0200
In-reply-to: <003001c14c43$08edb340$660aa8c0@cx795926b.phnx3.az.home.com>

I got that message initially until I set the "nokey" option - even though I
made absolutely sure I had a good key.  I suspect that will be my next
problem once I solve this one...  either that or the solution to this
problem will cure both.  Thanks for the feedback.

..
Norm

-----Original Message-----
From: John Abrams [mailto:networknavigators,AT,home,DOT,com
Sent: Wednesday, October 03, 2001 12:39 PM
To: Norm Woodward
Cc: cipe-l,AT,inka,DOT,de
Subject: Re: CIPE 1.46 in LRP 298

Unfortunately I do not have a solution for you but I am experiancing the
same problem and have been frustrated with it for a while now. I have also
been getting a message     kxchg: send: invalid arguement
----- Original Message -----
From: "Norm Woodward" <normw,AT,njwtech,DOT,com>
To: <cipe-l,AT,inka,DOT,de>
Sent: Wednesday, October 03, 2001 8:51 AM
Subject: RE: CIPE 1.46 in LRP 298

> Further to this message I sent earlier - I have also discovered that there
> is a weird message that shows up in /var/log/messages that says:
>
> Oct  3 08:58:58 router kernel: cipcb1: changing my address: 2.0.0.0
>
> and when I monitor packet traffic between the two carriers there is an
> attempt
> to send udp packets from 2.0.0.0:9990 to the other carrier.  Of course
there
> is no reply sent.  This must be the root of the problem, but I can't see
why
> the daemon suddenly tries to change its address when it sends packets
> between
> the carriers.  Any ideas?
>
> ..
> Norm
>
> -----Original Message-----
> From: owner-cipe-l,AT,inka,DOT,de [mailto:owner-cipe-l,AT,inka,DOT,de 
> Behalf Of
> Norm Woodward
> Sent: Tuesday, October 02, 2001 6:02 PM
> To: cipe-l,AT,inka,DOT,de
> Subject: CIPE 1.46 in LRP 298
>
>
> I REALLY tried... honest.  I have been working this over and over for 2
> whole days and I just can't make it work.  I downloaded ciped-1.lrp for
> the 2.2.19 kernel from leaf.sourceforge.net and installed it in my 2.9.8
> LRP.  The interface appears to come up correctly, but traffic does not go
> through it (i.e. I can't ping through it).  Here is what ifconfig looks
> like:
>
> cipcb0    Link encap:IPIP Tunnel  HWaddr
>           inet addr:10.0.98.24  P-t-P:10.0.99.24  Mask:255.255.255.255
>           UP POINTOPOINT NOTRAILERS RUNNING NOARP  MTU:1442  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100
>
> The other machine is configured the same except with numbers reversed.
> Its interface acts exactly the same.  Notice there are TX packets at
> the cipcb0 interface but no RX.
>
> My options looks like this:
>
> ptpaddr         10.0.99.24
> ipaddr          10.0.98.24
> me              24.7.141.99:9990
> peer            24.7.141.186:9990
> nokey
> maxerr          -1
>
> This is what the debug info looks like:
>
> Starting ciped-cb on cipcb0 using /etc/cipe/options.cipcb0
> CIPE daemon vers 1.4.6 (c) Olaf Titz 1996-2000
> device=cipcb0
> debug=yes
> ipaddr=10.0.98.24
> ptpaddr=10.0.99.24
> mtu=0
> metric=0
> cttl=0
> me=24.7.141.99:9990
> peer=24.7.141.186:9990
> key=(none)
> nokey=yes
> socks=
> tokxc=0
> tokey=0
> ipup=(none)
> ipdown=(none)
> arg=(none)
> maxerr=-1
> tokxts=0
> ping=0
> toping=0
> dynip=no
> Using cipcb0 index 0
>
> I am running it with "nokey" option right now to
> eliminate that as a possible problem.  Here is the route table:
>
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 10.0.99.24      0.0.0.0         255.255.255.255 UH    0      0        0
> cipcb0
> 24.7.141.0      0.0.0.0         255.255.255.128 U     0      0        0
eth0
> 10.0.99.0       10.0.99.24      255.255.255.0   UG    0      0        0
> cipcb0
> 10.0.98.0       0.0.0.0         255.255.255.0   U     0      0        0
eth1
> 0.0.0.0         24.7.141.1      0.0.0.0         UG    0      0        0
eth0
>
> And yet this is what happens when I ping the other end of the tunnel:
>
> router2# ping 10.0.99.24
> PING 10.0.99.24 (10.0.99.24): 56 data bytes
>
> --- 10.0.99.24 ping statistics ---
> 7 packets transmitted, 0 packets received, 100% packet loss
>
> I have ipchains filters set to do no filtering of any kind between
> these two boxes.  I even have rules accepting packets from the
> internal network of the other router - no luck.
>
> I may have something wrong with my forwarding rules:
>
> router2# ipchains -L forward -n
> Chain forward (policy ACCEPT):
> target     prot opt     source                destination           ports
> MASQ       all  ------  10.0.98.0/24          0.0.0.0/0             n/a
>
> I sure would appreciate any ideas or any help.  I was going to monitor
> the mail list for a while to make sure I wasn't asking a completely stupid
> question, but time is becoming a factor.  Thanks for your help.
>
> ..
> Norm Woodward
>
>
> --
> 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>
>
>
> --
> 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>





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