If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
Do you have experience port forwarding SMB ports on Windows?
Specifically forwarding SMB/CIFs TCP port 445 to higher than 1024? If so, which port forwarding hints might you offer to a noob? The problem set: o Windows is "stuck" listening for SMB/CIFs on TCP port 445. o Non-root Android is "stuck" not allowing apps access to 1-1024. The "trick" is to get Windows to "listen" on 445 & forward to 1234. Of course, the other trick is to get Android to send on TCP 1234. https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers *Have you experience actually doing that exact task for this purpose?* If you've actually _done_ it, then can you advise what's best? For example, I found a tutorial on the net but it used a virtual machine, which is too much overhead for what I'm trying to accomplish (IMHO). I'm thinking of this general process where I hope you have done it: a. Run an as-yet-unknown setup to ensure Windows can port forward https://support.microsoft.com/en-us/help/555744 There are some indications certain services need to be disabled. etc. b. Set up a free port mapper such as netsh, PortTunnel or Passport: http://www.steelbytes.com/?mid=34] https://sourceforge.net/projects/pjs-passport/ http://www.analogx.com/contents/download/network/pmapper/freeware.htm http://woshub.com/port-forwarding-in-windows/ netsh interface portproxy add Samba listenport=445 listenaddress=192.168.1.2 connectport=1234 connectaddress=192.168.0.3 protocol=tcp etc. c. Debug inevitable issues with any free TCP viewer https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview https://www.microsoft.com/en-us/download/details.aspx?id=9964 etc. Do you have experience port forwarding SMB ports on Windows? Specifically forwarding SMB/CIFs TCP port 445 to higher than 1024? If so, what helpful advice can you provide sufficient to be successful? -- If you're Rudy Wieser, Char Jackson, Wolf K, etc., please do not respond. |
Ads |
#2
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to somethinghigher than 1024 on Windows?
Arlen Holder wrote:
Do you have experience port forwarding SMB ports on Windows? Yes, when I needed to map a drive over an SSH tunnel. netsh interface portproxy add v4tov4 listenport=xxx listenaddress=192.168.xx.xx connectaddress=192.168.yy.yy connectport=yyy Because the lanmanserver service starts early and binds to 445 on all interfaces, you may need to install a virtual kernel NIC driver in order to get an interface with a "spare" IP address to listen on, it was available from MS last time I needed it on Win7, not sure about Win10. |
#3
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
Arlen Holder wrote:
[...] For SMB to work, we need to find a solution that will allow us to a. On Android, run a non-root Samba/SMB server to listen on port 7777 b. On Windows, run port-forwarding software to listen on port 445 c On Windows, forward the SMB connections to port 7777 So here's my plan, for SMB, to solve this age-old problem for everyone: 1. I'll keep seeking a non-root SMB server for Android, and, 2. Then, I'll run the netsh command on Windows to forward ports. The port forwarding for Windows is "on hold" until I can find an SMB server that works on Android non-root with ports above 1024. I re-checked my notes and at the time, I looked at: 'SMB cifs samba file server' https://play.google.com/store/apps/details?id=com.imperioustech.www.sambaserver "Uses Standard port 445 for rooted devices and automatically selects a suitable port for non-rooted devices." I didn't proceed with this, for the very reason you are now investigating, the need to map port 445 to a port number above 1024. Perhaps 'SMB cifs samba file server' is a candidate for you to investigate. Good luck. |
#4
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
On 18 Oct 2018 18:13:13 GMT, Frank Slootweg wrote:
I re-checked my notes and at the time, I looked at: 'SMB cifs samba file server' https://play.google.com/store/apps/details?id=com.imperioustech.www.sambaserver "Uses Standard port 445 for rooted devices and automatically selects a suitable port for non-rooted devices." I didn't proceed with this, for the very reason you are now investigating, the need to map port 445 to a port number above 1024. Perhaps 'SMB cifs samba file server' is a candidate for you to investigate. Hi Frank, Thanks for your helpful advice. Given that we seek a general solution that works for most people, you're correct that the way to approach solving this age-old problem is in two parts, where we (first) find an Android SMB server that can work on ports higher than 1024 on Nougat and above without being root, and then we (second) map Windows SMB TCP requests to be on the same higher-than-1024 port (e.g., 7777). Unfortunately, that com.imperioustech.www.sambaserver APK isn't on Google Play, or on F-Droid, so, while both problems are formidable, we're stuck with no resolution until we can find an SMB server for Android that can change the port without being root. Once we get an SMB server working, we can map Windows TCP port 445-7777. So we're all stuck, until we can find an SMB server that works sans root. |
#5
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
Arlen Holder wrote:
On 18 Oct 2018 18:13:13 GMT, Frank Slootweg wrote: I re-checked my notes and at the time, I looked at: 'SMB cifs samba file server' https://play.google.com/store/apps/details?id=com.imperioustech.www.sambaserver "Uses Standard port 445 for rooted devices and automatically selects a suitable port for non-rooted devices." I didn't proceed with this, for the very reason you are now investigating, the need to map port 445 to a port number above 1024. Perhaps 'SMB cifs samba file server' is a candidate for you to investigate. Hi Frank, Thanks for your helpful advice. Given that we seek a general solution that works for most people, you're correct that the way to approach solving this age-old problem is in two parts, where we (first) find an Android SMB server that can work on ports higher than 1024 on Nougat and above without being root, and then we (second) map Windows SMB TCP requests to be on the same higher-than-1024 port (e.g., 7777). Unfortunately, that com.imperioustech.www.sambaserver APK isn't on Google Play, or on F-Droid, Hmmm!? I thought I checked the Google Play URL before posting, but apparently I didn't. If you want to have a look at it, the APK *is. - of course! :-) - on Apkpu https://apkpure.com/smb-cifs-samba-file-server/com.imperioustech.www.sambaserver That it's no longer on Google Play and rather old (2015-12-12) is not very promising. But as - so far - you're empty-handed... so, while both problems are formidable, we're stuck with no resolution until we can find an SMB server for Android that can change the port without being root. Once we get an SMB server working, we can map Windows TCP port 445-7777. So we're all stuck, until we can find an SMB server that works sans root. |
#6
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
On 18 Oct 2018 20:42:41 GMT, Frank Slootweg wrote:
That it's no longer on Google Play and rather old (2015-12-12) is not very promising. But as - so far - you're empty-handed... Hi Frank Slootweg, Thanks for finding that APK for us. I realize it's difficult as nobody seems to have an SMB server that works. The goal is a general solution to run any Windows command on Android files. (Nobody is going to solve anything without understanding that is the goal.) That means we need a drive letter (I think) on Windows. In other words, the Android device has to show up as a "removable drive". That's easy to do (I've done it) but it's not easy as a general solution. Hence we're breaking new ground (as usual). Nobody knows how to do this ... yet. Most of the people who responded to the last thread, simply responded to keywords. They never even understood the problem. They responded to keywords the same way they respond to those keywords every time they see them. They didn't even read the words between the keywords. You know this to be true Frank, where, so far, only you and Paul (and maybe a couple of others) have shown any comprehension of the problem set. The goal is a general purpose solution for every user to run any Windows command on the Android file system over USB (which means it needs to be mounted as a drive letter, as far as I understand things on Windows). If we can't get USB, then we'll take WiFi over SMB. If we can't get SMB, then we already have plenty of solutions that work. So that, in a nutshell, is the entire problem set, outlined in order. Thanks for understanding that breaking new ground is never easy, where the goal is a _general_ solution for everyone. (That's _always_ the goal, by the way, which is why what I do is _harder_ than what most people do.) At the risk of elevating the detail level of this thread well over the heads of 99% of the people here, I'll state the obvious which is that I already have a whole bunch of working solutions (in best-to-worst order): o *LibMTP freeware* works _perfectly_ on Linux (as you know) o *MTPDrive payware* works perfectly fine on Windows (as you know) o *MTPDrive crippleware* works reasonably well on Windows (as you know) o *WebDav servers* work ok on Android (using Windows network locations) o *FTP servers* work ok on Android (again, using Windows network locations) .... (there are plenty of other servers such as ssh, adb, http, etc.) o *SMB servers* would mount as drive letters (but they have other problems) I'll repeat that I already have multiple solutions that work great for me. That's not the problem set. *The problem set is a _general_ solution that works for everyone.* To that end, I see only three viable approaches: 1. Find an MTPDrive alternative (such as libMTP) for Windows 2. Find an SMB solution that works on both Android & Windows |
#7
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
Once we get an SMB server working, we can map Windows TCP port 445-7777. So we're all stuck, until we can find an SMB server that works sans root. Keep in mind that Windows 10 no longer supports SMBv1. You must find an android app that uses SMBv2 to communicate with Windows 10. |
#8
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to somethinghigher than 1024 on Windows?
M.L. wrote:
Once we get an SMB server working, we can map Windows TCP port 445-7777. So we're all stuck, until we can find an SMB server that works sans root. Keep in mind that Windows 10 no longer supports SMBv1. You must find an android app that uses SMBv2 to communicate with Windows 10. Well, that's easy enough to check. Yup, still there. https://i.postimg.cc/0Q3YmL6p/smbv1-17763-55.gif Win10 asks for authentication more than it should. There is a patch for WinXP for SMBV1, which when I applied it, broke sharing. The Win10 end was sending "Need More Information" as a status back to the WinXP machine, before refusing to talk to it. I removed the patch and the connection worked again. Lots of ways to break it, that's for sure. But the mechanical bits... are still there. It's up to the user to puzzle out, why it's not working today :-) As Char as pointed out in the past, lots and lots of broken networking cases, can be solved by using IP address notation \\192.168.7.23\datadisk instead of \\bob\datadisk as the latter needs an additional subsystem to translate symbolic to numeric address. On a Linux box (one where they didn't care), that typical gets it running for you, using the IP address of the server. There have been some Linux distros with perfectly working and very nice file sharing (both client *and* server!), but there is no consistency from release to release on the topic. It's a shame really. Paul |
#9
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
On Sat, 20 Oct 2018 00:37:18 -0400, Paul wrote:
\\192.168.7.23\datadisk instead of \\bob\datadisk Hi Paul, Can you help unstuck us on doublebackslash syntax? The doublebackslash syntax works _great_ with WebDAV servers on Android: http://www.bild.me/bild.php?file=8605173dir05.jpg For example this mounts Android filesystems over WiFi as a removable drive: net use X: \\192.168.1.6@8080\DavWWWRoot\ NOTE: This has a huge advantage that "DavWWWRoot" is a WebDAV keyword! But, I can't figure out the doublebackslash syntax for FTP servers! http://www.bild.me/bild.php?file=4785408ftpshare01.jpg http://www.bild.me/bild.php?file=8734999ftpshare02.jpg This doubleslash syntax works just fine as a "network location" (Using the default of "francis" for both the login & passwd.) http://www.bild.me/bild.php?file=4785408ftpshare01.jpg But I can't, for the life of me, figure out the doublebackslash syntax! http://www.bild.me/bild.php?file=8734999ftpshare02.jpg Since these syntax attempts fail every time for me: dir :2221 net use \\192.168.1.6@2221\Root etc. I suspect DOS will work just fine, if we can just figure out the syntax. Can you, or anyone, help us figure out the FTP doublebackslash syntax? |
#10
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to somethinghigher than 1024 on Windows?
Arlen Holder wrote:
On Sat, 20 Oct 2018 00:37:18 -0400, Paul wrote: \\192.168.7.23\datadisk instead of \\bob\datadisk Hi Paul, Can you help unstuck us on doublebackslash syntax? The doublebackslash syntax works _great_ with WebDAV servers on Android: http://www.bild.me/bild.php?file=8605173dir05.jpg For example this mounts Android filesystems over WiFi as a removable drive: net use X: \\192.168.1.6@8080\DavWWWRoot\ NOTE: This has a huge advantage that "DavWWWRoot" is a WebDAV keyword! But, I can't figure out the doublebackslash syntax for FTP servers! http://www.bild.me/bild.php?file=4785408ftpshare01.jpg http://www.bild.me/bild.php?file=8734999ftpshare02.jpg This doubleslash syntax works just fine as a "network location" (Using the default of "francis" for both the login & passwd.) http://www.bild.me/bild.php?file=4785408ftpshare01.jpg But I can't, for the life of me, figure out the doublebackslash syntax! http://www.bild.me/bild.php?file=8734999ftpshare02.jpg Since these syntax attempts fail every time for me: dir :2221 net use \\192.168.1.6@2221\Root etc. I suspect DOS will work just fine, if we can just figure out the syntax. Can you, or anyone, help us figure out the FTP doublebackslash syntax? Mapping a share to a drive letter, works for smb. https://www.howtogeek.com/118452/how...pt-in-windows/ FTP is a different URI and protocol. There's an example of mapping an FTP site here. I'm not convinced this is exactly what you want. https://www.thewindowsclub.com/map-an-ftp-drive-windows When they do it here, it doesn't have a drive letter. What exactly has been mapped ? What is the access syntax ? Explorer is supporting the URI, rather than some other layer. http://cybernetnews.com/cybernotes-m...ve-in-windows/ I would have to set up an FTP server to test. Something I don't normally keep running here. This goes to a whole bunch more trouble to achieve that result. It's an "ftp use" equivalent to "net use", complete with adding what appears to be a parallel stack for storage. This appears to be free. https://www.ferrobackup.com/map-ftp-as-disk.html Paul |
#11
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
On Sun, 21 Oct 2018 16:42:22 -0400, Paul wrote:
Mapping a share to a drive letter, works for smb. https://www.howtogeek.com/118452/how...pt-in-windows/ Hi Paul, I appreciate you're trying to help, since this is the holy grail for mounting FTP "shares" over WiFi as a drive letter on Windows using nothing on Windows but the native "net use" command (which we _know_ must work!). I'm sorry this is so complex - where I think only Frank Slootweg and I seem to have a clear handle on the complexity. With respect to mounting Android FTP "shares" as a drive letter on Windows using "net use" syntax.. the problem, as I see it, is _only_ of syntax. Nothing else. The reason I say it must be syntax is that it works sometimes. And it fails sometimes. Specifically... For mapping Android FTP servers over WiFi to a drive letter, these work: o Windows NetDrive freeware o Windows DirectNetDrive freeware For mapping Android FTP servers over WiFi to a drive letter, these fail: o Windows native "net use" o Windows FTPuse freeware o Windows SFTPNetDrive freeware So if we can figure out why some methods work, and others fail, we could figure out why the methods that fail, don't work - which is most likely a syntax problem (because some methods work just fine to map Android FTP server shares as a drive letter over WiFi). The problem _must_ be as simple as syntax, for all I know at this time. The reason I say it _must_ be as simple as syntax, is because I already long ago had FTP drives mounted as drive letters using DirectNetDrive & NetDrive Windows freeware. o DirectNetDrive http://www.bild.me/bild.php?file=4731516dir011.jpg o NetDrive 1.3.2.0 http://www.bild.me/bild.php?file=1383190dir014.jpg *So certainly we _can_ mount FTP "shares" as a drive letter over WiFi.* So all we have to figure out is the right syntax to give Windows "net use". To get that syntax correct, it's good that you started with SMB since o Windows works best native with SMB o And where the UNC syntax will likely be best described for SMB But SMB servers, as you know, are problematic on Android. https://groups.google.com/forum/#!topic/comp.mobile.android/3QQ8bAZeXNI And worse, SMB UNC syntax doesn't usually specify the port syntax But we need that port syntax to make an FTP UNC syntax work. Still, that reference is good for UNC syntax help sans ports: https://www.howtogeek.com/118452/how-to-map-network-drives-from-the-command-prompt-in-windows/ Specifically the ability to specify the SMB user & password (if not port). net use s: \\tower\movies /user:HTG CrazyFourHorseMen Which, for our FTP user & password "francis" & \DCIM folder, would be: net use s: \\192.168.1.7\DCIM /user:francis francis Which results in the DOS error: System error 53 has occurred. The network path was not found. Where I left this Android freeware FTP server at its default settings: https://play.google.com/store/apps/details?id=com.theolivetree.ftpserver Interestingly, this login/passwd/port URI works just fine as a URL in a Windows web browser and that URI also works just fine as a "network location" in Windows file explorer: Where "francis" is the default FTP server user name & default password. Notice the default ftp server port of "2221" isn't in the SMB syntax (probably because it's assumed to be TCP port 445 by Windows). For the freeware Android WebDAV server below set to its defaults: https://play.google.com/store/apps/details?id=com.theolivetree.webdavserver This is a URI that works both as a URL in a web browser on Windows and as a "network location" in the Windows file explorer: http://192.168.1.7:8080/DCIM/Camera And, this works as a UNC to "mount" that as a "removable drive": net use X: \\192.168.1.7@8080\DCIM\Camera http://www.bild.me/bild.php?file=8605173dir05.jpg Since SMB syntax shows us how to specify the UNC user & password, and since WebDAV syntax shows us how to specify the UNC port, maybe we can put the two syntaxes together to specify both the UNC port & user/password? net use W: \\192.168.1.7@2221\DCIM\Camera /USER:francis francis Interestingly, that didn't result in an "error 53", but an "error 59": System error 59 has occurred. An unexpected network error occurred. FTP is a different URI and protocol. There's an example of mapping an FTP site here. I'm not convinced this is exactly what you want. https://www.thewindowsclub.com/map-a...drive-windows\ That seems oh so very close to working (it almost worked!): http://www.bild.me/bild.php?file=9948610ftpshare03.jpg Windows10 File Explorer: Computer Map Network Drive Map Network Drive Drive = Q: Map Network Drive \\192.168.1.7@2221\DCIM [x]Connect using different credentials It popped up a request for the credentials of "francis & francis". But it failed with an error after asking a few times for the login/passwd: "Windows The mapped network drive could not be created because the following error has occurred: A device attached to the system is not functioning." http://www.bild.me/bild.php?file=5127116ftpshare04.jpg Even though clearly the web browser & "network location" both simultaneously worked with this URI: Since it _almost_ works to mount as a drive letter, I suspect there's just one more thing we need to do (perhaps somehow marking the directory as "shared" on Android?) When they do it here, it doesn't have a drive letter. What exactly has been mapped ? What is the access syntax ? Explorer is supporting the URI, rather than some other layer. http://cybernetnews.com/cybernotes-m...ve-in-windows/ Yes. This has been working all along. It's what I've been calling a "network location". This URI syntax has always worked just fine as a "network location" Its _only_ the mapping to a drive letter that the syntax is needed where you'd think this would work - but it errors out at error 59: net use \\192.168.1.7@2221\DCIM /USER:francis francis The problem, as I see it, is _only_ one of syntax. Nothing else. Although, I must admit, FTPuse and SFTP Net Drive don't work, so whatever is making _them_ fail, may be what is making "net use" fail also. I would have to set up an FTP server to test. Something I don't normally keep running here. It's easy to set up an FTP server on Android over your WiFi. You download this server & that's it. It's set up already. https://play.google.com/store/apps/details?id=com.theolivetree.ftpserver This goes to a whole bunch more trouble to achieve that result. It's an "ftp use" equivalent to "net use", complete with adding what appears to be a parallel stack for storage. This appears to be free. https://www.ferrobackup.com/map-ftp-as-disk.html Yes. We know all about FTPuse. FTPUse used to work for me prior to Windows 10, and FTPUse works fine for Frank Slootweg who is not on Windows 10 (I think he's on Win7). http://www.bild.me/bild.php?file=4223201dir010.jpg In summary, we _know_ it's clearly possible to map FTP servers to drive letters since we already have working solutions, such as the older free-for-home-use NetDrive version 1.3.2.0 freeware running on Windows: https://filehippo.com/download_netdrive/history/5/ http://www.bild.me/bild.php?file=1383190dir014.jpg And also with DirectNetDrive freware running on Windows: http://www.directnet-drive.net/ http://www.bild.me/bild.php?file=6340420dir012.jpg In summary, I apologize for the complexity, where, as I see it, since we _know_ that some of the software has no problem mounting the Android FTP "shares" as a "removable drive" in Windows 10, that the only problem we're having with "net use" is the syntax. Solving that syntax problem is going to take someone who knows more about Windows than I do, as I tried experimentally, with a lot of syntaxes. The best clue we have is that these have no problem mounting the Android FTP directories as a drive letter over WiFi: o NetDrive o DirectNetDrive While these fail to mount the Android FTP directory over WiFi as a drive letter: o net use o FTPuse o SFTPNetDrive If we can figure out _why_ those _fail_, that will probably tell us what the problem is with the "net use" syntax (since we know it _can_ work). |
#12
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
Arlen Holder wrote:
[About 'Map network drive', 'Add a network location' and 'net use'.] AFAICT from all references sofar and some testing: 1. 'Map network drive' and 'net use' can not handle FTP syntax, period. 2. 'Add a network location' *can* handle FTP syntax, and *can* handle a (FTP) port number. 3. (Windows) File Explorer *can* handle FTP syntax and *can* handle a (FTP) port number. This is irrelevant for the problem at hand, but is used to verify that the FTP server is working correctly. In order to verify 2., I needed both a public FTP server (because the FTP servers on Android (have to) use non-standard port numbers) and a/my Android FTP server (ES File Explorer). As the public FTP server I used 'ftp://speedtest.tele2.net'. Verify 3.: ========== - The FTP URL 'ftp://speedtest.tele2.net' should work in your browser and in (Windows) File Explorer. - The FTP URL 'ftp://speedtest.tele2.net:21' - i.e. with the default FTP port number 21 - should also work in your browser and in (Windows) File Explorer. - The FTP URL 'ftp://speedtest.tele2.net:80' - i.e. with a port number other than the default FTP port number 21 - should FAIL in your browser and in (Windows) Verify 2.: ========== - (Windows) File Explorer - This PC - Add a network location - Next - Choose a custom network location - Next - Internet or network address: - ftp://speedtest.tele2.net - Next - (leave as is) - Next - (leave as is) - Next - untick 'Open this network location when I click Finish.' - Finish. - 'This PC' will now show a Network Location 'speedtest.tele2.net', which will open on a double-click. - If you delete and re-add the Network Location, but now enter ftp://speedtest.tele2.net:21 as the 'Internet or network address:', you will see that that also works. - If you delete and re-add the Network Location, but now enter ftp://speedtest.tele2.net:80 as the Internet or network address:', you will see that that FAILs, which it is *supposed* to do, because 80 is the incorrect port number. - So we have verified that: 2. 'Add a network location' *can* handle FTP syntax, and *can* handle a (FTP) port number. We can also use 'Add a network location' with a FTP server on Android, by using (for example) ftp://192.168.0.109:3721 as the 'Internet or network address:', but that does not offer much new functionality, because we can already enter ftp://192.168.0.109:3721 directly in the 'path' bar of (Windows) File Explorer, so this is just a way of not have to re-enter the FTP URL. The FTP server is still not accessible *outside* File Explorer (and web browsers), i.e. it is *not* accessible by normal 'DOS' command, like 'dir', etc.. So we're stuck with: 1. 'Map network drive' and 'net use' can not handle FTP syntax, period. If someone thinks differently, then please show *real* *working* examples with *real* FTP servers and port numbers, i.e. something like: [ftp://]host.domain:port Where host, domain and port are real. |
#13
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
Frank,
1. 'Map network drive' and 'net use' can not handle FTP syntax, period. If someone thinks differently, then please show *real* *working* examples with *real* FTP servers and port numbers, i.e. something like: I'm surprised that you even considered testing it. FTP is not, and has never been, a way to access a drive. In the same way "net" (use) has never been something to support internet protocols. Also, FTP is a *file transfer* (as in: the whole thing) protocol, not ment to be used to do random reads and writes to a file. DIR ? Yes. COPY ? yes. DEL ? yes. ATTRIB ? Nope, only Linux-style permissions are supported. Anything else ? Not so much. As such it cannot even be used to do Arlens "every window command" with it. And that is where his story ends. Unless he's willing to check out stuff like this he https://www.ferrobackup.com/map-ftp-as-disk.html .... Which he isn't (which is a good, but limiting choice). Than again, as long as you use third-party software (or write it yourself!) you can get (most) everything to work - even (full, raw) disk access over morse. :-) Regards, Rudy Wieser |
#14
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
R.Wieser wrote:
Frank, 1. 'Map network drive' and 'net use' can not handle FTP syntax, period. If someone thinks differently, then please show *real* *working* examples with *real* FTP servers and port numbers, i.e. something like: I'm surprised that you even considered testing it. FTP is not, and has never been, a way to access a drive. I can assure you that I know full well what FTP can and cannot do (I've - professionally - been doing networking since the very early 70s, before any kind of 'Internet'), but read on. In the same way "net" (use) has never been something to support internet protocols. Well, as 'Arlen' posted, 'net use' *does* work with a WebDAV server and - in this context - WebDAV does offer similar functionality as FTP. So for WebDAV, 'net use' *is* "a way to access a drive" and hence *is* "something to support internet protocols". The whole point is that 'net use' *does* offer WebDAV compatibility/ functionality, but for some reason does *not* offer FTP compatibility/ functionality. That might make sense to Microsoft, but it doesn't make any sense to normal people, especially since FTP is older than WebDAV. Also, FTP is a *file transfer* (as in: the whole thing) protocol, not ment to be used to do random reads and writes to a file. DIR ? Yes. COPY ? yes. DEL ? yes. ATTRIB ? Nope, only Linux-style permissions are supported. Anything else ? Not so much. As such it cannot even be used to do Arlens "every window command" with it. Yes, that's the whole point! That's why he - and everybody else - *wants* a SMB solution, but - unless rooted - Android can not use ports below 1024 and Windows is too stupid to use another port (than the default 445), which most other SMB clients/servers *can*. So he/everybody else *wants* a SMB solution, but *until* that actually *works* - for a SMB server on a non-rooted Android device -, he's looking at less-ideal alternatives. And that is where his story ends. Unless he's willing to check out stuff like this he https://www.ferrobackup.com/map-ftp-as-disk.html ... Which he isn't (which is a good, but limiting choice). I can't blame you for not following all he posts, but he *did* and *does* look into this (FTPUSE) [1], but for some reason, he can not get it to work on Windows *10*. (He used it before on some other Windows version - probably Windows XP - and I used (no longer need it) it on Windows 8.1.) He has asked for others to test it on Windows 10, but AFAICT nobody has done so. I wonder why!? :-) If you have Windows 10 and want to help him, please feel free. Than again, as long as you use third-party software (or write it yourself!) you can get (most) everything to work - even (full, raw) disk access over morse. :-) Nah! Morse code is SO old-fashioned. These days we use Avian Carriers [2]! [1] AFAIR, he was actually the first to mention FTPUSE in these groups. From: Jonas Schneider Newsgroups: microsoft.public.windowsxp.general,comp.mobile.and roid Subject: What do you use to copy text files from Windows XP to Android over WiFi? Date: Fri, 24 Mar 2017 05:41:45 +0000 (UTC) Message-ID: [2] http://www.ietf.org/rfc/rfc1149.txt |
#15
|
|||
|
|||
What's the best way to forward SMB TCP port 445 to something higher than 1024 on Windows?
Frank,
I can assure you that I know full well what FTP can and cannot do (I've - professionally - been doing networking since the very early 70s, before any kind of 'Internet') My apologies. Well, as 'Arlen' posted, 'net use' *does* work with a WebDAV server and - in this context - WebDAV does offer similar functionality as FTP. Grumble, grumble ... Only now, due to your WebDav reference, I see that I mixed two threads up: The "android over USB" and this one. Mea culpa. :-( Yes, that's the whole point! Phew, I got at least that one right. :-) That's why he - and everybody else - *wants* a SMB solution, but - unless rooted - Android can not use ports below 1024 and Windows is too stupid to use another port (than the default 445), which most other SMB clients/servers *can*. I thought that that was solved ? I saw him mention a few port echoing (proxy) programs, with one of them being a standard windows app. Did it fizzle out for some reason ? I can't blame you for not following all he posts, but he *did* and *does* look into this (FTPUSE) [1], Its not that I think that he doesn't look into stuff, but that he expects others to name the programs that will solve his problems. [1] AFAIR, he was actually the first to mention FTPUSE in these groups. I might be too pessimistic - its ofcourse possible that he found some usable software on his own - but seeing how he pumps everyone here to come up with the programs he needs my default is to assume he got it by pumping some poor sod outside these newsgroups. He has asked for others to test it on Windows 10, but AFAICT nobody has done so. I wonder why!? :-) well... uuhh... Yeah, what can I say. I think he there reaps what he has sown. whistle If you have Windows 10 and want to help him, please feel free. No and no. And thats another reason why I dislike the guy. He keeps dumping his requests into the XP newsgroup, even though he should be aware that programs working on XP likely won't work on W10 (and vise verse). Nah! Morse code is SO old-fashioned. These days we use Avian Carriers [2]! :-) I thought of mentioning those, but found them a too-recent history. :-p Regards, Rudy Wieser |
Thread Tools | |
Display Modes | |
|
|