On Fri, 28 May 2004, Thomas Hertz wrote:
> 
> Yes, many products out there offers the possibility to route broadcasts but
> the FreeBSD team has decided that this is violating some RFC:s (which it
> is...)

It only violates RFCs in some cases.  In other cases, *not* routing them
violates RFCs. :-)

In principle, one could even NAT-redirect directed broadcasts, though
doing this unconditionally is probably a bad idea.

On Fri, 28 May 2004, Mitch (WebCob) wrote:
> 
> This would solve the wakee on lan problem - wouldn't it?

As I posted before, you don't specifically need broadcasts for
wake-on-LAN.  The main reason broadcasts are popular is to avoid the need
for ARP resolution (since the target machine is on no condition to
answer).  Adding a static ARP entry on the m0n0wall would get around that,
although you'd have to be careful to keep it in sync.

Making the ARP cache timeout really long would have a somewhat similar
effect.  In general, long-lived ARP cache entries are only problematic
when changing the MAC address of a machine used as a server.  This can be
gotten around by sending a few pings from the server to a nonexistent IP
after the address change.  However, the RFCs recommend short ARP cache
timeouts whenever Proxy ARP is in use, to avoid Proxy ARP's becoming even
more of a troublemaker than it already is.

Another solution would be an ARP feature to allow static "fallback"
entries, to be used only when the normal ARP mechanism fails.  If the
fallback entry became "stale", WOL would stop working but normal
connectivity would still work.  The "WOL not working" part is unavoidable,
anyway, since WOL requires knowledge of the MAC address regardless of ARP
issues.

On Fri, 28 May 2004, Neil Schneider wrote:
> Thomas Hertz said:
> > Hello Nicolas,
> >
> > Theoretically, this should be possible by using a WINS server on each
> > side
> > of the tunnel. As of the current version of Samba, I don't think it is
> > supported to let two Samba WINS servers exchange browse lists between
> > each

I believe that's true, but WINS is for name resolution, not browsing.  The
browsing part is handled by "master browsers", which may or may not also
be "domain controllers".

> > other, but using Windows servers should be possible. Windows SMB
> > protocol
> > that is used for "browsing" shares uses broadcasts, and broadcasts are
> > not
> > routable across subnets.
> 
> Exchanging browse lists between Samba servers acting as PDCs has been
> supported for a long time. The options are:
>         remote announce = 192.168.0.10
>         remote browse sync = 192.168.0.10
> 
> If two samba servers on either side of the vpn have this configured,
> and pointing to each other, then cross subnet browsing will work. I've
> had it working for nearly 3 years for one of my clients. I don't know
> the Windows equivelent if you're using NT/XP/W2K.

How does name resolution work in this environment, given that nmbd is
capable of acting as a WINS client *or* server, but not both?

					Fred Wright