Mobile access blade with segfault.

[Dreyfuss]

Hi! It seems that I discovered the problem about File Sharing describe in https://community.checkpoint.com/t5/Remote-Access-VPN/Mobile-Access-Blade-with-CIFS-segfault/m-p/818...

It turns out that Checkpoint itself is dubious in understanding about compatibility in smbv2 / 3 with version 80.30 (even in kernel 3.10). In one sk CP says it is not compatible, in another CP says it is compatible. In my studies, I saw that it was compatible, yes. And I started without migrating to version 80.40. The heart of the matter is the fact that, for Mobile Access, the default is for the feature to make the connection in SMBv1, according to https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut.... This should not be default, or at least, that this information should be clearer.
There is also clear confusion regarding the compatibility of version 80.30 and smbv2 / 3. 

DEFAULT is still SMBv1!!!

After applying these settings, I listed the dialect between server and Windows Server:

XXX.XXX.XXX.XXX/xxx /opt/CPcvpn-R80.30/mnt/cvpn_mnt/ml14 cifs rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=john.doe,domain=XXXXXX,uid=0,noforceuid,gid=0,noforcegid,addr=XXX.XXX.XXX.XXX,file_mode=0755,dir_mode=0755,nounix,mapposix,noperm,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1 0 0

In spite of this call to be with the support of Checkpoint of the United States for 365 days (1 YEAR!), no one in CP knows to fix it.
SR: 6-0001974972

Now I got one more problem: after 2 hours, the mounting simply vanishes from mount location and the user of Mobile Access loses the connection to the share. So, after a re authentication, everything works again. Here we go again.

[PhoneBoy]

@AndreiR any way we can make SMBv3 the default in a future JHF or version?

[Jenni_Guerrica]

Did you ever get a solution?  We are having a similar issue now on R80.40 jumbo 94

[11 Aug 15:47:31] T_event_fdclr_epoll: failed to clear socket: 54 from epoll set: Bad file descriptor
[11 Aug 15:47:31] T_event_fdclr_epoll: failed to clear socket: 55 from epoll set: Bad file descriptor
[11 Aug 15:47:31] T_event_fdclr_epoll: failed to clear socket: 56 from epoll set: Bad file descriptor
[11 Aug 15:47:31] T_event_fdclr_epoll: failed to clear socket: 57 from epoll set: Bad file descriptor
[11 Aug 15:47:31] T_event_fdclr_epoll: failed to clear socket: 58 from epoll set: Bad file descriptor
[11 Aug 15:47:31] T_event_fdclr_epoll: failed to clear socket: 59 from epoll set: Bad file descriptor

[Dreyfuss]

Hi there!

There are two problems: the first one is solved simply changing the default version on SMB (DEFAULT is v1!) as follows: cvpnd_settings $CVPNDIR/conf/cvpnd.C set FileShareDefaultSmbVersion "<version>"

The second problem is: after two hours (aprox) the users loses the connection. There´s no answer from TAC, so I made a "gambiarra" (https://www.urbandictionary.com/define.php?term=Gambiarra)
I scheduled a job by crontab (using jobuser) to make a ls (1 minute each) in the /opt/mnt/etc,etc,etc where the mountings are located. So, the Gaia´ OS do not loses the connection with the file server.
Hope it helps!

[PhoneBoy]

Just to be clear, SMBv2/v3 does not work on the Linux 2.6.18 kernel, which was standard prior to R80.40.
And the fact the connection times out after 2 hours does make some sense since that's the default connection timeout if there is no activity on that connection.
That "gambiarra" is one way to keep those connections active. 🙂

[Dreyfuss]

I agree! Fortunately, we upgraded to kernel 3.10 (R80.30), that is compatible with SMBv2/3. Since @Jenni_Guerrica is running with 80.40, probably it´s standard for it. IMO, since the user is connected in Portal, the Gaia should keep those connections running up, until the user disconnects (Sign Out) or the reach the interval for reconnection/reauth.