Posts by fs-support_AZ

Hello,

maybe you can try to generate new keys on the board. Normally the ssh keys will be generated at first startup.
The script in /etc/init.d/S50ssh checks for keys in /etc:
-rw------- 1 root root 672 Mar 27 2015 ssh_host_dsa_key
-rw-r--r-- 1 root root 590 Mar 27 2015 ssh_host_dsa_key.pub
-rw------- 1 root root 227 Mar 27 2015 ssh_host_ecdsa_key
-rw-r--r-- 1 root root 162 Mar 27 2015 ssh_host_ecdsa_key.pub
-rw------- 1 root root 387 Mar 27 2015 ssh_host_ed25519_key
-rw-r--r-- 1 root root 82 Mar 27 2015 ssh_host_ed25519_key.pub
-rw------- 1 root root 965 Mar 27 2015 ssh_host_key
-rw-r--r-- 1 root root 630 Mar 27 2015 ssh_host_key.pub
-rw------- 1 root root 1675 Mar 27 2015 ssh_host_rsa_key
-rw-r--r-- 1 root root 382 Mar 27 2015 ssh_host_rsa_key.pub

Maybe they are expired or something else. Then you remove these files:" rm /etc/ssh_host_* "
After the files are deleted you can create new ones with "sh /etc/init.d/S50ssh start".
You should get something like this:

Also it could be useful to remove your board from the known_hosts file on your host-PC.
ssh-keygen -f "/home/<username>/.ssh/known_hosts" -R <board-ip>
This is on Linux Mint. So maybe it is different on other distributions.

Now you can try to connect again with ssh root@<board-ip>

Then there could be this output:
The authenticity of host '10.0.0.253 (10.0.0.253)' can't be established.
ECDSA key fingerprint is 53:3a:b7:c8:5a:5c:9b:e3:81:8a:53:c2:ff:6e:8c:1e.
Are you sure you want to continue connecting (yes/no)?

Press 'yes' and you should get a connection to the board.

Kind regards

A. Zeiler
F&S

Hello,

I tried it with armStoneA9 but anyway if it will not work I will try with efus...
Are you connecting from your board to your computer or vice versa?
I tried to connect from my board to my host and I got the same message. When I'm connecting from my host to my board everything works fine.
Command to connect from host to board: ssh root@<ipaddress of board>

Kind Regards

A. Zeiler
F&S

Hello,

as mentioned in the email, the problem comes from the mediastreamer2 library in the "mediastreamer-2.8.2/src/alsa.c"-file -> "alsa_set_params()"-function. The calculation of the "stop_threshold"-variable is wrong because of reading back the wrong exact set value (exact_ulvalue)
after setting the periods in "snd_pcm_hw_params_set_periods_near()"-function. The stop_threshold variable is used by ALSA for automatic stop after reading a buffer.

Due to a wrong assignment the "periods"-variable gets the value of periodsize, which for example can be 1024 or 2048. The "stop_threshold"-variable is calculated with "periods * periodsize" in the "snd_pcm_sw_params_set_stop_threshold()"-call.
This normally would be the buffersize (for example 8192 bytes if periods would be 8). In this case "stop_threshold" would be calculated up to 1048576.
Divided by buffersize you would get the duration of the loop playing after a interruption (about 128sec). This values are just a example. In some cases (if periodsize would be for example 2048 bytes) the audio loop would be longer (>8min).

Enclosed is a patch for this problem.

Best regards,

Andreas Zeiler