I am fairly new to SNMP and i have created a SNMP Agent in java using the snmp4j library.
In my code, i have added localhost as a trap destination. I therefore receive the notifications on the port 162 :
targetMIB.addTargetAddress(new OctetString("notification"),
TransportDomains.transportDomainUdpIpv4,
new OctetString(new UdpAddress("127.0.0.1/162").getValue()),
200, 1,
new OctetString("notify"),
new OctetString("v2c"),
StorageType.permanent);
What i am trying to do now is to receive traps from another ip address using a snmp browser such as iReasoning MIB Browser. But there i cannot manage to add an entry to the target mib.
Am i missing something ?
Thank you.
EDIT :
I want to add an entry using the mib browser to the target Address table. With iReasoning Mib browser i don't have the create row button and with ManageEngine's tool i have an add button but it does not seem to do anything.
I am therefore only trying here to change the row i have created with the code :
Here is a screen shot of the mib browser :
When i try to change the ip address i get an error :
I have tried to set the value using an OctetString with :
127.0.0.1:162
127.0.0.1/162
0700000100A2
0x0700000100A2
but nothing works
For further info, i solved my problem using the NET-SNMP tools.
What i did was :
Download net-snmp binaries
Make sure the mibs are located in the default folder (see readme)
Try a snmpwalk :
snmpwalk -v2c -c [READ_COMMUNITY] 127.0.0.1 targetaddrtable
SNMP-TARGET-MIB::snmpTargetAddrTDomain.'test' = OID: SNMPv2-TM::snmpUDPDomain
SNMP-TARGET-MIB::snmpTargetAddrTAddress.'test' = Hex-STRING: 00 00 00 00 00 A1
SNMP-TARGET-MIB::snmpTargetAddrTimeout.'test' = INTEGER: 1500
SNMP-TARGET-MIB::snmpTargetAddrRetryCount.'test' = INTEGER: 3
SNMP-TARGET-MIB::snmpTargetAddrTagList.'test' = STRING: v2c
SNMP-TARGET-MIB::snmpTargetAddrParams.'test' = STRING:
SNMP-TARGET-MIB::snmpTargetAddrStorageType.'test' = INTEGER: nonVolatile(3)
4) Do a set :
snmpset -v2c -c [COMMUNITY_WRITE] 127.0.0.1 snmpTargetAddrTAddress.'test' x 0000000000A1 snmpTargetAddrTDomain.'test' o 1.3.6.1.6.1.1 snmpTargetAddrTagList.'test' s notify snmpTargetAddrParams.'test' s v2c
snmpTargetAddrRowStatus.'test' i 4
SNMP-TARGET-MIB::snmpTargetAddrTAddress.'test' = Hex-STRING: 00 00 00 00 00 A1
SNMP-TARGET-MIB::snmpTargetAddrTDomain.'test' = OID: SNMPv2-TM::snmpUDPDomain
SNMP-TARGET-MIB::snmpTargetAddrTagList.'test' = STRING: notify
SNMP-TARGET-MIB::snmpTargetAddrParams.'test' = STRING: v2c
SNMP-TARGET-MIB::snmpTargetAddrRowStatus.'test' = INTEGER: createAndGo(4)
the snmpTargetAddrTAddress is a test
Related
Where can I find a definition of the Windows Schannel fatal alerts codes that show up in Event Viewer? For instance:
A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40.
A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 70. The Windows SChannel error state is 105.
The alert codes are defined at:
https://learn.microsoft.com/en-us/windows/win32/secauthn/schannel-error-codes-for-tls-and-ssl-alerts
40 = SSL3_ALERT_HANDSHAKE_FAILURE
42 = TLS1_ALERT_BAD_CERTIFICATE
43 = TLS1_ALERT_UNSUPPORTED_CERT
44 = TLS1_ALERT_CERTIFICATE_REVOKED
45 = TLS1_ALERT_CERTIFICATE_EXPIRED
46 = TLS1_ALERT_CERTIFICATE_UNKNOWN
48 = TLS1_ALERT_UNKNOWN_CA
70 = TLS1_ALERT_PROTOCOL_VERSION
I've installed a vps on ubuntu 18.04 with virtualmin as control panel. Once I create a user in a virtual server, the server automatically creates a 'mail' directory besides the 'Maildir' folder (which is normally used for storing mails via IMAP). The server makes use of postfix.
My folder structure in the user folder is now like this:
root#server01:/home/tuppr/homes/dprins# ls -al
total 28
drwxr-x--- 7 dprins#tuppr.nl tuppr 4096 Jan 11 21:02 .
drwxr-xr-x 3 tuppr tuppr 4096 Jan 11 21:01 ..
drwx------ 3 dprins#tuppr.nl tuppr 4096 Jan 11 21:02 mail
drwx------ 9 dprins#tuppr.nl tuppr 4096 Jan 11 21:01 Maildir
drwx------ 2 dprins#tuppr.nl tuppr 4096 Jan 11 21:02 .spamassassin
drwxr-xr-x 2 dprins#tuppr.nl tuppr 4096 Jan 11 21:04 .tmp
drwx------ 7 dprins#tuppr.nl tuppr 4096 Jan 11 21:02 .usermin
The problem is that incoming mails are strangely enough stored in the 'Maildir' directory, but email clients and webmail don't see it.
My postfix main.cf looks like this:
root#server01:/home/tuppr/homes/dprins# cat /etc/postfix/main.cf
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = server01.dennisprins.nl
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, server01.dennisprins.nl, localhost.dennisprins.nl, , localhost
#relayhost =
relayhost = vps.transip.email:587
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_tls_security_level = encrypt
smtp_tls_note_starttls_offer = yes
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
virtual_alias_maps = hash:/etc/postfix/virtual
sender_bcc_maps = hash:/etc/postfix/bcc
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
#smtp_tls_security_level = may
allow_percent_hack = no
In the 'mail' directory I usually only find some 'dovecot' log files, but no real e-mails. Those are stored in the 'Maildir', but for some reason every e-mailclient I tried doesn't seem to discover the mails stored in that folder. Like it's ignoring those. The webmail client also doesn't see any incoming mails. But they are physically stored in 'Maildir'.
Sending mails, however, is going well. Every mail I sent using a third party email client (on my Mac for example) are stored on the server and the webmail client also sees them in the 'Sent' folder.
My dovecot configuration is also pointing towards 'Maildir'. Executing a grep command for '/mail' doesn't show up anything rather than outcommented rules in dovecot.
My usermin mailbox configuration looks like this:
root#server01:/etc/dovecot# cat /etc/usermin/mailbox/config
spam_always=0
folder_types=local,ext,pop3,imap
no_mailer=0
server_attach=0
top_buttons=1
mail_dir=/var/spool/mail
mail_dir_qmail=Maildir
mail_file=mbox
shortindex=0
mail_system=4
from_format=1
smtp_ssl=0
pop_locks=1
nologout=1
wrap_width=80
spam_report=
perpage=20
folder_virts=virt,comp
show_to=0
mail_style=0
no_orig_ip=1
html_base64=0
edit_from=0
no_crlf=0
sendmail_path=/usr/lib/sendmail
noindex_hostname=1
from_map=/etc/postfix/virtual
mail_qmail=
pop3_server=localhost
send_mode=localhost
server_name=
smtp_pass=
global_address=
ldap_login=
ldap_quotas=
ldap_base=
smtp_user=
max_attach=
global_address_group=
smtp_port=
ldap_host=
ldap_tls=
max_quota=
ldap_pass=
smtp_auth=
ldap_port=
I also read and tried this article:
https://www.virtualmin.com/node/35887
https://www.virtualmin.com/node/36027
I checked literally everything but I can't find out why it's not working. All DNS records are perfectly fine. SPF records as well. Those are already checked. Whenever I delete the 'mail' directory, it's coming back as soon as I use the e-mailaccount (whether it's via a mail client or webmail)
Do you guys have any idea why it's behaving like this?
Hello your configuration is wrong when you do the email configuration, there is no local host, but the DNS you configured for POP3 or SMTP.
they must have SSL configuring.
Also, the type of sending is not localhost. You must also have a configured port. Whether for SMTP or POP3.
Well basically this file you sent is missing a lot of information
I checked your server to see if there was any wrong configuration. But in reality there is no configuration in this domain that you have posted.
Below are the main settings you should make in your DNS
http tuppr.nl The remote name could not be resolved: 'tuppr.nl' (http://tuppr.nl)
spf tuppr.nl DNS Record not found
dmarc tuppr.nl DNS Record not found
mx tuppr.nl No DMARC Record found
mx tuppr.nl DNS Record not found
dns tuppr.nl DNS Record not found
mx tuppr.nl DMARC Quarantine / Reject policy not enabled
send your feedback
I want to create a FTP connection and send a big file via it and see its effect in my network. In order to do that, I wrote the following lines in OMNet++ scenario file. I am not sure whether this is a correct way of creating a FTP connection or not. I set "thinkTime" and "IdleInterval" parameters to zero to send the FTP data immediately and in one session. Since the file size is too big for my current simulation, I think I would have only one session through the whole simulation time. However the throughput of my FTP connection is too low and I am not sure. Can someone help me? All suggestions or FTP examples are welcome.
# FTPclusterMember FTP
**.clusterMember[0].tcpApp[1].typename = "TCPBasicClientApp"
**.clusterMember[0].tcpApp[1].connectAddress = "FTPserver"
**.clusterMember[0].tcpApp[1].connectPort = 21
# Download Scenario requestLength < replyLength
**.clusterMember[0].tcpApp[1].requestLength = 100B
**.clusterMember[0].tcpApp[1].replyLength = 1500MB
**.clusterMember[0].tcpApp[1].thinkTime = 0s
**.clusterMember[0].tcpApp[1].idleInterval = 0s
# FTPserver Settings
**.FTPserver.numTcpApps = 1
**.FTPserver.tcpApp[0].typename = "TCPSinkApp"
**.FTPserver.tcpApp[0].localAddress = "FTPserver"
**.FTPserver.tcpApp[0].localPort = 21
Since FTP uses TCP in transport layer, we can use "TCPBasicClientApp" and "TCPGenericSrvApp" for FTP client and server respectively. For simulating behavior of FTP protocol, we set the port to 21. In addition, for simulation upload and download scenario, you just need to change the size of request length and reply length. As an example, please take a look at codes below;
# FTPclusterMember FTP
**.clusterMember[0].numTcpApps = 1
**.clusterMember[0].tcpApp[0].typename = "TCPBasicClientApp"
**.clusterMember[0].tcpApp[0].connectAddress = "FTPserver"
**.clusterMember[0].tcpApp[0].connectPort = 21
# Download Scenario requestLength < replyLength
# Upload Scenario requestLength > replyLength
**.clusterMember[0].tcpApp[0].requestLength = 1500MB
**.clusterMember[0].tcpApp[0].replyLength = 100B
**.clusterMember[0].tcpApp[0].thinkTime = 0s
**.clusterMember[0].tcpApp[0].idleInterval = 0s
# FTPserver Settings
**.FTPserver.numTcpApps = 1
**.FTPserver.tcpApp[0].typename = "TCPGenericSrvApp"
**.FTPserver.tcpApp[0].localAddress = "FTPserver"
**.FTPserver.tcpApp[0].localPort = 21
As you can see, I set "idleInterval" abd "thinktime" to zero. With these values, you can be sure that you have a constant transmission of FTP packets during your simulation time.
I am trying to send data over BLE from Bluno to a Raspberry Pi (Raspian), bluez 5.50.
Whilst the connection seems to be fine. I am struck in a point where am unable to retrieve serial data from notification handle.
Below is what I tried.
pi#raspberrypi:~ $ sudo gatttool -b <BLE-MAC-ADDRESS> -I
<BLE-MAC-ADDRESS>[LE]> connect
Attempting to connect to <BLE-MAC-ADDRESS>
Connection successful
[<BLE-MAC-ADDRESS>][LE]>
Notification handle = 0x0025 value : 32
Notification handle = 0x0025 value : 32
Notification handle = 0x0025 value : 32
Notification handle = 0x0025 value : 32
[<BLE-MAC-ADDRESS>][LE]>char-read-hnd 0x0025
handle : 0x0025 value : 01
Notification handle = 0x0025 value : 32
Notification handle = 0x0025 value : 32
[<BLE-MAC-ADDRESS>][LE]>
So the problem here is , Notification handle listener 'listens' to the serial data and returns the value( 2 -> Hex:32) every 1 second from Bluno (as programmed in Adurinosketch).
But when I try to retrieve this value through the command char-read (tried both by handle & uuid) it always returns 01 ?!!!
Ultimately I want to retrieve this value in my Python code (am using Pexpect for this)
Any help / directions appreciated.
Ok , Here is what I ended up doing in my Python code to retrieve the value
`
child = pexpect.spawn("sudo gatttool -b <BLUNO-MAC-ADDR> -I")
# Connect to the device.
print("Connecting to Bluno...")
child.sendline("connect")
child.expect("Connection successful", timeout=5)
print(" Connected!")
while True:
child.expect("Notification handle = 0x0025 value: ", timeout=10)
child.expect("\r\n", timeout=10)
resp = child.before
print(process_my_data(bytearray.fromhex(resp.decode("utf-8")).decode()))
`
It seems like 802.11 probe requests never contain a real BSSID but rather a wildcard BSSID (e.g. ff:ff:ff:ff:ff:ff) however I can't seem to find any documentation stating this. This Meraki documentation says:
"Because the probe request is sent from the mobile station to the
destination layer-2 address and BSSID of ff:ff:ff:ff:ff:ff all AP's
that receive it will respond."
Does this mean the probe requests never contain real BSSIDs? Even though they sometimes contain SSIDs?
I've seen many Probe Request frame with specific BSSID. For example, in a wireless distribution system(WDS), one AP would probe another AP with specific BSSID since they have the same SSID:
Frame 2022: 310 bytes on wire (2480 bits), 310 bytes captured (2480 bits)
Radiotap Header v0, Length 25
802.11 radio information
IEEE 802.11 Probe Request, Flags: opmP..FT.
Type/Subtype: Probe Request (0x0004)
Frame Control Field: 0x41f3
.... ..01 = Version: 1
.... 00.. = Type: Management frame (0)
0100 .... = Subtype: 4
Flags: 0xf3
.... ..11 = DS status: WDS (AP to AP) or Mesh (MP to MP) Frame (To DS: 1 From DS: 1) (0x3)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...1 .... = PWR MGT: STA will go to sleep
..1. .... = More Data: Data is buffered for STA at AP
.1.. .... = Protected flag: Data is protected
1... .... = Order flag: Strictly ordered
.101 1101 0001 0110 = Duration: 23830 microseconds
Receiver address: 80:1d:30:a5:81:39 (80:1d:30:a5:81:39)
Destination address: 80:1d:30:a5:81:39 (80:1d:30:a5:81:39)
Transmitter address: 4b:3b:67:a4:4d:fe (4b:3b:67:a4:4d:fe)
Source address: 4b:3b:67:a4:4d:fe (4b:3b:67:a4:4d:fe)
BSS Id: ef:e1:f9:51:09:e6 (ef:e1:f9:51:09:e6)
.... .... .... 0010 = Fragment number: 2
0100 1110 1001 .... = Sequence number: 1257
Frame check sequence: 0x853d68c9 [incorrect, should be 0x7089dc98]
[FCS Status: Bad]
HT Control (+HTC): 0x8ab91f91
WEP parameters
Data (245 bytes)
Assume your PC had joined a open wireless network named Starbucks, and when you are at home, if some Rogue AP has the same name with it, then your PC connects to the AP. That's why some clients will actually allow you to optionally select a BSSID as well. And in ad-hoc network, there are many probe requests with specific BSSID.
I cannot find anything that definitely says a probe request will never contain a real BSSID. Yet in all examples I've found online, it is set to ff:ff:ff:ff:ff:ff. Here is another case from the blog of a wireless network expert:
Below shows the detail of Probe Request frame sent by the client which
is a management type with subtype value of 4. As you can see client is
sending it 6Mbps (lowest supported rate by the client). Address fields
are set like below
Address Field-1 = Receiver Address (= Destination Address) ff:ff:ff:ff:ff:ff
Address Field-2 = Transmitter Address (=Source Address) 84:38:38:58:63:D5
Address Field-3 = BSSID ff:ff:ff:ff:ff:ff
In addition I did my own testing and never found a real BSSID broadcast. So while I won't say it never happens, it definitely happens so rarely that it's worth considering that it will never be available.