2. News ******** Wi-Fi Router Integrated Onto SOC Broadcom Corp. just announced the release of a highly integrated Wi-Fi router processor, enabling manufacturers to build networking products that address the performance, cost and security needs of small businesses.
The new AirForce BCM5350 with Sentry5 technology combines 54g wireless LAN routing, Fast Ethernet switching, accelerated virtual private network (VPN) security, and a MIPS(R) instruction set processor into a single system-on-a-chip (SoC). The company claims that this high level of integration eliminates the need for multiple components while delivering the performance and security previously available from devices at up to twice the cost. Broadcom --> http://lists.planetee.com/cgi-bin3/DM/y/egBk0F7aIi0Emn0BIsA0Ao Bob George wrote: > There are a few guys I've worked with over the years who, no matter what > the challenge, immediately start working on a technical solution without > bothering to understand first what the requirements are. I always like > to start with "What does it (whatever it is) need to do?" > > So same question here: WHAT is this 'thing' supposed to do when it's all > done? The same functions as that $70 linux-on-linksys solution? Act as a > DOS-based modem or radio transmitter/receiver? > > Day Brown wrote: > >> Bob George wrote: >> >>> [...] Sure. You push a character into the UART and tell it to send. >>> Ok so far... It's digital data, so then what? Where's it go out >>> that port? >> >> >> I believe there are transmitter chips that will accept a 5vdc signal >> to set the output frequency. > > > I'm sure there are chips that will let you set a frequency. That isn't > what you described, but OK. They DO exist. So your device sets the > output frequency of (presumably) a radio device of some sort? > >>> [...] An interrupt is generated, all other processing stops >>> (completely) until that I/O is completed. [...] >> >> >> The only time the com port signal would be needed is to change, or >> establish the frequencies to be used. > > > OK, so you ARE referring to using DOS to communicate a setting to a > transmitter of some sort. No problem there. That much works fine. > >> Nevertheless, there are setups which run off preset crystals at >> designated frequencies, so then the com port would not be needed. > > > Sure. Or you could use a knob to set a frequency. You presumably want to > talk TO someone and not just broadcast (or?) so it would be handy if you > and your pals agreed to some reasonably small number of potential > channels. Unless you want to run scanner-style and hop around until you > find someone yammering, then "connect" somehow? > >> But if, as below you used more than one antenna, or for whatever >> reason, like trying different setups out, being able to conveniently >> change the frequencies would be useful. > > > If the one or more antennas are tied to the same transmitter, it doesn't > matter WHAT frequency you're using. Or do you really mean more than one > RADIO (transmitter/receiver)? > >>> And then there's the question: What the hell are you getting at? >>> WHY are you taking audio input via the soundcard and doing what a >>> modem does in but in software? Why are you pushing digital >>> characters out the serial port, but receiving analog (?) via the >>> sound card? >> >> >> The soundcard expects analogue, the transmitter/receivers also expect >> analogue. Seems reasonable to get them to work together. > > > So you're going to tie the analog output from the radio to the > soundcard, and have the DOS machine do A/D conversion? Via the > soundcard? Or are you going to talk on one end and use some bizarre > 'speech-to-text' engine under DOS? (I like that one. :) > > OK, so far we have a machine running DOS that can set radio frequencies > via DOS software, and doo 'something' to a recieved analog signal coming > in via that radio. > > You just described an expensive, DOS-based version of a tabletop radio, > unless there's more to it. > >>> What data? What are you doing here? You surely don't "need" a GUI >>> to use the web! Lynx runs on DOS today. >> >> >> There seem to be a variety of webpages which no DOS software will >> render. > > > OK, so you NOW are going to be talking to someone other than your band > of ASCII-ueberalles rebel compadres, eh? So this thing needs to actually > make it from your wonderland to "the real world." How does that happen? > Does this behemoth end up plugging into another device (the > linux-on-linksys perhaps?) that actually does the "real work?" > >>>> But many of us remember being online with DOS at a BBS, and with >>>> the data rate nowadays, seems like COMMO would still download >>>> .gif or .jpg, and that you could shell out to look at the images, >>>> or listen to sound files. >>> >>> >>> Wait, you're NOT using Mozilla/GUI now? >> >> >> Of course, I'm using Mozilla; with XANDROS. > > > So you're using the Xandros Linux OS now. No more DOS? The entire > DOS-based gizmo described so far winds up talking to a Linux box in the > end? > >>> You mean shell out to an image viewer? Sure that works. 'Course the >>> "download" stuff probably stops dead (unless there's more to this >>> than COMMO you mentioned) but that works. >> >> >> It never bothered me that the download stopped. I didnt come across >> that many images I wanted to bother with. > > > EVERYTHING stops until the software lets go. You have described a > DOS-based system that is going to have to handle a lot of incoming > analog signals and convert them to digital... BEFORE it even determines > whether those signals are of genuine interest. Assuming your machine is > fast enough to do that (not a problem) anything other software on the > system is going to have to wait until this (raw) decoding occurs. Sure, > you can stive for 'efficient' code. You also need to buffer the other > stuff that's coming in whilst this is all occurring (in real-time via > the IRQ interrupts generated by the sound card.) It's starting to sound > like the system is going to be VERY VERY busy just contending with this > inbound (you haven't described outbound) traffic. > >>> Viruses worked just fine with DOS. DOS systems were readily >>> infected back in the glory days of the BBS. Downloading via any >>> other network would be no different, and the same safeguards would >>> be required as of any other OS. >> >> >> All the saboteurs nowadays aim their weapons at windoz; > > > An equally determined crowd aims at the network and infrastructure, or > raw TCP/IP traffic. NOTHING is untouched that's on the Internet. If this > contraption talks to anybody outside, it will probably get hit. Yes, > they may not know what your system consists of (this is the argument > used by proprietary wireless vendors) but 'security by obscurity' is > little guarantee. > > > nobody > >> *cares* what we are trying to do in DOS. > > > So far, I agree completely! > >> As for viruses working fine >> with DOS, I *never*, in a dozen years online with BBSes, had a virus >> problem. > > > I never had one on my system either, but that doesn't mean they weren't > a pervasive problem. Perhaps your experience has as much to do with > vigilant and responsive (and over-worked) BBS ADMINS as your ninja-like > avoidance methods? > >> {COMMO} and the other DOS termcoms *could not* respond to a >> virus. > > > They were also SERIAL. Not networked. If a terminal-type interface is > all you need, then great. But SOMETHING has to talk on the network to > get to those web pages you mentioned. What will do that? If it's > network, it may well be vulnerable to some of the same exploits that > target TCP/IP stacks on Windows, *nix and Cisco gear. *NOTHING* is > immune to attack if it's connected to anything else. > >> You had to download an infected file, and then *run* it. With >> DOS, there was no *background* for this to happen in. > > > See previous item. If you're not on the network, fine. But setting up a > DOS PC that surfs the web via SOME OTHER networked computer isn't a full > solution. Something has to talk on the network. If you're talking about > using a PC as a dumb terminal, sure that's pretty bulletproof. But what > that terminal attaches TO needs to be as well. > >> All the termcom >> did was render the ANSI bbs menus and show you the available file >> lists and newsgroups. Even the 'ANSI bombs' could be avoided by using >> an ANSI driver which did not include the routines to reassign key >> codes. > > > Ha, I forgot about those! So much the the name of the OS being > protection. There's a perfect example of an attack that did not require > any action on the part of the use to effect an attack. Sure, there are > REACTIVE measures. Doesn't help if you already got bit, though. > >> I'm not suggesting that you use the 70$ box; but it is indicative of >> the low cost of hardware that might be designed to accept a DOS >> wireless connection. > > > Sorry, but now I'm lost. Above, you were describing a DOS system driving > some sort of radio contraption. Now you're talking about THAT talking to > an 802.11b spread spectrum system? Or do you mean get a DOS PC to talk > wireless to the linksys? The latter is certainly doable, though I can't > cite any products available to the general public to do so, other than > ethernet-wireless bridges (again, a "smart" device to which the DOS box > talks.) > >> [...] >> Which raises the question of what other systems DOS users could still >> employ... another connection point built to work with DOS from the >> git go. > > > That is the missing link after all! > >> The incompetence of the local ISPs I have, all three, is such that no >> DOS software will log on to any of them. > > > That's as likely a failure of the DOS market to continue development to > keep otherwise perfectly viable products up to current standards. ISPs > presumably have weighed the risks of losing the ever-shrinking > population of DOS-only customers against the ever-growing need for > enhanced capabilities to increase profitability in an ever-increasingly > complex and competitive environment. They live or die by pennies. > > > However, BBS systems and > >> networks still exist which DOS can use > > > Yes, and a dumb terminal could be used as well. > >> if furthermore there is a >> wireless way to reach a DOS hub, then users would still have a >> cheaper and more robost way to exchange data. > > > On what do you base "cheaper?" Or "robust" for that matter? Do you mean > the contraption you were describing at the start? > > > Then, they can us a > >> local network which may have a GUI OS to view images or whatever. > > > So one machine to do everything with under DOS, and another to view > imageas and whatever else? I'm confused. > >> I >> dont see much need for such a local server to need anything more than >> DOS. > > > As long as you have SOMETHING TO CONNECT TO that does "all that other > stuff" (like actually talking to other systems) then sure. A terminal > works fine. > > > Since hardware is so cheap, there is not nearly the need for a > >> multitasking platform to also handle the firewall. > > > I'm trying hard to follow: Are you saying you could do everything the > $70 Linux-on-Linksys system does more cheaply and reliable under DOS? > Are you including the voice capabilities? Spread spectrum radio? > > Day, you've thrown out a good smattering of solutions. What problems are > they to solve? > > DOS can do a LOT of things, and many VERY WELL. However, a single DOS > system (nor a handful) can't necessarily do EVERYTHING that you seem to > be alluding to. > > - Bob > >
