OK, I've downloaded the docs for the WRT54G and looked at it.

It would appear to be a bridge, not a router. This is what infuriates me about marketing people. Words mean things, and when you call an "apple" a "potato", some people who like to use the right word for the right thing (like me) get pissed off. It would appear that the WRT54 family of "routers" can run a routing protocol, but it would appear that the default mode is as a level-2 device, using spanning tree bridging.

It would appear to me that, yes, if you have someone penetrate the WEP security on your wireless port, they would be able to access the Windows Workgroup enabled PC's on the Ethernet switch side of this device. I do not see a way in the Linksys documentation of blocking the protocol(s) for Workgroup from being accessed by wireless devices.

If you're really enterprising, you could download the source for DD-WRT (or other open source firmware for the WRT54) and add protocol filtering to the configuration. All that really needs to be done here is to configure the 'router' to not allow certain Ethernet or IP protocols or ports (respectively) to be transmitted across the WRT inside the 'router'. It is that simple.

I still know some people inside cisco and I'll flip 'em a note and suggest that they add this feature to the Linksys firmware. It is a really obvious idea and one that would really enhance user security. Still, even if the device allowed you to block the Workgroup protocols, you should know that any protocol can be "tunneled" past most firewalls inside HTTP. If you've never seen "tunneling" before, here it is, boiled down:

Let's say you have some protocol you want to get past your firewall. FTP, SMTP, whatever.

You write up some browser plug-in (say, in Java or Javascript, or ActiveX) and you grap the FTP/SMTP packets on your PC and wrap them inside a HTTP packet that is allowed past your firewall.

On the other end, your HTTP server looks at the HTTP packet and says "Oh, I see this is a FTP or SMTP packet -- I'll unwrap the payload out of the HTTP packet and forward it on to the FTP or SMTP port on the destination machine."

Wha-la, no more firewall, until such time as the firewall admin configures a deeper access list to see the tunneled header.

Then the hackers respond by using SSL to encrypt the HTTP payload, and the firewall is effectively neutralized.