Connection refused after auto-flash

[Tom Ooten]

Hi,

I have the multiconnect conduit for a while now and it was working fine.

Last week I had a problem on the gateway so I decided to flash it with the tutorial “Using Auto-Flash During Reboot” on this page : http://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/

The Leds blinked in a progression pattern so I assumed the flash goes well.

But now, I can’t access the gateway by ssh like I already did before. I put the ip address 192.168.2.2, I have the good logs on ipconfig.
I can ping 192.168.2.1 and 192.168.2.2, but when I try to connect by ssh root@192.168.2.1, I have the following message :

“ssh: connect to host 192.168.2.1 port 22: Connection refused”

Thanks in advance for any help,

Tom.

[Jason Reiss]

You can try to access the device through the USB Device port on the back of the unit. Connect with a terminal emulator at 115200. Login with the same creds as ssh.

[Tom Ooten]

Thank you for the support jason, I can now access the gateway via USB.

But I am still not able to connect via ssh, and here is my /etc/network/interfaces file :

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# Wired interface
auto eth0

iface eth0 inet static
address 192.168.2.1
netmask 255.255.255.0

# Bridge interface with eth0 (comment out eth0 lines above to use with bridge)
# iface eth0 inet manual
#
# auto br0
# iface br0 inet static
# bridge_ports eth0
# address 192.168.2.1
# netmask 255.255.255.0

# Wifi client
# NOTE: udev rules will bring up wlan0 automatically if a wifi device is detected
# and the wlan0 interface is defined, therefore an "auto wlan0" line is not needed.
# If "auto wlan0" is also specified, startup conflicts may result.
#iface wlan0 inet dhcp
#wpa-conf /var/config/wpa_supplicant.conf
#wpa-driver nl80211

I still have a “ssh: connect to host 192.168.2.1 port 22: Connection refused” when I connect with my PC via ethernet

• This reply was modified 8 years, 4 months ago by Tom Ooten.

[Jeff Hatch]

Tom,

Could you make sure that ssh is running with a ps, and get the output of the “netstat -na” command if you can? Connection refused errors usually mean that nothing is listening on port 22.

You will probably also need to define a gateway in the /etc/network/interfaces if you are going to connect from a different subnet than 192.168.2.x.

[Tom Ooten]

Indeed, it seems that the TCP is not configurated or something like that

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
netstat: /proc/net/tcp6: No such file or directory
netstat: /proc/net/udp6: No such file or directory
netstat: /proc/net/raw6: No such file or directory
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  2      [ ACC ]     STREAM     LISTENING       1157 /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     SEQPACKET  LISTENING        401 /var/run/udev/control
unix  4      [ ]         DGRAM                      1195 /dev/log
unix  3      [ ]         DGRAM                       407
unix  3      [ ]         STREAM     CONNECTED       1161
unix  3      [ ]         DGRAM                       408
unix  2      [ ]         DGRAM                      1198
unix  3      [ ]         STREAM     CONNECTED       1160
unix  2      [ ]         DGRAM                      1285

I know about the gateway definition for connecting on my network subnet, already did it thank you 🙂

[Jeff Hatch]

Tom,

It looks like you have networking. The “No such file or directory” errors are for IPv6 stuff. I have the same output from “netstat” on my Conduit. I was hoping to see output from “netstat -na” that will tell us what ports listens are on. In addition to the output you already generated there will be additional listings at the top like:

admin@mtcdt:/var/config# netstat -na
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
tcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:1880            0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:1881          0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:1882          0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      
tcp        0      0 127.0.0.1:1883          0.0.0.0:*               LISTEN      
tcp        0      0 192.168.2.1:22          192.168.2.200:49724     ESTABLISHED 
tcp        0      0 127.0.0.1:1883          127.0.0.1:60482         ESTABLISHED 
tcp        0      0 127.0.0.1:45297         127.0.0.1:9000          TIME_WAIT   
tcp        0      0 127.0.0.1:60482         127.0.0.1:1883          ESTABLISHED 
tcp        0      0 127.0.0.1:43899         127.0.0.1:80            TIME_WAIT  

Thanks,

Jeff

[Tom Ooten]

Hi Jeff,

Thanks for the reply.

The output I showed on post #10429 was from “netstat -na”, there is nothing more that is displayed

I wonder if I did well while flashing the Multiconnect, it seems that the mLinux distribution is not the same as before

• This reply was modified 8 years, 4 months ago by Tom Ooten.

[Jeff Hatch]

Tom,

Any chance now that you have the debug console hooked up that you can capture the console output when the unit reboots? It’s possible that related errors might come out in that output. Also, take a look in /var/log/messages and see if there are any networking related errors.

One last thing to make sure that the ethernet interface is up, could you do an “ifconfig -a” and make sure that the eth0 interface is up and has the correct address?

Jeff

[Tom Ooten]

Jeff,

Nothing particular on the log messages, exept from errors about jffs2 :

Dec 14 17:38:45 mtcdt user.warn kernel: jffs2: Empty flash at 0x03c6b8d0 ends at 0x03c6c000
Dec 14 17:38:45 mtcdt user.notice kernel: jffs2: notice: (1) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
Dec 14 17:38:45 mtcdt user.info kernel: VFS: Mounted root (jffs2 filesystem) readonly on device 31:8.
Dec 14 17:38:45 mtcdt user.info kernel: devtmpfs: mounted
Dec 14 17:38:45 mtcdt user.info kernel: Freeing unused kernel memory: 156K (c04ef000 - c0516000)
Dec 14 17:38:45 mtcdt user.notice kernel: jffs2: notice: (64) check_node_data: wrong data CRC in data node at 0x03c6b750: read 0xb4fd09ac, calculated 0x53b26c49.
Dec 14 17:38:45 mtcdt user.notice kernel: jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x004417cc: Read 0xffffffff, calculated 0xd09df165
Dec 14 17:38:45 mtcdt user.warn kernel: jffs2: Empty flash at 0x004418c4 ends at 0x00442000
Dec 14 17:38:45 mtcdt user.notice kernel: jffs2: notice: (73) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
Dec 14 17:38:45 mtcdt user.notice kernel: jffs2: notice: (73) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
Dec 14 17:38:45 mtcdt user.err kernel: cdc_acm 1-2.3:1.0: This device cannot do calls on its own. It is not a modem.

And here is my ifconfig, I am pretty sure I have got the right interface up :

root@mtcdt:~# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:08:00:4A:02:0E
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:34 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3543 (3.4 KiB)  TX bytes:0 (0.0 B)
          Interrupt:23 Base address:0xc000

gre0      Link encap:UNSPEC  HWaddr 00-00-00-00-FF-00-00-00-00-00-00-00-00-00-00-00
          NOARP  MTU:1476  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)

gretap0   Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          BROADCAST MULTICAST  MTU:1462  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:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

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)

tunl0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          NOARP  MTU:1480  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)

Plus I have this log :

Dec 14 17:41:14 mtcdt user.info kernel: macb f802c000.ethernet eth0: link up (100/Half)

Also, when I ping google, the output is : Network is unreachable

Tom.

• This reply was modified 8 years, 4 months ago by Tom Ooten.
• This reply was modified 8 years, 4 months ago by Tom Ooten.
• This reply was modified 8 years, 4 months ago by Tom Ooten.

[Jeff Hatch]

Tom,

The interface information looks good. Since there were no established listens from the “netstat -na” it appears that sshd is not getting started for some reason. You can verify this with a “ps -auxww | grep ssh”. On the mLinux model you should be able to do an “/etc/init.d/sshd restart” if sshd is not running or to restart it. If that does not get sshd up and running check /var/log/messages and hopefully it logs something. If it is not running you could try running sshd by hand at the command line with the “-d” option to find out why it is not coming up. The debug options range from -d -d1, -d2 to -d3, with increased verbosity.

Jeff

[Tom Ooten]

It seems “/etc/init.d/sshd restart” is doing nothing, no logs on “/var/log/messages” either

sshd is not working

I am off for today, restarting tomorrow on the issue

Thanks a lot to both of you

Tom.

• This reply was modified 8 years, 4 months ago by Tom Ooten.

[Tom Ooten]

Hi again,

The logs on the messages i posted are output from the multitech mlinux model after auto-flashing it with the followed instructions : http://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/ (section “Using Auto-Flash During Reboot”)

To do this I took the following files from the library http://www.multitech.net/mlinux/images/3.1.0/mtcdt/ :

– mlinux-factory-image-mtcdt-20150527081222.rootfs.jffs2
– uImage–3.12.27-r11.2-mtcdt-20150527052826.bin

Should I try using other files for the auto-flash or are those two files okay ?

Tom.

[Jeff Hatch]

Tom,

One possibility is that the rootfs file got corrupted on download. Did you run an md5 and check the hash against whats in the md5sums.txt? There have been observed instances where the rootfs file got corrupted, but it still “installed”, and significant portions of the file system were missing. If the file appears to be correct then you could try to re-flash the unit.

Jeff

[Tom Ooten]

Hi Jeff,

Your point is interesting, I checked both files I have download with the md5sums.text file ans it match, so I suppose the files were not corrupted.
Then I tried to re-flash the conduit with the exact same process than I did last time, but when I reboot the conduit nothing happen (the LEDs do not blink in a progression pattern), even with a SD card

Tom

[Jeff Hatch]

Tom,

File an issue in the MultiTech Portal with support. It looks like there are probably some hardware issues with that unit. Filing the issue will get you started in the process to get a replacement.

Jeff

[Tom Ooten]

Hi again,

I tried the debug mode (micro USB connection in the front of the conduit) and this line appears after boot :

jffs2: notice: (186) check_node_data: wrong data CRC in data node at 0x0883dec8: read 0x103ae9f2, calculated 0xb69d3c7e.

So it seems the flash went wrong

Also, I will try to do the U-Boot TFTP to flash the firmware, but I am not sure about the TFTP. All I have to do is put the oe_uImage.bin and oe_rootfs.jffs2 files in the tftpboot dir (c:\tftpboot ?) and configure the ip adresses ?

[Jeff Hatch]

Tom,

You are correct that all you have to do is have the oe_uImage.bin and oe_rootfs.jffs2 files in the tftpboot directory for your tftp server on your PC. Make sure to name the kernel and file system files the same as what is in the u-boot env as I think you are doing, and configure the correct IP address for the Conduit and the tftp server. Then you should be able to use the “run krb” command. It is very similar (if not the same) as the instructions for flashing through u-boot in mLinux as described about halfway down the page under “Using U-boot & TFTP”.

Hopefully everything will go well and the re-flash will get you up and running.

Jeff

[Jeff Hatch]

Tom,

Somehow my link to the flash instructions disappeared:

Jeff

[Jeff Hatch]

Tom,

Alright, it deleted the link twice. Here it is in plain text:

http://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/

Jeff

[Tom Ooten]

Jeff,

Thanks for the tips.

However, I can’t set up the U-boot environment with the minicom, with this command line :

minicom --script=uboot-setenv

The script is running from “setting U-Boot variables…” to “printenv”, then I quit the minicom

So I reboot, interrupt U-Boot, and printenv, but it is still the same environment (with no krb, tftp_kernel and tftp_rootfs)

I tried to setenv manually but errors occurs (syntax error, unknown command ‘nand erase.part bootstarp’)

I think understand that I have to run the uboot-setenv script from U-Boot> but I don’t know how, minicom is not working there.

[Jeff Hatch]

Tom,

Just making sure: Is your uboot-setenv script doing a saveenv at the end. If not, the variable settings will not persist.

Jeff

[Tom Ooten]

Hi Jeff,

Okay, I have another problem now, I can not get the files oe_uImage.bin and oe_rootfs.jffs2 from my PC because they are to heavy.
I obtain the following log => TFTP error: ‘Undefined error code’ (0)

I tried with a lighter file (.txt) and it works, I can copy the .txt file from my PC, but not the firmware files.

I think I am very close

Edit : And now after trying this, I can not boot it anymore even with “env defaut -a” and then “save env”, returning this error :

Loading from nand0, offset 0x200000
** Unknown image type
Wrong Image Format for bootm command
ERROR: can't get kernel image!

Tom.

• This reply was modified 8 years, 3 months ago by Tom Ooten.

[Tom Ooten]

Alright,

Problem fixed, topic close !
My MultiConnect is re-flashed and works just as when I started with it.

I was unable to copy the files because I checked the checkbox “Option negociation” on TFTP server settings.

Thank you for all your support.

Best Regards,

Tom.

[Jeff Hatch]

Tom,

Great to hear! Which tftp server were you using (in case someone else runs into the same thing flashing their device).

Jeff

[Tom Ooten]

Hi,

I used the TFTP server proposed on the “Flashing mLinux Firmware” page of Multitech Developer Resources, called tftpd32.

About the configuration of it, I followed the following tutorial : http://www.tricksguide.com/how-to-setup-a-tftp-server-tftpd32-windows.html

With this configuration, the error described in post #10754 occured : firmware files can not be copy from the tftp server because they are too heavy.
To fix this, I unchecked the checkbox called “Option negociation”

Regards,

Tom.

• This reply was modified 8 years, 3 months ago by Tom Ooten.

[Author]

Posts