Open Madi112233 opened 4 years ago
Can you share the result of the following commands ?
Here with PPTP vpn connected:
root@DD-WRT2:~# ps -ax | grep ksmbd ps: unrecognized option: a BusyBox v1.31.1 (2020-06-13 00:39:55 +03) multi-call binary. Usage: ps Show list of processes w Wide output T Show threads root@DD-WRT2:~# ps -w | grep ksmbd 4678 root 1196 S ksmbd.mountd -c /tmp/smb.conf -u /tmp/smb.db 4679 root 1244 S ksmbd.mountd -c /tmp/smb.conf -u /tmp/smb.db 4683 root 0 SW [ksmbd-br0] 4686 root 0 SW [ksmbd-eth0] 5109 root 0 SW [ksmbd:41014] 5186 root 0 SW [ksmbd:50195] 5288 root 0 SW [ksmbd:55663] 5719 root 0 SW [ksmbd:57556] 6139 root 1364 R grep ksmbd
root@DD-WRT2:~# ifconfig -a
ath0 Link encap:Ethernet HWaddr
ath1 Link encap:Ethernet HWaddr
br0 Link encap:Ethernet HWaddr
eth0 Link encap:Ethernet HWaddr
eth1 Link encap:Ethernet HWaddr
imq0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 UP RUNNING NOARP MTU:1500 Metric:1 RX packets:1361734 errors:0 dropped:0 overruns:0 frame:0 TX packets:1360384 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:30 RX bytes:1371540831 (1.2 GiB) TX bytes:1369167783 (1.2 GiB)
imq1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq10 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq11 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq12 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq13 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq14 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq15 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq3 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq4 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq5 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq6 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq7 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq8 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq9 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16000 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:11000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MULTICAST MTU:65536 Metric:1 RX packets:75 errors:0 dropped:0 overruns:0 frame:0 TX packets:75 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:9229 (9.0 KiB) TX bytes:9229 (9.0 KiB)
ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.2.1 P-t-P:192.168.2.10 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1400 Metric:1 RX packets:722 errors:0 dropped:0 overruns:0 frame:0 TX packets:509 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:95324 (93.0 KiB) TX bytes:152563 (148.9 KiB)
teql0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
okay, thanks! can you share "dmesg" result also ?
Sure! root@DD-WRT2:~# dmesg | grep ksmbd [ 37.999828] ksmbd: kill command received [ 698.792885] ksmbd: kill command received [ 701.156453] ksmbd: ksmbd_conn_handler_loop:339: sock_read failed: -108 [ 1190.106728] ksmbd: kill command received
Strangely I don't see any usuccessfull connections. You might also need below: root@DD-WRT2:~# netstat -an | grep 445 tcp 0 0 0.0.0.0:445 0.0.0.0: LISTEN tcp 0 0 0.0.0.0:445 0.0.0.0: LISTEN tcp 0 0 192.168.2.1:445 192.168.2.127:50195 ESTABLISHED tcp 0 0 192.168.2.1:445 192.168.2.105:41424 ESTABLISHED tcp 0 0 192.168.2.1:445 192.168.2.147:57556 ESTABLISHED tcp 0 0 192.168.2.1:445 192.168.2.121:55663 ESTABLISHED tcp 0 0 192.168.2.1:445 192.168.2.105:41014 ESTABLISHED tcp 0 0 192.168.2.1:445 192.168.2.127:51782 ESTABLISHED
I think I know what is happening. When samba service starts ppp0 link is down, so it doesn't add PPP interface even if you specify it (interfaces = ... ppp0). Samba only adds interfaces that are UP. I think the problem with ksmbd that cannot correctly add ip/mask in the interfaces section
for smb.conf interfaces = br0 eth0 lo 192.168.2.1/32 bind interfaces only = no ps output: root@DD-WRT2:/jffs/etc# ps -w | grep ksmbd 13921 root 1196 S ksmbd.mountd -c /jffs/etc/smb.conf -u /jffs/etc/smb.db 13922 root 1224 S ksmbd.mountd -c /jffs/etc/smb.conf -u /jffs/etc/smb.db 13924 root 0 SW [ksmbd-br0] 13927 root 0 SW [ksmbd-eth0] 13937 root 1364 S grep ksmbd
root@DD-WRT2:/jffs/etc# netstat -an | grep 445 tcp 0 0 0.0.0.0:445 0.0.0.0: LISTEN tcp 0 0 0.0.0.0:445 0.0.0.0: LISTEN netstat: /proc/net/tcp6: No such file or directory netstat: /proc/net/udp6: No such file or directory netstat: /proc/net/raw6: No such file or directory
If I change bind interfaces only = Yes
it adds lo interface, so reading the config, but still no samba connection from 192.168.1.10/32 to samba share at 192.168.1.1 (though it says connection timeout), even though I specified it according to samba spec docs.
ps output:
root@DD-WRT2:/jffs/etc# ps -w | grep ksmbd 14398 root 1196 S ksmbd.mountd -c /jffs/etc/smb.conf -u /jffs/etc/smb.db 14399 root 1224 S ksmbd.mountd -c /jffs/etc/smb.conf -u /jffs/etc/smb.db 14401 root 0 SW [ksmbd-lo] 14403 root 0 SW [ksmbd-eth0] 14405 root 0 SW [ksmbd-br0] 14408 root 1364 S grep ksmbd
root@DD-WRT2:/jffs/etc# netstat -an | grep 445 tcp 0 0 0.0.0.0:445 0.0.0.0: LISTEN tcp 0 0 0.0.0.0:445 0.0.0.0: LISTEN tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN netstat: /proc/net/tcp6: No such file or directory netstat: /proc/net/udp6: No such file or directory netstat: /proc/net/raw6: No such file or directory
Not sure what needs to be done with IPs but when ppp0 is UP I can restart samba service and get it working, but this is not practical since it will require restarting samba every time pptp0 is up (screwing other lan users who access samba too)
Okay, ksmbd doesn't support ip/mask in interfaces param. I am wondering one thing, which of the two (interfaces = ppp0 or 192.168.2.1/32) affect working ppp0 in samba ?
It works ONLY when 3 condition s are met: 1) ppp0 is UP 2) ppp0 is added to interfaces in smb.conf 3) samba service is restarted
But if you disconnect from VPN then connect again you no longer have samba share access without restarting the samba service. Would it be possible to specify IP/mask instead of interface?
It works ONLY when 3 condition s are met:
Ah, a little confunsing. samba is different with cifsd(ksmbd). You are saying samba 3.6 or cifsd(ksmbd) ?
Oh, I meant cifs(ksmbd) for sure. My apology. Everything above is for cifs(ksmbd)
I've changed the title, the only issue I see for know is the ability to add IP/mask to interfaces param in smb.conf. This was fully supported in old samba according to samba wiki. That is what all VPN using people are probably need.
Okay, Let me check it.
I encountered a couple issues that seem related:
Compiling ksmbd in the kernel rather than as a module limits the interfaces it can listen on. Specifically, since ksmbd is loaded before the userland daemon is started, it binds a socket for each netdevice available at that point. Setting the interface= parameter in smb.conf has no effect in that case.
Listening on interfaces that come up late (virtual interfaces, external NICs) This is the same issue that Madi112233 reported. In that case, the interface is of type ppp, but the same is true for bridges for example, or for USB NICs that can appear after the ksmbd module has been loaded.
I can think of two potential solutions (untested so far):
bind a single socket to INADDR_ANY, and accept() connections from there. This is not ideal, since it means ksmbd listens on all interfaces. To limit this, one would have to configure netfilter to accept connections only from specific interfaces.
have ksmbd.mountd bind the sockets and pass them to the kernel. From a quick look at nfsd source, it seems the userland daemon binds sockets on each interface, and then passes them to the kernel via /proc. Would something like this be possible with netlink for ksmbd ?
@mmakassikis Thanks for your suggestion! Frankly, I don't have any room to work this right now. Can you do that ?
Would something like this be possible with netlink for ksmbd ?
Not sure, because I don't know which socket data is passed to /proc/X...
Sorry for not getting back earlier. Here is a branch using the INADDR_ANY to handle newly added interfaces. As indicated in the commit message, the "interface" parameters in mountd are completely ignored. I don't know if that's acceptable.
I also tried passing the listener sockets from userland. On the kernel side, one has to call sockfd_lookup() which returns a struct socket
from the file descriptor. This works, until you restart mountd. It will attempt to rebind the socket(s) on the same port and this fails because the kernel is already listening on it.
This is not an issue if you're simply restarting mountd, but if you're restarting it to change the configuration, then there's additional state to handle (which interfaces are bound ? should they be kept or removed ? etc).
Comparing with NFS: rpc.nfsd is run to configure the kernel module and exits. When one wants to change the listening addresses, then rpc.nfsd is run once to close the existing kthreads, and once again to set the new addresses and start new kthreads.
Sorry for not getting back earlier. Here is a branch using the INADDR_ANY to handle newly added interfaces. As indicated in the commit message, the "interface" parameters in mountd are completely ignored. I don't know if that's acceptable.
What is different with that "interface" parameters is not used in smb.conf ? "interface" parameter is requested by openWRT. If the interface is ignored, How can I limit the listening per NIC?
I also tried passing the listener sockets from userland. On the kernel side, one has to call sockfd_lookup() which returns a struct socket from the file descriptor. This works, until you restart mountd. It will attempt to rebind the socket(s) on the same port and this fails because the kernel is already listening on it.
I still don't understand about the second method. Could you share the patch for second way ? You need to change ksmbd.mountd(in ksmbd-tools).
What is different with that "interface" parameters is not used in smb.conf ? "interface" parameter is requested by openWRT. If the interface is ignored, How can I limit the listening per NIC?
If the interface parameter is ignored, access control can still be enforced using netfilter.
I also tried passing the listener sockets from userland. On the kernel side, one has to call sockfd_lookup() which returns a struct socket from the file descriptor. This works, until you restart mountd. It will attempt to rebind the socket(s) on the same port and this fails because the kernel is already listening on it.
I still don't understand about the second method. Could you share the patch for second way ? You need to change ksmbd.mountd(in ksmbd-tools).
Please see the following branches:
It's a variant of what I had attempted before. Initially, I was binding the sockets in ksmbd.mountd and passing them to the kernel for it to accept() clients and do further processing. The above branches implement something slightly different: ksmbd.mountd binds the sockets on each configured interface and accepts client connections, which are then passed to ksmbd. It also monitors RTM_NEWLINK/RTM_DELLINK messages to dynamically setup/teardown listeners.
The above works well in my testing so far.
Disregard my previous post. there's a bug I haven't been able to track down, that made it impossible for some clients to transfer large files.
Here's a new branch that monitors netdev changes in the kernel module. Compared to my first suggestion, it handles the "interface" parameter passed by ksmbd.mountd while also addressing the initial issue of handling interfaces that do not exist when ksmbd is loaded.
@namjaejeon could you take a look ?
@mmakassikis Okay, Thanks for your work!, I will check it this weekends.
The patch looks good when I check it roughly! But does it fix the issue("Issue: ksmbd share does not support IP/mask defining in smb.conf interfaces, so it rejects requests coming from temporary PPTP VPN subnet") Madi112233 reported ?
Strictly speaking, my patch doesn't change anything with regards to IP/mask handling: ksmbd.mountd still only parses interface names.
However, the issue of accepting connections from a newly added interface is solved. For example, let's consider a system with multiple interfaces:
# ip -br link
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0 UP 52:54:00:3d:53:a1 <BROADCAST,MULTICAST,UP,LOWER_UP>
eth1 DOWN 52:54:00:ef:92:48 <BROADCAST,MULTICAST>
eth2 DOWN 52:54:00:96:25:60 <BROADCAST,MULTICAST>
eth3 DOWN 52:54:00:28:ef:cb <BROADCAST,MULTICAST>
ksmbd module is loaded, and ksmbd.mountd is started with the minimal config in the global section:
[global]
netbios name = SMBD
ksmbd listens on all interfaces that are UP:
# ss -planetusi | grep 445
tcp LISTEN 0 16 ::%eth0:445 :::* ino:13618300 sk:2b7 v6only:0 <->
tcp LISTEN 0 16 ::%lo:445 :::* ino:13618299 sk:2b8 v6only:0 <->
If I bring up eth1, then ksmbd opens a new listening socket:
# ip link set eth1 up
# ss -planetusi | grep 445
tcp LISTEN 0 16 ::%eth1:445 :::* ino:13641206 sk:2b9 v6only:0 <->
tcp LISTEN 0 16 ::%eth0:445 :::* ino:13618300 sk:2b7 v6only:0 <->
tcp LISTEN 0 16 ::%lo:445 :::* ino:13618299 sk:2b8 v6only:0 <->
The same thing happens if a new interface is added and brought up:
# ip link add name veth0 type veth peer name veth1
# ip link set veth0 up
# ss -planetusi | grep 445
tcp LISTEN 0 16 ::%veth0:445 :::* ino:13647610 sk:2ba v6only:0 <->
tcp LISTEN 0 16 ::%eth1:445 :::* ino:13641206 sk:2b9 v6only:0 <->
tcp LISTEN 0 16 ::%eth0:445 :::* ino:13618300 sk:2b7 v6only:0 <->
tcp LISTEN 0 16 ::%lo:445 :::* ino:13618299 sk:2b8 v6only:0 <->
The behavior is similar if the interfaces=
parameter is set, except of course that ksmbd only binds to the specified interfaces. Repeating the previous example:
# pkill ksmbd.mountd
# ip link del veth0 down
# ip link set eth1 down
# ./control/ksmbd.control -s
# grep -A4 global smb.conf.example
[global]
bind interfaces only = yes
interfaces = lo eth0 veth0
netbios name = SMBD
# ./mountd/ksmbd.mountd -c smb.conf.example -u smbpwd.db
# ss -planetusi | grep 445
tcp LISTEN 0 16 ::%eth0:445 :::* ino:13682261 sk:2bc v6only:0 <->
tcp LISTEN 0 16 ::%lo:445 :::* ino:13682260 sk:2bd v6only:0 <->
# ip link set eth1 up
# ip link add name veth0 type veth peer name veth1
# ip link set veth0 up
# ss -planetusi | grep 445
tcp LISTEN 0 16 ::%veth0:445 :::* ino:13688375 sk:2be v6only:0 <->
tcp LISTEN 0 16 ::%eth0:445 :::* ino:13682261 sk:2bc v6only:0 <->
tcp LISTEN 0 16 ::%lo:445 :::* ino:13682260 sk:2bd v6only:0 <->./mountd/ksmbd.mountd -c smb.conf.example -u smbpwd.db
Note that no socket was created for eth1, as it is not in the allowlist.
Okay, Could you send the patches to the linux-cifsd mailing list ? and I really appreciate if you check more the issue Madi112233 reported.
@Madi112233: It is solved now?
@Madi112233: It is solved now?
This is Excellent! Was this change already included in ksmbd 3.3.6 to verify?
In ksmb (in-kernel samba) compiled for DD-WRT (OpenWRT) smb does not accept the requests coming through ppp0 tunnel which can only be defined through IP/mask in smb.conf (e.g. PPTP vpn). Same setup worked for samba 3.6. (old samba allowed adding IP/mask to the smb.conf in interfaces = DD-WRT (OpenWRT) Router acts as a Server for both Samba and PPTP. All subnets and routes are defined to allow PPTP to see local network Somehow ksmbd rejects all requests are coming from PPTP client.
Issue: ksmbd samba share does not support IP/mask defining in smb.conf interfaces, so it rejects requests coming from temporary PPTP VPN subnet