syslogd and pppd

syslogd and pppd

Post by Ross Ashle » Sun, 31 Dec 1899 09:00:00



Trying to get a modem to work on a laptop, syslog isn't logging. I'm using a
ppp script that's worked before. I have the debug option turned on in the
/etc/ppp/options file and have the debug ommand line parameter in the ppp
script (hopefully that's redundant). Still, no detailed info is getting to
/var/log/messages (that's where the syslog.conf file should be putting the
pppd output). All it puts there is a message saying the script failed.

I eventually made the /dev/ttyS1 port on the laptop chmod 777 and +s, so the
script printed detailed info to the xterm that I launched it from. The
detailed info is the following;

...
LCP: timeout sending Config-Requests
Connection terminated.
Receive serial link is not 8-bit clean:
Problem: all had bit 7 set to 0

I then played with setserial, not too much playin', and I then put it right
back the way it was. The detailed pppd info is no longer echo'd to the
terminal. I'm right back where I started with no useful debug info.

So I have 2 problems; first is the logging problem and the second is the
dialup problem. Does anyone have any ideas about either problem?

--

"The secret to success is sincerity. Once you can fake that, you've got it
made."
                                        - anonymous

 
 
 

syslogd and pppd

Post by Ross Ashle » Sun, 31 Dec 1899 09:00:00


I'm answering my own post in case anyone else has this problem.

 pppd sends debug output to the LOG_LOCAL2 facility, so syslog.conf needs a
line like the following;

local2.*                /var/log/ppp-log

As for the modem, configuring the ttyS1 port with irq 0 using setserial forced
some probing for a correct interrupt request. So, using setserial like this
solved my problem;

setserial /dev/ttyS1 irq 0 port 0x02f8


> Trying to get a modem to work on a laptop, syslog isn't logging. I'm using a
> ppp script that's worked before. I have the debug option turned on in the
> /etc/ppp/options file and have the debug ommand line parameter in the ppp
> script (hopefully that's redundant). Still, no detailed info is getting to
> /var/log/messages (that's where the syslog.conf file should be putting the
> pppd output). All it puts there is a message saying the script failed.

> I eventually made the /dev/ttyS1 port on the laptop chmod 777 and +s, so the
> script printed detailed info to the xterm that I launched it from. The
> detailed info is the following;

> ...
> LCP: timeout sending Config-Requests
> Connection terminated.
> Receive serial link is not 8-bit clean:
> Problem: all had bit 7 set to 0

> I then played with setserial, not too much playin', and I then put it right
> back the way it was. The detailed pppd info is no longer echo'd to the
> terminal. I'm right back where I started with no useful debug info.

> So I have 2 problems; first is the logging problem and the second is the
> dialup problem. Does anyone have any ideas about either problem?

> --

> "The secret to success is sincerity. Once you can fake that, you've got it
> made."
>                                         - anonymous

--

"The secret to success is sincerity. Once you can fake that, you've got it
made."
                                        - anonymous

 
 
 

syslogd and pppd

Post by Bill Unr » Sun, 31 Dec 1899 09:00:00



]I'm answering my own post in case anyone else has this problem.

] pppd sends debug output to the LOG_LOCAL2 facility, so syslog.conf needs a
]line like the following;

]local2.*               /var/log/ppp-log

No. pppd sends output to the daemon facility, chat sends its to the
local2 facility. So what you want is
local2.*;daemon.*       /var/log/ppp-log
and then do killall -1 syslogd

]As for the modem, configuring the ttyS1 port with irq 0 using setserial forced
]some probing for a correct interrupt request. So, using setserial like this
]solved my problem;

]setserial /dev/ttyS1 irq 0 port 0x02f8

?? You could try auto_irq, rather than irq0. HOwever, ttyS1 is almost
certainly an onboard serial port, unless it has been disabled. Thus if
it is an internal modem you MUST disable the onboard serial port COM2
Then you could try using setserial to define the irq for Linux.
Note that this does NOT set the irq of the modem. It simply tells linux
which irq the modem is using (ie you need to know it befor hand).

Note that the error message
 Receive serial link is not 8-bit clean:
usually does not indicate a modem problem, but rather a connection
problem. The remote end answered but did not run ppp, rather it sent
back ascii text.

]> Trying to get a modem to work on a laptop, syslog isn't logging. I'm using a
]> ppp script that's worked before. I have the debug option turned on in the
]> /etc/ppp/options file and have the debug ommand line parameter in the ppp
]> script (hopefully that's redundant). Still, no detailed info is getting to
]> /var/log/messages (that's where the syslog.conf file should be putting the
]> pppd output). All it puts there is a message saying the script failed.
]>
]> I eventually made the /dev/ttyS1 port on the laptop chmod 777 and +s, so the
]> script printed detailed info to the xterm that I launched it from. The
]> detailed info is the following;
]>
]> ...
]> LCP: timeout sending Config-Requests
]> Connection terminated.
]> Receive serial link is not 8-bit clean:
]> Problem: all had bit 7 set to 0
]>
]> I then played with setserial, not too much playin', and I then put it right
]> back the way it was. The detailed pppd info is no longer echo'd to the
]> terminal. I'm right back where I started with no useful debug info.
]>
]> So I have 2 problems; first is the logging problem and the second is the
]> dialup problem. Does anyone have any ideas about either problem?

 
 
 

syslogd and pppd

Post by Ross Ashle » Sun, 31 Dec 1899 09:00:00



> ] pppd sends debug output to the LOG_LOCAL2 facility, so syslog.conf needs a
> ]line like the following;

> ]local2.*          /var/log/ppp-log

> No. pppd sends output to the daemon facility, chat sends its to the
> local2 facility. So what you want is
> local2.*;daemon.*  /var/log/ppp-log

I'm using the Suse 6.4 dist. This is a portion of the /etc/ppp/options file.

# Increase debugging level (same as -d). The debug output is written
# to syslog LOG_LOCAL2.
debug

Quote:> and then do killall -1 syslogd

Another way to send SIGHUP is;

kill -HUP `/var/run/syslogd.pid`

either way it forces syslogd to reread it's config file.

Quote:> ]setserial /dev/ttyS1 irq 0 port 0x02f8

> ?? You could try auto_irq, rather than irq0. HOwever, ttyS1 is almost
> certainly an onboard serial port, unless it has been disabled. Thus if
> it is an internal modem you MUST disable the onboard serial port COM2
> Then you could try using setserial to define the irq for Linux.
> Note that this does NOT set the irq of the modem. It simply tells linux
> which irq the modem is using (ie you need to know it befor hand).

I did try the auto_irq option with no luck. I didn't get anywhere until I used
the setserial command above.

Quote:> Note that the error message
>  Receive serial link is not 8-bit clean:
> usually does not indicate a modem problem, but rather a connection
> problem. The remote end answered but did not run ppp, rather it sent
> back ascii text.

Using irq 4 on ttyS1, I was able to get the modem to dial, the remote end
probably was sending reasonable LCP frames, but I think I had interrupt
problems that prevented correct interpretation of them.

With that serserial command and no changes to my dialin script, I'm logged in
with no problems.

Thanks for your help.

--

"The secret to success is sincerity. Once you can fake that, you've got it
made."
                                        - anonymous

 
 
 

syslogd and pppd

Post by Bill Unr » Fri, 29 Sep 2000 13:28:34



]> ] pppd sends debug output to the LOG_LOCAL2 facility, so syslog.conf needs a
]> ]line like the following;
]>
]> ]local2.*         /var/log/ppp-log
]>
]> No. pppd sends output to the daemon facility, chat sends its to the
]> local2 facility. So what you want is
]> local2.*;daemon.* /var/log/ppp-log

]I'm using the Suse 6.4 dist. This is a portion of the /etc/ppp/options file.

]# Increase debugging level (same as -d). The debug output is written
]# to syslog LOG_LOCAL2.
]debug

Well eitehr they  are wrong or they have altered pppd from what ANU, the
writers of pppd actually use. I have not used suse, so do not know which
of those two has happened.

]> and then do killall -1 syslogd

]Another way to send SIGHUP is;

]kill -HUP `/var/run/syslogd.pid`

I think you want
kill -HUP ` cat /var/run/syslogd.pid`  

I find killall easier. Your milage may vary.

]either way it forces syslogd to reread it's config file.

]> ]setserial /dev/ttyS1 irq 0 port 0x02f8
]>
]> ?? You could try auto_irq, rather than irq0. HOwever, ttyS1 is almost
]> certainly an onboard serial port, unless it has been disabled. Thus if
]> it is an internal modem you MUST disable the onboard serial port COM2
]> Then you could try using setserial to define the irq for Linux.
]> Note that this does NOT set the irq of the modem. It simply tells linux
]> which irq the modem is using (ie you need to know it befor hand).

]I did try the auto_irq option with no luck. I didn't get anywhere until I used
]the setserial command above.

Maybe SUSE again trying to "improve" on the Linux everone else uses?
I do not know athat the irq 0 is supposed to mean or do, not why you are
using modem on a standard serial port.

]> Note that the error message
]>  Receive serial link is not 8-bit clean:
]> usually does not indicate a modem problem, but rather a connection
]> problem. The remote end answered but did not run ppp, rather it sent
]> back ascii text.

]Using irq 4 on ttyS1, I was able to get the modem to dial, the remote end
]probably was sending reasonable LCP frames, but I think I had interrupt
]problems that prevented correct interpretation of them.

iThe standard characteristic of bad irq is that during the chat script
the responses take of order 20 sec to come back-- looking in the log
file for the local2 facility.

]With that serserial command and no changes to my dialin script, I'm logged in
]with no problems.

Good. However, you must have a very strange and unusual setup.