OpenWrt Forum Archive

Topic: 7.07: locked out of router after a day

The content of this topic has been archived on 28 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Post #1
driven
30 Jul 2007, 08:12

Using a wrt54gl v1.1 and kamikaze 7.07.  Install goes ok.  If I leave it running for a day, it's ok. If I turn it off for 5 minutes and turn it back on, it's ok.  If I turn it off and come back a day later, I can't log in.  ssh hangs during the protocol negotiation.  If I boot failsafe, I can telnet but that's it.  Nothing typed at the command prompt shows up.

If I reflash, everything is ok again.  Until the next day.  Same thing happens.  After waiting 5 minutes for the ssh session the router resets the connection.  Here is an ethereal capture of a failed ssh login:

      1 0.000000    192.168.1.10          192.168.1.1           TCP      45875 > ssh [SYN] Seq=0 Len=0 MSS=1460 TSV=48851980 TSER=0 WS=7
      2 0.000948    192.168.1.1           192.168.1.10          TCP      ssh > 45875 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=0
      3 0.001013    192.168.1.10          192.168.1.1           TCP      45875 > ssh [ACK] Seq=1 Ack=1 Win=5888 Len=0
      4 0.007612    192.168.1.1           192.168.1.10          SSHv2    Server Protocol: SSH-2.0-dropbear_0.49\r
      5 0.007976    192.168.1.10          192.168.1.1           TCP      45875 > ssh [ACK] Seq=1 Ack=24 Win=5888 Len=0
      6 0.008424    192.168.1.10          192.168.1.1           SSHv2    Client Protocol: SSH-2.0-OpenSSH_4.4
      7 3.009928    192.168.1.10          192.168.1.1           SSHv2    [TCP Retransmission] Client: Unknown (46)[Unreassembled Packet [incorrect TCP checksum]]
      8 9.012572    192.168.1.10          192.168.1.1           SSHv2    [TCP Retransmission] Client: Unknown (46)
      9 21.015019   192.168.1.10          192.168.1.1           SSHv2    [TCP Retransmission] Client: Unknown (46)
     10 45.018839   192.168.1.10          192.168.1.1           SSHv2    [TCP Retransmission] Client: Unknown (46)
     11 50.022171   Fujitsu_1e:5c:7b      00:18:39:7a:8c:0b     ARP      Who has 192.168.1.1?  Tell 192.168.1.10
     12 50.022549   00:18:39:7a:8c:0b     Fujitsu_1e:5c:7b      ARP      192.168.1.1 is at 00:18:39:7a:8c:0b
     13 93.024413   192.168.1.10          192.168.1.1           SSHv2    [TCP Retransmission] Encrypted request packet len=20
     14 98.023425   Fujitsu_1e:5c:7b      00:18:39:7a:8c:0b     ARP      Who has 192.168.1.1?  Tell 192.168.1.10
     15 98.023796   00:18:39:7a:8c:0b     Fujitsu_1e:5c:7b      ARP      192.168.1.1 is at 00:18:39:7a:8c:0b
     16 189.028927  192.168.1.10          192.168.1.1           SSHv2    [TCP Retransmission] Encrypted request packet len=20
     17 194.032132  Fujitsu_1e:5c:7b      00:18:39:7a:8c:0b     ARP      Who has 192.168.1.1?  Tell 192.168.1.10
     18 194.032501  00:18:39:7a:8c:0b     Fujitsu_1e:5c:7b      ARP      192.168.1.1 is at 00:18:39:7a:8c:0b
     19 300.994388  192.168.1.1           192.168.1.10          TCP      ssh > 45875 [FIN, ACK] Seq=24 Ack=1 Win=5840 Len=0
     20 300.995644  192.168.1.10          192.168.1.1           SSHv2    Encrypted request packet len=752
     21 301.202572  192.168.1.1           192.168.1.10          TCP      ssh > 45875 [FIN, ACK] Seq=24 Ack=1 Win=5840 Len=0
     22 301.202629  192.168.1.10          192.168.1.1           TCP      [TCP Dup ACK 20#1] 45875 > ssh [ACK] Seq=774 Ack=25 Win=5888 Len=0 SLE=24 SRE=25
     23 305.998546  Fujitsu_1e:5c:7b      00:18:39:7a:8c:0b     ARP      Who has 192.168.1.1?  Tell 192.168.1.10
     24 305.998922  00:18:39:7a:8c:0b     Fujitsu_1e:5c:7b      ARP      192.168.1.1 is at 00:18:39:7a:8c:0b

This has happened on two 54GL's.  I have a serial console on one of them and can log in that way but I don't see any clues as to why this is happening.  I have made no changes to the router except for setting the password.

Where can I look to find out what is wrong?

Post #2
driven
30 Jul 2007, 21:30

Found the problem.  It wasn't the routers or 7.07.  It was my laptop.  After doing a suspend to disk and then a resume it somehow buggers up the ethernet port.  It mostly works, but not completely as evidenced by my problem above.

So FYI to SuSE 10.2 users who suspend to disk: I already found that my wireless interface needed to be shut down before a suspend, now it turns out my ethernet interface does also.  I created a wrapper around the /usr/sbin/s2disk program that removes the network interface modules.  After resuming you need to modprobe them back in and all will be well with the world.

Thanks,

DR

The discussion might have continued from here.