[opensuse] DSL always on possible?
I have a DSL connected server running with openSUSE 13.1. This server has an on-demand DSL connection which should be "always on" because I use the server from outside (using Dyndns). In /etc/sysconfig/network/providers/provider0 there is ASKPASSWORD='no' AUTODNS='yes' DEMAND='yes' DSLSUPPORTED='yes' IDLETIME='1500' ISDNSUPPORTED='no' MODEMSUPPORTED='no' MODIFYDNS='no' PASSWORD='secret' PHONE='' PROVIDER='A Provider' USERNAME='username' DEFAULTROUTE='yes' IPADDR='' MODIFYIP='yes' REMOTE_IPADDR='' AUTO_RECONNECT='yes' My problem is, that I need a nearly useless service ('ping' or 'fetchmail' for instance) which starts network requests regularly so that the DSL connection starts and stays alive. Is there a recommended way to start DSL without any network request, so that it's nearly always on? In openSUSE documentation I only found two alternatives: always-on and manually. Both are not ideal. (I know, that the provider breaks the connection every 24 hours. The router should reconnect then.) Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2015 08:01 AM, Bjoern Voigt wrote:
Is there a recommended way to start DSL without any network request, so that it's nearly always on? In openSUSE documentation I only found two alternatives: always-on and manually. Both are not ideal. (I know, that the provider breaks the connection every 24 hours. The router should reconnect then.)
It sounds like you will have to generate traffic occasionally. If the ISP is killing the connection, there's nothing else that will work. I'd say a ping every hour or so should do the trick. That won't cost much performance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-09 14:12, James Knott wrote:
On 01/09/2015 08:01 AM, Bjoern Voigt wrote:
Is there a recommended way to start DSL without any network request, so that it's nearly always on? In openSUSE documentation I only found two alternatives: always-on and manually. Both are not ideal. (I know, that the provider breaks the connection every 24 hours. The router should reconnect then.)
It sounds like you will have to generate traffic occasionally. If the ISP is killing the connection, there's nothing else that will work. I'd say a ping every hour or so should do the trick. That won't cost much performance.
It should be possible to configure the network for always on, and reconnect automatically when it does, instantly. Routers do. Maybe IDLETIME 0 or -1, just a very wild guess. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 01/09/2015 08:50 AM, Carlos E. R. wrote:
On 2015-01-09 14:12, James Knott wrote:
Is there a recommended way to start DSL without any network request, so that it's nearly always on? In openSUSE documentation I only found two alternatives: always-on and manually. Both are not ideal. (I know, that the provider breaks the connection every 24 hours. The router should reconnect then.) It sounds like you will have to generate traffic occasionally. If the ISP is killing the connection, there's nothing else that will work. I'd say a ping every hour or so should do the trick. That won't cost much
On 01/09/2015 08:01 AM, Bjoern Voigt wrote: performance. It should be possible to configure the network for always on, and reconnect automatically when it does, instantly. Routers do.
Maybe IDLETIME 0 or -1, just a very wild guess.
Where is the disconnect occurring? At the server or ADSL modem? If the ISP shuts down the connection to the modem. the server might not know about it. Another keep alive might be to do DHCP requests. That's simple enough to do. The dhcpcd -l option can be used to set a lease time independent of the server. So, if set to 3600 seconds, it would make a request every hour. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-09 16:26, James Knott wrote:
On 01/09/2015 08:50 AM, Carlos E. R. wrote:
Where is the disconnect occurring? At the server or ADSL modem? If the ISP shuts down the connection to the modem. the server might not know about it.
I'm almost sure that the adsl modem tells the controlling software of any status change, such as the connection going down and the cause.
Another keep alive might be to do DHCP requests. That's simple enough to do. The dhcpcd -l option can be used to set a lease time independent of the server. So, if set to 3600 seconds, it would make a request every hour.
which is one hour (top) that the server is unreachable. If the network daemon can not be told to keep the connection alive no matter what, then you have to run a ping daemon or a host query or anything, perhaps every minute. And that's a kludge. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 01/09/2015 11:58 AM, Carlos E. R. wrote:
On 2015-01-09 16:26, James Knott wrote:
On 01/09/2015 08:50 AM, Carlos E. R. wrote:
Where is the disconnect occurring? At the server or ADSL modem? If the ISP shuts down the connection to the modem. the server might not know about it. I'm almost sure that the adsl modem tells the controlling software of any status change, such as the connection going down and the cause.
Most ADSL connections are connected via Ethernet. There is no such signal on Ethernet.
Another keep alive might be to do DHCP requests. That's simple enough to do. The dhcpcd -l option can be used to set a lease time independent of the server. So, if set to 3600 seconds, it would make a request every hour. which is one hour (top) that the server is unreachable.
My understanding is that the link drops if inactive after a while. If so, then periodic traffic will keep the link up, so long as something is sent before it drops. The OP already mentioned pings or fetchmail as a way to do that. If the DHCP requests are sufficient, then a minor editing of the line DHCLIENT_LEASE_TIME="" in /etc/sysconfig/network/dhcp and restarting dhcpcd is all that's required. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 01/09/2015 11:58 AM, Carlos E. R. wrote:
On 2015-01-09 16:26, James Knott wrote:
On 01/09/2015 08:50 AM, Carlos E. R. wrote:
Where is the disconnect occurring? At the server or ADSL modem? If the ISP shuts down the connection to the modem. the server might not know about it. I'm almost sure that the adsl modem tells the controlling software of any status change, such as the connection going down and the cause.
Most ADSL connections are connected via Ethernet. There is no such signal on Ethernet.
Back when we had ADSL, the mode/router sent log messages and snmp traps when the connectrion went up and down. -- Per Jessen, Zürich (11.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2015 02:03 PM, Per Jessen wrote:
James Knott wrote:
On 01/09/2015 11:58 AM, Carlos E. R. wrote:
On 2015-01-09 16:26, James Knott wrote:
On 01/09/2015 08:50 AM, Carlos E. R. wrote: Where is the disconnect occurring? At the server or ADSL modem? If the ISP shuts down the connection to the modem. the server might not know about it. I'm almost sure that the adsl modem tells the controlling software of any status change, such as the connection going down and the cause. Most ADSL connections are connected via Ethernet. There is no such signal on Ethernet. Back when we had ADSL, the mode/router sent log messages and snmp traps when the connectrion went up and down.
Well, that's one possibility, assuming the OPs modem does the same. However, I have looked at ADSL connections with Wireshark and don't recall seeing SNMP or syslog traffic. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 01/09/2015 02:03 PM, Per Jessen wrote:
James Knott wrote:
On 2015-01-09 16:26, James Knott wrote:
On 01/09/2015 08:50 AM, Carlos E. R. wrote: Where is the disconnect occurring? At the server or ADSL modem? If the ISP shuts down the connection to the modem. the server might not know about it. I'm almost sure that the adsl modem tells the controlling software of any status change, such as the connection going down and the cause. Most ADSL connections are connected via Ethernet. There is no such signal on Ethernet. Back when we had ADSL, the mode/router sent log messages and snmp
On 01/09/2015 11:58 AM, Carlos E. R. wrote: traps when the connectrion went up and down.
Well, that's one possibility, assuming the OPs modem does the same. However, I have looked at ADSL connections with Wireshark and don't recall seeing SNMP or syslog traffic.
It wouldn't be on the ADSL side, it would be on the ethernet side. -- Per Jessen, Zürich (11.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2015 03:36 PM, Per Jessen wrote:
It wouldn't be on the ADSL side, it would be on the ethernet side.
That's where I was looking. I have often used Wireshark on a lot of systems, to see just what's happening. If the modem is sending SMTP or syslog traffic intended for the user, then it would have to be on the Ethernet port. On the other hand, if it was intended only for the ISP, as is likely, then it wouldn't be seen on the Ethernet side. If the OP is to use either to determine if the link is down, then it has to appear at the Ethernet port in order for him to do something with it. Incidentally, I have often looked at the cable modem traffic and seen ICMP & ARP traffic that had nothing to do with my equipment. I haven't seen anyone else's traffic though. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 01/09/2015 03:36 PM, Per Jessen wrote:
It wouldn't be on the ADSL side, it would be on the ethernet side.
That's where I was looking. I have often used Wireshark on a lot of systems, to see just what's happening. If the modem is sending SMTP or syslog traffic intended for the user, then it would have to be on the Ethernet port.
Both would need to be enabled - SNMP traps and syslog both need a target host. -- Per Jessen, Zürich (15.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/10/2015 01:42 PM, Carlos E. R. wrote:
On 2015-01-10 18:38, Per Jessen wrote:
Both would need to be enabled - SNMP traps and syslog both need a target host. What can be used to capture and display snmp events?
Check out SNMP in Yast Software Management. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-10 21:57, James Knott wrote:
On 01/10/2015 01:42 PM, Carlos E. R. wrote:
On 2015-01-10 18:38, Per Jessen wrote:
Both would need to be enabled - SNMP traps and syslog both need a target host. What can be used to capture and display snmp events?
Check out SNMP in Yast Software Management.
I did, some time ago, and played a bit with it, but it was complicated. Nothing plug and play. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2015-01-10 21:57, James Knott wrote:
On 01/10/2015 01:42 PM, Carlos E. R. wrote:
On 2015-01-10 18:38, Per Jessen wrote:
Both would need to be enabled - SNMP traps and syslog both need a target host. What can be used to capture and display snmp events?
Check out SNMP in Yast Software Management.
I did, some time ago, and played a bit with it, but it was complicated. Nothing plug and play.
SNMP is not really for the home user. Nor for the small office. Software to receive SNMP traps - snmptrapd (basic, must be scripted), nagios. There are of course commercial solutions out there, mostly enterprise level (BMC Patrol, IBM Netview/Tivoli, etcetera). If you want to play and learn about the possibilities, snmptrapd is a good place to start. I wouldn't call it plug&play though. -- Per Jessen, Zürich (5.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-11 11:15, Per Jessen wrote:
Carlos E. R. wrote:
I did, some time ago, and played a bit with it, but it was complicated. Nothing plug and play.
SNMP is not really for the home user. Nor for the small office.
But home adsl-routers often have snmp capabilities.
Software to receive SNMP traps - snmptrapd (basic, must be scripted), nagios. There are of course commercial solutions out there, mostly enterprise level (BMC Patrol, IBM Netview/Tivoli, etcetera).
If you want to play and learn about the possibilities, snmptrapd is a good place to start. I wouldn't call it plug&play though.
Mmm. Could snmptrapd be used to simply write what it gets to a text file, so that I can look and find out if there is anything interesting there? I found <http://www.net-snmp.org/wiki/index.php/TUT:Configuring_snmptrapd>. I'll have a look. I also wanted to have a look at cacti, but it seems complicated to set up. There is a wiki page on that at opensuse.org -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2015-01-11 11:15, Per Jessen wrote:
Carlos E. R. wrote:
I did, some time ago, and played a bit with it, but it was complicated. Nothing plug and play.
SNMP is not really for the home user. Nor for the small office.
But home adsl-routers often have snmp capabilities.
Quite likely because their software and interface is also used in more enterprise level products.
Could snmptrapd be used to simply write what it gets to a text file, so that I can look and find out if there is anything interesting there?
Yep, absolutely. In /etc/snmp/snmptrapd.conf you specify which script should be called for which trap, e.g.: traphandle IF-MIB::linkUp <script> <arguments> traphandle IF-MIB::linkDown <script> <arguments> traphandle default <script-to-write-to-log> To have traps sent from other Linux boxes, install net-snmp and put "trapsink <your snmptrapd machine>" in /etc/snmp/snmpd.conf. -- Per Jessen, Zürich (3.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-12 08:28, Per Jessen wrote:
Carlos E. R. wrote:
Could snmptrapd be used to simply write what it gets to a text file, so that I can look and find out if there is anything interesting there?
Yep, absolutely. In /etc/snmp/snmptrapd.conf you specify which script should be called for which trap, e.g.:
traphandle IF-MIB::linkUp <script> <arguments> traphandle IF-MIB::linkDown <script> <arguments>
traphandle default <script-to-write-to-log>
To have traps sent from other Linux boxes, install net-snmp and put "trapsink <your snmptrapd machine>" in /etc/snmp/snmpd.conf.
I simply have: authCommunity log,execute,net public authCommunity log,execute,net private I thought that would write things to the log. The log is created (/var/log/net-snmpd.log) but is empty. I noticed a packet coming, I saw it on the firewall log. I can't write a script to handle writing myself to the log if I absolutely have no idea what script to write or what is coming (I have no idea what the router sends, it is not documented at all)... I thought that the daemon would do the logging itself. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Mon, Jan 12, 2015 at 3:54 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2015-01-12 08:28, Per Jessen wrote:
Carlos E. R. wrote:
Could snmptrapd be used to simply write what it gets to a text file, so that I can look and find out if there is anything interesting there?
Yep, absolutely. In /etc/snmp/snmptrapd.conf you specify which script should be called for which trap, e.g.:
traphandle IF-MIB::linkUp <script> <arguments> traphandle IF-MIB::linkDown <script> <arguments>
traphandle default <script-to-write-to-log>
To have traps sent from other Linux boxes, install net-snmp and put "trapsink <your snmptrapd machine>" in /etc/snmp/snmpd.conf.
I simply have:
authCommunity log,execute,net public authCommunity log,execute,net private
I thought that would write things to the log.
No, it simply enables snmptrapd to perform selected actions for selected community strings. How exactly it performs these actions is defined by other options.
The log is created (/var/log/net-snmpd.log) but is empty. I noticed a packet coming, I saw it on the firewall log.
Yes, my experience with net-snmp is that it logs not that much by default. You may need to tweak logging options. But I must admit configuring net-snmp is not for the faint of heart ... :)
I can't write a script to handle writing myself to the log if I absolutely have no idea what script to write or what is coming (I have no idea what the router sends, it is not documented at all)... I thought that the daemon would do the logging itself.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-12 14:13, Andrei Borzenkov wrote:
On Mon, Jan 12, 2015 at 3:54 PM, Carlos E. R. <> wrote:
I simply have:
authCommunity log,execute,net public authCommunity log,execute,net private
I thought that would write things to the log.
No, it simply enables snmptrapd to perform selected actions for selected community strings. How exactly it performs these actions is defined by other options.
As I have no idea what strings the router may send (the documentation doesn't say), I can't write any action.
The log is created (/var/log/net-snmpd.log) but is empty. I noticed a packet coming, I saw it on the firewall log.
Yes, my experience with net-snmp is that it logs not that much by default. You may need to tweak logging options. But I must admit configuring net-snmp is not for the faint of heart ... :)
It logs nothing... I got that configuration from the "tutorial" here: http://www.net-snmp.org/wiki/index.php/TUT:Configuring_snmptrapd where it says "By default, it will simply log all incoming notifications via syslog." But it does not, apparently. Or the router is not sending things, despite the hit on the firewall log. So I try sending things from one computer to another, but I can't. The tutorial suggests: snmptrap -v 1 -c public host UCD-TRAP-TEST-MIB::demotraps "" 6 17 "" \ SNMPv2-MIB::sysLocation.0 s "Just here" I try that, verbatim:
Telcontar:~ # snmptrap -v 1 -c public host UCD-TRAP-TEST-MIB::demotraps "" 6 17 "" SNMPv2-MIB::sysLocation.0 s "Just here" getaddrinfo: host Name or service not known getaddrinfo("host", NULL, ...): Name or service not known snmptrap: Telcontar:~ #
Ok, it needs a hostname, obviously. So I type it:
Telcontar:~ # snmptrap -v 1 -c public amonLanc.valinor UCD-TRAP-TEST-MIB::demotraps "" 6 17 "" SNMPv2-MIB::sysLocation.0 s "Just here" MIB search path: /root/.snmp/mibs:/usr/share/snmp/mibs Cannot find module (UCD-TRAP-TEST-MIB): At line 0 in (none) UCD-TRAP-TEST-MIB::demotraps: Unknown Object Identifier USAGE: snmptrap [OPTIONS] AGENT TRAP-PARAMETERS
Version: 5.7.2 Web: http://www.net-snmp.org/
or the other example:
Telcontar:~ # snmptrap -v 2c -c public amonLanc.valinor "" UCD-NOTIFICATION-TEST-MIB::demoNotif SNMPv2-MIB::sysLocation.0 s "Just here" MIB search path: /root/.snmp/mibs:/usr/share/snmp/mibs Cannot find module (UCD-NOTIFICATION-TEST-MIB): At line 0 in (none) UCD-NOTIFICATION-TEST-MIB::demoNotif: Unknown Object Identifier Telcontar:~ #
So the tutorial is useless. :-/ (the tutorial example logs are dated "1999-11-12", so they are a decade and a half old) Ok, at <http://www.net-snmp.org/wiki/index.php/TUT:snmptrap#SNMPv1_Traps" it says that the example will not work on SUSE because it needs extra things. Instead try this:
Telcontar:~ # snmptrap -v 1 -c public amonLanc.valinor NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification "" 6 17 "" netSnmpExampleHeartbeatRate i 123456 Telcontar:~ #
which at least doesn't produce an error. First attempt is blocked by the destination firewall, so I correct that, repeat, and still nothing is logged:
AmonLanc:~ # l /var/log/net-snmpd.log -rw-r--r-- 1 root root 0 Jan 11 17:59 /var/log/net-snmpd.log AmonLanc:~ #
AmonLanc:~ # rcsnmptrapd status Checking for service snmptrapd: running snmptrapd.service - LSB: Receive and log SNMP trap messages Loaded: loaded (/etc/init.d/snmptrapd) Active: active (running) since Mon 2015-01-12 13:46:52 CET; 1h 53min ago CGroup: /system.slice/snmptrapd.service └─4580 /usr/sbin/snmptrapd -A -LF n /var/log/net-snmpd.log -p /var/run/snmptrapd.pid
AmonLanc:~ #
Still, nothing is logged at the destination. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2015-01-12 14:13, Andrei Borzenkov wrote:
On Mon, Jan 12, 2015 at 3:54 PM, Carlos E. R. <> wrote:
I simply have:
authCommunity log,execute,net public authCommunity log,execute,net private
I thought that would write things to the log.
No, it simply enables snmptrapd to perform selected actions for selected community strings. How exactly it performs these actions is defined by other options.
As I have no idea what strings the router may send (the documentation doesn't say), I can't write any action.
Sure you can - just use the default to log everything. A traphandler called by snmptrapd is given four lines on stdin: hostname ipaddress oid1 value1 oid2 value2 See "man snmptrapd.conf", section "traphandle". net-snmp also comes with sample scripts etc.
Or the router is not sending things, despite the hit on the firewall log.
You have configured the router where to send the snmp traps? There might also be settings wrt which traps to send. "tcpdump -p 162" might also show you the traps.
(the tutorial example logs are dated "1999-11-12", so they are a decade and a half old)
SNMP is not a rapidly changing topic. Also, like Andrei said, configuring an snmp setup is not for the faint of heart. It is not overly user-friendly. I can't help with the logging, I've never bothered setting it up. Our SNMP monitor writes everything to a database. -- Per Jessen, Zürich (5.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Mon, 12 Jan 2015 15:46:36 +0100 "Carlos E. R." <robin.listas@telefonica.net> пишет:
On 2015-01-12 14:13, Andrei Borzenkov wrote:
On Mon, Jan 12, 2015 at 3:54 PM, Carlos E. R. <> wrote:
I simply have:
authCommunity log,execute,net public authCommunity log,execute,net private
I thought that would write things to the log.
No, it simply enables snmptrapd to perform selected actions for selected community strings. How exactly it performs these actions is defined by other options.
As I have no idea what strings the router may send (the documentation doesn't say), I can't write any action.
"action" includes logging here.
The log is created (/var/log/net-snmpd.log) but is empty. I noticed a packet coming, I saw it on the firewall log.
Yes, my experience with net-snmp is that it logs not that much by default. You may need to tweak logging options. But I must admit configuring net-snmp is not for the faint of heart ... :)
It logs nothing...
I got that configuration from the "tutorial" here:
http://www.net-snmp.org/wiki/index.php/TUT:Configuring_snmptrapd
where it says "By default, it will simply log all incoming notifications via syslog."
But it does not, apparently.
It does but see below.
└─4580 /usr/sbin/snmptrapd -A -LF n /var/log/net-snmpd.log -p /var/run/snmptrapd.pid
-LF n will limit output to messages of notice or higher priority and apparently snmptrapd logs incoming traps at info priority. Of course it is not documented anywhere.
On 2015-01-12 21:20, Andrei Borzenkov wrote:
В Mon, 12 Jan 2015 15:46:36 +0100 "Carlos E. R." <> пишет:
But it does not, apparently.
It does but see below.
└─4580 /usr/sbin/snmptrapd -A -LF n /var/log/net-snmpd.log -p /var/run/snmptrapd.pid
-LF n will limit output to messages of notice or higher priority and apparently snmptrapd logs incoming traps at info priority. Of course it is not documented anywhere.
The trick is in "/etc/sysconfig/net-snmp": ## Path: System/Net-SNMP ## Description: Log level of the snmp server. ## Type: string(!,a,c,e,w,n,i,d,0,1,2,3,4,5,6,7) ## Default: n # # Defines the log level for snmpd. # # The default is "n" (5, LOG_NOTICE) # SNMPD_LOGLEVEL="7" Change the default "n" to "7". It is probably the same as "d". The relevant section of the manual seems to be this: -L[efos] Specify where logging output should be directed (standard error or output, to a file or via syslog). See LOGGING OPTIONS in snmpcmd(1) for details. and LOGGING OPTIONS The mechanism and destination to use for logging of warning and error messages can be controlled by passing various parame- ters to the -L flag. -Le Log messages to the standard error stream. -Lf FILE Log messages to the specified file. -Lo Log messages to the standard output stream. -Ls FACILITY Log messages via syslog, using the specified facility ('d' for LOG_DAEMON, 'u' for LOG_USER, or '0'-'7' for LOG_LOCAL0 through LOG_LOCAL7). There are also "upper case" versions of each of these options, which allow the corresponding logging mechanism to be restricted to certain priorities of mes- sage. Using standard error logging as an example: -LE pri will log messages of priority 'pri' and above to standard error. -LE p1-p2 will log messages with priority between 'p1' and 'p2' (inclusive) to standard error. For -LF and -LS the priority specification comes before the file or facility token. The priorities recognised are: 0 or ! for LOG_EMERG, 1 or a for LOG_ALERT, 2 or c for LOG_CRIT, 3 or e for LOG_ERR, 4 or w for LOG_WARNING, 5 or n for LOG_NOTICE, 6 or i for LOG_INFO, and 7 or d for LOG_DEBUG. Normal output is (or will be!) logged at a priority level of LOG_NOTICE The default command line is: /usr/sbin/snmptrapd -A -LF n /var/log/net-snmpd.log \ -p /var/run/snmptrapd.pid The manual explains -Lf, but not -LF. From my tests, Lf seems to be a pipe, LF a file. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
В Tue, 13 Jan 2015 16:34:47 +0100 "Carlos E. R." <robin.listas@telefonica.net> пишет:
-Lf FILE Log messages to the specified file.
...
There are also "upper case" versions of
^^^^^^^^^^^^^^^^^^^^^
each of these options, which allow the corresponding logging mechanism to be restricted to certain priorities of mes- sage.
...
For -LF and -LS the priority specification
^^^^^^^
comes before the file or facility token. The priorities recognised are:
0 or ! for LOG_EMERG, 1 or a for LOG_ALERT, 2 or c for LOG_CRIT, 3 or e for LOG_ERR, 4 or w for LOG_WARNING, 5 or n for LOG_NOTICE, 6 or i for LOG_INFO, and 7 or d for LOG_DEBUG.
...
The manual explains -Lf, but not -LF.
I would not call the part you yourself quoted "does not explain". What is missing then?
From my tests, Lf seems to be a pipe, LF a file.
Both are file as explained above in manual.
On 2015-01-13 17:21, Andrei Borzenkov wrote:
В Tue, 13 Jan 2015 16:34:47 +0100 "Carlos E. R." <> пишет:
...
The manual explains -Lf, but not -LF.
I would not call the part you yourself quoted "does not explain". What is missing then?
A separate paragraph for -LF and -Lf, for instance. The wording is not clear: perhaps you understand it, but I don't.
From my tests, Lf seems to be a pipe, LF a file.
Both are file as explained above in manual.
No, with -Lf I get a pipe or something, not a file - see the "=" at the end: AmonLanc:~ # l /var/log/net-snmpd.log srwxr-xr-x 1 root root 0 Jan 13 15:57 /var/log/net-snmpd.log= AmonLanc:~ # The result is that I can not even try to read it: AmonLanc:~ # less /var/log/net-snmpd.log /var/log/net-snmpd.log is not a regular file (use -f to see it) AmonLanc:~ # less -f /var/log/net-snmpd.log /var/log/net-snmpd.log: No such device or address AmonLanc:~ # -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
В Tue, 13 Jan 2015 17:41:13 +0100 "Carlos E. R." <robin.listas@telefonica.net> пишет:
On 2015-01-13 17:21, Andrei Borzenkov wrote:
В Tue, 13 Jan 2015 16:34:47 +0100 "Carlos E. R." <> пишет:
...
The manual explains -Lf, but not -LF.
I would not call the part you yourself quoted "does not explain". What is missing then?
A separate paragraph for -LF and -Lf, for instance. The wording is not clear: perhaps you understand it, but I don't.
From my tests, Lf seems to be a pipe, LF a file.
Both are file as explained above in manual.
No, with -Lf I get a pipe or something, not a file - see the "=" at the end:
Because syntax is wrong. As written in manual, difference between Lf and LF (or small and capital form in general) is extra argument that sets priority. So in -Lf n /var/log/net-snmpd.log "-Lf n" is log file option (may be you have file with name "n" somewhere now) and /var/log/net-snmpd.log is interpreted as normal argument which is "listening address". So snmptrapd simply attempts to listen on it; because it looks like file name, it is interpreted as Unix domain socket. "-Lf /path/to/file" vs. "-LF <prio> /path/to/file" I said it was not for the faint of heart, did I? :)
AmonLanc:~ # l /var/log/net-snmpd.log srwxr-xr-x 1 root root 0 Jan 13 15:57 /var/log/net-snmpd.log= AmonLanc:~ #
The result is that I can not even try to read it:
AmonLanc:~ # less /var/log/net-snmpd.log /var/log/net-snmpd.log is not a regular file (use -f to see it) AmonLanc:~ # less -f /var/log/net-snmpd.log /var/log/net-snmpd.log: No such device or address AmonLanc:~ #
On 2015-01-13 19:31, Andrei Borzenkov wrote:
В Tue, 13 Jan 2015 17:41:13 +0100 "Carlos E. R." <> пишет:
Because syntax is wrong. As written in manual, difference between Lf and LF (or small and capital form in general) is extra argument that sets priority. So in
-Lf n /var/log/net-snmpd.log
"-Lf n" is log file option (may be you have file with name "n" somewhere now) and /var/log/net-snmpd.log is interpreted as normal argument which is "listening address". So snmptrapd simply attempts to listen on it; because it looks like file name, it is interpreted as Unix domain socket.
LOL.
"-Lf /path/to/file" vs. "-LF <prio> /path/to/file"
I said it was not for the faint of heart, did I? :)
Yes, you did. But I do have an snmp log now, I got it working. It was actually very easy, just replace an "n" with a "7" in "/etc/sysconfig/net-snmp" (to increase log level verbosity) and restart the daemon. Whether I go further than this or not, I don't know. I'll just keep the daemon listening to find out what the router sends. So far, just a hello world. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
AmonLanc:~ # rcsnmptrapd status Checking for service snmptrapd: running snmptrapd.service - LSB: Receive and log SNMP trap messages Loaded: loaded (/etc/init.d/snmptrapd) Active: active (running) since Mon 2015-01-12 13:46:52 CET; 1h 53min ago CGroup: /system.slice/snmptrapd.service └─4580 /usr/sbin/snmptrapd -A -LF n /var/log/net-snmpd.log -p /var/run/snmptrapd.pid
This is what I used when I was playing with snmptrapd: snmptrapd -A -Lf /var/log/snmptraps -- Per Jessen, Zürich (2.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-13 08:28, Per Jessen wrote:
Carlos E. R. wrote:
AmonLanc:~ # rcsnmptrapd status Checking for service snmptrapd: running snmptrapd.service - LSB: Receive and log SNMP trap messages Loaded: loaded (/etc/init.d/snmptrapd) Active: active (running) since Mon 2015-01-12 13:46:52 CET; 1h 53min ago CGroup: /system.slice/snmptrapd.service └─4580 /usr/sbin/snmptrapd -A -LF n /var/log/net-snmpd.log -p /var/run/snmptrapd.pid
This is what I used when I was playing with snmptrapd:
snmptrapd -A -Lf /var/log/snmptraps
Well... I changed that, and restarted the service: case "$1" in start) echo -n "Starting snmptrapd: " # startproc $SNMPTRAPD $SNMPTRAPD_CONF -A -LF ${SNMPD_LOGLEVEL:-n} $SNMPTRAPD_LOGFILE -p $SNMPTRAPD_PID #CER startproc $SNMPTRAPD $SNMPTRAPD_CONF -A -Lf ${SNMPD_LOGLEVEL:-n} $SNMPTRAPD_LOGFILE -p $SNMPTRAPD_PID rc_status -v ;; stop) AmonLanc:~ # systemctl status snmptrapd snmptrapd.service - LSB: Receive and log SNMP trap messages Loaded: loaded (/etc/init.d/snmptrapd) Active: active (running) since Tue 2015-01-13 15:57:00 CET; 2s ago Process: 27208 ExecStop=/etc/init.d/snmptrapd stop (code=exited, status=0/SUCCESS) Process: 27217 ExecStart=/etc/init.d/snmptrapd start (code=exited, status=0/SUCCESS) CGroup: /system.slice/snmptrapd.service └─27225 /usr/sbin/snmptrapd -A -Lf n /var/log/net-snmpd.log -p /var/run/snmptrapd.pid Jan 13 15:57:00 AmonLanc snmptrapd[27217]: Starting snmptrapd: ..done Jan 13 15:57:00 AmonLanc systemd[1]: Started LSB: Receive and log SNMP trap messages. AmonLanc:~ # The log changes: AmonLanc:~ # l /var/log/net-snmpd.log srwxr-xr-x 1 root root 0 Jan 13 15:57 /var/log/net-snmpd.log= AmonLanc:~ # The result is that I can not even try to read it: AmonLanc:~ # less /var/log/net-snmpd.log /var/log/net-snmpd.log is not a regular file (use -f to see it) AmonLanc:~ # less -f /var/log/net-snmpd.log /var/log/net-snmpd.log: No such device or address AmonLanc:~ # I use this to send traps from another machine (taken from the tutorial): Telcontar:~ # snmptrap -v 1 -c public amonLanc.valinor NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification "" 6 17 "" netSnmpExampleHeartbeatRate i 123456 Telcontar:~ # So I reverted the change. Then I edited "/etc/sysconfig/net-snmp": ## Path: System/Net-SNMP ## Description: Log level of the snmp server. ## Type: string(!,a,c,e,w,n,i,d,0,1,2,3,4,5,6,7) ## Default: n # # Defines the log level for snmpd. # # The default is "n" (5, LOG_NOTICE) # SNMPD_LOGLEVEL="a" Then I sent a "trap" and I got a single byte in /var/log/net-snmpd.log: AmonLanc:~ # hexdump -C /var/log/net-snmpd.log 00000000 0a |.| 00000001 AmonLanc:~ # But repeating the send doesn't produce another. Then I changed the value in "/etc/sysconfig/net-snmp" to "7", and finally I get entries in the log! AmonLanc:~ # cat /var/log/net-snmpd.log NET-SNMP version 5.7.2 2015-01-13 16:11:25 Telcontar.valinor [192.168.1.14] (via UDP: [192.168.1.14]:44398->[192.168.1.15]:162) TRAP, SNMP v1, community public NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification Enterprise Specific Trap (17) Uptime: 4 days, 3:13:44.59 NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatRate = INTEGER: 123456 AmonLanc:~ # Bingo! So I disable/enable snmp in the router, which I knew produced a message, and got it in the log: 2015-01-13 16:13:00 router [UDP: [192.168.1.1]:161->[192.168.1.15]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (804792300) 93 days, 3:32:03.00 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-MIB::warmStart SNMPv2-MIB::snmpTrapEnterprise.0 = OID: SNMPv2-SMI::enterprises.16972.2.10 (what it means exactly, I dunno :-) ) (just the uptime is clear) Which is what I wanted, find out what traps my router sends by capturing them in a log. :-) Whether the info is interesting or not, or even useful, is still to be found. I'd like to see traffic info, or disconnections... disconnections I see in syslog, anyway. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Tue, 13 Jan 2015 16:23, Carlos E. R. <robin.listas@...> wrote:
On 2015-01-13 08:28, Per Jessen wrote:
Carlos E. R. wrote: [snip]
This is what I used when I was playing with snmptrapd:
snmptrapd -A -Lf /var/log/snmptraps
Well... I changed that, and restarted the service:
case "$1" in start) echo -n "Starting snmptrapd: " # startproc $SNMPTRAPD $SNMPTRAPD_CONF -A -LF ${SNMPD_LOGLEVEL:-n} $SNMPTRAPD_LOGFILE -p $SNMPTRAPD_PID #CER startproc $SNMPTRAPD $SNMPTRAPD_CONF -A -Lf ${SNMPD_LOGLEVEL:-n} $SNMPTRAPD_LOGFILE -p $SNMPTRAPD_PID rc_status -v ;; stop)
First error here: either you remove the part "${SNMPD_LOGLEVEL:-n}", or edit the config-file where this is defined: In file "/etc/init.d/snmptrapd" line 26 says: "SNMPD_CONFIG=/etc/sysconfig/net-snmp" File "/etc/sysconfig/net-snmp": SNMPD_LOGLEVEL="i" (default is "n") [snip]
The log changes:
AmonLanc:~ # l /var/log/net-snmpd.log srwxr-xr-x 1 root root 0 Jan 13 15:57 /var/log/net-snmpd.log= AmonLanc:~ #
The result is that I can not even try to read it:
AmonLanc:~ # less /var/log/net-snmpd.log /var/log/net-snmpd.log is not a regular file (use -f to see it) AmonLanc:~ # less -f /var/log/net-snmpd.log /var/log/net-snmpd.log: No such device or address AmonLanc:~ #
Now, this is just wrong. That should be a plain test file, not a socket. Remove file, create empty file as root, set mode: " rm /var/log/net-snmpd.log touch /var/log/net-snmpd.log chmod ug=rw,o=r /var/log/net-snmpd.log "
## Path: System/Net-SNMP ## Description: Log level of the snmp server. ## Type: string(!,a,c,e,w,n,i,d,0,1,2,3,4,5,6,7) ## Default: n # # Defines the log level for snmpd. # # The default is "n" (5, LOG_NOTICE) # SNMPD_LOGLEVEL="a"
With this you only log the highest level, alert = a = 0 = LOG_ALERT anything lower, e.g. notice = n = 5 = LOG_NOTICE, or the even lower info = i = 6 = LOG_INFO will NOT be logged. Thus shooting your own foot. Better chnge that to "i" for info, or go the full mounty with "d" for debug.
But repeating the send doesn't produce another. Then I changed the value in "/etc/sysconfig/net-snmp" to "7", and finally I get entries in the log!
AmonLanc:~ # cat /var/log/net-snmpd.log
NET-SNMP version 5.7.2 2015-01-13 16:11:25 Telcontar.valinor [192.168.1.14] (via UDP: [192.168.1.14]:44398->[192.168.1.15]:162) TRAP, SNMP v1, community public NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification Enterprise Specific Trap (17) Uptime: 4 days, 3:13:44.59 NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatRate = INTEGER: 123456 AmonLanc:~ #
Bingo!
So I disable/enable snmp in the router, which I knew produced a message, and got it in the log:
2015-01-13 16:13:00 router [UDP: [192.168.1.1]:161->[192.168.1.15]:162]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (804792300) 93 days, 3:32:03.00 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-MIB::warmStart SNMPv2-MIB::snmpTrapEnterprise.0 = OID: SNMPv2-SMI::enterprises.16972.2.10
(what it means exactly, I dunno :-) ) (just the uptime is clear)
Which is what I wanted, find out what traps my router sends by capturing them in a log. :-) Whether the info is interesting or not, or even useful, is still to be found.
I'd like to see traffic info, or disconnections... disconnections I see in syslog, anyway.
Lets look at the full picture: snmpwalk -v 2c -c public 192.168.1.1 The output will be long, maybe use a redirect into a file, or pipe into a pager. This gives you a hint (OID) to what to define a trap for. e.g. for my easy.box router a grepped output of above: IF-MIB::ifDescr.12 = STRING: PPPoE1 IF-MIB::ifDescr.13 = STRING: PPPoE2 IF-MIB::ifMtu.12 = INTEGER: 1492 IF-MIB::ifMtu.13 = INTEGER: 1492 IF-MIB::ifSpeed.12 = Gauge32: 6909000 IF-MIB::ifSpeed.13 = Gauge32: 6909000 IF-MIB::ifAdminStatus.12 = INTEGER: up(1) IF-MIB::ifAdminStatus.13 = INTEGER: up(1) IF-MIB::ifOperStatus.12 = INTEGER: up(1) IF-MIB::ifOperStatus.13 = INTEGER: up(1) IF-MIB::ifLastChange.12 = Timeticks: (0) 0:00:00.00 IF-MIB::ifLastChange.13 = Timeticks: (0) 0:00:00.00 IF-MIB::ifInOctets.12 = Counter32: 4273396241 IF-MIB::ifInOctets.13 = Counter32: 120249109 IF-MIB::ifInUcastPkts.12 = Counter32: 9964923 IF-MIB::ifInUcastPkts.13 = Counter32: 899379 IF-MIB::ifInNUcastPkts.12 = Counter32: 0 IF-MIB::ifInNUcastPkts.13 = Counter32: 0 IF-MIB::ifInDiscards.12 = Counter32: 0 IF-MIB::ifInDiscards.13 = Counter32: 0 IF-MIB::ifInErrors.12 = Counter32: 0 IF-MIB::ifInErrors.13 = Counter32: 0 IF-MIB::ifInUnknownProtos.12 = Counter32: 0 IF-MIB::ifInUnknownProtos.13 = Counter32: 0 IF-MIB::ifOutOctets.12 = Counter32: 396091514 IF-MIB::ifOutOctets.13 = Counter32: 191153470 IF-MIB::ifOutUcastPkts.12 = Counter32: 6608037 IF-MIB::ifOutUcastPkts.13 = Counter32: 899394 IF-MIB::ifOutNUcastPkts.12 = Counter32: 0 IF-MIB::ifOutNUcastPkts.13 = Counter32: 0 IF-MIB::ifOutDiscards.12 = Counter32: 0 IF-MIB::ifOutDiscards.13 = Counter32: 0 IF-MIB::ifOutErrors.12 = Counter32: 0 IF-MIB::ifOutErrors.13 = Counter32: 0 IF-MIB::ifOutQLen.12 = Gauge32: 1 IF-MIB::ifOutQLen.13 = Gauge32: 1 The command: snmptable -v 2c -c public 192.168.1.1 .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable should (for most routers) give the info above as a table It's long since I had to use snmp to debug a network (1997), thus the knowlegde of trap design is no longer there. Sorry. - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-13 17:03, Yamaban wrote:
On Tue, 13 Jan 2015 16:23, Carlos E. R. <robin.listas@...> wrote:
First error here: either you remove the part "${SNMPD_LOGLEVEL:-n}", or edit the config-file where this is defined:
In file "/etc/init.d/snmptrapd" line 26 says: "SNMPD_CONFIG=/etc/sysconfig/net-snmp"
File "/etc/sysconfig/net-snmp": SNMPD_LOGLEVEL="i" (default is "n")
I found out that later, the email illustrates the finding process :-)
[snip]
The log changes:
AmonLanc:~ # l /var/log/net-snmpd.log srwxr-xr-x 1 root root 0 Jan 13 15:57 /var/log/net-snmpd.log= AmonLanc:~ #
The result is that I can not even try to read it:
AmonLanc:~ # less /var/log/net-snmpd.log /var/log/net-snmpd.log is not a regular file (use -f to see it) AmonLanc:~ # less -f /var/log/net-snmpd.log /var/log/net-snmpd.log: No such device or address AmonLanc:~ #
Now, this is just wrong. That should be a plain test file, not a socket. Remove file, create empty file as root, set mode:
No, the "/usr/sbin/snmptrapd" program created the socket (I thought it was a pipe, I'm not familiar with named such), automatically. When I reverted the change to the command call, it went back to a normal file. Why it went to be socket, the manual does not say in the -LF explanation paragraph. Or I did not understand it.
SNMPD_LOGLEVEL="a"
With this you only log the highest level, alert = a = 0 = LOG_ALERT
I found out that later, as my email described. Initially I thought that 'a' stood for "all". Trial and test procedure. Now I have a "7". :-)
Lets look at the full picture:
snmpwalk -v 2c -c public 192.168.1.1
The output will be long, maybe use a redirect into a file, or pipe into a pager.
575 lines.
This gives you a hint (OID) to what to define a trap for. e.g. for my easy.box router a grepped output of above:
Interesting.
The command:
snmptable -v 2c -c public 192.168.1.1 .iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable
should (for most routers) give the info above as a table
It does, yes. :-) Much clearer. A partial dump (right side eliminated, to reduce size): SNMP table: IF-MIB::ifTable ifIndex ifDescr ifType ifMtu ifSpeed ifPhysAddress ifAdminStatus ifOperStatus ifLastChange ifInOctets ifInUcastPkts ifInNUcastPkts ... ... 1 lo softwareLoopback 16436 10000000 up up 0:0:00:00.00 11457 39 0 2 ifb0 ethernetCsmacd 1500 100000000 fa:5c:27:a5:9b:96 up up 0:0:00:00.00 2149514530 167200975 0 3 ifb1 ethernetCsmacd 1500 100000000 b2:cf:fd:d9:49:17 up up 0:0:00:00.00 2527931709 170609810 0 4 gre0 ethernetCsmacd 1476 100000000 down down 0:0:00:00.00 0 0 0 5 sit0 ethernetCsmacd 1480 100000000 down down 0:0:00:00.00 0 0 0 6 ip6tnl0 ethernetCsmacd 1460 100000000 down down 0:0:00:00.00 0 0 0 7 eth0 ethernetCsmacd 1500 100000000 f8:1a:67:91:f4:22 up up 0:0:00:00.00 3292715655 173486729 0 8 eth1 ethernetCsmacd 1500 100000000 f8:1a:67:91:f4:23 down down 0:0:00:00.00 0 0 0 9 eth0.2 ethernetCsmacd 1500 100000000 f8:1a:67:91:f4:22 up up 0:0:00:00.00 259769855 159060267 0 10 eth0.3 ethernetCsmacd 1500 100000000 f8:1a:67:91:f4:22 up up 0:0:00:00.00 4010041 57925 0 11 eth0.4 ethernetCsmacd 1500 100000000 f8:1a:67:91:f4:22 up up 0:0:00:00.00 27751566 555019 0 12 eth0.5 ethernetCsmacd 1500 100000000 f8:1a:67:91:f4:22 up up 0:0:00:00.00 3001184338 13813519 0 13 br0 ethernetCsmacd 1500 100000000 f8:1a:67:91:f4:22 up up 0:0:00:00.00 2016987080 166645366 0 14 wifi0 ethernetCsmacd 1500 100000000 f8:1a:67:91:f4:22 up up 0:0:00:00.00 0 166079559 0 15 ath0 ethernetCsmacd 2290 100000000 f8:1a:67:91:f4:22 up up 0:0:00:00.00 3758522139 12232150 0 16 nas0 aal5 1500 0 78:1a:67:91:f4:23 up down 0:0:00:00.00 0 0 0 17 nas0_1 aal5 1500 0 f8:1a:67:91:f4:23 up down 0:0:00:00.00 0 0 0 18 nas1 aal5 1500 0 7a:1a:67:91:f4:23 up down 0:0:00:00.00 0 0 0 19 nas1_1 aal5 1500 0 fa:1a:67:91:f4:23 up down 0:0:00:00.00 2057650864 173525023 0 22 ppp1 ppp 1480 0 up down 0:0:00:00.00 637671953 5584182 0 So perhaps what I have to look for is for the ifInOctets and ifOutOctets columns. Apparently there is a row for each eth interface, the wifi... I suppose one of them would be the adsl pipe. I could interrogate at intervals and calculate traffic. Perhaps the "ppp1" line. Or no, ifOperStatus is down. But the ifInOctets value changes with time.
It's long since I had to use snmp to debug a network (1997), thus the knowlegde of trap design is no longer there. Sorry.
No, you got me forward :-) It may be doable, one day I'm bored or very interested to code it. For now, my curiosity is satisfied. If I were to find an application, ready made, that does it, that would be different. A plugin for gkrellm, perhaps... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 01/10/2015 12:38 PM, Per Jessen wrote:
James Knott wrote:
It wouldn't be on the ADSL side, it would be on the ethernet side. That's where I was looking. I have often used Wireshark on a lot of systems, to see just what's happening. If the modem is sending SMTP or syslog traffic intended for the user, then it would have to be on
On 01/09/2015 03:36 PM, Per Jessen wrote: the Ethernet port. Both would need to be enabled - SNMP traps and syslog both need a target host.
I have set up telecom equipment to use syslog, but never had occasion to use SNMP. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-09 21:07, James Knott wrote:
On 01/09/2015 02:03 PM, Per Jessen wrote:
Well, that's one possibility, assuming the OPs modem does the same. However, I have looked at ADSL connections with Wireshark and don't recall seeing SNMP or syslog traffic.
My adsl router does send me syslog packets, but because I configured it that way. My current router talks very little, my previous one was more talkative. Both are snmp capable, but I don't know how to use that. I would like to... perhaps to log traffic stats. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2015-01-09 21:07, James Knott wrote:
On 01/09/2015 02:03 PM, Per Jessen wrote:
Well, that's one possibility, assuming the OPs modem does the same. However, I have looked at ADSL connections with Wireshark and don't recall seeing SNMP or syslog traffic.
My adsl router does send me syslog packets, but because I configured it that way. My current router talks very little, my previous one was more talkative. Both are snmp capable, but I don't know how to use that. I would like to... perhaps to log traffic stats.
For that, take a look at cacti and/or nagios. -- Per Jessen, Zürich (5.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-11 11:34, Per Jessen wrote:
Carlos E. R. wrote:
My adsl router does send me syslog packets, but because I configured it that way. My current router talks very little, my previous one was more talkative. Both are snmp capable, but I don't know how to use that. I would like to... perhaps to log traffic stats.
For that, take a look at cacti and/or nagios.
Which one is easier? :-) I installed cacti sometime ago, but I did not find the sweet time spot to configure it, so it does nothing yet. I had a look at the page somewhere at opensuse.org and it seems complicated. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
В Sun, 11 Jan 2015 16:39:10 +0100 "Carlos E. R." <robin.listas@telefonica.net> пишет:
On 2015-01-11 11:34, Per Jessen wrote:
Carlos E. R. wrote:
My adsl router does send me syslog packets, but because I configured it that way. My current router talks very little, my previous one was more talkative. Both are snmp capable, but I don't know how to use that. I would like to... perhaps to log traffic stats.
For that, take a look at cacti and/or nagios.
Which one is easier? :-)
They serve different purpose. Nagios is primarily monitoring tool - it collects metrics and can trigger reactions based in these metrics. Cacti is primarily long term graphing tool. It collects metrics, stores them persistently over long period and can draw pretty graphs from them. There are nagios plugins to implement cacti functionality; I do not think opposite is true.
I installed cacti sometime ago, but I did not find the sweet time spot to configure it, so it does nothing yet. I had a look at the page somewhere at opensuse.org and it seems complicated.
On 2015-01-11 16:48, Andrei Borzenkov wrote:
В Sun, 11 Jan 2015 16:39:10 +0100 "Carlos E. R." <> пишет:
For that, take a look at cacti and/or nagios.
Which one is easier? :-)
They serve different purpose. Nagios is primarily monitoring tool - it collects metrics and can trigger reactions based in these metrics. Cacti is primarily long term graphing tool. It collects metrics, stores them persistently over long period and can draw pretty graphs from them.
There are nagios plugins to implement cacti functionality; I do not think opposite is true.
I will go with cacti, then. I had a second look at <https://en.opensuse.org/Cacti> and will try it. First at my desktop machine, where mysql and apache are alread running. Then, if I succeed and like it, I'll move it to a 32 bit laptop without battery that acts as server full time. Maybe, a second step, could split the capture section to the laptop, and the analysis to the desktop, which is way more powerful. Dunno if possible. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2015-01-09 18:09, James Knott wrote:
On 01/09/2015 11:58 AM, Carlos E. R. wrote:
On 2015-01-09 16:26, James Knott wrote:
On 01/09/2015 08:50 AM, Carlos E. R. wrote:
Where is the disconnect occurring? At the server or ADSL modem? If the ISP shuts down the connection to the modem. the server might not know about it. I'm almost sure that the adsl modem tells the controlling software of any status change, such as the connection going down and the cause.
Most ADSL connections are connected via Ethernet. There is no such signal on Ethernet.
If that were the case, it would be a stand alone "adsl router", and it would handle itself completely. The OP would not be asking us how to configure the router. And anyway, those routers do reconnect automatically. Notice that the OP specified that the DSL connection is handled by openSUSE. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 01/09/2015 02:53 PM, Carlos E. R. wrote:
On 2015-01-09 18:09, James Knott wrote:
On 01/09/2015 11:58 AM, Carlos E. R. wrote:
On 2015-01-09 16:26, James Knott wrote:
On 01/09/2015 08:50 AM, Carlos E. R. wrote: Where is the disconnect occurring? At the server or ADSL modem? If the ISP shuts down the connection to the modem. the server might not know about it. I'm almost sure that the adsl modem tells the controlling software of any status change, such as the connection going down and the cause. Most ADSL connections are connected via Ethernet. There is no such signal on Ethernet. If that were the case, it would be a stand alone "adsl router", and it would handle itself completely. The OP would not be asking us how to configure the router. And anyway, those routers do reconnect automatically.
Notice that the OP specified that the DSL connection is handled by openSUSE.
It would be nice if the OP came back, as we're now just speculating. However, he did say keep alive traffic would work. Neither of us knows enough about his set up to go further than that. I expect his problem is he's trying to use it to connect a server, which waits for incoming traffic, rather than as a computer that initiates the traffic, causing the ADSL to wake up when required. Also, it doesn't have to be a router to use an Ethernet connection. Plain modems were used long before ADSL capable routers were available. In that case, the computer or router had to be configured to use PPPoE to the modem. There might be something possible there, as PPPoE supports keep alive. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/09/2015 11:53 AM, Carlos E. R. wrote:
And anyway, those routers do reconnect automatically.
Some do, some merely watch for traffic, and reconnect when OUTGOING traffic is needed. When we had an office in Australia, that circuit would drop on the Australian ASDL end, and the router (stand alone) would NOT reconnect until something in the Sydney office triggered traffic. So when our Alaska office tried to connect to sync files Sydney could not be reached. We installed a slow ping (interval about 5 minutes as I recall) in the Sydney server to our Alaska server and that kept the line up. An external modem is no solution to inward reachability. - -- After all is said and done, more is said than done. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlSwN1MACgkQv7M3G5+2DLJJDACfTCy9MFHH5UJFvVYUm6mjRijP QlUAn38uBddauZ4VvWx4L1GlmXUwga8W =ao5I -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2015 03:17 PM, John Andersen wrote:
We installed a slow ping (interval about 5 minutes as I recall) in the Sydney server to our Alaska server and that kept the line up.
Keep alives are quite common in networking and telecommunications. I first came across them around 1978 with a pair of Data General Eclipse computers. The standby computer would watch the traffic from one specific port which contained the keep alive. If nothing happened for a period of time, it assumed the on-line computer had died and initiated a switch over. Of course, Ethernet has a Link Integrity Test (LIT) every 16 mS. Routing protocols and Spanning Tree also have keep alive traffic to ensure the other devices are working. Even my 6in4 tunnel IPv6 has a keep alive. Bottom line, periodic pings or DHCP requests should not be much of a problem. A small script in cron.hourly to ping a few times every hour should do the trick, if that DHCP request interval doesn't. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2015 09:09 AM, James Knott wrote:
The OP already mentioned pings or fetchmail as a way to do that. If the DHCP requests are sufficient, then a minor editing of the line DHCLIENT_LEASE_TIME="" in /etc/sysconfig/network/dhcp and restarting dhcpcd is all that's required.
But why burden the dhcp server with a useless request, especially when taking that action might actually GET a new IP which would require teardown and reestablishment of any existing open sockets to remote targets. Granted that would usually (but not always) happen automatically, but you can induce a LOT of traffic if your ISP does not reissue the same IP. Further not all ISPs honour users requests as to lease times. Especially those short of IP addresses. You can start a ping at boot time with an INTERVAL of N seconds where n is calculated to be just shorter than the drop time, and all you impact is a tiny task in your machine and some tcp stack time on the ping target, and no disruption of open (but quiescent) sockets. Alternatively, open imap connection to a server supporting idled is usually sufficient unless the drop time is less than socket time-out, which is usually somewhere around 18 minutes. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2015 03:11 PM, John Andersen wrote:
But why burden the dhcp server with a useless request, especially when taking that action might actually GET a new IP which would require teardown and reestablishment of any existing open sockets to remote targets.
That shouldn't happen, as the client will request the same address and the server is supposed to grant it if available. As long as the request is made within the lease time, it must not be assigned to someone else.
Further not all ISPs honour users requests as to lease times. Especially those short of IP addresses.
That's why I said "if the DHCP requests are sufficient".
You can start a ping at boot time with an INTERVAL of N seconds where n is calculated to be just shorter than the drop time, and all you impact is a tiny task in your machine and some tcp stack time on the ping target, and no disruption of open (but quiescent) sockets.
There are a number of ways of pinging at interval. I don't know what the allowable range is for ping -i <interval>.
Alternatively, open imap connection to a server supporting idled is usually sufficient unless the drop time is less than socket time-out, which is usually somewhere around 18 minutes.
That's getting back to what he mentioned with fetchmail for a keep alive. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2015 12:24 PM, James Knott wrote:
You can start a ping at boot time with an INTERVAL of N seconds where n is
calculated to be just shorter than the drop time, and all you impact is a tiny task in your machine and some tcp stack time on the ping target, and no disruption of open (but quiescent) sockets.
There are a number of ways of pinging at interval. I don't know what the allowable range is for ping -i <interval>.
We set ours for 5 minutes, which was all we needed to keep our line up.
Alternatively, open imap connection to a server supporting idled is usually sufficient unless the drop time is less than socket time-out, which is usually somewhere around 18 minutes.
That's getting back to what he mentioned with fetchmail for a keep alive.
At the time we were doing this we were paying by the byte. Fetchmail or even pop induced a lot of traffic, whereas imap IDLED hardly generated anything at all, because the client simply tries to read a socket until it became readable due to the server having something to send or the socket timing out. Just our cheapskate habits showing up I guess. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/09/2015 04:04 PM, John Andersen wrote:
Just our cheapskate habits showing up I guess.
I wonder how much DHCP requests would cost you. Also, in that situation, you might want to go longer between pings. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-09 22:16, James Knott wrote:
On 01/09/2015 04:04 PM, John Andersen wrote:
Just our cheapskate habits showing up I guess.
I wonder how much DHCP requests would cost you. Also, in that situation, you might want to go longer between pings.
A lot if the server at the ISP is configured such that it issues you a new IP. It is a bit trickier to configure the client to do this query than issuing a ping from cron :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Thanks for all answers. After reading your posts, the section "More Advanced PPP Configurations" in "Linux Network Administrators Guide" (see http://www.tldp.org/LDP/nag2/x7297.html) and the manual page of pppd(8), I think that I need the following pppd options maxfail 0 persist holdoff 3 "persist" should do what I want from ppp(8) persist Do not exit after a connection is terminated; instead try to reopen the connection. The maxfail option still has an effect on persistent connections. "demand" and "idle" options are probably counterproductive, if I want an "always on" PPP connection. Unfortunately I do not know how to configure my DSL Internet connection with YaST or directly with a configuration file /etc/sysconfig/network/providers/provider* so that "pppd" starts with my options and not with the "demand" option. Probably this is a missing function in openSUSE's network setup tools. Until now, I haven't tested my options. Thanks also for the "ping" and "DHCP" hints. I think, it's OK to ping a private IP address which is not part of my LAN, but routing thinks, that the address can be reached with default route. With something like "ping 10.1.2.3" (if 10.0.0.0/8 is not part of my network) the PPP connection comes up and my provider drops the useless ICMP packets. By the way, "pppd" can easily detect broken connections. The detection is done with PPP echo-requests. A broken connection looks like this in /var/log/messages: 2015-01-08T23:12:01.312736+01:00 mybox pppd[2143]: No response to 4 echo-requests 2015-01-08T23:12:01.313875+01:00 mybox pppd[2143]: Serial link appears to be disconnected. 2015-01-08T23:12:01.331279+01:00 mybox pppd[2143]: Connect time 112.6 minutes. 2015-01-08T23:12:01.332208+01:00 mybox pppd[2143]: Sent 31680069 bytes, received 958993900 bytes. 2015-01-08T23:12:05.468567+01:00 mybox pppd[2143]: Connection terminated. 2015-01-08T23:12:05.492789+01:00 mybox pppd[2143]: Sent PADT 2015-01-08T23:12:06.483599+01:00 mybox pppd[2143]: Script /etc/ppp/ip-down finished (pid 23628), status = 0x0 2015-01-08T23:12:46.107025+01:00 mybox pppd[2143]: Starting link 2015-01-08T23:13:21.162423+01:00 mybox pppd[2143]: Timeout waiting for PADO packets 2015-01-08T23:13:21.163602+01:00 mybox pppd[2143]: Unable to complete PPPoE Discovery Greetings, Björn Carlos E. R. wrote:
On 2015-01-09 14:12, James Knott wrote:
Is there a recommended way to start DSL without any network request, so that it's nearly always on? In openSUSE documentation I only found two alternatives: always-on and manually. Both are not ideal. (I know, that the provider breaks the connection every 24 hours. The router should reconnect then.) It sounds like you will have to generate traffic occasionally. If the ISP is killing the connection, there's nothing else that will work. I'd say a ping every hour or so should do the trick. That won't cost much
On 01/09/2015 08:01 AM, Bjoern Voigt wrote: performance. It should be possible to configure the network for always on, and reconnect automatically when it does, instantly. Routers do.
Maybe IDLETIME 0 or -1, just a very wild guess.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stefan Seyfried wrote:
Hi Bjoern,
this has nothing to do with the kernel, so your choice of mailing list is sub-optimal. I'll answer here anyway. I know. I mix mails for two lists in one folder and I took the false mailing list name in first try.
Am 08.01.2015 um 23:56 schrieb Bjoern Voigt:
/etc/sysconfig/network/providers/provider0 there is
ASKPASSWORD='no' AUTODNS='yes' DEMAND='yes' IDLETIME='1500' AUTO_RECONNECT='yes'
My problem is, that I need a nearly useless service ('ping' or 'fetchmail' for instance) which starts network requests regularly so that the DSL connection starts and stays alive.
Is there a recommended way to start DSL without any network request, so that it's nearly always on? In openSUSE documentation I only found two alternatives: always-on and manually. Both are not ideal. (I know, that the provider breaks the connection every 24 hours. The router should reconnect than.) If you put it to always-on (I guess that would be "DEMAND=no") and leave "AUTO_RECONNECT=yes", doesn't it auto reconnect after the provider drops the connection?
It's a long time since I used modems/ppp other than 3G in my Linux box, so I don't know the exact details, but it would seem logical.
another way would be to put idletime to 90000 seconds, but you still need to start the connection somehow with a ping or similar. Thank you. "DEMAND=no" and big idle times look logical.
I should test all the discussed options. By the way, what is a good way to avoid network packets which bring up the PPP connection on-demand for testing "persist" options? (My idea is to write a firewall rule, which blocks all traffic from LAN to dsl0 device. Another option can be the "active-filter" expressions in pppd. "Closing all network programs" is probably not the best option, because there are too much programs and libraries which use the network.) Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
By the way: after upgrading openSUSE 13.1 to 13.2 I found, that the support for /etc/sysconfig/network/providers/ DSL configurations (manually created or via YaST -> Network Devices -> DSL) is gone. I have no running openSUSE 13.1 system anymore and could not test /etc/sysconfig/network/providers/ configurations anymore, see https://wiki.archlinux.de/title/PPPoE_mit_pppd The Arch Linux page https://wiki.archlinux.de/title/PPPoE_mit_pppd shows configurations with the pppd "persist" option. These configurations can be used to manually start DSL connections also on openSUSE 13.2. Bjoern Voigt wrote:
I should test all the discussed options. By the way, what is a good way to avoid network packets which bring up the PPP connection on-demand for testing "persist" options? (My idea is to write a firewall rule, which blocks all traffic from LAN to dsl0 device. Another option can be the "active-filter" expressions in pppd. "Closing all network programs" is probably not the best option, because there are too much programs and libraries which use the network.)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-01-09 23:59, Bjoern Voigt wrote:
Unfortunately I do not know how to configure my DSL Internet connection with YaST or directly with a configuration file /etc/sysconfig/network/providers/provider* so that "pppd" starts with my options and not with the "demand" option. Probably this is a missing function in openSUSE's network setup tools.
Perhaps in "/etc/ppp/options". I see "maxfail" there, commented out. Or perhaps IDLETIME 0 or -1, as I said previously, in the provider file.
Until now, I haven't tested my options.
Thanks also for the "ping" and "DHCP" hints. I think, it's OK to ping a private IP address which is not part of my LAN, but routing thinks, that the address can be reached with default route. With something like "ping 10.1.2.3" (if 10.0.0.0/8 is not part of my network) the PPP connection comes up and my provider drops the useless ICMP packets.
Just ping google. 8.8.8.8. One packet. ROTFL! Just found this by error: cer@Telcontar:~> host google google has address 127.0.53.53 google mail is handled by 10 your-dns-needs-immediate-attention.google. cer@Telcontar:~> X'-)
By the way, "pppd" can easily detect broken connections. The detection is done with PPP echo-requests. A broken connection looks like this in /var/log/messages:
Yep. Sounds familiar. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (7)
-
Andrei Borzenkov -
Bjoern Voigt -
Carlos E. R. -
James Knott -
John Andersen -
Per Jessen -
Yamaban