On Sun, 11 May 2003, Manuel Kasper wrote:
> The mailing list address is now m0n0wall at lists dot m0n0 dot ch (no need to
> resubscribe; all subscribers have been copied over). Redirections have
> been set up for the old addresses (URLs and mailing lists). There's now
> also a separate mailing list for m0n0BSD, so if you're interested in it,
> feel free to subscribe (m0n0bsd dash subscribe at lists dot m0n0 dot ch).
So if the impending move of the lists was the reason not to bother setting
up the "Reply-To:", that's no longer an issue. :-) Right now it's
necessary to edit the address manually when replying to a post.
> OK, now it's time to let you know that I made an executive decision
> concerning SSH in m0n0wall. I decided that I do not want SSH (for logging
> in remotely and getting a shell) in m0n0wall. I cannot see the point in
> having it - FreeBSD in m0n0wall is so stripped down, there isn't even a
> simple text editor. m0n0wall was intended as a "black-box" system, and the
> user shouldn't need to (or be able to) worry about the underlying
> operating system (FreeBSD, in this case). Besides, due to the custom rc.*
> stuff (mostly PHP), there are few hooks where one could easily add his/her
> own stuff on a live system.
But the #1 reason for wanting shell access is diagnostics. Any router
worth its salt should offer the "big three" of network debugging - ping,
traceroute, and tcpdump. Although m0n0wall currently has a limited ping
capability, web-based ping is inferior for at least two reasons:
1) Ping has lots of options, and even if menus were provided for them all,
that would be much less convenient than just typing the options you want
on the command line.
2) Ping is most useful when the output is observable in real time, which
is fundamentally inconsistent with a web interface.
Similar issues apply to traceroute and tcpdump, though those are currently
not available at all in m0n0wall.
Sure, it's usually possible to perform those functions from another
machine, but it's often important to be able to use them from the router's
"point of view", which has no remote substitute. And of course the
ability to use the serial console for them can be useful in avoiding
"polluting" the network traffic one is investigating.
It's worth noting that lots of "little" devices offer shell access these
days, though usually via Telnet rather than SSH (which isn't unreasonable
within a LAN). E.g.:
1) All of SnapGear's routers support Telnet, though this feature is
2) Alcatel DSL modems support Telnet (as well as FTP).
3) HP network printservers support configuration via Telnet, which is a
good thing since their web-based setup only supports certain browsers
running under Windows. :-)