> Mike Aldred writes:
First, I must apologise, I was lazy and I didn't post my full config, etc, when
I knew I should, sorry.
I'm currently at work, and the machine with the problems is at home. Currently
everything is working ok, so I'll do the best I can at the moment.
> "Stops working" in what way?
Basically I can't connect or ping to any computer on the Internet, I'm fairly
new to Solaris so I'm unsure how to test much further than trying to ping a
known IP address.
> Are there error counts in "netstat -ni" or in "pppstats"? What about
> the non-zero values printed by "kstat sppp\*"?
I had no idea to try those. :)
At the moment here's what I've got, it's working fine at the moment. I'll try
them again when it decides that I'm not worthy of a net connection.
(IP addresses changed)
-bash-3.2$ ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
inet 127.0.0.1 netmask ff000000
e1000g0: flags=201100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4,CoS> mtu
1500 index 2
inet 10.1.1.33 netmask ff000000 broadcast 10.255.255.255
e1000g1: flags=201100842<BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4,CoS> mtu 1500
index 3
inet 0.0.0.0 netmask 0
sppp0:
flags=10011008d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,ROUTER,IPv4,FIXEDMTU>
mtu 1492 index 10
inet XXX.XXX.XXX.XXX --> YYY.YY.YY.YY netmask ff000000
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252
index 1
inet6 ::1/128
-bash-3.2$ netstat -ni
Name Mtu Net/Dest Address Ipkts Ierrs
Opkts Oerrs Collis Queue
lo0 8232 127.0.0.0 127.0.0.1 43780 0
43780 0 0 0
e1000g0 1500 10.0.0.0 10.1.1.33 7342456 0
10397463 0 0 0
e1000g1 1500 default 0.0.0.0 6722382 0
7892045 0 0 0
sppp0 1492 YYY.YY.YY.YY XXX.XXX.XXX.XXX 3915369 0 4926632 0
0 0
Name Mtu Net/Dest Address Ipkts Ierrs
Opkts Oerrs Collis
lo0 8252 ::1 ::1 43780 0
43780 0 0
-bash-3.2$ pfexec pppstats
IN PACK VJCOMP VJUNC VJERR | OUT
PACK VJCOMP VJUNC NON-VJ
1294490599 3930489 0 0 0 | 4828273110
4946176 0 0 4946176
-bash-3.2$ pfexec kstat sppp\*
module: sppp instance: 0
name: sppp0 class: net
allocbfail 0
crtime 297886.491964483
ierrors 0
ierrors_lower 0
ioctlsfwd 12
ioctlsfwderr 0
ioctlsfwdok 12
ipackets 3931856
ipackets64 3931856
ipkts_ctl 790
ipkts_qdropped 0
ipkts_runts 0
ipkts_toolong 0
lsdown 0
lsneedup 0
mctlsfwd 0
mctlsfwderr 0
mctlsknown 0
mctlsunknown 0
obytes 514950909
obytes64 4809918205
oerrors 0
oerrors_lower 0
opackets 4947875
opackets64 4947875
opkts_ctl 791
opkts_qdropped 0
opkts_runts 0
opkts_toolong 0
rbytes 1294739879
rbytes64 1294739879
snaptime 344972.336861725
> Can you do "ping -sn" on the remote IP address? If
> you do, what do you see happening to the statistics?
I will post the results when the link goes down.
> Can you snoop the underlying Ethernet link? What
> does that show before and after the failure?
I didn't know about snoop either. :/
I will get that setup and post the info when I have it.
> > Aug 12 18:13:38 storageserver pppd[1960]: [ID
> 702911 daemon.debug] rcvd [LCP EchoReq id=0x8
> magic=0x59621493 69 77 9a 10]
> > Aug 12 18:13:38 storageserver pppd[1960]: [ID
> 702911 daemon.debug] sent [LCP EchoRep id=0x8
> magic=0x69779a10 69 77 9a 10]
>
> Is this after a failure or before? If it's after,
> then it looks like there's nothing wrong with PPP itself. The problem
> is likely to be higher up -- something wrong with routing or wrong
> with the ISP itself.
Sorry, this is before the failure, best I can tell, unfortunately it's like a
toaster, it won't happen when I'm watching it, so those are just the last lines
of the log from pppd.
> > I could write a script that checks if the machine
> can ping, etc, every 5 minutes and if not, restart
> the pppd process, but there must be a reason why the
> machine isn't picking up the disconnection?
>
> I don't see a disconnect here, at least at the PPP
> level. If the peer
> is able to respond to LCP Echo-Request packets, then
> as far as anyone
> can tell, the PPP link is still "up."
>
> Do you have compression enabled? One suggestion is
> to simplify first:
> disable compression. Use "noccp novj" in your
> configuration file.
> (ISP bugs in dealing with compression are
> unfortunately not uncommon.)
>
> Failing all that, posting your configuration files
> and logs either
> here or some accessible site would help a lot in
> diagnosing possible
> problems. (Though from the symptoms, it doesn't
> immediately sound
> like a PPP problem to me.)
Here's the peer file for my ISP:
sppptun
plugin pppoe.so
connect "/usr/lib/inet/pppoec e1000g1" # dial into ISP
persist
user username # my account name at my ISP
noauth # do not authenticate the ISP's identity (client)
noipdefault # assume no IP address; get it from ISP
noccp # ISP doesn't support free compression
novj
noaccomp
nopcomp
usepeerdns
defaultroute # install default route; ISP is Internet gateway
My /etc/ppp/options file just has:
plink
And /etc/ppp/pppoe.if
e1000g1
When it fails again, I'll post the pppstats info, etc, again.
Thanks for your help, I really appreciate it.
Mike
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
[email protected]
