Huawei E353 & SSH


#1

Hey Guys,

We’re using an E353. We have a good connection to your network and can reach the outside world. Great… but how can we ssh into the device. ifconfig shows only the local IP from your network and we need to be able to login the the device.

  • rock

#2

Take a look at our Spacebridge feature: https://hologram.io/docs/guide/cloud/spacebridge-tunnel/

It allows tunneling inbound to a cellular connection without having to install a VPN or anything


#3

Hey Reuben,

I saw that and went through the process but cannot get it to work. That page is very confusing.
i.e. does the link id need the string “link” pre-pended to the number or just the number? I tried it both ways of course…

I enabled the tunnel from the dash board ok. generated and uploaded the key ok.
but I cannot connect. it just hangs. Any suggestions.

Not using the GUI client.

  • Rock

#4

Oh if you’re doing it via ssh without the client then you need the word link in there.
Which command is hanging? The ssh to setup the tunnel or the one to your pi through the tunnel?


#5

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

#6

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


#7

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

#8

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


#9

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

#10

bump…

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

  • rock

#11

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


#12

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

#13

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


#14

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

#15

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


#16

no luck, times out

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

  • rock

#17

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?


#18

WOW! that worked!

What could that possibly be?

  • rock

#19

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.


#20

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