Got strange stuff. Setup: VirtualBox + CentOs7 + python3.6 + scapy2.4.0
Got network with only 4-5 hosts active: gateway, CentOs in VirtualBos, PC on which VirtualBox running and something else.
Trying to do:
ans, unans = sr(IP(dst='10.10.10.1-100')/ICMP(), iface = 'enp0s3', retry=0, timeout=1)
Begin emission: ...
Received 1822 packets, got 99 answers, remaining 1 packets
ans
Results: TCP:0 UDP:0 ICMP:99 Other:0
unans
Unanswered: TCP:0 UDP:0 ICMP:1 Other:0
ans[x] - are legit ICMP Reply packets.
unans[0] - no ICMP reply from CentOs VM itself
So looks like everything is alive instead of 4-5 hosts which actually are alive
What could be the possible reason ?
You want to know the possible reason, but scapy is not giving you enough details. So use tcpdump:
$ sudo tcpdump -e -c 200 icmp
Send the probe packets while tcpdump is running, in order to view address and timing details. It is possible you are seeing lots of perfectly normal ICMPs, for example port unreachable, or network unreachable. Tcpdump will tell you exactly what went over the network interface.
Related
when try to send an ipv6 packet i get
WARNING: Mac address to reach destination not found. Using broadcast.
Finished sending 1 packets
when i send a packet to specific destination using ipv6 as following:
syn = IPv6(dst=destination,src=source) / TCP(sport=555,dport=80,flags="S")
syn_ack = sr1(syn,timeout=11)
this happend if i use the ipv6 while on ipv4 i dont see this issue
scapy version :2.4.3
platform: windows server 2019
I have a VM backed by vCenter.
vCenter ESXi have physical adapter "Broadcom BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller" and SR-IOV enabled on this.
VM is connected to 1mgmt network (vmxnet3) and 2 SR-IOV adapters (SRIOVPassthrough).
Upon booting of the VM, only 2 networks shown up. (1mgmt and 1SR-IOV).
Journalctl -k logs showed following error.
[ 4832.408471] bnxt_en 0000:13:00.0 (unnamed net_device) (uninitialized): Error (timeout: 500015) msg {0x0 0x0} len:0
[ 4832.408930] bnxt_en: probe of 0000:13:00.0 failed with error -1
Reboot of machine did not help at all.
For the successful one adapter
bnxt_en 0000:03:00.0 eth1: NIC Link is Up, 25000 Mbps full duplex, Flow control: ON - receive & transmit
bnxt_en 0000:03:00.0 eth1: FEC autoneg off encodings: None
I did rescan of the pci devices and did multiple times reboot without any success.
Any pointers would be really helpful
We've got a similar issue and were able to fix it.
In our case we had the same error message on Debian 10, 11 and Oracle Linux 8 but we installed it directly on hardware without an hypervisor.
But it could be the same issue cause you're using passthrough.
There are two ways to fix it:
Usage of UEFI Boot
Disable PXE Boot and keep Bios / Legacy Boot
Both options fixed it.
Disabling PXE didn't work for us, but we can get the ports back online, by running
echo 0000:af:00.0 > /sys/bus/pci/drivers/bnxt_en/bind
Where 0000:af:00.0 is the PCI number for the port, which can be gotten from dmesg | grep bnxt_en and looking for the port or ports that failed.
For some strange reason unknown to me, my RPi appears to have been set incorrectly to UTC +65s. The output I receive is the following:
sudo ntpd -gq
ntpd: time set -65.706156s
I have tried stopping and restarting ntp server (no effect).
When I check the sync servers using the following command, I do receive a ping back so it's not a case of the servers not responding, or a firewall issue:
grep -P "^server" /etc/ntp.conf
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst
ping -c 1 0.debian.pool.ntp.org
PING 0.debian.pool.ntp.org (193.1.219.116) 56(84) bytes of data.
64 bytes from tbag.heanet.ie (193.1.219.116): icmp_req=1 ttl=51 time=18.8 ms
--- 0.debian.pool.ntp.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 18.818/18.818/18.818/0.000 ms
I'm at a loss as to how to correct this.
UPDATE:
Running the ntpq -p command yields the following info:
remote refid st t when poll reach delay offset jitter
==============================================================================
*adsl-172-10-0-1 117.70.*.110 4 u 2 64 7 0.617 -0.070 0.109
Is this the ntp server that I'm trying to sync to - because that IP belongs to CHINANET (I don't know how or why).
I also tried to manually set the RPi time, after stopping ntp service, setting the time correctly and restarting the service.
What I noticed was that the time was correctly set for a good 5 seconds, before reverting back to it's 65s offset. So it appears that this is the issue.
Found the solution as described in post 6 of the link:
http://forum.openmediavault.org/index.php/Thread/13035-Raspberry-Pi-NTP-service-not-using-etc-ntp-conf/
Basically, connecting the RPi to the network, the DHCP server acts as the NTP server and creates a copy of the ntp.conf file in the location /var/lib/ntp/ntp.conf.dhcp
This file overrides the default /etc/ntp.conf file, so deleting it and then stopping the ntp service, performing a resync, and then starting the service is the only way to resolve this.
The command for resync is:
sudo ntpdate -b pool.ntp.org
The original issue was that the ntp server was syncing with a CHINANET server and causing a 65s offset, which I suspect is down to a misconfigured DCHP/NTP server on our network.
I wrote a minuscule script to test an SMTP connection with Net::SMTP:
#!/usr/bin/perl -w
use strict;
use Net::SMTP;
my $smtp = Net::SMTP->new( 'mypc', Port => 10025, Timeout => 30, Debug => 1 );
die "Couldn't connect to SMTP server" unless $smtp;
An SMTP server is running on mypc:10025 and dumps all I/O it does. When I execute the script from a Debian Linux machine (64bit, Perl v5.20.2), the SMTP server shows I/O activity and everything works as expected:
zb226#debian8:~$ ./net_smtp.pl
Net::SMTP>>> Net::SMTP(2.33)
Net::SMTP>>> Net::Cmd(2.30)
Net::SMTP>>> Exporter(5.71)
Net::SMTP>>> IO::Socket::INET(1.35)
Net::SMTP>>> IO::Socket(1.38)
Net::SMTP>>> IO::Handle(1.35)
Net::SMTP=GLOB(0x118adc0)<<< 220 Hi
Net::SMTP=GLOB(0x118adc0)>>> EHLO localhost.localdomain
Net::SMTP=GLOB(0x118adc0)<<< 250 OK
When I execute this on the Windows 8 machine (64bit, Strawberry Perl 5.22.0), no connection is established. I can see this by the total absence of I/O in the SMTP server. Net::SMTP does not connect. The script just dies, as is expected in this case:
C:\test>perl -w net_smtp.pl
Couldn't connect to SMTP server at net_smtp.pl line 5.
Observations:
Interestingly, the script dies after what feels like 3 seconds, not the 30 seconds I specified.
I can use telnet.exe to connect to the SMTP server and it shows I/O activity.
I have tried turning off the Windows firewall completely without any improvement.
I had an admin disable the corporate anti-virus software temporarily without any improvement.
Updating Strawberry Perl to the currently recommended 5.24.0.1 didn't help either.
I'm not sure what to try next.
Edit: Tried a small IO::Socket::INET script to verify perl can actually connect on this Windows PC:
#!/usr/bin/perl
use strict;
use IO::Socket::INET;
my #hosts = qw/ mypc:10025 /;
foreach my $host ( #hosts ) {
my $open = defined IO::Socket::INET->new(PeerAddr => $host, Timeout => 5) || 0;
printf "Probed %s -> %s \n", $host, $open ? 'ok' : 'NOK';
}
I see I/O in the SMTP server and it works as expected:
C:\test>perl -w io_socket.pl
Probed mypc:10025 -> ok
Based on the information from the other answer the underlying problem is, that
the hostname used resolves to both an IPv4 and IPv6 address,
the SMTP server is only listening at the IPv4 address or the IPv6 address is blocked by a firewall,
and a recent version of Net::SMTP is in use which contrary to older versions transparently supports IPv6 and IPv4.
Because if the IPv6 support and the commonly used preference for the newer IPv6 against IPv4 Net::SMTP will resolve the hostname and then try the IPv6 address - and fail to connect. Direct use of IO::Socket::INET instead works because it is doing only IPv4 (contrary to IO::Socket::IP used by Net::SMTP).
The reason it works on Linux and not on Windows is probably the different version of Perl: the new version of Net::SMTP with built-in IPv6 (and SSL) support ships only since Perl 5.22 as a CORE module, i.e. the Perl on Windows (5.22) has the version with IPv6 support while the Perl on Linux (5.20) does not.
There are several ways to fix the problem:
use the IPv4 address directly instead of the hostname
make the SMTP server listen on both IPv4 and IPv6
or specify the address family to use, i.e.
my $smtp = Net::SMTP->new( 'mypc', ..., Domain => AF_INET );
Following this discussion, I found that the problem is related to IPv6. Opening C:\strawberry\perl\lib\Net\SMTP.pm and changing the line...
our #ISA = ('Net::Cmd', $inet6_class || 'IO::Socket::INET');
...to...
our #ISA = ('Net::Cmd', 'IO::Socket::INET');
...makes the original script run:
C:\test>perl -w net_smtp.pl
Net::SMTP>>> Net::SMTP(3.08)
Net::SMTP>>> Net::Cmd(3.08)
Net::SMTP>>> Exporter(5.72)
Net::SMTP>>> IO::Socket::INET(1.35)
Net::SMTP>>> IO::Socket(1.38)
Net::SMTP>>> IO::Handle(1.36)
Net::SMTP=GLOB(0x58e8fc)<<< 220 Hi
Net::SMTP=GLOB(0x58e8fc)>>> EHLO localhost.localdomain
Net::SMTP=GLOB(0x58e8fc)<<< 250 OK
For now, I'm relieved because I can continue my work, but if anybody has further clues as to how to avoid this ugly patch, I'll happily accept an elaborated answer.
Edit: Correspondingly and without patching, disabling IPv6 does the trick as well.
My Dear All the Greatest Lords,
Some expert listed the details of connecting to a wireless network as,
This is a step-to-step guide for connecting to a WPA/WPA2 WiFi network via the Linux command line interface. The tools are:
wpa_supplicant
iw
ip
ping
iw is the basic tool for WiFi network-related tasks, such as finding the WiFi device name, and scanning access points. wpa_supplicant is the wireless tool for connecting to a WPA/WPA2 network. ip is used for enabling/disabling devices, and finding out general network interface information.
The steps for connecting to a WPA/WPA2 network are:
Find out the wireless device name.
$ /sbin/iw dev
phy#0
Interface wlan0
ifindex 3
type managed
The above output showed that the system has 1 physical WiFi card, designated as phy#0. The device name is wlan0. The type specifies the operation mode of the wireless device. managed means the device is a WiFi station or client that connects to an access point.
Check that the wireless device is up.
$ ip link show wlan0
3: wlan0: (BROADCAST,MULTICAST) mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
link/ether 74:e5:43:a1:ce:65 brd ff:ff:ff:ff:ff:ff
Look for the word "UP" inside the brackets in the first line of the output.
In the above example, wlan0 is not UP. Execute the following command to bring it up:
$ sudo ip link set wlan0 up
[sudo] password for peter:
Note: you need root privilege for the above operation.
If you run the show link command again, you can tell that wlan0 is now UP.
$ ip link show wlan0
3: wlan0: (NO-CARRIER,BROADCAST,MULTICAST,UP) mtu 1500 qdisc mq state DOWN mode DEFAULT qlen 1000
link/ether 74:e5:43:a1:ce:65 brd ff:ff:ff:ff:ff:ff
Check the connection status.
$ /sbin/iw wlan0 link
Not connected.
The above output shows that you are not connected to any network.
Scan to find out what WiFi network(s) are detected
$ sudo /sbin/iw wlan0 scan
BSS 00:14:d1:9c:1f:c8 (on wlan0)
... sniped ...
freq: 2412
SSID: stanford
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: (0x0000)
... sniped ...
The 2 important pieces of information from the above are the SSID and the security protocol (WPA/WPA2 vs WEP). The SSID from the above example is stanford. The security protocol is RSN, also commonly referred to as WPA2. The security protocol is important because it determines what tool you use to connect to the network.
Connect to WPA/WPA2 WiFi network.
This is a 2 step process. First, you generate a configuration file for wpa_supplicant that contains the pre-shared key ("passphrase") for the WiFi network.
$ sudo -s
[sudo] password for peter:
$ wpa_passphrase stanford >> /etc/wpa_supplicant.conf
...type in the passphrase and hit enter...
wpa_passphrase takes the SSID as the single argument. You must type in the passphrase for the WiFi network stanford after you run the command. Using that information, wpa_passphrase will output the necessary configuration statements to the standard output. Those statements are appended to the wpa_supplicant configuration file located at /etc/wpa_supplicant.conf.
Note: you need root privilege to write to /etc/wpa_supplicant.conf.
$ cat /etc/wpa_supplicant.conf
# reading passphrase from stdin
network={
ssid="stanford"
#psk="testtest"
psk=4dfe1c985520d26a13e932bf0acb1d4580461dd854ed79ad1a88ec221a802061
}
The second step is to run wpa_supplicant with the new configuration file.
$ sudo wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant.conf
-B means run wpa_supplicant in the background.
-D specifies the wireless driver. wext is the generic driver.
-c specifies the path for the configuration file.
Use the iw command to verify that you are indeed connected to the SSID.
$ /sbin/iw wlan0 link
Connected to 00:14:d1:9c:1f:c8 (on wlan0)
SSID: stanford
freq: 2412
RX: 63825 bytes (471 packets)
TX: 1344 bytes (12 packets)
signal: -27 dBm
tx bitrate: 6.5 MBit/s MCS 0
bss flags: short-slot-time
dtim period: 0
beacon int: 100
Obtain IP address by DHCP
$ sudo dhclient wlan0
Use the ip command to verify the IP address assigned by DHCP. The IP address is 192.168.1.113 from below.
$ ip addr show wlan0
3: wlan0: mtu 1500 qdisc mq state UP qlen 1000
link/ether 74:e5:43:a1:ce:65 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.113/24 brd 192.168.1.255 scope global wlan0
inet6 fe80::76e5:43ff:fea1:ce65/64 scope link
valid_lft forever preferred_lft forever
Add default routing rule.
The last configuration step is to make sure that you have the proper routing rules.
$ ip route show
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.113
The above routing table contains only 1 rule which redirects all traffic destined for the local subnet (192.168.1.x) to the wlan0 interface. You may want to add a default routing rule to pass all other traffic through wlan0 as well.
$ sudo ip route add default via 192.168.1.254 dev wlan0
$ ip route show
default via 192.168.1.254 dev wlan0
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.113
ping external ip address to test connectivity
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=48 time=135 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=48 time=135 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=48 time=134 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 134.575/134.972/135.241/0.414 ms
The above series of steps is a very verbose explanation of how to connect a WPA/WPA2 WiFi network. Some steps can be skipped as you connect to the same access point for a second time. For instance, you already know the WiFi device name, and the configuration file is already set up for the network. The process needs to be tailored according to your situation.
Thoroughly followed the above tutorial, I failed to connect the wireless router.
(working as root)
......
#wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf -D wext
#iw wlan0 link
Not connected.
Even I disable the WPA authentication using,
iwconfig wlan0 essid XXXXXXXXXXXXX
of no avail.
But the GNOME wireless tray is functioning(can select, connect, disconnect etc.)
Thank you a lot in advance.
Latest wpa_supplicant is able to do all the job itself.
The wpa_supplicant option you wrote seem to me ok.
But please, check the options in the file "/etc/wpa_supplicant.conf", if it readable and is well written (ssid,wpa,password correct....)