(I posted this in the Network/Internet forum. It was suggested to post here as well.)
I have a database manager (Sybase SQLAnywhere) running in an OS/2 guest VM. I have not succeeded in making it visible to the outside world. The dbm is also running on a native OS/2 installation without any problem so I an guessing that the linux host is somehow preventing the expected operation.
I have opened port 1498 (sybase-sqlany) in the linux firewall. I have also allowed UDP/TCP broadcasts on port 1498. When a SQL client (in a VM!) is searching for a connection, it broadcasts on port 1498 IP 255.255.255.255, then 192.255.255.255 which elicits a response from the native OS/2 system. The dbm in the VM never responds. (I do not run both servers at the same time.)
What settings are required to allow a broadcast through to the VM?
IMO you should also post your virtualization technology.
You should also understand that switches do not normally allow broadcasts.
Probably the real question should be why you want to allow broadcasts when much of networking is dedicated to eliminating in favor of directed connections. So, for example with your db although I am not familiar with specifically that with others it’s common to register clients instead of relying on discovery by broadcast. Even “modern” implementations of Workgroup communications favor dirwcted TCP/IP instead of legacy broadcasts.
(I have posted this question in several fora starting with VirtualBox; the tech was obvious there. So far, no one has offered a hint of a solution. )
You should also understand that switches do not normally allow broadcasts.
That has not been an issue here since, well, ever. The ethernet switches have always allowed broadcasts.
Probably the real question should be why you want to allow broadcasts when much of networking is dedicated to eliminating in favor of directed connections. Even “modern” implementations of Workgroup communications favor directed TCP/IP instead of legacy broadcasts.
Well that may be. For the products we have, however, the initial server discovery is by broadcast. After the server has responded, a point-to-point connection is established for the remainder of the session.
Guys,
I stand by my statement although the default settings of some switching equipment may have changed.
Switches are not supposed to allow broadcasts to pass by default, its the hubs which existed prior to switches which allowed by default. Routers are a completely different class of network devices which as noted have never allowed broadcasts to pass.
It’s one of the things that defines a switch device.
So, the inference of my statement is that you should inventory your network layout and identify each physical and virtual switch, then test (or research the features) of each to verify what it might take to allow broadcasts… Some managed switches can simply be configured accordingly, others might need to be replaced.
Another simple test is to configure a client and server connected either by a known hub, direct link or switch known to be configured to pass broadcasts. If your discovery by broadcast works there, then you can add in additional devices until you find the culprit.
Of course they are supposed to forward broadcasts otherwise DHCP wouldn’t work by default if you connected a server and a host to one switch. They always worked this way and still do by default. How LAN Switches Work - Cisco Systems
The major difference with hubs and switches is with collisions.
)
otherwise DHCP wouldn’t work by default if you connected a server and a host to one switch. They always worked this way and still do by default.