|>>Which application uses mailslots? I only ever found one real |>>application that used them, and that was "Declan's Korean Dictionary" |>>from [1]. |> |>The browse (Network Neighborhood) service uses them. Other then that, |>I have not seen any uses of it. | | Protel 98 (likely higher versions too) uses them. | | MSDN says that the datagrams are limited to 424 bytes in length, so
even if
| they are not very useful otherwise, getting Protel running on wine
seems a
| worthy goal to me. I'll try hacking on it and seeing where I end up.
See http://www.ubiqx.org/cifs/Browsing.html#BRO.3 for more information
libsmbclient from Samba 3 does not support it at the moment
What do the "match_mailslot_name" and "cli_send_mailslot" functions do, then? Anyway, if the wire protocol is simple enough, and so it seems from ubiqx.org article, then I can just synthesize all the relevant layers to send the multicast UDP. The only piece of info that I'll (hopefully) need from wine is the netbios node name. For reception, I'll bind UDP port 138 (netbios-dgm) if it's not already bound, to receive the mailslots coming in. Now, if a samba server is already running on given host, which is reasonable if the person running wine wants to share something with other windows hosts, is it possible to somehow poll the nmbd and/or smbd to get the mailslot datagrams that weren't "consumed" by the browsing protocols? Does that make sense? Any more hints? Cheers, Kuba
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Kuba Ober wrote: |>|>>Which application uses mailslots? I only ever found one real |>|>>application that used them, and that was "Declan's Korean Dictionary" |>|>>from [1]. |>|> |>|>The browse (Network Neighborhood) service uses them. Other then that, |>|>I have not seen any uses of it. |>| |>| Protel 98 (likely higher versions too) uses them. |>| |>| MSDN says that the datagrams are limited to 424 bytes in length, so |> |>even if |> |>| they are not very useful otherwise, getting Protel running on wine |> |>seems a |> |>| worthy goal to me. I'll try hacking on it and seeing where I end up. |> |>See http://www.ubiqx.org/cifs/Browsing.html#BRO.3 for more information |>libsmbclient from Samba 3 does not support it at the moment | What do the "match_mailslot_name" and "cli_send_mailslot" functions do, then? Those are internal functions - the "official" functions are in libsmbclient.h. Of course, it is very well possible to use these functions (they haven't changed for ages). However, it might be hard to use that function (given that it's internal). Now that I've looked at the prototype, it looks ok: int cli_send_mailslot(int dgram_sock, BOOL unique, const char *mailslot, ~ char *buf, int len, ~ const char *srcname, int src_type, ~ const char *dstname, int dest_type, ~ struct in_addr dest_ip, struct in_addr src_ip, ~ int dest_port, int src_port); | Anyway, if the wire protocol is simple enough, and so it seems from ubiqx.org | article, then I can just synthesize all the relevant layers to send the | multicast UDP. The only piece of info that I'll (hopefully) need from wine is | the netbios node name. | | For reception, I'll bind UDP port 138 (netbios-dgm) if it's not already bound, | to receive the mailslots coming in. Samba (nmbd) binds to that port (for browsing among other things). | Now, if a samba server is already running on given host, which is reasonable | if the person running wine wants to share something with other windows hosts, | is it possible to somehow poll the nmbd and/or smbd to get the mailslot | datagrams that weren't "consumed" by the browsing protocols? In Samba 3, no (all this stuff is handled inside of nmbd, not exported). | Does that make sense? Any more hints? Yes, makes sense to me. I still think it would make more sense to work on Samba integration with Samba4 rather then 3 as it'll be troublesome with Samba3. Cheers, Jelmer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCNdsIPa9Uoh7vUnYRAjGwAJoCFQbAE/GWfReVkfTpxIo+sX1bpACfRECB oXcEa1LlORUDplId+g+8U8I= =OLrO -----END PGP SIGNATURE-----
On Mon, 14 Mar 2005, Kuba Ober wrote: [...]
For reception, I'll bind UDP port 138 (netbios-dgm) if it's not already bound, to receive the mailslots coming in.
Note that on Unix you'll need to be root to bind to port 138 (<1024). Just wanted to mention that, just in case. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une b\xEAta...
On wtorek 15 marzec 2005 05:39 am, Francois Gouget wrote:
On Mon, 14 Mar 2005, Kuba Ober wrote: [...]
For reception, I'll bind UDP port 138 (netbios-dgm) if it's not already bound, to receive the mailslots coming in.
Note that on Unix you'll need to be root to bind to port 138 (<1024). Just wanted to mention that, just in case.
Then probably we can have a tiny suid-executable that's just a reflector: redirects all incoming packets to some other port, and vice versa. Cheers, Kuba
On Tue, Mar 15, 2005 at 04:51:19PM -0500, Kuba Ober wrote:
On wtorek 15 marzec 2005 05:39 am, Francois Gouget wrote:
On Mon, 14 Mar 2005, Kuba Ober wrote: [...]
For reception, I'll bind UDP port 138 (netbios-dgm) if it's not already bound, to receive the mailslots coming in.
Note that on Unix you'll need to be root to bind to port 138 (<1024). Just wanted to mention that, just in case.
Then probably we can have a tiny suid-executable that's just a reflector: redirects all incoming packets to some other port, and vice versa.
Use a iptables firewall rule. Ciao, Marcus
Hi, On Wed, Mar 16, 2005 at 09:53:15AM +0100, Marcus Meissner wrote:
On Tue, Mar 15, 2005 at 04:51:19PM -0500, Kuba Ober wrote:
On wtorek 15 marzec 2005 05:39 am, Francois Gouget wrote:
On Mon, 14 Mar 2005, Kuba Ober wrote: [...]
For reception, I'll bind UDP port 138 (netbios-dgm) if it's not already bound, to receive the mailslots coming in.
Note that on Unix you'll need to be root to bind to port 138 (<1024). Just wanted to mention that, just in case.
Then probably we can have a tiny suid-executable that's just a reflector: redirects all incoming packets to some other port, and vice versa.
Use a iptables firewall rule. That's a nice idea, but I'm not sure it's actually feasible, since without further Wine infrastructure the user would have to add this firewall rule on his own. I think we need some kind of suid root daemon soon, because there are several aspects that might require that: this very problem, further Samba integration, the ping implementation in Wine (which requires root on Linux), maybe even some syscalls or I/O communication in Linux, some filesystem interaction (but that one will need less and less root permission, I guess) and probably some more. Such a daemon would then be able to add this firewall rule, too, of course.
OR maybe do some kind of sudo trickery directly at Wine installation to be able to use that whenever we require that. That way we might not even need such a specific Wine root daemon, which should be a good thing. (after all we should attempt to make use of existing, established and well-working infrastructure as much as possible instead of inventing new specific, non-general crap). Andreas Mohr
Kuba Ober wrote:
Then probably we can have a tiny suid-executable that's just a reflector: redirects all incoming packets to some other port, and vice versa.
The real solution is to talk through Samba or the kernel. If Wine owns port 138/139 then Samba won't work, and vice versa. There needs to be some sharing mechanism. Mike
On Wed, 2005-03-16 at 18:55 +0900, Mike McCormack wrote:
Kuba Ober wrote:
Then probably we can have a tiny suid-executable that's just a reflector: redirects all incoming packets to some other port, and vice versa.
The real solution is to talk through Samba or the kernel. If Wine owns port 138/139 then Samba won't work, and vice versa. There needs to be some sharing mechanism.
This is one of the many things I hope we will discuss at the WineConf. There should be a good Samba contingent there, and I'm assured a few wine folks intend to turn up ;-) In all seriousness, there are existing mechanisms to get at some of these packets to non-root users, but they are a bit of a Samba-specific hack. For Samba4 (which is where we should plan integration, because we can design it properly) I would love to see wine able to register for such mailslots with the Samba server. (Alternate non-samba solutions will probably be required in parallel, I suppose). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net
Andrew Bartlett wrote:
hack. For Samba4 (which is where we should plan integration, because we can design it properly) I would love to see wine able to register for such mailslots with the Samba server. (Alternate non-samba solutions will probably be required in parallel, I suppose).
I'm wondering whether fuse (http://fuse.sourceforge.net/) might be a good way for Samba and Wine to communicate? If Samba were a fuse server, and provided named pipes and mailslots through a single fd, that would be the perfect interface for Wine. For those not familiar with why we can't use libsmbclient, it's because we need to make sure that many Wine processes can share reading and writing to a single file atomically. ReadFile needs to be done in a single read() operation, and WriteFile in a single write(), otherwise there'll be race conditions. Mike
participants (7)
-
Andreas Mohr -
Andrew Bartlett -
Francois Gouget -
Jelmer Vernooij -
Kuba Ober -
Marcus Meissner -
Mike McCormack