strange network freezes when wrong time is set (with transmission-gtk)

whoops · 2011-08-13 15:38:59

Hi!

After transmission-gtk running for a while, the network doesn't work any more, not even the connection to the router. Even after closing transmission-gtk, the problem persists until I disconnect from the network (using wicd / wpa atm) - or wicd freezes and refuses to start again. Trying to use ifconfig / iwconfig makes the terminal freeze (not recovering with ctrl+c), other tty/vty's still work. System won't shutdown / reboot after this happens, the tty that gave the command just freezes.

Not sure where to start here... can't use iwconfig/ifconfig... can't look up stuff online while I'm on the machine trying to work this out... any hints?

Thanks!

edit: some random information that I don't think contains anything useful:

wlan0     IEEE 802.11bgn  ESSID:"wlanx"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 48:5B:39:E8:54:98   
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=47/70  Signal level=-63 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:67   Missed beacon:0

wlan0     Link encap:Ethernet  HWaddr 54:E6:FC:88:C9:72  
          inet addr:192.168.144.56  Bcast:192.168.255.255  Mask:255.255.0.0
          inet6 addr: fe80::56e6:fcff:fe88:c972/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16365 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12310 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8815506 (8.4 Mb)  TX bytes:2072550 (1.9 Mb)

(thats when everything works fine of course...tools don't work when this error occurs )

edit:
After looking for the fifth time, found a semi-interesting part in messages.log (thats a few minutes around the problem occuring, with failed reboot etc...):

Dec  9 16:52:22 localhost kernel: [ 1501.828150] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Dec  9 16:52:23 localhost kernel: [ 1502.096812] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Dec  9 16:52:23 localhost kernel: [ 1502.350614] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Dec  9 16:52:26 localhost kernel: [ 1504.914410] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Dec  9 16:52:26 localhost dhcpcd[4723]: version 5.2.12 starting
Dec  9 16:52:26 localhost dhcpcd[4723]: wlan0: broadcasting for a lease
Dec  9 16:52:29 localhost dhcpcd[4723]: wlan0: offered 192.168.144.56 from 192.168.11.11
Dec  9 16:52:29 localhost dhcpcd[4723]: wlan0: acknowledged 192.168.144.56 from 192.168.11.11
Dec  9 16:52:29 localhost dhcpcd[4723]: wlan0: checking for 192.168.144.56
Dec  9 16:52:34 localhost dhcpcd[4723]: wlan0: leased 192.168.144.56 for 600000 seconds
Dec  9 16:52:34 localhost dhcpcd[4723]: forked to background, child pid 4746
Dec  9 16:54:45 localhost kernel: [ 1644.059228] transmission-gt[4941]: segfault at fffffffffffffff7 ip 000000000044d347 sp 00007f79b69feac0 error 4 in transmission-gtk[400000+b7000]
Dec  9 17:03:20 localhost dhcpcd[6704]: sending signal 1 to pid 4746
Dec  9 17:03:20 localhost dhcpcd[6704]: waiting for pid 4746 to exit
Dec  9 17:03:20 localhost dhcpcd[4746]: received SIGHUP, releasing
Dec  9 17:03:20 localhost dhcpcd[4746]: wlan0: releasing lease of 192.168.144.56
Dec  9 17:03:20 localhost dhcpcd[4746]: wlan0: removing interface
Dec  9 17:03:21 localhost kernel: [ 2160.076551] cfg80211: Calling CRDA to update world regulatory domain
Dec  9 17:03:21 localhost kernel: [ 2160.423451] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Dec  9 17:03:24 localhost kernel: [ 2163.236352] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Dec  9 17:03:26 localhost kernel: [ 2165.659989] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Dec  9 17:03:27 localhost kernel: [ 2165.947971] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Dec  9 17:03:29 localhost kernel: [ 2168.505313] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Dec  9 17:03:30 localhost dhcpcd[6860]: version 5.2.12 starting
Dec  9 17:03:30 localhost dhcpcd[6860]: wlan0: broadcasting for a lease
Dec  9 17:03:32 localhost dhcpcd[6860]: wlan0: offered 192.168.144.56 from 192.168.11.11
Dec  9 17:03:32 localhost dhcpcd[6860]: wlan0: acknowledged 192.168.144.56 from 192.168.11.11
Dec  9 17:03:32 localhost dhcpcd[6860]: wlan0: checking for 192.168.144.56
Dec  9 17:03:38 localhost dhcpcd[6860]: wlan0: leased 192.168.144.56 for 600000 seconds
Dec  9 17:03:38 localhost dhcpcd[6860]: forked to background, child pid 6883
Dec  9 17:07:35 localhost -- MARK --
Dec  9 17:21:01 localhost dhcpcd[8752]: sending signal 1 to pid 6883
Dec  9 17:21:01 localhost dhcpcd[8752]: waiting for pid 6883 to exit
Dec  9 17:21:01 localhost dhcpcd[6883]: received SIGHUP, releasing
Dec  9 17:21:01 localhost dhcpcd[6883]: wlan0: releasing lease of 192.168.144.56
Dec  9 17:22:22 localhost shutdown[8824]: shutting down for system reboot
Dec  9 17:22:22 localhost init: Switching to runlevel: 6
Dec  9 17:22:23 localhost acpid: exiting
Dec  9 17:23:54 localhost kernel: [    0.000000] Initializing cgroup subsys cpuset
Dec  9 17:23:54 localhost kernel: [    0.000000] Initializing cgroup subsys cpu

Last edited by whoops (2011-08-14 07:51:53)

MoonSwan · 2011-08-13 16:38:31

Try a different torrent client perhaps? If the error still occurs then it might be something that is part of the torrent apps's backend, IE a network issue not a software issue?

whoops · 2011-08-13 17:16:30

I have not been able to reproduce this with any other software, just with transmission-gtk, so far. But isn't the fact that it can stop the root account from using iwconfig / ifconfig and even from shutting down the machine already a pretty big argument for that not only being a problem with transmission-gtk? I'm not sure if a program executed as a normal user should even be able to do something like that on purpose.

Looks a little bit like a DoS attack... on... something that is not only used for the network? dbus dos attack? Maybe the "kernel something loopback stuff's thing count" is flooded or something? Meh, I have no idea how stuff works.

Last edited by whoops (2011-08-13 17:20:51)

alphaniner · 2011-08-14 01:56:40

Have you used any other torrent clients though? When running torrents (any client, Lin & Win), I occasionally lose all communication including local network. I have to reset my router (WRT54g) to 'fix' things.

dodo3773 · 2011-08-14 04:00:00

I have had problems where my connection would drop "coincidently" while downloading torrents. I use ipblock to block unwanted ip addresses, force encryption both ways, and use tcpkill (pretty sure it is in the "dsniff" package) to block foreign ports that seem suspicious to me. Also, I have noticed that if there is a lot of connections my network will almost halt and if I limit the connected number of connections per torrent after the swarm gets going then it will first drop peers instead of seeds so it does not really seem to effect speed either. I do not use transmission so I do not know all the particulars there ( using deluge) but there should be similar settings for encryption as well. If doing a lot of downloads I also reset my router (unplug it) for about 5 minutes when I am done and reboot just to be sure. If you think that your troubles may be caused by your isp or an anti-p2p group I would definitely give the above a shot.

Last edited by dodo3773 (2011-08-14 04:00:49)

whoops · 2011-08-14 07:50:38

Found part of the cause: my clock was off a few months (it's astounding how long I managed to browse my log files without noticing that all the current lines say "december"). After setting the correct time, all those problems disappeared. Still curious though, what happened. Should something like that be possible? If it's a bug, I don't know where / how to look it up / submit it . Sounds like a kernel issue...? Then again, everything that "shouldn't happen" sounds like a kernel issue to me

Last edited by whoops (2011-08-14 07:55:05)

Arch Linux

#1 2011-08-13 15:38:59

strange network freezes when wrong time is set (with transmission-gtk)

#2 2011-08-13 16:38:31

Re: strange network freezes when wrong time is set (with transmission-gtk)

#3 2011-08-13 17:16:30

Re: strange network freezes when wrong time is set (with transmission-gtk)

#4 2011-08-14 01:56:40

Re: strange network freezes when wrong time is set (with transmission-gtk)

#5 2011-08-14 04:00:00

Re: strange network freezes when wrong time is set (with transmission-gtk)

#6 2011-08-14 07:50:38

Re: strange network freezes when wrong time is set (with transmission-gtk)

Board footer