Date: Wed, 8 Dec 1999 01:18:24 +0100 From: Juergen Lock <nox@jelal.kn-bremen.de> To: Gary Jennejohn <garyj@muc.de> Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: i4b syncppp not talking with Ascend Max (HP,4000-6000) version 6.1.3 - 6.1.7 ? Message-ID: <19991208011823.A18553@saturn.kn-bremen.de> In-Reply-To: <199912072207.XAA05730@peedub.muc.de> References: <19991207212756.A1824@saturn.kn-bremen.de> <199912072207.XAA05730@peedub.muc.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 07, 1999 at 11:07:56PM +0100, Gary Jennejohn wrote: > Juergen Lock writes: > > > >OK here you go... > > > >isp3: ipcp nak opts: address [wantaddr 212.162.0.121] <7>isp3: sppp_set_ip_ad > >dr: rtinit DEL failed, error=65 <== EHOSTUNREACH > >isp3: sppp_set_ip_addr: rtinit ADD failed, error=17[agree] <== EEXIST > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Hmm is that the problem, does that mean it is unable to add the route? > > > > Certainly looks like it. It appears that the kernel is convinced that a > route already exists. Hmm but why, my entire routing table at that time consisted of the lo0 entry and the default route to the syncppp interface... > The fact that you were still seeing 0.0.0.0 using > ethereal (as reported in your previous mail) btw that wasn't ethereal, it was an ipfw log rule. (bpf didn't get that packet as it didn't make it to the wire, it only saw the ppp packets...) > supports that. The failure > to delete can be explained by the fact that was no route there to be > deleted, I suppose. > > Unfortunately, I can't tell what happens in a normal connection because I > have static IP addresses and sppp_set_ip_addr never gets called. > > Does it work to other ISPs ? > Yep, with mobilcom or talkline for example it works. (essentially same setup, just other interfaces with different numbers and login/passwords.) At my `regluar' ISP btw i have static IPs too (and still use raw IP not syncppp for lower overhead), but during the day these `Call-by-Call' ISPs are cheaper than a local call, and that not working new one now even would be between 1800 and 2100... > >isp3: ipcp output <conf-req id=0x4 len=10 03-06-d4-a2-00-79> > >isp3: ipcp input(req-sent): <conf-req id=0x2 len=10 03-06-c3-7a-80-21> > >isp3: ipcp parse opts: address > >isp3: ipcp parse opt values: address 0.0.0.1 [ack] send conf-ack > >isp3: ipcp output <conf-ack id=0x2 len=10 03-06-c3-7a-80-21> > >isp3: ipcp input(ack-sent): <conf-ack id=0x4 len=10 03-06-d4-a2-00-79> > >isp3: ipcp tlu > >isp3: lcp close(opened) > >isp3: phase terminate > > did you bring the interface down here ? The failure in sppp_set_ip_addr > should not cause this. > Yep, sorry forgot to note that in the log. > >isp3: ipcp down(opened) > >isp3: ipcp close(starting) > >isp3: sppp_set_ip_addr: rtinit DEL failed, error=65 > >isp3: sppp_set_ip_addr: rtinit ADD failed, error=17<7>isp3: lcp output <term-r > >eq id=0x5 len=4> > > here it's trying to reinstate the old IP address in the routing table. > > >isp3: lcp input(closing): <term-ack id=0x5 len=4> > >isp3: phase dead > >isp3: lcp down(closed) > >isp3: Down event (carrier loss) > > > > So, is the problem maybe just that the local and remote addresses are on > >entirely different nets? Is that against the ppp spec? > > > > I don't know for sure, but I don't think so. Seems to me that I was getting > IP addressed which had almost no relation to the address of the router when > I was still using an ISP who assigned dynamic addresses. Well yes, thats probably not it. because... > > Unfortunately, I can't explain why adding the route fails. The routing code > is nearly impossible to understand based on cursory examination and I'm > not willing to invest the time needed to figure it out. I just tried this: # ifconfig ipr3 10.0.0.1 10.0.0.2 # ifconfig ipr3 down delete # ifconfig isp6 10.0.0.1 10.0.0.2 ifconfig: ioctl (SIOCAIFADDR): File exists # ifconfig isp6 down delete # ifconfig tun0 10.0.0.1 10.0.0.2 # ifconfig tun0 down delete There sure is something strange with the syncppp interfaces as only those seem to get the error... and btw even tho it gets the error it still does add the route at least in this (static ip) case. (as shown by netstat -r...) Confused, -- Juergen Lock <nox.foo@jelal.kn-bremen.de> (remove dot foo from address to reply) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991208011823.A18553>