i have got modem with double sim slot to insert two different sim cards.
mmcli output:
-----------------------------------
3GPP EPS | ue mode of operation: csps-2
| initial bearer path: /org/freedesktop/ModemManager1/Bearer/2
| initial bearer ip type: ipv4v6
-----------------------------------
SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/3
| sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/2
| slot 2: /org/freedesktop/ModemManager1/SIM/3 (active)
-----------------------------------
Bearer | paths: /org/freedesktop/ModemManager1/Bearer/3
Is there a possibility to get two activated wwan's from this sim cards? I can switch between them but i want to try to get two of them at once.
Thanks a lot for any suggestions.
It may be unworkable. Producer not provide dual sim support for model of modem which i have.
Additional information in this link Quectel Specification. There are no information about 'dual sim' unlike these SCx modems
Related
My question is much more conceptual than ever. I'd like to describe a good scenario using the Cucumber feature file where I have to have for each row of my Data table a new access token from the Identity Provider.
I.e
Scenario:
Given <Code Authorization>
And <Access Token>
And The client has the following information
| email | FirstName | Phone |
| xpto# | Richard | 343242|
When the client via Post /xpto
Then The API response a Json file
| code | response |
| 200 | xpto |
I'll use a Data Table for this kind of approach. However, I cannot give a static Access Token because it will expire. I should get a new one every time when my test run but It is not my test it self. The Token is just a Data that I have to have to test my scenario.
Is it ok call a REST in an Given Step? If I do this I am mixing up the objective of my scenarios.
Any thougts are welcome not for your mind but by the book. :-)
Kind Regards,
It seems that you need the token in order to set up the scenario. In that case it is fine to have that in a Given step. You can perform REST or other calls in step definitions for that Given step. For ex: It may look something like below. You can change wordings as you like but try to word it in a manner that shows initial state of the application.
Given I have a token for this scenario
And The client has the following information
| email | FirstName | Phone |
|xpto# | Richard | 343242|
...
...
Given steps are meant to establish a given state. It is considered best practice in BDD. You can find this information in official BDD docs here
Also , if you want to read more about the purpose and structure of Given , When and Then , be sure to have a look here
I build open cryptoki library from source and try to initialize the software token.
but when running pkcsconf -I -c 3 for initializing the token, I get the following Error message:
Enter the SO PIN:
Enter a unique token label: poef
Error initializing token: 0xA4 (CKR_PIN_LOCKED)
The token Info looks like this:
$ pkcsconf -t
Token #3 Info:
Label: IBM OS PKCS#11
Manufacturer: IBM Corp.
Model: IBM SoftTok
Serial Number: 123
Flags: 0xD80045 (RNG|LOGIN_REQUIRED|CLOCK_ON_TOKEN|USER_PIN_TO_BE_CHANGED|SO_PIN_COUNT_LOW|SO_PIN_LOCKED|SO_PIN_TO_BE_CHANGED)
Sessions: 0/18446744073709551614
R/W Sessions: 18446744073709551615/18446744073709551614
PIN Length: 4-8
Public Memory: 0xFFFFFFFFFFFFFFFF/0xFFFFFFFFFFFFFFFF
Private Memory: 0xFFFFFFFFFFFFFFFF/0xFFFFFFFFFFFFFFFF
Hardware Version: 1.0
Firmware Version: 1.0
Time: 08:07:03
So as I understand I should reset the Software Token, to get a default SO PIN and could initialize the token, to use it. But I cannot find anything about that in the official docs.
To reset everything, you have to delete the content of /var/opencryptoki/swtok
Have you seen this page https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lxce/lxce_initializing_ep11token.html
I have no familiarity with this specific SW P11 implementation but the command sequence here seems to make sense.
The default pin is 12345678, you would want to change that, initialize the user pin, change that. Theory being that in that sequence you wont be locked.
I'm trying to install an applet on a SIM card wich supports java card V3.0.4. When I try to establish a secure channel to load the applet, the card returns an error:
mode_211
enable_trace
establish_context
card_connect
select -AID A000000151000000
Command --> 00A4040008A000000151000000
Wrapped command --> 00A4040008A000000151000000
Response <-- 6F108408A000000151000000A5049F6501FF9000
open_sc -security 1 -keyind 0 -keyver 0 -mac_key 79AA24D80FF0056101F1D9AB6DCAF0E6
-enc_key 79AA24D80FF0056101F1D9AB6DCAF0E6
Command --> 80CA006600
Wrapped command --> 80CA006600
Response <-- 664A734806072A864886FC6B01600B06092A864886FC6B020202630906072A86488
6FC6B03640B06092A864886FC6B048000640B06092A864886FC6B040255640B06092A864886FC6B0
481079000
Command --> 8050000008F05E65BF5254BC9F00
Wrapped command --> 8050000008F05E65BF5254BC9F00
Response <-- 00005147A5190C5352322002001C1F47B6C76BABFD305EBBC2CD1BB39000
mutual_authentication() returns 0x8030F00A (The Secure Channel Protocol passed and reported do not match.)
I'm using GPShell-1.4.4. I guess the problem is using wrong key set! Am I true or there is something else I cannot guess what?!
Thanks for your response,
(I am partly reusing an answer I wrote for your previous question which you suddenly deleted)
Error code GP211_ERROR_INCONSISTENT_SCP means that GPShell's intended SCP version mismatches with the real SCP version given by the card (see here).
Check the 12th byte of card response to INITIALIZE UPDATE -- Secure Channel Protocol identifier (see e.g. GP Card Specification 2.3, section E5.1.6) and use parameter -scp.
Alternatively you might want to use GlobalPlatformPro as GPShell is quite outdated...
Beware that you can block your card by issuing multiple INITIALIZE UPDATE commands without successful authentication!
As your current question contains the complete log it is possible to parse the Card Data tag giving (according to GP 2.2.1):
66 Card Data
73 Card Recognition Data / Discretionary Data Objects
06 OID
2A864886FC6B01 {globalPlatform 1} // Card Recognition Data
60 Application Tag 0
06 OID
2A864886FC6B020202 {globalPlatform 2 2 2} // GP 2.2 Card
63 Application Tag 3
06 OID
2A864886FC6B03 {globalPlatform 3} // Card Identification Scheme
64 Application Tag 4
06 OID
2A864886FC6B048000 {globalPlatform 4 128 0x00} // SCP80 i=0x00
64 Application Tag 4
06 OID
2A864886FC6B040255 {globalPlatform 4 2 0x55} // SCP02 i=0x55
64 Application Tag 4
06 OID
2A864886FC6B048107 {globalPlatform 4 129 0x07} // SCP81 i=0x07
So you might want to use -scp 2 -scpimpl 0x55 or -scp 2 -scpimpl 85 (which happens to be the same).
Or use GlobalPlatformPro.
Alternatively -scpimpl 0x15 should work as well as the Well-known pseudo-random algorithm
(card challenge) bit in 'i' should not matter...
Good luck!
I am building my own kernel. The device tree of the kernel is modified, because of an own designed mainboard.
I can enable the can devices by:
// here ATMEL is defining the can0 and can1 memory mapped devices
#include "sama5d3_can.dtsi"
...
can0: can#f000c000 {
status = "okay";
};
can1: can#f8010000 {
status = "okay";
};
But now I want to switch the names of them. Can0 should become can1 and can1 should be can0.
How to do that?
PS: the error print when switching the labels and building the kernel:
| ERROR (duplicate_label): Duplicate label 'can0' on /ahb/apb/can#f8010000 and /ahb/apb/can#f000c000
| ERROR (duplicate_label): Duplicate label 'can1' on /ahb/apb/can#f8010000 and /ahb/apb/can#f000c000
The network "devices" do not take their name from the DTS at all. They get it from the name that is given to the netdevice.name.
In your case, the at91_can.c driver calls alloc_candev() that explicitely sets the interface's name to can%d (can0, can1, ...). The number "assigned" to each device in then strictly dependant on the sequence of the "enumeration" of the hardware and its registration with the at91_can driver.
Changing the device tree will not help you in changing the name of the network interfaces. If you really need to change the name of the can interfaces, you could write udev rules that do so.
Let's say I have a client that wants to send two large requests to the server (at the same time).
Let's say the first payload is "ABCD" and the second payload is "WXYZ".
First block of first request has messageID=1 and token=0x1 with payload "AB",
First block of second request has messageID=2 and token=0x2 with payload "WX",
Second block of first request has messageID=3 and token=0x3 with payload "CD",
Second block of second request has messageID=4 and token=0x4 with payload "YZ".
You can see where I'm going with this. If messageID and token are different for each request, and they don't follow in consecutive order, how is the server supposed to concatenate the correct blocks?
Here's a sequence diagram:
CLIENT SERVER
| |
| CON [MID=1,TOK=1], POST, /foo, 1:0/1/128, "AB" ------> |
| |
| <------ ACK [MID=1,TOK=1], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=2,TOK=2], POST, /foo, 1:0/1/128, "WX" ------> |
| |
| <------ ACK [MID=2,TOK=2], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=3,TOK=3], POST, /foo, 1:1/0/128, "CD" ------> |
| |
| <------ ACK [MID=3,TOK=3], 2.01 Created, 1:1/0/128 |
| |
| CON [MID=4,TOK=4], POST, /foo, 1:1/0/128, "YZ" ------> |
| |
| <------ ACK [MID=4,TOK=4], 2.01 Created, 1:1/0/128 |
The problem occurs on message 3: The server now has two incomplete payloads, how can it reliably map the third request to the correct payload? How does it know that the payload is supposed to be "ABCD" instead of "WXCD"?
The specification for blockwise transfer only states the following:
As a general comment on tokens, there is no other mention of tokens
in this document, as block-wise transfers handle tokens like any
other CoAP exchange. As usual the client is free to choose tokens
for each exchange as it likes.
You are right, in fact the block-wise specs highlight it and propose a workaround (for the block2 option only):
The Block2 option provides no way for a single endpoint to perform
multiple concurrently proceeding block-wise response payload transfer
(e.g., GET) operations to the same resource. This is rarely a
requirement, but as a workaround, a client may vary the cache key
(e.g., by using one of several URIs accessing resources with the same
semantics, or by varying a proxy-safe elective option).
and:
The Block1 option provides no way for a single endpoint to perform
multiple concurrently proceeding block-wise request payload transfer
(e.g., PUT or POST) operations to the same resource. Starting a new
block-wise sequence of requests to the same resource (before an old
sequence from the same endpoint was finished) simply overwrites the
context the server may still be keeping. (This is probably exactly
what one wants in this case - the client may simply have restarted
and lost its knowledge of the previous sequence.)