Huawei E353 & SSH

OK, so from the example I’m just trying to connect via:

ssh -p 999 -L 5000:link(mylinkid):22 -N -i spacebridge.key htunnel@tunnel.hologram.io

I’m getting (mylinkid) from my dashboard device page upper right hand corner. Am i missing something?

btw: if it matters it’s a zedboard not a Pi, but the connection is good, I can ping the world. wget pages, etc…

  • rock

Yeah so that gets the tunnel running and then you connect through it to ssh to your device. In another terminal do something like:
ssh -p 5000 username@localhost

yeah… I feel a little silly on that one but it’s still not connecting.

i tried it with the gui client and get the same thing, no connection. shh works on this device using the lan connection from other machines on our network, so I don’t think it’s our config.

the connection attempt just times out and I have no failed login attempts in the device’s auth.log file.

How can i check the keys I uploaded to see if they are ok?

  • rock

If that initial ssh command doesn’t give you an error then the keys are good.

Usually this issue is caused by the routing table not being right on the device. Do you have the ethernet and cellular interfaces up at the same time? It’s probably trying to route the response to the ssh connection back over ethernet instead of cellular. You can try pulling down the ethernet interface before bringing up the cellular interface (assuming you’re not running headless) or you can add a default route back over the cellular connection

The eth0 interface is down so I tried adding a default route but the ssh connection still just hangs. I’m at a loss… this is weird…

zbconsole:/ # ifconfig
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:10.52.222.193  P-t-P:10.64.64.64  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:115 errors:0 dropped:0 overruns:0 frame:0
          TX packets:122 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:8968 (8.9 KB)  TX bytes:8573 (8.5 KB)

zbconsole:/ # route -n
Kernel IP routing table
Destination   Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.64.64.64     0.0.0.0         UG    0      0        0 ppp0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
10.64.64.64     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
  • rock

bump…

Please, is the default route in the above post correct for the cellular connection to your network?

  • rock

That does look ok especially since it’s the only route. Do you get any errors on that tunnel ssh connection?

Hey Reuben,

I know this should work and I can only believe I have a config error somewhere, so starting from scratch… I did a fresh install of openssh on the device. I then tested with a hard LAN connection and eth0 interface only, ssh works OK with no ssh config mods, password login.

On the device
The device network info is as before, the eth0 is down and physically disconnected:
zbconsole:~ # ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1380 (1.3 KB) TX bytes:1380 (1.3 KB)

ppp0 Link encap:Point-to-Point Protocol
inet addr:10.52.222.193 P-t-P:10.64.64.64 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:181 errors:0 dropped:0 overruns:0 frame:0
TX packets:186 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:15424 (15.4 KB) TX bytes:13758 (13.7 KB)

On the client
Start the tunnel in a terminal, (API key was uploaded):

[rocco@faultred .ssh]$ ssh -p 999 -L 5000:link*****:22 -N -i spacebridge.key htunnel@tunnel.hologram.io
The authenticity of host ‘[tunnel.hologram.io]:999 ([104.130.174.172]:999)’ can’t be established.
ECDSA key fingerprint is ********************************************************.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘[tunnel.hologram.io]:999,[104.130.174.172]:999’ (ECDSA) to the list of known hosts.

tunnel is running:
[rocco@faultred ~]$ ps -aef | grep ssh
rocco 21108 20967 0 16:28 pts/10 00:00:00 ssh -p 999 -L 5000:link*****:22 -N -i spacebridge.key htunnel@tunnel.hologram.io

connect attempt:
[rocco@faultred ~]$ ssh -vvv -p 5000 rocco@localhost
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 5000.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load “/home/rocco/.ssh/id_rsa” as a RSA1 public key
debug1: identity file /home/rocco/.ssh/id_rsa type 1
debug1: identity file /home/rocco/.ssh/id_rsa-cert type -1
debug1: identity file /home/rocco/.ssh/id_dsa type -1
debug1: identity file /home/rocco/.ssh/id_dsa-cert type -1
debug1: identity file /home/rocco/.ssh/id_ecdsa type -1
debug1: identity file /home/rocco/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/rocco/.ssh/id_ed25519 type -1
debug1: identity file /home/rocco/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
ssh_exchange_identification: Connection closed by remote host
[rocco@faultred ~]$

After a time the tunnel connection sees:
channel 2: open failed: connect failed: Connection timed out

Thanks

  • rock

Is PPP up right this second? I can’t seem to ping you from our server. Can you ping outbound over ppp0?

yea, it’s up.

zbconsole:~ # ping google.com
PING google.com (216.58.210.46) 56(84) bytes of data.
64 bytes from lhr25s11-in-f46.1e100.net (216.58.210.46): icmp_req=1 ttl=47 time=299 ms
64 bytes from lhr25s11-in-f14.1e100.net (216.58.210.46): icmp_req=2 ttl=47 time=278 ms
64 bytes from lhr25s11-in-f14.1e100.net (216.58.210.46): icmp_req=3 ttl=47 time=277 ms

I have a WAN IP of 185.3.54.10

  • rock

Hmm now I can ping it. I wonder if that outbound traffic was needed to get the routing to sync up.

Try sshing in now

no luck, times out

tunnel returns
channel 2: open failed: connect failed: Connection timed out

  • rock

Hmm and now I can’t ping it again. This is weird. Can you try starting up that ping on the device and then try to ssh in?

WOW! that worked!

What could that possibly be?

  • rock

Heh, well that’s good.

I’m not totally sure. It’s almost like the carrier is tearing down the routing when there isn’t anything actively happening for a few seconds. We’ll reach out to our carrier partners and see what’s up. Normally this isn’t needed for things to work.

I’d appreciate that, we wanted to use the service for remote maintenance on sensor nodes.

please update me if you make any determination.

thanks for your help Reuben!

Also, when I killed the ping, I lost the connection on the session

  • rock

Hey Reuben,

Do we have any info from the carriers on this?

  • rock

Has there been any resolution on this issue?

I know this is an old thread. Here’s my new one on what seems to be a very similar issue:
https://community.hologram.io/t/keeping-ppp-connection-alive-while-tunneling-without-spacebridge/2666

Hi, what kind of computing device are you using with the E353? Is it running Linux? How are you making the connection? Are you able to connect to Verizon?

Hey Blake,

I never did get a resolution, the thread just died I guess…

We ended up setting a cron job that runs every 2 minutes and pings a DNS server. This was enough to keep the routes up and since then have had no issues.

Our product is still in development but we are going to a different provider for production as apparently we can’t count on this working…

Regards,
Rock