410c/Ubuntu: Can't SSH in

Hi,
is there something new with this issue?
For my home automation I would like to change from RPi2 to the dragonboard 410c ( FHEM ). Because DB410 comes with wifi and BT on board. AND it has eMMC :wink: on RPi my SD-Cards die frequently.
So i can also change my hum/Temp Sensors and thermostates to BT le ( and connect over WLAN to The Webserver.
The Second Step could be to connect a 7"+ Touch Display to the board and use it as main Terminal :wink:

Greetings, Bugs

I’ve had success with installing Vino VNC on the DragonBoard (apt-get install vino-server), then installing dconf to make the necessary changes to Vino in order to allow me to remote into the DragonBoard. Specifically, I needed to use dconf to edit settings under org > gnome > desktop > remote-access; I needed to make sure that disable-background, prompt-enabled, and require-encryption were all UNchecked (the encryption issue might be a bug, actually; I haven’t been able to set up any configuration where configuration is allowed), and then making sure that disable-xdamage was checked. I also needed to use dconf edit the graphics settings under org > gnome > desktop > interface, UNchecking enable-animations.

After this, I could use tightVNC client to successfully VNC into the DragonBoard under port 5900.

Now, in order to allow the VNC client to connect to the DragonBoard by IP address, I had to use the LXSession configuration application (under “Preferences”) and, in the “Autostart” section, I added a command to start vino-server at startup (the specific command is @/usr/lib/vino/vino-server) and to call a script (run-nmap-every-minute-task.sh) that forces the DragonBoard to use the nmap tool (obtained via apt-get install nmap) to scan the network every minute, allows other machines to then connect to the DragonBoard. This startup command was @lxterminal -e /home/linaro/run-nmap-every-minute-task.sh, and the code within it is simply

#!/bin/bash
printf "\nBeginning infinite loop...\n"
while true
do
	sudo nmap -sP 192.168.0.0/24
	printf "\nScan complete; now waiting 60 seconds...\n"
	sleep 60
done

Hopefully this helps! This method certainly works for me; I’m finally able to run my device headlessly, albeit insecurely, but for my testing and development, it certainly is sufficient.

Hi @bugs

I don’t think the underlying problem has been resolved yet. The db410c does not react correctly to multicast packets which I believe is a power optimization in the wifi firmware (popular on android devices) that the kernel cannot disable.

In other words if you home automation needs multicast you’re probably stuck. However if not the ping sweep hack (http://www.redfelineninja.org.uk/daniel/?p=421 ) might be enough for you to switch over.

I have started a new thread on workarounds for this issue.

https://www.96boards.org/forums/topic/ssh-and-ping-workarounds/

Sean

Thanks For your reply.
I will try to test this.
Is there a Chance to rewrite/patch/hack the driver to fix this?
I am only a C programmer for embeddet Systems and have no xp with linux and driver :frowning:

Bugs

@bugs,

I am thinking that maybe you misunderstood @snowbird’s entry.

please check the instructions for the two work-arounds in this link: any of them are very straightforward to implement - they only require minimal changes to the DragonBoard 410c Debian file system.

let me know if something is not quite clear.

I put together a temporary workaround packed in a debian installable package.

After downloading the the deb file from this location you should be able to install it by executing:
$ sudo dpkg -i wifi-workaround.arm64.deb

Then reboot the board.

If you wish to remove the package once installed simply execute:
apt-get remove wifi-workaround

The source code and the script that generates the .deb file is available in the tar file at the same location. So if you are not completely happy with the trivial daemon that I put together - which sends the ARP requests spaced every millisecond- you can of course modify it and reinstall your very own version.

Is there any ongoing work on the wcn36xx driver to implement ARP offloading and/or power management?

hi,

finally some good news here…

We believe we’ve managed to fix this issue. All the changes required are in the wcn36xx kernel driver. I have pushed all patches in the 4.2 release branch:

https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/shortlog/refs/heads/release/qcomlt-4.2

And there is a build available for testing:

http://builds.96boards.org/snapshots/dragonboard410c/linaro/debian/46/

If you have any feedback on this build, please let us know. Of course, all the workaround mentioned above are not needed anymore

Our next release is supposed to be based on 4.4 kernel in 2 to 3 weeks, but you can use the build #46 in the mean time. If there is a huge demand, we can spin a release with 4.2 with this bug fix…

In the next few weeks, we will clean up the wcn36xx patches from our tree and submit them upstream.

WOW, that sounds nice!
this Weekend I hope i can try it.
Very nice work!

Bugs

Nicely done! I look forward to testing this when the next release comes out. No rush from me for an advanced release, I’m using a USB ethernet adapter for my development so I haven’t been plagued by this problem for a while now (it was certainly annoying when I was on wifi though).

Hi
I flushed my dragon board with debian/46 image and tired to ssh my board after registering my router.
Indeed the dragon board handles the arp_req broadcast and i managed to ssh/ping it without any trouble :slight_smile:

BUT:
I think there is still a problem with the wifi firmware or some other power mode configuration.
Maybe the ps-pull / beacon mode is not configured correctly.

    Typical ping to my dragonboard over wifi looks like:

%>ping 10.0.0.8

Pinging 10.0.0.8 with 32 bytes of data:
Reply from 10.0.0.8: bytes=32 time=84ms TTL=64
Reply from 10.0.0.8: bytes=32 time=4ms TTL=64
Reply from 10.0.0.8: bytes=32 time=5ms TTL=64
Reply from 10.0.0.8: bytes=32 time=6ms TTL=64

Ping statistics for 10.0.0.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 84ms, Average = 24ms

As you can see the first ping is very long, and then it gets shorted.
sometimes the first ping is even longer…

It seems the wifi gets to sleep very quickly which is ok for mobile phones but not for AlwaysOn device.
The SSH also suffers for keystrokes long latencies for the same reason

Could you please remove the deep sleep configuration from the wifi?

Thanks
Idan

Hi Idan,

Thanks for verifying that the fixes worked for you. There are a number of configuration options related to sleep mode, so I will look through them and see if I can configure this behavior away.

The driver should be possible to use both on mobile and always-on setups, so we also need to find a suitable way to expose this knob to the system.

Regards,
Bjorn

Hi
Is there any progress?
If so, could you please provide a quick update?

Thanks
Idan

I’m also having problems with what might be the wifi module going to sleep. I regularly get
wlan0: deauthenticated from XX:XX:XX:XX:XX:XX (Reason: 7=CLASS3_FRAME_FROM_NONASSOC_STA) .

(I replaced the MAC address with X)
This makes an SSH session quite unreliable.

Hi
Actually until sleep issues are solved SSH to the dragonboard using wifi is hell. i get disconnected every half minute because of these wifi issues. then you have to reconnect to a NEW ssh session.

I found a temp solution, MIT developed a new “ssh like” protocol that can do roaming or in our case reconnect the active ssh every disconnect.
The beauty of the mosh is that you dont have to config anything, its bootstrap using your current ssh deamon.
more info:
Mosh: the mobile shell

The youtube video demo showing how awesome it is…

sudo apt-get mosh will install it on your dragonboard

It still only just a temp solution since every 12 hrs (by average) wifi got killed and you cannot even reconnect using mosh but have to reboot your dragonboard.

Idan