Samba unusable



  • [192.168.1.*/clients]-> [pfSense] -> [192.168.2.8/smb]

    My samba server is behind the pfSense box, the respective ports required by Samba is opened,
    and there are no issues in connecting or generally utilizing the shares on the server.

    The issue comes after a short while of using the service, like watching an episode or listeing to music.
    After say 5 minutes or so, the file simply drops/playback stops, and mplayer/xmms claims the file no longer exists. The samba share dies, and has to be forcefully unmounted, and remounted again; watch for 5 minutes and then rinse and repeat.

    It is obvious that pfSense is causing this, connecting the server directly to the network used by the clents and everything works fine; add the pfSense box back, and the proplem re-appears.

    Are there any way to resolve this issue, the days are very long and boring without music.

    Are pfSense closing the connections? Whats happening here, and how can I solve it?

    Best Regards,
    MeatPuppet



  • Sounds like a problem with you're config.  I'm currently happily listening to music from a Samba share, through my stock 1.2 release pfSense host, and have been for about an hour or so.

    What rules do you have?  Does tcpdump/wireshark show anything?



  • These are the rules:

    The following ports are open from WAN to Server 0 (optional int):
    udp/137, udp/138, tcp/139, tcp/445 and tcp/22
    These ports are also accepted incoming in the local iptables firewall on the server. (The exact same ports that are opened in iptables on the server, is mirrored on the pfSense box)

    The following ports are open from Server 0 to WAN:
    udp/137, udp/138, tcp/139, tcp/445 and tcp/22

    My guess would be that the pfSense box is dropping the connections after a certain timeout, say when the clients are playing from their cache, and when they attempt to buffer more; they expect the connection to still be open, while pfSense has closed it; and thus a new state must be opened. But I dont know.

    Keeping constant activity on the server seems to make XMMS/mplayer/whatever play longer, say if I have a movie or something running in the background, and jiggling it so it constantly gathers data, I can postpond it for some time.Same goes if I just frantically browse around the samba shares to keep the activity. It does not work however, just with a movie playing normally, but thats most likely due to my 64MB mplayer cache. It seems to play out the cahce, and then die; and when I try to re-open the file, the samba share is dead. So I have to forcefully (-l/-f) unmount it and start over again.

    The issue is totally reproducable on all clients, and disappears instantaneously if I connect the samba server directly, and not passing it through pfSense. There should be no "timeout"/latency issues present either, I can push multiple Megabyes per second from the server to the clients (or back) via the pfSense box without any problems.

    Could there be any merit in say setting an outrageous State Timeout in the firewall rule, or am I looking at this the wrong way?

    Best Regards,
    MeatPuppet



  • I think you're barking up the wrong tree. We all use pfSense, most of us in multiple locations and all day long, without seeing this kind of problem.

    Have you swapped out any network cards in the pfSense machine to see if the problem persists? Same for ethernet cables.

    What does the syslog say on both the samba and pfSense machines at around the time the disconnection?



  • The network cards are realteks, to be more spesific the box is a Watchguard Firebox X.

    For some reason, the samba server works just fine from Trusted, or more spesifically from behind the SonicWall. The issue is present for all clients connected to Medium Trust.
    Thus it is very unlikley the issue is the cable, or the nics; if it were a hardware problem the clients behind the SonicWall would work in the same matter, and the server would still exhibit the same symptoms if I connected  directy to the Medium Trust VLAN, and it does not. Why it works flawlessly from behind the SonicWall I do not have any clues to. It should be noted that I have tried multiple computers, all running different configurations, hardware as well as distrobutions (I have however not tried with Windows, since I do not have any pc's running that readily avaliable).
    It could obviously be a routing issue, however nothing points to this, and every other service beyond samba works just fine.

    There are no logs on the samba server that would point to any issues, but the dmesg on the clients are filled to the brink with random samba errors, but nothing really useful there either.

    SMB connection re-established (-5)
    smb_add_request: request [f50f2300, mid=54473] timed out!
    smb_file_aio_read: OST 2/13 - Weekend (c-4).mp3 validation failed,
    error=4294967291
    SMB connection re-established (-5)
    smb_add_request: request [f50f2a00, mid=54716] timed out!
    smb_file_aio_read: OST 2/13 - Weekend (c-4).mp3 validation failed,
    error=4294967291
    SMB connection re-established (-5)
    smb_add_request: request [f50f2300, mid=54927] timed out!
    smb_file_aio_read: OST 2/13 - Weekend (c-4).mp3 validation failed,
    error=4294967291
    SMB connection re-established (-5)
    smb_add_request: request [f50f2c00, mid=55138] timed out!
    smb_file_aio_read: OST 2/13 - Weekend (c-4).mp3 validation failed,
    error=4294967291
    SMB connection re-established (-5)
    smb_add_request: request [f50f2100, mid=16044] timed out!
    smb_add_request: request [f50f2100, mid=16045] timed out!
    smb_lookup: find Mp3/Album failed, error=-512
    smb_add_request: request [f50f2300, mid=16047] timed out!
    smb_add_request: request [f7022700, mid=16049] timed out!
    smb_add_request: request [f50f2e00, mid=16050] timed out!
    smb_add_request: request [f50f2e00, mid=16051] timed out!
    –> to infinity and beyond.

    Best Regards,
    MeatPuppet


Log in to reply