I am trying to receive a trap generated by a cisco router on my VM- Ubuntu 14.04. I can do a snmwalk so I guess snmp is working fine but I am not able to receive the traps generated by router on my VM.
a#ubuntu:~$ sudo /etc/init.d/snmpd restart
* Restarting network management services:
a#ubuntu:~$ sudo /etc/init.d/snmpd status
* snmpd is running
* snmptrapd is running
Here is what I have inside files-
/etc/default/snmpd-
export MIBS=
SNMPDRUN=yes
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -c /etc/snmp/snmpd.conf'
TRAPDRUN=yes
# snmptrapd options (use syslog).
TRAPDOPTS='-n -On -t -Lsd -p /var/run/snmptrapd.pid'
/etc/snmp/-
snmpd.conf-
rocommunity public
snmptrapd.conf-
disableAuthorization yes
snmp.conf-
mibs:
The command I am running for viewing the traps on VM-
a#ubuntu:/etc/snmp$ sudo snmptrapd -f -Lo -c snmptrapd.conf
couldn't open udp:162 -- errno 98 ("Address already in use")
I am confused since the port is being used by snmptrap itself-
a#ubuntu:~$ cat /etc/services|grep 162
snmp-trap 162/tcp snmptrap # Traps for SNMP
snmp-trap 162/udp snmptrap
a#ubuntu:~$ sudo netstat -lnp| grep 162
udp 0 0 0.0.0.0:162 0.0.0.0:* 6216/snmptrapd
a#ubuntu:~$ ps -ef | grep snmptrapd
root 6216 2076 0 10:43 ? 00:00:00 /usr/sbin/snmptrapd -Lsd -p /var/run/snmptrapd.pid
a 6493 2667 0 11:47 pts/8 00:00:00 grep --color=auto snmptrapd
Generating a trap from windows using SnmpTrapGen.exe leads to the same error.
Is there any way of solving this issue? I have googled a lot and stuck on this for days, any help will be very much appreciated.
Thanks a lot in advance!!
Port 162 can listen only with an application. If you get this error , you have an app already running which listens port 162 , those can be snmptrapd service or your own application for snmp traps. You should close one of the applications.
Related
I'm setting suricata on debian 10 to block expected request with run command as below:
/usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid -q 3 -q 4 -q 5 -D -v --user=logstash
Whenever I receives a request which is matched to be blocked, example:
{"timestamp":"2021-12-16T14:59:09.855634+0000","flow_id":3110969609810,"event_type":"drop","src_ip":"192.168.1.5","dest_ip":"192.168.1.18","proto":"ICMP","icmp_type":8,"icmp_code":0,"drop":{"len":60,"tos":0,"ttl":128,"ipid":29443,"icmp_id":256,"icmp_seq":31241},"alert":{"action":"blocked","gid":1,"signature_id":1000002,"rev":1,"signature":"ICMP connection attempt","category":"","severity":3}}
Suricata will be stopped right after that with this error:
[4585] 16/12/2021 -- 14:59:09 - (respond-reject-libnet11.c:226) <Error> (RejectSendLibnet11L3IPv4ICMP) -- [ERRCODE: SC_ERR_LIBNET_INIT(144)] - libnet_inint failed: libnet_open_raw4(): SOCK_RAW allocation failed: Operation not permitted
[4577] 16/12/2021 -- 14:59:09 - (tm-threads.c:1807) <Error> (TmThreadCheckThreadState) -- [ERRCODE: SC_ERR_FATAL(171)] - thread W-NFQ#5 failed
Output of file capability is:
# getcap /usr/bin/suricata
/usr/bin/suricata = cap_net_admin,cap_net_raw,cap_sys_nice+eip
What could I do to make it work now?
I have postfix 3.3.0 and Active Directory on Server 2019. I want the connection to be secure and to validate the server certificate.
When trying to send an email, I am unable to and see this in syslog.
postfix/submission/smtpd[7432]: warning: dict_ldap_set_tls_options: Unable to allocate new TLS context -1: Can't contact LDAP server
Here's the contents of /etc/postfix/ldap-users.cf
bind = yes
bind_dn = {valid bind account}
bind_pw = {valid bind password}
version = 3
timeout = 20
size_limit = 1
expansion_limit = 0
start_tls = yes
tls_require_cert = yes
tls_ca_cert_file = /var/spool/postfix/mydomain.tld.crt
server_host = ldap://dc.mydomain.tld/
search_base = dc=mydomain,dc=tld
scope = sub
query_filter = (&(objectClass=person)(mail=%s))
result_attribute = mail
result_format = %s
With this configuration, postmap -q test#mydomain.tld ldap:/etc/postfix/ldap-users.cf works. openssl s_client -starttls ldap -connect dc.mydomain.tld:389 also works (no validation errors). Even with tls_require_cert = no, it still fails. When start_tls = no, everything works fine.
Before I specified tls_ca_cert_file, I imported my .crt into ca-certificates. The error I received was postfix/postmap[4994]: error: dict_ldap_connect: Unable to set STARTTLS: -11: Connect error. It seems Postfix doesn't read from the computer cert store. After testing with tls_ca_cert_file from my home, it changed to the error I'm getting now, -1. I first tried from /etc/postfix, then now chroot home (based on an Internet suggestion Postfix couldn't access it).
I realized I made the classic mistake of installing from the stock repositories, and ended up with an old version. I ended up compiling Postfix from source.
sudo groupadd postfix
sudo groupadd postdrop
sudo useradd -c "Postfix Daemon User" -d /var/spool/postfix -g postfix -s /bin/false -u 32 postfix
wget http://cdn.postfix.johnriley.me/mirrors/postfix-release/official/postfix-3.6.2.tar.gz
tar xzf postfix-3.6.2.tar.gz
sudo apt-get install libdb-dev gcc m4 make libsasl2-dev openssl libssl-dev libldb-dev libldap2-dev
cd postfix-3.6.2/
make makefiles CCARGS="-I/usr/include/openssl -I/usr/include/sasl/ -DUSE_TLS -DHAS_LDAP -DUSE_SASL_AUTH -DUSE_CYRUS_SASL" AUXLIBS="-lssl -lcrypto -lldap -llber -lsasl2"
make
sudo make install
I have a NUC in Ubuntu. I would like to write a program in c for serial port send and receive message.
The device is /dev/ttyUSB0.
It is success to use Linux command echo "message" > /dev/ttyUSB0 and use minicom to get the result.
But the device is open fail when using c program, fd always return -1
int fd;
fd = open ("/dev/ttyUSB0", O_RDWR);
Then I try to use raspbian pi in debian, and run the same program. It can open the device.
Is there any setting is missing in Ubuntu platform in NUC? Thanks you very match.
Update:
I print out the error message: open() failed with error [Permission denied],
then I try to use sudo to run the exe file, then I can get the usb device
this is current file detial
-rwxrwxr-x 1 u u 9048 Aug 22 19:15 uart
-rw-rw-r-- 1 u u 1424 Aug 22 19:15 uart.c
Beside I use chown change the permission of file, is there any other method?
sudo usermod -a -G dialout <User>
/dev/ttyxy is owned by the user root and the group dialout , so I added myself to the dialout group. At least worked for me.
If your situation allow you to use sudo, then why any alternative !
I'm trying to diagnose a problem with the OpenSIPS ( a SIP proxy ) application.
When sending two different UDP packets to the same IP and port, one call fails with -1 EPERM (Operation not permitted) whilst the other is fine.
Both of the calls are made from the same process ( at least the same PID ).
The code in question is on github.
Here's the strace output:
strace -e sendto
sendto(7, "SIP/2.0 100 Giving a try\r\nVia: S"..., 315, 0, {sa_family=AF_INET, sin_port=htons(5060), sin_addr=inet_addr("yyy.yyy.yyy.yyy")}, 16) = 315
sendto(7, "INVITE sip:myHomeDesktop#xxx"..., 1253, 0, {sa_family=AF_INET, sin_port=htons(5060), sin_addr=inet_addr("xxx.xxx.xxx.xxx")}, 16) = 1253
sendto(7, "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP"..., 707, 0, {sa_family=AF_INET, sin_port=htons(5060), sin_addr=inet_addr("yyy.yyy.yyy.yyy")}, 16) = -1 EPERM (Operation not permitted)
It turns out that the kernel conntrack modules were dropping the packet, leading to the syscall getting the EPERM error and not sending the packets.
I found this after looking at the syslog and finding:
May 26 10:59:45 localhost kernel: nf_ct_sip: dropping packet: cannot add expectation for voice
I was completely unaware that I was using the sip conntrack module, and it's not dynamically loaded on my system (lsmod shows blank).
I circumvented the problem by turning off connection tracking for my SIP traffic with:
iptables -I OUTPUT -t raw -p udp --sport 5060 -j CT --notrack
iptables -I PREROUTING -t raw -p udp --dport 5060 -j CT --notrack
I'm trying to use a somewhat old DAQ, and had to jump through a few hoops to get an old (circa 2004) device driver for it to compile (DTI-DT340 Linux-DAQ-PCI).
I've gotten to the point where it compiles, I can load the kernel module, it finds the card, and I can create the character devices using mknod.
But I can't seem to open these devices and keep getting errno 19 (ENODEV) 'No such device' when I try to
open("/dev/dt340/0",O_RDWR);
but mknod had no complaints about making it, and it's there:
# ls -l /dev/dt340/
total 0
crw-rw-r-- 1 root staff 250, 0 2009-04-23 11:02 0
crw-rw-r-- 1 root staff 250, 1 2009-04-23 11:02 1
crw-rw-r-- 1 root staff 250, 2 2009-04-23 11:02 2
crw-rw-r-- 1 root staff 250, 3 2009-04-23 11:02 3
Is there something I'm neglecting to do? What might be a reason open fails?
Here's the script I use to load the driver and make the devices.
#!/bin/bash
module="dt340"
device="dt340"
mode="664"
# invoke modprobe with all arguments we were passed
#/sbin/modprobe -t misc -lroot -f -s $module.o $* || exit 1
insmod $module.ko
# remove stale nodes
rm -f /dev/${device}/[0-3]
major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices`
mkdir -p /dev/${device}
mknod /dev/${device}/0 c $major 0
mknod /dev/${device}/1 c $major 1
mknod /dev/${device}/2 c $major 2
mknod /dev/${device}/3 c $major 3
# give appropriate group/permissions, and change the group
# not all distributions have staff; some have "users" instead
group="staff"
grep '^staff:' /etc/group > /dev/null || group="users"
chgrp $group /dev/${device}/[0-3]
chmod $mode /dev/${device}/[0-3]
Some additional info:
#grep dt340 /proc/devices
250 dt340
# lsmod | grep dt340
dt340 21516 0
# tail /var/log/messages
Apr 23 11:59:26 ve kernel: [ 412.862139] dt340 0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Apr 23 11:59:26 ve kernel: [ 412.862362] dt340: In function dt340_init_one:
Apr 23 11:59:26 ve kernel: [ 412.862363] Device DT340 Rev 0x0 detected at address 0xfebf0000
#lspci | grep 340
03:01.0 Multimedia controller: Data Translation DT340
ANSWER: A printk confirmed that the -ENODEV was thrown from inside open(). Following an oldstyle
while ((pdev = pci_find_device(PCI_VENDOR_ID_DTI, PCI_ANY_ID, pdev)))
(which is deprecated), if(!pdev) ends up true, and returns the -ENODEV.
I'm inching closer - I guess I have to work through and update the pci code to use more modern mechanisms...
If the device shows up in /proc/devices, and you're sure you've got the number right in mknod, then the driver itself is refusing the open. The driver can return any error code from open() - including "no such device", which it might if it discovered a problem initialising the hardware.
I'd guess it is a problem in the driver, check the open function.
It shows up in /proc/devices, so all the generic device stuff seems to be ok.
mknod doesn't care if there is an device corresponding to the given major/minor numbers. Are you sure insmod is installing your module? What does lsmod tell you?
I'm unfamiliar with having to add the ".ko" extension. Is that something specific to your device driver?
Check through lspci and make sure hardware is properly initialized. If your system supports hotplug, pci_find_device won't work. The problem with this is a refcnt. The best way to deal and learn is to dissect the API. BOL !!