SIM7020E responds on AT+COPS=? with ERROR - iot

HW: SIM7020E NB-IoT HAT (from waveshare) + RPI3B + NB-IOT SIM from Vodafone CZ.
I am trying connect to NB-IOT network without success (automatic, manual), AT+COPS command show behavior that I don't understood.
AT
OK
ATI
SIM7020E R1752
AT+CGMI
SIMCOM_Ltd
AT+CGMM
SIM7020E
AT+GMM
SIM7020E
AT+CCID
898823900000********
AT+CPIN?
+CPIN: READY
AT+CFUN?
+CFUN: 1
AT+COPS?
+COPS: 0
Response isn't constant, most common value are listed.
AT+CSQ
+CSQ: 15,0
+CSQ: 14,6
+CSQ: 15,0
+CSQ: 14,7
+CSQ: 15,7
+CSQ: 16,0
AT+CMEE=2
Until this moment everything seems OK.
This command in most case end with ERROR +-99% , other time return network list. I don't understood why AT+COPS=? return ERROR.
AT+COPS=?
+CME ERROR: operation not allowed
AT+COPS=?
+COPS: (1,"23003","23003","23003",9),(1,"23001","23001","23001",9),,(0-4),(0-2)
When I try manually connected to existing, non existing network (AT+COPS=1,2,"23003" AT+COPS=1,2,"23001" AT+COPS=1,2,"23099") with inserted Vodafone SIM card it will stop responding to any command until power cycle.
When I try commands without inserted SIM card (AT+COPS=? AT+COPS=1,2,"23003" AT+COPS=1,2,"23001" AT+COPS=1,2,"23099") it will respond CME ERROR: SIM failure or CME ERROR: SIM not inserted.

After problems with SIM7020E NB-IoT HAT, I tried using BC66-TE-B-KIT (devkit with BC66 chip) with same result. After while I found that I don't have configured Default PSD Connection Settings.
Required Default PSD Connection Settings on BC66:
AT+QCGDEFCONT="IP","nb.m2mc"
Required Default PSD Connection Settings on SIM7020x:
AT*MCGDEFCONT="IP","nb.m2mc"
After setting PSD connection to NB-IOT network start working.

Related

Modem AT commands, unable to get into data mode (PPP)

I have a simcom7600 modem which I am trying out via AT commands.
I was able to use AT commands to setup the modem, and connect to an MQTT broker and exchange messages. Now I am trying to figure out how I can do something similar, but then with my own TCP/IP stack. Before diving into the deep there, I would like to confirm that I can get into data mode (PPP) which I am not able to, it seems.
I attached my modem (AT+CGATT=1), and activated it (AT+ACACT=1,1). I verified that I have a carrier/provider (AT+COPS?).
So I thought I was all set to send the ATO (online) commands. But it returns NO_CARRIER every time I try. I have no idea what I am doing wrong.
The logging that confirms above statements:
AT+COPS?
Sending command: AT+COPS?
AT+COPS?[CR][CR][LF]+COPS: 0,0,"NL KPN simyo",7[CR][LF][CR][LF]OK[CR][LF]
AT+cgatt?
Sending command: AT+cgatt?
AT+cgatt?[CR][CR][LF]+CGATT: 1[CR][LF][CR][LF]OK[CR][LF]
AT+cgact?
Sending command: AT+cgact?
AT+cgact?[CR][CR][LF]+CGACT: 1,1[CR][LF]+CGACT: 2,0[CR][LF]+CGACT: 3,0[CR][LF][CR][LF]OK[CR][LF]
ATO
Sending command: ATO
ATO[CR][CR][LF]NO CARRIER[CR][LF]
PS: the [CR][LF] stand for resp. \r and \n, I replace them before I log for ease of reading.
I obviously have to supply more info to the modem, but from this manual I can't seem to figure out which commands I miss, and how I could validate step by step that I am on the right track.
I found this nice document. I'll share it here in case somebody else struggles with this as well.
When I send the following commands:
ATZ (reset)
ATE0 (disable echo)
AT+CGREG? (check registration to PDP network)
AT+CGDCONT=1,"IP","internet" (set APN for my provider, they expect the string "internet")
ATD*99# (start data mode, aka PPP)
then I can break out and move back into PPP with the following commands:
+++ (send + character, wait for 700ms, send + character, wait for 700ms, send + character) => back to AT command mode
ATO (back to data mode)
NOTE: the APN your provider expects, is I think in all cases an easy Google. Your provider will most likely explain how to manually set your APN in case your phone won't do it automatically.

Errors shown by k6 when reaching a bigger number of virtual users

I'm evaluating k6 for my load testing needs. I've set up a basic load test and I'm currently trying to interpret the error messages and result values I get. Maybe someone can help me interpret what I'm seeing:
If I crank up the VUS to about 300, I start seeing error messages in the console and at 500 lots of error messages.
These mostly consist of:
dial tcp XXX:443: i/o timeout
read tcp YYY(local ip):35252->XXX(host ip):443: read: connection reset by peer
level=warning msg="Request Failed" error="unexpected EOF"
Get https://REQUEST_URL/: context deadline exceeded"
I also have problems with several checks:
check errors in which res.status === 0 and res.body === null
check errors in which res.status === 0, but the body contains the correct content
How can res.status be 0 but the body still contains the proper values?
I suspect that I'm reaching the connection limit of my load producing machine and that's why I get the error messages. So I'd have to set up a cluster or move to the Cloud runners!?
The stats generated by k6 show long http_req_blocked values, which I interpret as the time waiting to get a connection port. This seems to indicate that the connection pool of my test running machine is at its limits.
http_req_blocked...........: avg=5.66s min=0s med=3.26s max=59.38s p(90)=13.12s p(95)=20.31s
http_req_connecting........: avg=1.85s min=0s med=280.16ms max=24.27s p(90)=4.2s p(95)=9.24s
http_req_duration..........: avg=2.05s min=0s med=496.24ms max=1m0s p(90)=4.7s p(95)=8.39s
http_req_receiving.........: avg=600.94ms min=0s med=82.89µs max=58.8s p(90)=436.95ms p(95)=2.67s
http_req_sending...........: avg=1.42ms min=0s med=35.8µs max=11.76s p(90)=56.22µs p(95)=62.45µs
http_req_tls_handshaking...: avg=3.85s min=0s med=1.78s max=58.49s p(90)=8.93s p(95)=15.81s
http_req_waiting...........: avg=1.45s min=0s med=399.43ms max=1m0s p(90)=3.23s p(95)=5.87s
Can anyone help me out interpret the results I'm seeing?
You are likely running out of CPU on the runner.
As explained in the http specific metrics of the documentation, you are right about http_req_blocked it is (mostly) the time from when we say we want to make a
request to when we get a socket on which to do it. This is most likely because:
the test runner is running out of CPU and can't handle both making all the other request and starting new
the system under test is running out of CPU and has ... the same problem
You will need to monitor them (you are highly advised to do this regardless) as test at 100% runner CPUs are probably not very representable :) and you likely don't want the system you are testing to get to 100% as well.
The status code === 0 means that we couldn't make the request/read the response ... for some reason, usually explained by the error and error_code.
As I commented if you have status code 0 and a body this is most likely a bug ... at least I don't remember there being a case where this won't be true.
The errors you have list mean (most likely):
dial tcp XXX:443: i/o timeout
this is literally we tried to get a tcp connection and it took too long (probably the reason for the big http_req_blocking)
read tcp YYY(local ip):35252->XXX(host ip):443: read: connection reset by peer
the other side closed the connection .. likely because some timeout was reached - for example, if we don't read over 30 seconds the server decides that we won't read anymore and closes it ... and in the case where CPU is 100% there is a good chance some connection won't get time to be read from.
level=warning msg="Request Failed" error="unexpected EOF"
literally, what it says .. the connection was closed when we totally didn't expect, or more accurately the golang net/http stdlib didn't expect. Likely again a timeout just at a point in the life of the request where the other errors aren't returned.
Get https://REQUEST_URL/: context deadline exceeded"
This is because a request took longer then the timeout (by default 60s) and will at some point be changed to a better error message.

Failed to execute './tools/motelist-linux'

I am using sky motes in cooja simulator of contiki. I want to use collect-view. So I added few sky motes in a simulation and right clicked one of the nodes to start collect-view. Then I clicked 'Program-Nodes' button.
I got the following error:
Programming failed: java.io.IOException: Failed to execute './tools/motelist-linux'.
For sky motes, I noticed the motelist-linux file is here. So I updated the lines to
public static final String MOTELIST_LINUX = "./tools/sky/motelist-linux";
public static final String MOTELIST_MACOS = "./tools/sky/motelist-macos";
I have verified that motelist-linux & motelist-macos files have necessary permissions. But I got the same error again.
Programming failed: java.io.IOException: Failed to execute './tools/sky/motelist-linux'.
How do I get rid of the error? or
Is there any other way to use collect-view?
You need sudo permissions for accessing serial port in linux. Please open cooja with sudo and try. it might work. There is another possibility that serial port of the mote might be opened by another application. Make sure that no other application is using serial port of the mote which you are trying to program.
Credits: https://github.com/contiki-os/contiki/issues/2198

CUPS returns 'complete' on jobs which are still printing

I am communicating with CUPS using IPP protocol. I have all drivers for my printers installed in CUPS (using .ppd file) and printers got latest firmware.
When I query a job which a printer printing right now it says that the job's state is 'complete' before the printer even finish printing. It seems that the CUPS marks the job as 'complete' when it finish 'uploading' the file.
I would not expect this behaviour and I basically need to know when exactly the printer printed last paper for a job.
The code looks as follow. The self.printer().ippPrinter() is an instance of node-ipp and it points to a printer. To read the the state of the job I am using attribute 'job-state'.
var msg = {
"operation-attributes-tag": {
'job-id': id
}
};
self.printer().ippPrinter().execute("Get-Job-Attributes", msg, function(err, res){
var attributes = res['job-attributes-tag'];
self.setAttributes = attributes;
callback.call(self, attributes);
});
Does anyone know why I am having this issue or .. how to make it working?
Thank you!
CUPS can only forward job-states received from the printer. A lot of printer drivers and protocols work like 'fire and forget'.
Usually IPP printers allow CUPS and other clients to monitor the current job-state until it's finished/printed. Some manufacturers don't implement IPP properly and classify submitted jobs as printed - even if the printer has a paper jam!
Conclusion:
If your printer does not fully support IPP you probably won't be able to check for 'printed successfully'.
RFC 8011 5.3.7.1
If the implementation is a gateway to a printing system that never provides detailed status about the Print Job, the implementation MAY set the IPP Job’s state to ’completed’, provided that it also sets the ’queued-in-device’ value in the Job’s "job-state-reasons" attribute
#Jakub, you may well be communicating with CUPS using IPP... But are you sure that CUPS is communicating with the print device via IPP?
You can check this by running
lpstat -h cupsservername -v
This should return the device URI assigned to each print queue, which CUPS uses to address the actual printing device:
If that URI does contain ipp://, ipps://, http:// or https:// CUPS indeed talks IPP to the print device and you should be able to get actually correct status messages.
But if you see socket:// then CUPS is configured to use the AppSocket method (sometimes also called 'HP Jet Direct' or 'IP Direct Printing') to forward jobs. This is a "fire and forget" protocol. Basically it is the same as if you did run netcat print-device 9100 < myprintfile to shovel the printable data to port 9100 of the printer. The CUPS socket backend handling this spooling to the printer will not get any other acknoledgement from the printer than what TCP/IP provides confirming that the last packet was transfered. Hence it has to close down its process and report to the CUPS daemon successful-ok, even if the printer is still busy spitting out lots paper and will maybe never complete the full job because it runs into a paper jam...
If you see lpd:// the situation is similar (but uses port 515).
You may have success with a full status reporting by switching the CUPS-to-printdevice path from AppSocket or LPD to IPP like so:
sudo lpadmin -p printername ipp://ipaddress-of-printer
or
sudo lpadmin -p printername http://ipaddress-of-printer:631

ndisproto sample not reading any traffic

i was trying to get familiar with ndisproto samples in wdk. As per the doc, the -r -n 10 option should read 10 packets off the interface, but nothing in result even if I ping to the interface! The only time it reads traffic is when we use write option.
The sample is same, without any modification other than altering to #define NPROTO_PACKET_FILTER (NDIS_PACKET_TYPE_ALL_LOCAL|NDIS_PACKET_TYPE_PROMISCUOUS).
Is the driver really wired to read traffic originating from other sources?
What am I missing? Any idea how to read/sniff the traffic using ndisproto?
C:\Users\Administrator\Desktop\ndisprot>prottest.exe -r -n 10 \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8}
Option: NumberOfPackets = 10
Trying to access NDIS Device: \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8}
Opened device \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8} successfully!
Trying to get src mac address
GetSrcMac: IoControl success, BytesReturned = 14
Got local MAC: 00:0c:29:23:b1:09
DoReadProc
C:\Users\Administrator\Desktop\ndisprot>prottest.exe -w -n 1 \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8}
Option: NumberOfPackets = 1
Trying to access NDIS Device: \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8}
Opened device \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8} successfully!
Trying to get src mac address
GetSrcMac: IoControl success, BytesReturned = 14
Got local MAC: 00:0c:29:23:b1:09
DoWriteProc
DoWriteProc: sent 100 bytes
DoWriteProc: finished sending 1 packets of 100 bytes each
DoReadProc
DoReadProc: read pkt # 1, 100 bytes
DoReadProc finished: read 1 packets
Got the answer at last. The reason is, the driver sample is specifically designed to send/receive EAP over LAN frames, not all. There are a couple of break statements in NdisprotReceiveNetBufferLists that prevents any other packets other than frames of ethertype 0x888E from reaching the client app.
Same is the case for send.

Resources