0

I'm setting up an embedded Linux system and accessing it via SSH for development purposes. I've set up a static IP address and a Dropbear SSH server, and both appear to be working for the most part.

I can access the device with its IPv6 address, but the handshake times out when I use its IPv4 address. I've tried changing said address in case it was taken, but it didn't change anything. I've also tried adding firewall rules to ensure that the SSH client wouldn't be blocked.

I've looked around for information on what could cause this, but the closest thing I could find was a question asking about why Dropbear worked on IPv4 but not IPv6. I have the opposite problem. I would simply use IPv6 and bypass the issue, but the system will eventually need to be accessed via a Node.js server over HTTP. I don't want it to require an IPv6 address in the URL.

I suspect that the problem might have something to do with the address scopes, as the IPv6 is listed as scope link while the IPv4 is listed as scope global eth0. (I'm connecting the board directly to the computer with an Ethernet cable.) If this is in fact the problem, is there a way to configure address scopes? I couldn't find anything on that particular topic.

The relevant information is below:

~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0a:35:00:eb:e9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.130/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:35ff:fe00:ebe9/64 scope link
       valid_lft forever preferred_lft forever
~# ip route
default via 192.168.0.1 dev eth0
192.168.0.0/24 dev eth0  src 192.168.0.130
~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0a:35:00:eb:e9 brd ff:ff:ff:ff:ff:ff
~# ip tunnel
~# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:ftp                   *:*                     LISTEN
tcp        0      0 *:ssh                   *:*                     LISTEN
tcp        0      0 *:telnet                *:*                     LISTEN
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
getnameinfo failed
getnameinfo failed
tcp6       0      0 [UNKNOWN]:ssh           [UNKNOWN]:1755          ESTABLISHED
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   Path
  • 1
    Can you ping it via IPv4? Can you reach it via HTTP over IPv4? Is your SSH client on the same Ethernet LAN as your SSH server? What's your SSH client machine's IPv4 settings like? Is it set to be on the same IPv4 subnet? – Spiff Jun 29 '17 at 23:53
  • I can ping it via IPv6 but not IPv4. The client and the server are connected directly to one another with an Ethernet cable, so they should be on the same LAN. (Also, as I've mentioned, SSH works over IPv6 on that connection.) I can't reach it over HTTP on IPv4 or IPv6 because I haven't configured it for that; that said, it times out on IPv4 and simply refuses on IPv6. The client has IPv4 192.168.1.121, subnet mask 255.255.255.0, and default gateway 192.168.1.1. The subnet mask is the same on the server. Also, I've tried server IPs on the 192.168.1.x range without success. – Matthias Guenther Jul 5 '17 at 16:36
  • 1
    Well right now you seem to have a subnet mismatch. Your server is on 192.168.0.x/24, and your client is on 192.168.1.x/24. Fix that first. If you still have problems, edit your Question to include the same command output for your client that you included for your server. – Spiff Jul 5 '17 at 16:49

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.