I'm using the Raspberry Pi 4 and trying to have an Internet access using the A9G GSM/GPRS+GPS Module.
At first I have install ppp with sudo apt-get install ppp screen elinks
I have create a file with name rnet in path /etc/ppp/peers/rnet:
# My APN internet.vodafone.gr
connect "/usr/sbin/chat -v -f /etc/chatscripts/gprs -T internet.vodafone.gr"
# Communication port:
/dev/ttyS0
# Baudrate
9600
# Assumes that your IP address is allocated dynamically by the ISP.
noipdefault
# Try to get the name server addresses from the ISP.
usepeerdns
# Use this connection as the default route to the internet.
defaultroute
# Makes PPPD "dial again" when the connection is lost.
persist
# Do not ask the remote to authenticate.
noauth
# No hardware flow control on the serial link with GSM Modem
nocrtscts
# No modem control lines with GSM Modem
local
In file gprs in path /etc/chatscripts/gprs I have add the line that need my "MY_4_DIGIT_PIN":
ABORT BUSY
ABORT VOICE
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "NO DIAL TONE"
ABORT "NO ANSWER"
ABORT "DELAYED"
ABORT "ERROR"
# cease if the modem is not attached to the network yet
ABORT "+CGATT: 0"
"" AT
TIMEOUT 12
OK ATH
OK ATE1
# +CPIN provides the SIM card PIN
OK AT+CPIN="MY_4_DIGIT_PIN"
# +CFUN may allow to configure the handset to limit operations to
# GPRS/EDGE/UMTS/etc to save power, but the arguments are not standard
# except for 1 which means "full functionality".
#OK AT+CFUN=1
OK AT+CGDCONT=1,"IP","\T","",0,0
OK ATD*99#
TIMEOUT 22
CONNECT ""
So when I'am trying to starts up the rnet file:
sudo pon rnet
I get this error message in syslog (cat /var/log/syslog | grep pppd):
Oct 14 18:14:22 raspberrypi pppd[3063]: pppd 2.4.7 started by pi, uid 0
Oct 14 18:14:35 raspberrypi pppd[3063]: Connect script failed
Oct 14 18:15:06 raspberrypi pppd[3063]: Connect script failed
Oct 14 18:15:37 raspberrypi pppd[3063]: Connect script failed
...
When I am trying to run the below AT commands, the module seems to be work fine and be able to connected to network:
AT
OK
AT+CPIN?
+CPIN:READY
OK
AT+CREG?
+CREG: 1,1
OK
AT+CGATT?
+CGATT:1
OK
AT+COPS?
+COPS: 0,2,"20205"
AT+CGACT?
+CGACT: 1, 1
AT+HTTPGET="http://www.example.com/"
OK
HTTP/1.1 200 OK
...
So I can't understand if I have have writing something wrong in file rnet or is something else that I am not doing it right. If you have any idea please help me.
The problem was that my A9G Module, was not getting enough power.
Therefore, check if your A9G Module is turned on, before starting the process
and make sure that you have disabled login shell to be accessible over serial,
and also you have enabled the serial interface.
Related
I have a Raspberry PI with this GSM hat, and I want to connect to the mobile network with it. I have tried a couple of combinations of the gprs file to achieve this, but none of them would work.
I tried to go trough the provided instructions on the wiki.
That resulted in an error:
Script /usr/sbin/chat -v -f /etc/chatscripts/gprs finished (pid 1569), status = 0x3
When I start the connection with this command: pppd call gprs &
I get this if I check the /var/log/syslog file:
pppd[991]: pppd 2.4.7 started by pi, uid 0
chat[994]: abort on (BUSY)
chat[994]: abort on (VOICE)
chat[994]: abort on (NO CARRIER)
chat[994]: abort on (NO DIALTONE)
chat[994]: abort on (NO DIAL TONE)
chat[994]: abort on (NO ANSWER)
chat[994]: abort on (DELAYED)
chat[994]: abort on (ERROR)
chat[994]: abort on (+CGATT: 0)
chat[994]: send (AT^M)
chat[994]: timeout set to 12 seconds
chat[994]: expect (OK)
chat[994]: alarm
chat[994]: Failed
pppd[991]: Script /usr/sbin/chat -v -f /etc/chatscripts/gprs finished (pid 993), status = 0x3
pppd[991]: Connect script failed
The /etc/ppp/peers/gprs file:
#!/bin/bash
user "myusername#realm"
connect "/usr/sbin/chat -v -f /etc/chatscripts/gprs"
#/dev/modem
/dev/ttyS0
# Speed of the serial line.
115200
nocrtscts
debug
ipcp-accept-local
ipcp-accept-remote
# Assumes that your IP address is allocated dynamically by the ISP.
noipdefault
# Try to get the name server addresses from the ISP.
usepeerdns
# Use this connection as the default route.
defaultroute
# Makes pppd "dial again" when the connection is lost.
persist
# Do not ask the remote to authenticate.
noauth
Also I changed the pin in the /etc/chatscripts/gprs file:
# +CPIN provides the SIM card PIN
OK "AT+CPIN=1234"
Have you tried putting the APN of the service provider in the third line of the gprs file? The details come along when you purchase the SIM card.
It should be something like:
connect "/usr/sbin/chat -v -f /etc/chatscripts/gprs -T APN"
You may find an example in the following link:
https://www.rhydolabz.com/wiki/?p=16325
I follow the instructions to bootstrap a new Ceph (I'm new to Ceph) cluster.
I got the following error:
sudo cephadm bootstrap --mon-ip <mon-ip>
INFO:cephadm:Verifying podman|docker is present...
INFO:cephadm:Verifying lvm2 is present...
INFO:cephadm:Verifying time synchronization is in place...
INFO:cephadm:Unit systemd-timesyncd.service is enabled and running
INFO:cephadm:Repeating the final host check...
INFO:cephadm:podman|docker (/usr/bin/podman) is present
INFO:cephadm:systemctl is present
INFO:cephadm:lvcreate is present
INFO:cephadm:Unit systemd-timesyncd.service is enabled and running
INFO:cephadm:Host looks OK
INFO:root:Cluster fsid: e08484be-72c1-11ea-a13e-0050563f093a
INFO:cephadm:Verifying IP *<mon-ip>* port 3300 ...
INFO:cephadm:Verifying IP *<mon-ip>* port 6789 ...
ERROR: Failed to infer CIDR network for mon ip *<mon-ip>*; pass --skip-mon-network to configure it later
What does it mean ? How to fix it ?
cephadm is still fairly new. I've tracked a few days ago in:
https://tracker.ceph.com/issues/44828
Please run
ceph config set mon public_network <mon_network>
after bootstrap finished.
Is this the exact command you ran?
sudo cephadm bootstrap --mon-ip *<mon-ip>*
If so you actually need to replace *<mon-ip>* with the actual IP address that you want the monitor daemon to listen on.
For future reference, on that page, any command you see that has a variable surrounded by asterisks is something you would need to replace with an address/host/hostname etc. that applies to your environment.
I am using noble & bleno via node.js to connect to a BLE peripheral from Rasbian, yet something goes wrong and the connection can not be made. I tried multiple different BLE dongles and they all fail the same way. Currently I have a CSR 4.0 attached.
The connections works just fine when being made from OS X, iOS or Android.
Here is the HCI Dump:
2015-11-22 18:36:54.732907 < HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr 00:12:6F:6B:C7:32 type 0
interval 96 window 48 initiator_filter 0
own_bdaddr_type 0 min_interval 6 max_interval 12
latency 0 supervision_to 200 min_ce 4 max_ce 6
2015-11-22 18:36:54.734511 > HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x0c ncmd 1
Error: Command Disallowed
Now when I try a connection via hcitool lecc or gatttool the connection is made - yet trying to write characteristic values fails with Characteristic Write Request failed: Attribute requires authentication before read/write. Is this related?
I am on Linux raspberrypi 4.1.13+ #826 PREEMPT Fri Nov 13 20:13:22 GMT 2015 armv6l GNU/Linux
Unfortunately even security-level high or medium didn't help.
The issue was, that I had a connection from a Central (RPi is Peripheral) and I wanted to connect to another Peripheral, which would put the RPi into Central mode. Apparently this doesn't work with BlueZ.
So I ended up with using 2 Bluetooth Dongles.
If you are looking for another OS: Mac OS X does support this though.
Also I was told that Bluetooth 4.1 Dongles might work with this.
I have freshly installed an application on solaris 5.10 . When checked through ps -ef | grep hyperic | grep agent, process are up and running . When checked the status through svcs hyperic-agent command, the output shows that the agent is in maintenance mode . Application is working fine and I dont have any issues with the application . Please help
There are several reasons that lead to that behavior:
Starter (start/exec property of service) returned status that is different from SMF_EXIT_OK (zero). Than you may check logs:
# svcs -x ssh
...
See: /var/svc/log/network-ssh:default.log
If you check logs, you may see following messages that means, starter script failed or incorrectly written:
[ Aug 11 18:40:30 Method "start" exited with status 96 ]
Another reason for such behavior is that service faults during while its working (i.e. one of processes coredumps or receives kill signal or all processes exits) as described here: https://blogs.oracle.com/lianep/entry/smf_5_fault_retry_models
The actual system that provides SMF facilities for monitoring that is System Contracts. You may determine contract ID of online service with svcs -v (field CTID):
# svcs -vp svc:/network/smtp:sendmail
STATE NSTATE STIME CTID FMRI
online - Apr_14 68 svc:/network/smtp:sendmail
Apr_14 1679 sendmail
Apr_14 1681 sendmail
Than watch events with ctwatch:
# ctwatch 68
CTID EVID CRIT ACK CTTYPE SUMMARY
68 28 crit no process contract empty
Than there are two options to handle that:
There is a real problem with service so it eventually faults. Than debug the application.
It is normal behavior of service, so you should edit and re-import your service manifest, to make SMF less paranoid. I.e. configure ignore_error and duration properties.
I'm using python. I did a yum install memcached followed by a easy_install python-memcached
I used the simple test program from the Help(memcache). When I wasn't getting the proper answers I threw in some print statements:
[~/test]$ cat m2.py
import memcache
mc = memcache.Client(['127.0.0.1:11211'], debug=0)
x = mc.set("some_key", "Some value")
print 'Just set a key and value into the cache (suposedly)'
value = mc.get("some_key")
print 'Just retrieved that value from the cache using the key'
print 'X %s' % x
print 'Value %s' % value
[~/test]$ python m2.py
Just set a key and value into the cache (suposedly)
Just retrieved that value from the cache using the key
X 0
Value None
[~/test]$
The question now is, what have I failed to do in my installation? It appears to be working from an API perspective but it fails to put anything into the memcache share area.
I'm using a virtualbox vm running centos
[~]# cat /proc/version
Linux version 2.6.32-358.6.2.el6.i686 (mockbuild#c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Thu May 16 18:12:13 UTC 2013
Is there a daemon that is supposed to be running? I don't see an obvious named one when I do a ps.
I tried to get pylibmc installed on my vm but was unable to find a working installation so for now will see if I can get the above stuff working first.
I discovered if i ran straight from the python console GUI i get a bit more output if I set debug=1
>>> mc = memcache.Client(['127.0.0.1:11211'], debug=1)
>>> mc.stats
{}
>>> mc.set('test','value')
MemCached: MemCache: inet:127.0.0.1:11211: connect: Connection refused. Marking dead.
0
>>> mc.get('test')
MemCached: MemCache: inet:127.0.0.1:11211: connect: Connection refused. Marking dead.
When I try to use per the example telnet to connect to the port i get a connection refused:
[root#~]# telnet 127.0.0.1 11211
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
[root#~]#
I tried the instructions I found on the net for configuring telnet so localhost wouldn't be disabled:
vi /etc/xinetd.d/telnet
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = no
}
And then ran the commands to restart the service(s):
service iptables stop
service xinetd stop
service iptables start
service xinetd start
service iptables stop
I ran with both cases (iptables started and stopped) but it has no effect. So I am out of ideas. What do I need to do to make it so the PORT will be allowed? if that is the problem?
Or is there a memcached service that needs to be running that needs to open up the port ?
well this is what it took to get it working: ( a series of manual steps )
1) su -
cd /var/run
mkdir memcached # this was missing
In the memcached file I added "-l 127.0.0.1" to the OPTIONS statement. It's apparently a listen option. Do this for steps 2 & 3. I'm not certain which file is actually used at runtime.
2) cd /etc/sysconfig
cp memcached memcached.old
vi memcached
3) cd /etc/init.d
cp memcached memcached.old
vi memcached
4) Try some commands to see if the server starts now
/etc/init.d/memcached start
/etc/init.d/memcached status
/etc/init.d/memcached stop
/etc/init.d/memcached restart
I tried opening a browser, but it never seemed to actually display anything so I don't really know how valid this approach is. I'm not running apache or anything like this so perhaps its not relevant to my cause. Perhaps I would have to supply a ?key=blah or something.
5) http://127.0.0.1:11211
6) Now it should be ready to go. If one runs the test shown with the following it should work. At least it did for me. doing the help(memcache) will display a simple program. just paste that in and it should work just fine.
[~]$ python
>>> import memcache
>>> help(memcache)