<snip>
> "however now due to the increasing number of users I would just like the
> server to broadcast to the network."
>
> Maybe I'm misreading this, it is somewhat unclear.
It is: does she mean the X server (client machines) or the servers
that are providing service.
Reading further I *think* that the IPFilter firewall may be
running on the machine that is providing service to the X
terminals. If this *is* the case then she should add rules to
allow the server to receive broadcasts (without "keep state"!)
*and* (if necessary) allow 177/udp *out*. Antony Riley's
explanation of the broadcast XDMCP case is correct and these
additions should allow the broadcast case to work *if it's
all local traffic*. The IP addresses in the original message
imply it probably is local unless there are unusual netmasks.
> > > I have no idea why this would ever work through a router, unless the
> > > router is forwarding network broadcasts (which is generally a bad thing).
The only thing I can think of in this case would be to run
an X chooser on the router.
> > I'd agree in the first case. In the second case it *should*
> > work through a router. A straightforward UDP "keep state"
> > rule shoudl allow the XDMCP packets through. Once the XDMCP
> > negotiation(s) are complete, the server will need to display
> > a login window on the client which is a X11 call from the
> > server to port 6000 on the client.
>
> The port 6000 stuff is not relavent to the question, as the computers are not
> appearing on the chooser.
Just completing what needs to be there for the directed cast to work.
> Keep state will not work, if the query is sent to the broadcast address, as
> the reply will not be from the broadcast address, but from the machine that
> is replying.
In the broadcast case, I agree. In the unicast case it would (work).
--
David Pick
