Any way for this to work in docker desktop for m1 Mac? #12
Comments
|
Could you post the output of the container? I would expect some errors there as the installed Brother drivers for the shortcut keys to work are an amd64 package and not meant for arm. Not sure if Apple hacked some emulation layers into there, but even then I am not sure if this will work. It seems the implementation is very "non-standard", if basic things like host network mode are not supported... I have little hope here to be honest. But lets start with the output from the container... |
|
Ok, here are my logs: As for amd64 vs arm64, docker desktop uses qemu virtualization on macos as far as I understand and so I haven't had any trouble running a bunch of different docker images that weren't complied for arm64. I do get a message on this one which I haven't seen before when I do docker-compose up -d: But if I add And either way, I don't see any difference in the logs or in how the app works (at least, I am able to initiate a scan from the scripts in both cases). Thanks for your help! |
|
Interesting. So it seems things are running then. Good to know. I have little experience with (modern) cross platform containers, as I switched to x86 with most of my servers. Triggering with the script should work in any case, since this is nit deoensing on the Brother drivers at all. It uses built-in Linux features. You can also use the web interface on port 33355 (or 80 by default) to trigger a scan manually. Easier than launching the script from command line. Assuming your buttons are selectable (i.e., a server is set up), I assume that in your case the Brother driver will pick the internal Docker IP of the container and send this to the scanner via SNMP. This IP is of course not reachable from the outside. Thus, triggering a scan from the buttons will fail, as the scanner can't reach the server. Now, it might be possible to reimplement the Brother drivers, as we have most info on that in #10 from the pcap files, and manually configure the SNMP IP setting, but this will require some effort. This would allow to also use other IPs and travers NAT. Easier would be to somehow get the container on the host network, though. I fear there is not much way around this... |
|
It's a bit of a shot in the dark, as I can't get it to work here, but just for testing, what you could try is to launch from any computer that can reach your scanner something like this: Where is the IP address of your scanner and is the IP of the host your Docker container is running on. This should create a virtual shortcut button (i.e., on your scanner, select "Scan to PC", File, TEST, Start) which may or may not trigger the Brother driver in the container. |
|
Never mind, I set up my container without host network and tried this and while the setting of the parameters on the scanner works, it seems the trigger does not reach the server. Maybe there is some state involved in the driver, as well. Or I am missing something else entirely... |
|
Alright....so I experimented a bit more, reverse engineered the protocols a little (see also #10) and also build on someone elses reverse engineering of the binary. I think I have something that may work for you now. Try using the newest container, you no longer need network_mode:"host". Instead, set the ports to something similar to what you have already discovered yourself: ports: but additionally, you will need to define the IP address under which the scanner can find your machine. There is an undocumented option that we can use for this. If your laptop and your scanner are on the same network, this will be the address you are using to reach the web interface, as well. Depending on your setup, this may be the address of you Docker host, or your VM, etc. You might need additional settings on each virtualization layer. But this is no different than configuring access to the webserver, if this works, the scanner should be able to use the same setup to trigger a scan. Let me know how it goes! |
|
Thanks! I tried this out, still having some trouble though. I can see the "NAS" user the container is sending to the scanner on the scanner display when I do Scan to PC > file > NAS which I don't think was there before. But then it just says "connecting to computer" and times out. I did a tcpdump to see what it was doing, and there is a message coming from the scanner over udp, but it doesn't say what the message is and the container doesn't seem to respond. tcpdump output: and docker logs: If I docker exec inside the container and do a tcpdump there, I see UDP messages from the scanner getting into the container, and it looks like messages are being sent back, except a tcpdump from outside the container doesn't show these messages getting sent from the container back to the scannner...presumably why the scanner gets stuck at "connecting to computer": Not sure where to go from here. |
|
Maybe I could make a total hack to monitor tcpdump for a UDP message inside the container and when it comes, run the scantofile.sh script. Ha! |
|
Also now for the web gui I'm only getting a 500 service error, both if I check from inside the container and from outside. Not sure if something about that got changed in the last update you made or if I misconfigured something. |
|
First on the webserver: There shouldn't be any issues there. I haven't changed anything recently. Maybe check out the On the connectivity issues, I fear I need some more information. There seems to be some strange things going on:
So from what can gather here, there is at least one network too much. Try the following:
|
|
Closing this now. Feel free to reopen, if more support is required |
On docker desktop for Apple Silicon macs (m1, m2) the network_mode: "host" directive doesn't do anything.
I tried manually opening all the ports using
in my docker-compose.yml, and I also tried
This works when using the scrips after I exec into the docker container to pull a scan from the scanner, but the scanner never can find the server when I try to do scan to file. Is there some other port I should open or anything else I might be able to do to make it work?
The text was updated successfully, but these errors were encountered: