I am working on a DPDK project and experience issues that need you help.
The project needs to implement encryption/decryption through DPDK (multi-buffer library). To support all cipher and hash algorithms, I need create 4 type of virtual devices: crypto_null, crypto_aesni_mb, crypto_snow3g and crypto_zuc. I tried to create a crypto-scheduler to manage all 4 devices. When the devices attach to the scheduler, it failed. I can reproduce the exact same failure with the DPDK example program: l2fwd_crypto.
Here is the command I use to run l2fwd_crypto.
./l2fwd-crypto -l 0-1 -n 4 --vdev "crypto_aesni_mb0" --vdev "crypto_null" --vdev "crypto_zuc" --vdev "crypto_snow3g0" --vdev "crypto_scheduler,slave=crypto_null,slave=crypto_aesni_mb0,slave=crypto_snow3g0,slave=crypto_zuc" -- -p 0x3 --chain CIPHER_HASH --cipher_op ENCRYPT --cipher_algo aes-cbc --cipher_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f --auth_op GENERATE --auth_algo aes-xcbc-mac --auth_key 10:11:12:13:14:15:16:17:18:19:1a:1b:1c:1d:1e:1f
The error message is:
rte_cryptodev_scheduler_slave_attach() line 214: capabilities update failed
I am using DPDK 20.05 on CentOS 7.4
My question is:
Is this the correct way to handle all different crypto algorithm? I mean create 4 virtual devices.
Why the crypto scheduler failed?
Any suggestion/comments are really appreciated.
[EDIT-1: Based on comment conversation]
DPDK POLL mode Crypto Scheduler is intended to be running with either HW or SW of the same type. This is covered in dpdk document. Hence if one needs to Crypto scheduler to work, it has to initialized with all same type (either HW/SW).
Hence re-running the test with either all NULL, ZUC, SNoW, AES_MB will work
note: with respect to internally logic working, my personal opinion is the current logic in crypto-scheduler logic is correct. Because, in actual logic one will lookup dest-ip or src+dest IP in either ACL, LPM, or Exact Match to identify the SA or Crypto keys. this can offloaded to SW or HW depending upon work load or flow (mice or elephant) flow.
Related
I'm trying to find out if there is any native TCP/IP stack implemetation provided in DPDK or any popular open-source project to achieve it. Any help will be grateful.
Update:
My platform is Ubuntu 16.04 x64, Intel 82599es NIC with DPDK 20.08. What I'm trying to accomplish is to rebuild TCP connections out of the packets I receive on the NIC port for later use. I thought tools like ANS, mTCP and fstack may do the track but they are third party and some of them are not fully open-sourced, so I'm looking for a native one or one that is popular for developers. I don't know what should I call this kind of requirement, sorry for troubles causing because of the question, I'll change it after I know the related concept better.
There are no native TCP-IP stack implementation in DPDK version till date DPDK version 20.11 LTS. Going further in my humble opinion DPDK would not be implementing native TCP-IP stack. Hence current options are
Since the requirement is to rebuild TCP connection state information, my recommendation is to
create RTE_FLOW_ACTION_MIRROR to create the packet copy at HW NIC level for all interested TCP connection using a combination of IP-TCP address-ports.
If there is no HW option, either using ref_cnt_update or copying the user packet payload create a copy of the packet.
With help RTE_RINGS or RTE_FB_ARRAY organize the packets from client and server based on symmetric RSS (if available) or based on custom HASH to appropriate containers.
For you packet processing recommendation is either use FSTACK or mTCP or BSD TCP-ip from scratch
there are multiple references on the Internet which gives hints to get started too. Please refer
mTCP slide 14
fstack slide deck
On a test server there are two Samsung 960 Pro SSDs, exactly same maker, model and size. On both I've installed a fresh install of exactly the same OS, OmniOS r15026.
By pressing F8 at POST time, I can access the motherboard BOOT manager, and choose one of the two boot drives. Thus, I know which one the system booted from.
But how can one know programmatically, after boot, which is the boot disk?
It seems that is:
Not possible on Linux,
Not possible on FreeBsd
Possible on macOS.
Does Solaris/illumos offer some introspective hooks to determine which is the boot disk?
Is it possible to programmatically determine which is the boot disk on Solaris/illumos?
A command line tool would be fine too.
Edit 1: Thanks to #andrew-henle, I have come to know command eeprom.
As expected it is available on illumos, but on test server with OmniOS unfortunately it doesn't return much:
root#omnios:~# eeprom
keyboard-layout=US-English
ata-dma-enabled=1
atapi-cd-dma-enabled=1
ttyd-rts-dtr-off=false
ttyd-ignore-cd=true
ttyc-rts-dtr-off=false
ttyc-ignore-cd=true
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyd-mode=9600,8,n,1,-
ttyc-mode=9600,8,n,1,-
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
lba-access-ok=1
root#omnios:~# eeprom boot-device
boot-device: data not available.
Solution on OmniOS r15026
Thanks to #abarczyk I was able to determine the correct boot disk.
I had to use a slightly different syntax:
root#omnios:~# /usr/sbin/prtconf -v | ggrep -1 bootpath
value='unix'
name='bootpath' type=string items=1
value='/pci#38,0/pci1022,1453#1,1/pci144d,a801#0/blkdev#w0025385971B16535,0:b
With /usr/sbin/format, I was able to see entry corresponds to
16. c1t0025385971B16535d0 <Samsung-SSD 960 PRO 512GB-2B6QCXP7-476.94GB>
/pci#38,0/pci1022,1453#1,1/pci144d,a801#0/blkdev#w0025385971B16535,0
which is correct, as that is the disk I manually selected in BIOS.
Thank you very much to #abarczyk and #andrew-henle to consider this and offer instructive help.
The best way to find the device from which the systems is booted is to check prtconf -vp output:
# /usr/sbin/prtconf -vp | grep bootpath
bootpath: '/pci#0,600000/pci#0/scsi#1/disk#0,0:a'
On my Solaris 11.4 Beta system, there is a very useful command called devprop which helps answer your question:
$ devprop -s bootpath
/pci#0,0/pci1849,8c02#1f,2/disk#1,0:b
then you just have to look through the output of format to see what that translates to. On my system, that is
9. c2t1d0 <ATA-ST1000DM003-1CH1-CC47-931.51GB>
/pci#0,0/pci1849,8c02#1f,2/disk#1,0
Use the eeprom command.
Per the eeprom man page:
Description
eeprom displays or changes the values of parameters in the EEPROM.
It processes parameters in the order given. When processing a
parameter accompanied by a value, eeprom makes the indicated
alteration to the EEPROM; otherwise, it displays the parameter's
value. When given no parameter specifiers, eeprom displays the values
of all EEPROM parameters. A '−' (hyphen) flag specifies that
parameters and values are to be read from the standard input (one
parameter or parameter=value per line).
Only the super-user may alter the EEPROM contents.
eeprom verifies the EEPROM checksums and complains if they are
incorrect.
platform-name is the name of the platform implementation and can be
found using the –i option of uname(1).
SPARC
SPARC based systems implement firmware password protection with
eeprom, using the security-mode, security-password and
security-#badlogins properties.
x86
EEPROM storage is simulated using a file residing in the
platform-specific boot area. The /boot/solaris/bootenv.rc file
simulates EEPROM storage.
Because x86 based systems typically implement password protection in
the system BIOS, there is no support for password protection in the
eeprom program. While it is possible to set the security-mode,
security-password and security-#badlogins properties on x86 based
systems, these properties have no special meaning or behavior on x86
based systems.
I am working on Error Detection module and was attempting to test using the error injection implementation mentioned in Intel® Xeon® Processor C5500/C3500 Series Datasheet, Volume 2 in section 4.12.40. It asks to program the MC_CHANNEL_X_ADDR_MATCH, MC_CHANNEL_X_ECC_ERROR_MASK and MC_CHANNEL_X_ECC_ERROR_MASK registers but attempting to write to this has no effect. Realized there is a lock for this space which is indicated by status in MEMLOCK_STATUS register (device 0: function 0: offset 88h), which in my case is reporting 0x40401 as the set value. This means MEM_CFG_LOCKED is set and I am not able to even unlock using the MC_CFG_CONTROL register (device 0:function 0: offset 90h). I am writing 0x2 to this register but that does not help to unlock the ECC injection registers for writing. How can I achieve this? I am running FreeBSD on the bare metal and not as a virtual machine.
To the best of my knowledge, the whole TXT thing that is necessary for this is not supported on FreeBSD.
But this a quite an arcane area. You might have more luck asking this on the freebsd-hackers mailing list.
As someone who is very new to the opensource PBX projects like Asterisk and FreeSWITCH, I am grappling with some information overload. Have read the basic FreeSWITCH docs on Wiki, but still have few questions. Since I am not very familiar with the terminology, I will try to use close approximations.
Trying to create a small/minimalistic build of FreeSWITCH, that needs to run on an rather old laptop (Celeron 1GHz, 512MB RAM, 20GB HDD, already running Debian "Wheezy"), and set it up as a 6-port GSM-SIP/Jabber gateway. So, by "small" and "minimalistic", I mean one which doesn't have modules/optional-software that is not absolutely necessary (e.g. no need for IVR announcements, or Skype integration) -- to keep memory footprint smallest, and occupy less hard-disk real-estate.
The rough idea is to have 6 GSM ports (via 'GSM-open module', similar to chan_dongle) towards public telephony network, and about 60 SIP extension, and support upto 6 calls involving GSM ports, and about 6 SIP-SIP calls (intra PBX), on this setup. I have read that the CPU overhead of GSMopen module is pretty low, so I am guessing this is possible.
Can someone confirm this to be a realistic goal?
What might be the minimum set of modules to select for minimalistic build?
For modules not chosen during initial build, can those be added later? If so, would it require me to rebuild FreeSWITCH completely, only the modules, or that everything would be built, but only configuration changes would be required to ensure that modules are loaded, and configure?
Is there any rough estimate of what might be the maximum call-rate that could be supported in such a configuration? For SIP-SIP calls? Given the underpowered processor, and little RAM (as per modern standards), I am guessing that both shall be bottlenecks, but adding RAM might still be possible (even if costly and difficult).
I have read that "hooks" can be created using Lua/Python/Java etc.. However if someone share share few examples of what-all is possible using such hooks, it would make the concept clearer. Can one hope to write an application like "missed call log" or "redirect on no answer" using these hooks?
Can someone confirm this to be a realistic goal?
Yes, this is quite realistic. You need to target as little as possible transcoding, because that's where CPU resources are needed. But even with a 1Ghz Celeron, 6 transcoded sessions seem quite realistic. But it needs testing :)
What might be the minimum set of modules to select for minimalistic build?
Just start with the default list of modules, and add gsmopen (I have no experience with gsm gateways, can't help with that part). The memory footprint is pretty low, and you may need some of those modules later.
For modules not chosen during initial build, can those be added later?
as far as I remember, Wiki describes this process. You edit modules.conf and make the specific module.
Is there any rough estimate of what might be the maximum call-rate that could be supported in such a configuration? For SIP-SIP calls? Given the underpowered processor, and little RAM (as per modern standards), I am guessing that both shall be bottlenecks, but adding RAM might still be possible (even if costly and difficult).
It really depends on complexity of your dialplan. Each context consists of a number of conditions, which are doing regexp match on channel variables. So, the more complex your dialplan is, the less CPS you get. But for a 6-channel gateway, I don't see this a problem. GSM network will be much slower than your box :)
I have read that "hooks" can be created using Lua/Python/Java etc.. However if someone share share few examples of what-all is possible using such hooks, it would make the concept clearer. Can one hope to write an application like "missed call log" or "redirect on no answer" using these hooks?
You can control every aspect of FreeSWITCH behavior with FreeSWITCH. There are even examples when the complete dialplan is re-implemented by an external program (Kazoo does that).
The simplest mode of operation is when your Lua/JS/Perl/Python script is launched from within the dialplan: then it receives a "session" object, and you can do whatever you want with the call: play sounds, bridge, forward, make a new call and bridge them together, and so on. Here in my blog there's a little practical example.
Then, you can build an external application which connects to the FS socket and monitors the events and performs actions on active calls.
Also, it can be done in the opposite direction: you run a server, and FS connects to it with its socket library.
Also, you can have an HTTP service which delivers pieces of XML configuration to FreeSWITCH, and it requests those on every call (this would be the most CPU-intensive application). This way, you can feed FS from some internal database, and build fault-tolerant systems.
I hope this helps :)
You can also find me in skype if needed.
FreeSWITCH is not really memory-hungry, and you can simply start with the default set of modules (the best is to use the prebuilt Debian packages). For example, on my 64bit machine, the FreeSWIITH process occupies only 35MB of memory.
freeswitch#vx03:~$ uname -a
Linux vx03 2.6.32-5-xen-amd64 #1 SMP Thu Nov 3 05:42:31 UTC 2011 x86_64 GNU/Linux
freeswitch#vx03:~$ ps -p 11873 v
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
11873 ? S<l 10:29 0 0 258136 36852 2.3 /opt/freeswitch/bin/freeswitch -nc -rp -nonat -u freeswitch -g freeswitch
I will go through the rest of your questions later today
I'm a young professional who's into embedded design, IT networking, control/monitoring systems and much more. Currently, I'm developing a monitoring system using a device from Tibbo Techonology, their DS1102.
http://tibbo.com/products/controllers/ds110x/ds1102
It's a programmable device that covers serial and ethernet communications. For my project, its main tasks are serial data collection and database population. Serial communication is done through RS485 and database used is MySQL 5.5. My database is hosted on a public IP which also runs a webserver for the interface while my device is behind a NAT. It connects to the database directly using the public IP.
I'd like to ask for advices so that I can enhance and upgrade it. Right now these are the
questions I'd like to ask.
Which is better? Having the server on a public IP or using port forwarding?
I'm also using it as webserver for the interface of my monitoring system.
To communicate with the device (rebooting, changing IP etc), I wrote an application in
python using UDP (using port 65535 of device) and also set the device to communicate with the application for specific commands. My concern is I want to encrypt the communication between my python app and the device both ways. The only available function for both encrypting and decrypting on the DS1102 is RC4. What are your thoughts on using RC4 for this application? Also, I'm planning to do port forwarding on port 65535 so that I can use my python app from the outside. Can RC4 be reliable for this too? I really want to learn how to use encryptions properly.
I'm also planning to implement SMTP for alert messages. Tibbo has a sample code from which I based mine. Problem is, it's on AUTH PLAIN LOGIN. I think I want to turn it to STARTTLS later. Can you recommend some lessons on the algorithm of STARTTLS?
What are those details on MAIL FROM:<> and RCPT TO:<>? Because on using the command
DATA, the programmer can write anyway From: and To: which can make his identity someone else.
That's it for now. Suggestions are very welcome.
You can also share some good reading materials and links. I'm always hungry for learning. :)
Thanks for your time.
2.
Encryption substitutes the confidentiality of an arbitrary amount of data (the plaintext) with the confidentiality of a small amount data (the key). In other words, your communication is only as confidential as the key – if the shared secret key leaks out, the encryption is worthless. More on this.
Also note that plain RC4 provides no authenticity (message integrity). An adversary can modify messages as much as he wants. He can even send his own messages which will be considered perfectly valid by the cipher. Verifying the validity of the messages is is up to the code that parses the messages.
If your messages are simple (only a few bytes or so), an adversary could simply send random bytes until they decrypt such that they form a valid message, without knowing anything about the key. This happens on average after only 100 attempts for a 1-byte message for example.
You will obviously have to use some sort of a nonce to prevent trivial replay attacks.
RC4 is also rather quirky per se. I guess you are already aware of the numerous "drop-n" variants and so on.
In short, protocol design is perilous. Even experts often get it wrong (look at WEP for example). The most straightforward way to solve this would be to find hardware that can handle an existing protocol such as TLS.