I am struggling to make BLE connetion with raspberry pi 3.
When I make 1:1 connection, it works fine.
root#raspberrypi:~# hciconfig hci0 leadv
root#raspberrypi_SLAVE:~# echo "connect B8:27:EB:5D:C6:1E 1" > /sys/kernel/debug/bluetooth/6lowpan_control
root#raspberrypi:~# hcitool con
Connections:
< LE B8:27:EB:5D:C6:1E handle 64 state 1 lm MASTER
root#raspberrypi:~# ping -6 -I bt0 2005::b827:ebff:fe5c:b7a0
PING 2005::b827:ebff:fe5c:b7a0(2005::b827:ebff:fe5c:b7a0) from 2005::1 bt0: 56 data bytes
64 bytes from 2005::b827:ebff:fe5c:b7a0: icmp_seq=1 ttl=64 time=164 ms
64 bytes from 2005::b827:ebff:fe5c:b7a0: icmp_seq=2 ttl=64 time=89.1 ms
64 bytes from 2005::b827:ebff:fe5c:b7a0: icmp_seq=3 ttl=64 time=62.9 ms
64 bytes from 2005::b827:ebff:fe5c:b7a0: icmp_seq=4 ttl=64 time=85.6 ms
64 bytes from 2005::b827:ebff:fe5c:b7a0: icmp_seq=5 ttl=64 time=58.9 ms
--- 2005::b827:ebff:fe5c:b7a0 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 58.958/92.193/164.287/37.976 ms
But when I connect 2 or more devices, It does not work!!
root#raspberrypi:~# hciconfig hci0 leadv
root#raspberrypi_SLAVE2:~# echo "connect B8:27:EB:5D:C6:1E 1" > /sys/kernel/debug/bluetooth/6lowpan_control
root#raspberrypi:~# hcitool con
Connections:
> LE B8:27:EB:C2:60:83 handle 65 state 1 lm SLAVE
> LE B8:27:EB:5C:B7:A0 handle 64 state 1 lm SLAVE
root#raspberrypi:~# ping -6 -I bt0 2005::b827:ebff:fe5c:b7a0
PING 2005::b827:ebff:fe5c:b7a0(2005::b827:ebff:fe5c:b7a0) from 2005::1 bt0: 56 data bytes
^C
--- 2005::b827:ebff:fe5c:b7a0 ping statistics ---
28 packets transmitted, 0 received, 100% packet loss, time 28097ms
Can anyone tell me how to connect multiple devices with a BLE 6LoWPAN Border Router.
I solved this problem.
The problem was newest Laspbian kernel, version 4.14.y.
After rebuild 4.9.80-v7+, it works fine.
This post is almost 2 years old but it helped me a lot!
Had exactly the same error on my Raspberry Pis 4 running with Raspbian.
Looking at my kernel version with
uname -a
showed that it had the version 4.19.97-v7l+.
I found it a bit strange that downgrading to 4.9.80-v7+ should solve the issue so instead I upgraded to the newest kernel 5.4.40-v7l+ simply with
sudo rpi-update
and my BLE 6loWPAN connections worked just fine!
So it seems that kernel-versions between 4.14 and 4.19 have some issues with 6lowPAN over BLE. Couldn't find the reason for this on Google but updating fixed it!
Related
I installed three operating systems(let's say 3 hosts) in VMware, all with NAT mode. 3 hosts are named centos, centos 1,centos 2.(As the pic shows below)
3 hosts in VMware
The first host's IP address is 192.168.248.132, the second is 192.168.248.136, and we don't need to know third host's IP because it's not related to this issue.
I typed the command "ping 192.168.248.136", and the output on the screen is:
PING 192.168.248.136 (192.168.248.136) 56(84) bytes of data.
64 bytes from 192.168.248.136: icmp_seq=1 ttl=64 time=0.435 ms
64 bytes from 192.168.248.136: icmp_seq=2 ttl=64 time=0.313 ms
64 bytes from 192.168.248.136: icmp_seq=3 ttl=64 time=0.385 ms
This means ping command has succeeded and host no.2(whose IP addr is 192.168.248.136) has received ICMP and replied.
Meanwhile, I typed the command "tcpdump -i ens33" in host no.3. If everything had worked correctly, host no.3 would not have received any data between host no.1 and host no.2, because ICMP is neither broadcast nor multicast, so only host no.1 and 2 can send and receive. Also, host no.3's network interface is not promiscuous mode, so it can only receive it's own frame. The output from host no.3 below can show it is not promiscuous mode.
[root#localhost usr]# ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.248.137 netmask 255.255.255.0 broadcast 192.168.248.255
inet6 fe80::b488:bc2c:3770:a95f prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:0d:dc:86 txqueuelen 1000 (Ethernet)
RX packets 351081 bytes 512917768 (489.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 34947 bytes 2166260 (2.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
flag is 4163<UP,BROADCAST,RUNNING,MULTICAST>, "PROMISC" is not mentioned, so it is not promiscuous mode.
However, after I typed "tcpdump -i ens33" in host no.3, something appeared on the screen:
06:28:11.511233 IP 192.168.248.132 > 192.168.248.136: ICMP echo request, id 3137, seq 5, length 64
06:28:11.511503 IP 192.168.248.136 > 192.168.248.132: ICMP echo reply, id 3137, seq 5, length 64
Host no.3 received the dataflow between no.1 and 2, and this was supposed to be sent to no.2, but no.3 received it.
So here comes the question, why can host no.3 receive packet which was not supposed to be sent to it?
tcpdump by default activates "promiscuous mode" making it able to see anything on the network it is connected to (even if not explicitly sent to it).
the three hosts seem to be connected to a virtual switch that do not isolate the hosts from each other.
Mongodb 4.4.14 is intalled in Mac OS Monterey version 12.4.
Connection from Robo 3T installed in Mac itself works.
Connection from mongo cli in mac itself also works:
$ mongo
MongoDB shell version v4.4.14
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("ab8018b3-c4f2-4236-8c3b-abef5468bb03") }
MongoDB server version: 4.4.14
---
The server generated these startup warnings when booting:
2022-06-02T15:59:13.574+05:30: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
---
MongoDB Enterprise >
While connecting from Studio 3T installed in Windows Virtual Machine (it is Parallels software, NOT VirtualBox) to this mongodb 4.4, receiving the following error:
Connection failed.
SERVER [192.168.1.2:27017] (Type: UNKNOWN) CONNECTING
Details:
Timed out after 5000 ms while waiting to connect. Client view of cluster state is {type=UNKNOWN, servers=[{address=192.168.1.2:27017, type=UNKNOWN, state=CONNECTING}]
Note that the Mac host IP address is 192.168.1.2. And ping from Windows VM to Mac works fine. Also disabled the firewall in Windows.
C:\Windows\system32>ping 192.168.1.2
Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time<1ms TTL=64
Reply from 192.168.1.2: bytes=32 time<1ms TTL=64
Reply from 192.168.1.2: bytes=32 time<1ms TTL=64
Reply from 192.168.1.2: bytes=32 time<1ms TTL=64
Ping statistics for 192.168.1.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Windows\system32>
How to resolve this error?
In the parallels software network configuration, selected "Shared Network (Recommended)" and it worked fine.
I have a vm created in GCP and I setup kafka in it. I had changed the advertised listeners to the external public ip of the vm.
But when ever I try to connect from the local laptop I keep getting this error.
I checked the connectivity to machine from ping and I am getting response
PING 34.69.37.118 (34.69.37.118): 56 data bytes
64 bytes from 34.69.37.118: icmp_seq=0 ttl=54 time=266.223 ms
64 bytes from 34.69.37.118: icmp_seq=1 ttl=54 time=290.133 ms
64 bytes from 34.69.37.118: icmp_seq=2 ttl=54 time=264.678 ms
64 bytes from 34.69.37.118: icmp_seq=3 ttl=54 time=263.067 ms
^C
--- 34.69.37.118 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 263.067/271.025/290.133/11.088 ms
If your client (Kafka Producer) it is outside of the VM, you need to expose the following:
listeners=INTERNAL://0.0.0.0:19092,EXTERNAL://0.0.0.0:9092
listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT
advertised.listeners=INTERNAL://vm-address:19092,EXTERNAL://host-address:9092
inter.broker.listener.name=INTERNAL
Now your producer should use 19092
ubuntu#ip-172-31-45-35:~/cse303.p2$ node qloader.js
events.js:72
throw er; // Unhandled 'error' event
^
Error: failed to connect to [52.33.215.205:27017]
at null.<anonymous> (/home/ubuntu/cse303.p2/node_modules/mongoose/node_modules/mongodb/lib/mong odb/connection/server.js:556:74)
at EventEmitter.emit (events.js:106:17)
at null.<anonymous> (/home/ubuntu/cse303.p2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/connection_pool.js:156:15)
at EventEmitter.emit (events.js:98:17)
at Socket.<anonymous> (/home/ubuntu/cse303.p2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/connection.js:534:10)
at Socket.EventEmitter.emit (events.js:95:17)
at net.js:441:14
at process._tickCallback (node.js:415:13)
above is the error message i got when trying to do 'node' to run my database.
I have set all my security group to 'all traffic', I suppose it's not a problem with my security group.
When I ping that ip address it can connect, this is what is shows.
ubuntu#ip-172-31-45-35:~/cse303.p2$ ping 52.33.215.205
PING 52.33.215.205 (52.33.215.205) 56(84) bytes of data.
64 bytes from 52.33.215.205: icmp_seq=1 ttl=63 time=1.37 ms
64 bytes from 52.33.215.205: icmp_seq=2 ttl=63 time=1.27 ms
64 bytes from 52.33.215.205: icmp_seq=3 ttl=63 time=1.21 ms
64 bytes from 52.33.215.205: icmp_seq=4 ttl=63 time=1.25 ms
^C
--- 52.33.215.205 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.218/1.281/1.376/0.072 ms
So it can connect to that address, but when i add that port 27017, it does't work.
ubuntu#ip-172-31-45-35:~/cse303.p2$ ping 52.33.215.205:27017
ping: unknown host 52.33.215.205:27017
I am not sure whether my mongod is running properly, this is what i got.
ubuntu#ip-172-31-22-135:~$ sudo service mongodb start
mongodb start/running, process 1382
You can't ping a port. Ping is ICMP and not TCP or UDP. The line mongodb start/running, process 1382 indicates that MongoDB is running.
It is likely that MongoDB's bind IP is set to 127.0.0.1. In the MongoDB configuration, check the value of bind_ip. It is likely set to localhost (127.0.0.1) and thus will only accept connections from the local VM.
There are many guides out there that can help, such as this or this.
#!/usr/bin/perl
use Net::Ping;
$p = Net::Ping->new();
my $main_ip="$ARGV[0]";
if ($p->ping($main_ip,1)){
$result=true;
print "$main_ip is alive \n";
}else{
print "$main_ip is down \n";
}
I am using above perl script to ping check the server. It worked fine all the cases except for IP 192.168.0.168.
$ perl test.pl 192.168.0.168
192.168.0.168 is down
]$ ping 192.168.0.168
PING 192.168.0.168 (192.168.0.168) 56(84) bytes of data.
64 bytes from 192.168.0.168: icmp_seq=1 ttl=64 time=0.304 ms
64 bytes from 192.168.0.168: icmp_seq=2 ttl=64 time=0.355 ms
64 bytes from 192.168.0.168: icmp_seq=3 ttl=64 time=2.94 ms
64 bytes from 192.168.0.168: icmp_seq=4 ttl=64 time=0.388 ms
--- 192.168.0.168 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3292ms
rtt min/avg/max/mdev = 0.304/0.997/2.944/1.124 ms
]$ ping 192.168.0.18
PING 192.168.0.18 (192.168.0.18) 56(84) bytes of data.
From 192.168.0.181 icmp_seq=2 Destination Host Unreachable
From 192.168.0.181 icmp_seq=3 Destination Host Unreachable
From 192.168.0.181 icmp_seq=4 Destination Host Unreachable
--- 192.168.0.18 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3292ms
pipe 3
]$ perl test.pl 192.168.0.18
192.168.0.18 is down
I had no clue even I have increase ping timeout but the results same
The only problem i can think of is, that the ping command uses the ICMP protocol as default, while Net::Ping uses TCP. You can switch Net::Ping to ICMP by creating your object like this:
my $p = Net::Ping->new( 'icmp' );
Take note, that making ICMP pings requires root privilege on Unix.
In order to send icmp packets you must have rights to create raw sockets, i.e. have root rights.
I suppose you running ping.pl as ordinary user, but you need to be root
ls -al `which ping`
-rws--x--x 1 root root 39640 Dec 17 2011 /bin/ping
^
|
suid bit
ping program has a suid bit, which allows to run ping program with root rights.
By default Net::Ping tries to connect to echo port (7/tcp), if it gets ECONNREFUSED - this means that host is up but refuses connection (nothing is listening on that port). if connect breaks on timeout, this means that host is down.
But! I can block all connection to 7/tcp by firewall:
iptables -I INPUT -p tcp --dport 7 -j DROP
and... voila, i get down instead of alive
So, you should check firewall on your failure pinged host