System freezes, please help

Hello everyone,

I'm facing a major issue which has been bugging me for 2 days already and which i can not solve at all.
It's very odd and unexplainable to me.

I run FreeBSD 8.0 AMD64 with KDE 4.3.4, everything up to date.
I use a NTFS-partition, which is shared between various OSes,
and is auto-mounted on bootup.Last night i did a full check of that partition and it is healthy, no corruption. Torrenting to it
from other OSes (Windows 7, Linux etc.) is trouble-free and works.

Under FreeBSD however, whenever i try downloading a torrent,
the system freezes momentarily after hitting the "add" button, which is the final step before the download itself. No matter of the client program (and i tried all that i know of) - Deluge, Transmission, even the "native" KDE-one Ktorrent, ends up with the same result: immediate system freeze.

I'm mostly used to Deluge (from Linux), so i started with it,
but it ended up with "not connected" message after hitting the "add"-button, complaining the daemon at 127.0.0.1:58864 was not connected.The system didn't freeze, but i noticed python was dumped to my home dir - python26.core. Odd situation.
A month ago i was using FreeBSD with XFCE and deluge worked flawlessly. I removed deluge and tried Transmission - system freezes immediately. Same with Ktorrent.

I'm using PF, rechecked the rules several times - found nothing
that might be blocking or causing these issues otherwise.
I have no clue at all, where else i should look for resolving this issue, really. And why all this trouble with simple torrent
downloading.

Any help will be greatly appreciated.
 
Hey, and thanx for answering.

I was suspecting the firewall (PF), just did a probe with a base "workstation" mode of IPFW - same result, an immediate freeze x(

I'm using the ports's fusefs-ntfs, read-write mode works whitout
issues.
Here's the PF-conf (/etc/pf.conf) :
Code:
ext_if="tun0"
int_if="re0"
set loginterface $ext_if
set state-policy if-bound
set block-policy drop

# All incoming traffic on external interface is normalized and fragmented
# packets are reassembled.
scrub in on $ext_if all fragment reassemble

# Default DENY policy
block all

#Activate anti-spoofing protection 
set skip on lo0
antispoof for $ext_if inet

### block anything coming from sources that we have no back #routes for.
block in from no-route to any

### block packets that fail a reverse path check. we look up the routing
### table, check to make sure that the outbound is the same as the source
### it came in on. if not, it is probably source address spoofed.
block in from urpf-failed to any

### drop broadcast requests quietly.
block in quick on $ext_if from any to 255.255.255.255

### block packets claiming to come from reserved internal address blocks, as
### they are obviously forged and cannot be contacted from the outside world.
block in log quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 } to any

### block probes that can possibly determine our operating system by disallowing
### certain combinations that are commonly used by nmap, queso and xprobe2, who
### are attempting to fingerprint the server.
### * F : FIN  - Finish; end of session
### * S : SYN  - Synchronize; indicates request to start session
### * R : RST  - Reset; drop a connection
### * P : PUSH - Push; packet is sent immediately
### * A : ACK  - Acknowledgement
### * U : URG  - Urgent
### * E : ECE  - Explicit Congestion Notification Echo
### * W : CWR  - Congestion Window Reduced
block in quick on $ext_if proto tcp flags FUP/WEUAPRSF
block in quick on $ext_if proto tcp flags WEUAPRSF/WEUAPRSF
block in quick on $ext_if proto tcp flags SRAFU/WEUAPRSF
block in quick on $ext_if proto tcp flags /WEUAPRSF
block in quick on $ext_if proto tcp flags SR/SR
block in quick on $ext_if proto tcp flags SF/SF

#Alow all outgoing traffic from me
pass out on $ext_if proto { tcp, udp, icmp } from any to any modulate state

# Allow all incoming BitTorrent trafic (KTorrent)
pass in on $ext_if proto { tcp udp } from any to ($ext_if) port 51000 modulate state
pass in on $ext_if proto udp from any to ($ext_if) port 4444 modulate state
 
Mistake:
Code:
pass in on $ext_if proto { tcp[red],[/red] udp } from any to [red]($ext_if)[/red] port 51000 modulate state
pass in on $ext_if proto udp from any to [red]($ext_if)[/red] port 4444 modulate state
No coma

($ext_if) should be $ext_ip for example, you need IP there

==>
Code:
my_ip="123.123.123.123"
pass in on $ext_if proto { tcp, udp } from any to $my_ip port 51000 modulate state
pass in on $ext_if proto udp from any to $my_ip port 4444 modulate state


Am also concerned about your block in quick..... but I don't know what all those flags mean
 
Thanx a lot for your help, Killasmurf !

I was suspecting myself, having made errors somewhere :)

Will try out your suggestions and post back the results.
I'm afarid i have that "feeling", this won't resolve it anyway,
i tried with IPFW, and the system froze again.

On my way again...
 
well, simply try without firewalls at all :D
I also don't think that this will solve your problem [still you need to fix it :D ]

If I was you I'd try to download to UFS/ZFS before trying anything else. This way we will know if this problem is related directly to NTFS or there's something else. I bet it's NTFS itself {I haven't used fuse-ntfs, in fact I haven't used ntfs at all on freebsd}
 
You were quite right, Killasmurf86 !

I did what you suggested (even with some more paranoia at it, hehe)
- removed all that "block"-lines in pf.conf, leaving only the
default block-policy
- corrected the wrong lines in pf.conf
- first attempt after that, leaving Ktorrent to download to the
shared NTFS-partiton failed, with the same system freeze.
- restared, and after that told Ktorrent to download to my home
folder - there we have it, it started downloading !

Finally ! :)

So, the issue seems to have been the damn NTFS all the time...
The probes without a working firewall have proved that it wasn't
a firewall issue, neither IPFW's or PF's, because even under no
working firewall, the system froze again.
I also thought it could have been KDE's fault...

The hell with it, i'll reformat that NTFS partition as ext3 and try using it that way in FreeBSD.The strange thing is that under
FreeBSD with XFCE, downloading with Deluge to this NTFS partition
worked trouble-free.
Should i fill a bug report to the maintainers of the fusefs-ntfs module ?

Thanx a lot again for your time, helping me! :beer
 
hmm, interesting, that it worked on XFCE...

I don't think ext3 is supported on FreeBSD.

About ntfs... try simply $ dd if=/dev/random of=/path/to/NTFS/test_file.img bs=1m count=1000
See if that will hand system as well
If that hangs the system, then send pf about ntfs, otherwise I don't know what to do [probably send pr anyway]
 
Could you please explain your idea ?

I didn't get your suggestion, since i am not that experienced
in FreeBSD...

Thanx in advance !
 
run
Code:
$ dd if=/dev/random of=/path/to/NTFS/test_file.img bs=1m count=1000
this will write about 1GB file to NTFS filesystem.... see if this will hang your system.

just replace /path/to/NTFS/test_file.img to path in your NTFS dir
If this program stops writing without errors, and system won't freez, there might be some other problem, and NTFS might not be the issue
 
Now we get back to the issue, since :
Code:
Nord# dd if=/dev/random of=/mnt/Downloads/test_file.img bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 40.600048 secs (25826965 bytes/sec)
Nord# echo $?
0
Nord#

NTFS says now "not my fault", i start banging my head towards the wall, wondering what might have caused all this till now :)
 
Now that we are clear it was neither a firewall, and lastly - nor a ntfs issue, what's left ? :D

I don't even think of blaming FreeBSD, but rather...well, KDE 4?
As a new user to the FreeBSD world, i'm even more clueless,
and don't know what else i might think of, being the problem...

P.S. Would some parts of the system logs help in further investigating the problem ?
 
Well, you could start torrent client from console and redirect it's output to some file :D that might provide some info

for example, in console: $ deluge > test.log

Can't think of anything that could help otherwise.... but you know... I'm not a pro either :D
 
Although of having no further clarity or end result of what
is causing the freezes, i'd like to thank you again for all the help and time you spent on the issue. :beer

I'll leave it open for now, hoping for some people, or perhaps developers too, who might read this thread and would be interested in it, that they would give some further hints :)

Cheers and long live FreeBSD !
 
np..

I suggest you probably send this info to mailing list of some sort.... not many developers read this forum.

Perhaps try again with gnome if you 're willing to test.... this....
and if It works as well as XFCE, then send email to FreeBSD kde teem:
kde@FreeBSD.org
 
The problem is related to fusefs-ntfs port, it is buggy.
All fusefs ports crashed my system (probably because I'm using CURRENT)
 
Back
Top