Slashdot Mirror
Procom to Release NETBEUI for Linux
Procom has announced that they are releasing their NETBEUI stack to the Linux community. Press release is here. What the press release doesn't mention is that the stack will be available under the GPL license. The actual code release will be today or tomorrow (I will post a URL for the source as soon as I get it).
No. SMB-atop-NetBEUI is no more "native" than is SMB-atop-NetBIOS-over-TCP.
Yes, the NetBEUI headers take fewer bytes than the NetBIOS Session Service, TCP, and IP headers, but it's not at all clear that this necessarily buys you that much.
No, Procom have GPLed an implementation of the NetBEUI protocol, specificat ions for which have been available for a while. (Look in "The NetBIOS Frames Protocol" section of the IBM document in question - yes, IBM, who were involved in it, as well as in SMB.)
SMB requests and replies are stuffed into the payload of NetBIOS-over-NetBEUI (or "NetBIOS Frame Protocol") packets, just as they're stuffed into the payload of NetBIOS-over-TCP Datagram Service and Session Service packets, etc.. SMB doesn't, by and large, need to know or care what protocol NetBIOS runs atop.
Broadcasts suck NOT because they suck bandwidth. Most LAN's broadcast bandwidth is a small fraction of the availabe bandwidth, but may still have a significant broadcast problem.
:) ). And broadcasts are forwarded on to ALL stations on a LAN, so all stations take that performance hit. Multicasts are like broadcasts, but the NIC card can be told to only subscribe to the multicast addresses it wants, so it doesn't have to process what it is not interested in.
When an ethernet card receives a frame, it evaluates whether or not the machine is interested. The frame is important and requires processing if one of the following happens:
1. The destination address of the frame is the MAC address of the ethernet card (unicast)
2. The destination address of the frame is a broadcast
3. The destination address is a multicast the ethernet adapter is interested in
An "interesting" frame results in the ethernet card generating an interrupt, which the OS must then decapsulate and analyze, even if the OS is truly not interested. Broadcasts generate a large number of "interesting" packets for the nic card, which triggers a large number of interrupts on the PC, which in turn takes CPU cycles away from other important tasks (like SETI@home
A side note....If I remember correctly, this was the initial problem with the first DOOM. The first version of DOOM used broadcasts, which killed all stations on that LAN, even if they weren't running a network protocol. A later patch updated DOOM to use unicasts instead.
NetBIOS over IP applications, like SAMBA, has the same issues. It generates broadcasts to announce "i have these services", "wheres workgroup so-and-so?", etc., etc. The saving grace of Netbios over IP is the functionality of WINS (Windows Internet Name Service, the netbios equivalent of DNS...just less scalable). With WINS, stations can register and look up other hosts on the network WITHOUT using broadcasts.
If you run Netbios Over IP on a sizeable network, across routers, or both, USE WINS. Or enable WINS resolution via DNS. And disable NetBEUI and NetBIOS over IPX. If you run NetBIOS over multiple protocols, it will broadcast over each of those. Yuck. Bye-bye network.
--
John Kramer
John Kramer
God may be my co-pilot, but the devil is my backseat driver.
Sweet jesus, do you know what this means? It means I just lost atleast a dozen bets with my friends... I have to go shave my head bald now... good grief... it's 70 and balmy in hell right now!
And in a related story Tesla LLC filed suit against Marconi Corp for improper use of Patented materials. Tesla LLC claims that Marconi Corp. used their patented algorythms in the creation of the "Morse Code" protocol stack and will appear in Court on Friday seeking a priliminary injunction.
Both Tesla LLC and Marconi Corp. were unavailable for comment.
Guys... forget the RIAA and MPAA lawsuits we all have to come out in force for this one. Can you imagine what would happen if we lost? The precedent that gets set? Please... buy the t-shirts that copyleft is producing showing the "Morse Code" translation algorythm! Support the EFF and lets get our voices heard.
:)
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
>Ethernet will even allow you to run both 10 and 100 Mbps devices on thesame medium.
Yes, but not at the same time...you can choose one or the other for each connection. There are, of course, hubs and switches that convert the two so that your network can have both, but it's not quite the same thing.
I don't see why I'd want my mouse over (even a personal) ethernet (that's only connected to my computer). More latency is bad - I expect and demand immediate response from my pointing device... no slowdowns are acceptable. Network printers are quite common and have been for years, though not in a home setting. There are many outboard ethernet -> parallel converters, and the smarter printers have internal cards for them - a net printer with 32/64/128MB of ram is definitely the way to go, in terms of not sapping resources (parallel ports are aweful, USB better).
Mice need clocking and power, and you can't duplicate that over standard ethernet. An interesting idea, though.
USB is one big shared interrupt for all of your peripherals - so there's no need for an extra network connection, and it should save at least one or two IRQs (serial and parallel - leaving one serial open).
As for the relative pricing, I'd say USB is a lower cost solution for most things - not much translating and address matching. Much less hardware. Very little protocol overhead (as opposed to a LAN). Stands to reason the amount of hardware should reflect this.
"It's tough to be bilingual when you get hit in the head."
I for one could sure use NetBEUI under Linux. Here's why:
I've got a 10Mb LAN set up at home with two computers, and the hub also hooks up to a cable modem. I am paying for two IP addresses from my cable company (don't ask me why I'm not using masquerading. Both machines are dual-boot, and it's too much a pain. Besides, technically I'm not allowed to do masquerading anyway).
The problem is that the two IP's always end up being on different subnets (I don't know why Videotron does this to me. It's DHCP, and they say that they can't do anything about it)! This means that for the two machines to talk to each other over TCP, packets have to actually leave my LAN, travel over the cable modem to the router, and then back through the cable modem to the other machine.
However, with NetBEUI my problem is solved, and I can transfer files from one machine to the other without having the packets routed out of my LAN and back in again.
-- Will quantum computers run imaginary-time operating systems?
There are a few good reasons for NetBEUI. Here are a couple:
1: It's not TCP/IP and it's not routeable, therefore non attackable unless you are on the same network.
2: For people on cable modems, NetBEUI is a better protocol for file sharing because it doesn't get spewed out to the entire network.
3: (Cable modems again). Screwey Cable Cos can put different machines on the same modem onto different class Cs. This makes TCP/IP really bad for moving data arround because you are limited to you modem bandwidth.
4: A brain-dead AOL user can set it up.
Nuf Said.
Even very small LAN's now use TCP/IP. NetBEUI is a thing of the past. And where it is used, it is usually used incorrectly. I remember a large corporate network that bridged NetBEUI to over 2,000 nodes and hired me for big bucks to determine why their network was so unstable. Duh.
Screw Micro$oft.
Our site (a university in Oxford, but not the Oxford University) ran on NETBEUI for years and years. It was already well established when I joined in 1991, and some very privileged folk had network connections on - gasp - "the backbone" (a bit of coax that ran through ceiling voids and through the ducts between the buildings).
We ran Lan Manager 2.0 with one server (running Microsoft OS/2!) and forty DOS/Windows 3.0 clients. We evaluated and immediately rejected TCP/IP because (a) the server-side stack made the server blow up and (b) the client-side stack consisted of umpteen little TSRs which together left enough real-mode memory to run EDLIN. I should also point out that we British had brilliantly chosen X25 rather than TCP/IP as our national network protocol so the Internet dawned rather late here.
NETBEUI was succesful here for three reasons. Firstly it was "on" in a default installation of server and client. Secondly it was chatty and self-discovering, a bit like Appletalk (another technically crappy protocol that nevertheless made life easy when doing small setups). Thirdly it was monolithic and small in memory.
Now you aren't supposed to go above about 200 nodes in a bridged environment like this, as any fule kno, but we eventually had about 2,000 nodes running NETBEUI quite happily. It was only last summer that we finally got around to implementing VLANS on the central Cisco - and this brought the house down, as Microsoft's SMB clients (in 3.11 and 95) are pretty broken when it comes to working on vanilla TCP/IP with just a minimal LMHOSTS file and DNS support (we didn't want to use WINS).
Nowadays NETBEUI only operates in one of our VLANS, the one containing the main servers and the public PC labs. We've recently been remote-booting 95 using Lanworks ROMs and BOOTP. They load a floppy disk image which has the real-mode Lan Manager client (including NETBEUI), do a bit of hard disk integrity checking/maintenance, then whack the real-mode client on the head, vapourise the virtual A: drive, and execute Windows 95.
Works like a charm.
SO... what is the effect of this announcement on us? Well, back in the days of DEC we bought several big Alphas. We've been feeling pretty annoyed since Compaq/Microsoft ended development on this platform. Now, assuming that SAMBA gets modified to play nicely with this NETBEUI stack, we can give them a new lease of life by running Linux on them instead.
george
Could NetBEUI over Ethernet be a replacement for USB? Just name your mouse "mouse", your printer "printer", etc. You could plug it into a dedicated network card, a hub, or even directly into the network. I know they can make the cables reasonably thin, they do it for PCMCIA cards already.
How is USB any better than ethernet? Ethernet will even allow you to run both 10 and 100 Mbps devices on the same medium. I suppose the only thing you loose is the ability to line-power devices. With PCI you should even be able to share interrupts.
What's cheaper these days, an ethernet IC, or a USB IC?
As many have mentioned already, this product is so old and out-dated, no one really wants it. However, it allows Procomm to get a free image-enhancement with the Open-Source community. They give away something they don't want anyway, and in return, get lots of fuzzy feelings from us Linux geeks. I'm waiting for the day when a company like this GPLs a serious application that's actually worth something. Then, I'll be impressed.
I thought Samba already managed NetBEUI interoperability pretty well. What kind of improvements does this bring to the table?
No, Samba does NetBIOS over TCP/IP, NetBEUI is another kind of network protocol, like TCP/IP, or IPX/SPX.
NetBEUI isn't routable though, which is usually a bad thing.
Microsoft itself has been moving away from NetBUIS to NetBIUOS over TCP/IP for Windows networking.
What Samba really needs is the ability to run as a Primary Domain Controller. Will this contribution help meet that goal?
No, but the beta version of Samba already has this, you just have to compile the code yourself.
IIRC, Samba PDC code doesn't work well with BDC though.
George
Don't dis them for doing something we, as Free software advocates, have been asking companies to do -- namely giving mothballed products to everyone rather than hoarding them.
Even if NetBEUI isn't viable anymore, it has value as an Open Source application:
Opening code that companies no longer value is more than just good PR -- it's a valuable practice, and it should be encouraged on general principal.
phil
In a move that rocked the open source community, the Marconi Corp. today announced plans to GPL their "Morse Code" telegraphy protocol stack, formerly widely used for telegram transmission. "Now that we have our entire office on the open TCP/IP protocol, we felt it was time to 'give back' to the community", said Paul J. Oldtimer III, his wrist still twitching from a long session at the key. "Our Morse Code Stack is the best in the business, with centuries of development and debugging that has left it the most mature protocol available."
Not all agreed that this boon to humanity was a welcome offer. "Telegraphy?!?" bellowed Peter D. Spittle, a Linux enthusiast and Networking consultant to the International Megabuck Banking consortium. "Who the heck uses that anymore in a competitive business environment? Maybe as a slow secure-channel protocol to thwart crackers busting in on your IP router, but for everyday use the manual routing personnel can delay packets for as long as an hour, depending on coffee breaks".
However, officials for the Marconi Corp. insist it is still a relevant protocol. "Look, say the line between Witchata and Flagstaff goes down, you can still get a ticker tape of the message to our guy on a horse who'll get it thru! The message must get thru!!", repeated Mr. Oldtimer, slumping in his chair as the whiskey bottle fell to the floor.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
A lot of people would like to be able to boot diskless DOS/Win95/Win98 boxes from a Linux server. There isn't a functional way to do that using TCP/IP. Yeah, there are some DOS IP stacks but using them prevents IP from working once Windows boots up.
Currently the only real way to handle it is using Netware shares. But now it should be possible to do it with NetBEUI instead... a preferable solution for booting a Microsoft OS (call it evil if you want.) At home, this will let me run my Windows box without a hard drive just by hanging it off my Linux machine.
Heck, this would be useful if only to recover a crashed Windows box without a rescue disk. :)
NetBEUI is not dead yet!
The fact is, someone will use it. How many times do you hit "n" when you're configuring your kernel? Lot's I'll bet. I know I do. I really don't give a crap about "Amateur Radio AX.25 Level 2 protocol", and yet somehow it snuck its way into my config script. So what? I just hit "n", and then forget about it.
Just because you don't (or the majority of users doesn't) care about a particular feature, it doesn't mean that there's not a place for it.
I'll be the first to tell you to get rid of Netbeui from your main network but there is one thing you can use it for.
In a DMZ you can setup a web server and use netbeui to connect to a resource server in the same DMZ and keep your resource server safe from several types of hacks, not perfect but still gives old netbeui a job
The world isn't run by weapons anymore, or energy, or money. It's run by little ones and zeroes, little bits of data.