NetBEUI & wireless access problems

I think your wireless access point doesn't support NetBEUI. Try using TCP/IP.

Have you installed the 9/30/2003 driver release for the TEW-226PC?
http://www.trendware.com/asp/download/fileinfo.asp?file_id=288&B1=Search

There may also be updates for the notebook's pcmcia. I'd point to that
but you never mentioned the make/model.

Well, if it doesn't support NetBEUI, why does it /mostly/ work?  I don't see anything in the docs about not supporting the protocol, either.

Yes, the cards are running the latest drivers, the WAP has the latest firmware, and the issue is happening to two different make/model laptops, so I don't think there's a PCMCIA driver issue there.

I'm with LucF with this one.  I'm at a total lose why you are using NetBEUI.  It's old, unsupported by Microsoft these days and unnecessary.  All you need is TCP/IP, Microsoft Client for Network and File and Print Sharing enabled (and the PCs in the same workgroup of course)

Keep the Protocol NetBEUI it is fine.

This is a latency issue with the two wireless devices...
Your request to the share is being dropped faster than the request can get to the laptop!

first,
try updating your firmware on your router
you might be able to flash your trendnet card as well

set your wireless card to a specific data rate
like:
10baseT Full Duplex
forcing your card to transmit at specific speeds can certainly help with latency!
Auto-negotiate is not always best choice

check your router settings for
802.11a , 802.11b , 802.11g transmissions set to what your trendnet card can respond to.

Use default settings for starters just to get things going , you can always tweak your security later.


thanks,
wtrmk74

Well, I appreciate the comments, but so far nothing has worked.  Regarding whether to use NetBEUI or not, that's not the question here.  The fact is I'm using it, and I haven't seen anything explicitly stating that I can't.

Both my WAP and card are as up-to-date as they can get, and I can't reduce the speed of the connection.  But, if it were a latency issue, wouldn't it be more inconsistent?  Like, sometimes I can get in, sometimes I can't?  My connection is registering 90% strength; I have trouble accepting that not good enough.

how many tcp/ip protocols do you have adapters enabled for ?

The post I made on 12/2 was before I ran into problems with my own network as well !

the reason I ask is somtimes microsoft has a difficult time communicating when multiple protocols are selected !

I don't know why and I have spent two days researching. apparently microsoft knows about it and isn't planning on fixing !
I just had a similar problem when I upgraded an XP home box on my network to XP pro , that were networked with win2k machines using Netbeui as well. Everything was fine with netbeui until the switch !

It wasn't working well at all I might add !       I had disappearing computers and shares !

I switched to tcp/ip only !

But anyway,
have you tried all of them-             ( IPX/Netbeui/TCPIP ) these are the only available choices for netbios!

are you sharing root of drive ? or just directories ?

wtrmk74

I meant how many protocols do you have enabled on your ethernet adapters !

sorry it's late and i need sleep !

:(,

hows it going ?

At this point, I haven't any answers.  I'm only sharing using NetBEUI, but IP works fine (just the two protocols bound to the card).  I'm sharing entire partitions, and I'm using two Win2k systems that had no problems when talking over cable.  As soon as I went wireless, I lost reliability.  I can't use IP only, unless you can tell me how to configure a DHCP server (Active Directory?) to give out public and private IPs to each system and run NetBIOS over the private one only.

how is your network connected together ?

WAN>SERVER>ROUTER>CLIENTS

WAN>ROUTER>SERVER>CLIENTS

WAN>ROUTER-SERVER
                     \  -CLIENTS

or whatever !

wtrmk74

Um, the last one is closest, I guess.  But, remember, the issue isn't with IP, so there isn't really a "wan" with NetBEUI.

Anatomy of IEEE 802.11b Wireless

August 7, 2000
By Joel Conover
"The most basic portion of the MAC layer is the ability to sense a quiet time on the network and then choose to transmit. Once the host has determined that the medium has been idle for a minimum time period, known as DIFS (DCF [Distributed Coordination Function] Inter-Frame Spacing), it may transmit a packet. If the medium is busy, the node must wait for a time equal to DIFS, plus a random number of slot times. The time between the end of the DIFS period and the beginning of the next frame is known as the contention window.

Each station listens to the network, and the first station to finish its allocated number of slot times begins transmitting. If any other station hears the first station talk, it stops counting down its back-off timer. When the network is idle again, it resumes the countdown. In addition to the basic back-off algorithm, 802.11 adds a back-off timer that ensures fairness. Each node starts a random back-off timer when waiting for the contention window. This timer ticks down to zero while waiting in the contention window. Each node gets a new random timer when it wants to transmit. This timer isn't reset until the node has transmitted..."

That....with WEP and all the chatter with NetBEUI is creating network contention.  While on a small wired network, you will not notice it, you are seeing this very behavior on the WiFi segment.  IPX/SPX will resolve some of this, but TCP/IP would be the most efficient.

-Eric

Check this...
http://support.microsoft.com/default.aspx?scid=kb;en-us;267643

Ok, this is starting to make me believe that NetBEUI isn't the answer.  Now, sometimes I only have one laptop on the wireless - there can't be that much chatter...

Secondly, why doesn't any of the hardware mfg's state that NetBEUI isn't support?  It would seem that it would be wise to announce that pretty clearly to avoid stupid users (like me).

Hold yer horses there...
First off, you got this far, disqualifies you as a "stupid user"
Secondly, you knew when to ask for help before "fixing" it and jacking it totally...so don't discount that.  Personally, I like ones who take initiative and interest, but know when it is time for collaboration.  

NetBEUI is supported, it almost HAS to be.  Grandfathered if you well.  I bet that thing will work with AppletalkV1.  now we are talking CHATTY!!!  AppleTalk and a misconfigured Xerox printcenter with its BONE multicasts...noisiest things I have ever seen.  Just be happy we aren't routing Appletalk here...  Anyways, it supports (more than likely) Appletalk, NBF (NetBEUI), IPX/SPX, TCP/IP...maybe TCP/IPv6.  It is all part of the IEEE 802.11 specs for backwards compatibility and unilateral support for ethernet.  Anyways...back to the issue.

With wireless networks, you want to keep the air as quite as possible.  It is affected by so many different things, you definitely want to run a tight ship for that segment.  For example, on a good day I average 6-7mbps (780KBs-910KBs) downstream, I want as much of that as I can get and as reliable as possible.  It is something special when my proxy downloads something for me and it comes down at 11MBs (the 100base ceiling w/OH, well close to at least).  What does all this mean...well when dealing with shares, file and app serving on a WiFi, you want all the juice you can get.  NetBEUI is great for small simple wired non-routed networks.  Wireless, adds a layer of complexity...not a huge one...but it adds a variable.  So...what is wrong with using a private IP range?

I don't know you needs or scenario or even equipment for that matter.  I would recommend against NBF on WiFi....very insecure and antiquated.  What are your requirements exactly?

-Eric

And also...it isn't just the bandwidth we are concerned about, most SOHO WAPs have a decent but fixed amount of resources, every broadcast (which  almost defines NBF) goes to the top of the stack and there by processed.  

I hate to use games (RTS<Real Time Strategy>) as an example, but on a 100base SOHO switched network running IPX/SPX.  Switching to TCP/IP improved game performance about 7-10% globally.  Freed the CPUs and the NIC buffers from broadcast processing.  Noticeable in the game.  More so on the less powerful computers...but still...

-Eric

thanks for jumping in NetworkMerc I knew you would have good input on this post !

end-user are you getting the info you need to help you along !

:)

Hey no problem.  Whats the status en-user?

-Eric

Status is largely unchanged.  If the solution is to run NetBIOS on TCP/IP and I need a public IP on each system, the question then becomes - "How do I run NetBIOS over a private IP address for file-sharing without exposing my network by also responding on a public address?"

In other words, if each system has a public IP address, and I assign a new private one and enable NetBIOS over TCP/IP,  won't my public address also respond to NetBIOS packets?  Does this make sense?

No....install IPX/SPX and bind file sharing to that protocol and run TCP/IP on the hosts that need internet access and unbind file and printer sharing to TCP/IP.  This will provide the results you are looking for.

-Eric

Better yet....get a gateway/firewall/NAT device, configure its DHCP server, block all netBIOS ports EXPLICITLY statically map to specific servers that need southbound access.  Install TCP/IP only on all hosts as DHCP clients, configure the WAP as a DHCP relay, with WEP and hardcoded to WNIC MAC addresses.  Only one public IP is needed and internal everything is simplified.

This isn't bad for the price.
http://www.netgear.com/products/prod_details.asp?prodID=140&view=sb

-Eric

Block Incomming and Outgoing:
135          TCP
137          UDP
138          UDP
139          TCP



You will what to have a more defined security policy, but this will block RPC and netBIOS over TCPIP


-Eric

Ok, so I've blocked these ports at the router.  That should enable me to safely file share over TCP on this side, right?

Now, I need to setup an Active Directory server to handle name discovery, right?

Those ports above will block imcomming traffic as well as outgoing netBIOS traffic without impeding traffic internally.  Now you need to set a server as a WINS and DNS server and add the netbios and host names to the services.  AD is a totally different topic.  

-Eric

If you are using strong WEP and hardcoding the wNIC mac addresses in WAP ACL, you can set DNS to allow unsecure dynamic updates, for virtually Administrative-free operation.  Even better make it a cachng and forwarding DNS server and let it be the DHCP server instead of your router.  Configure it to update DNS host names, create a scope using a private subnet.  Have the WAP forward all TCPIP traffic to and from the wired and wireless segments (<if availiable> including broadcasts, session keepalives and/or increase session time out value, it may have a "bridging" mode).  Disable "Computer Browser" service from all clients and servers except on the DNS server and make sure all internal hosts have NetBIOS over TCPIP enabled and "TCP/IP NetBIOS helper" service on Automatic and running.

-Network IP design (suggested)
CIDR: 192.168.100.254
#of Networks: 1
#of hosts:254
ID:192.168.100.0
Broadcast: 192.168.100.255
Type: Private Full Class C
Subnet: 192.168.100.0
Mask: 255.255.255.0
DNS Server: 192.168.100.1
Default Gateway: 192.168.100.254
WINS Server: 192.168.100.1
DHCP Server: 192.168.100.1
DHCP Scope: 192.168.100.100-192.168.100.199

-Router (if WAN IP is assigned via DHCP by the ISP)
1.Disable the routers DHCP server
2.WAN interface: per ISP/OEM instuctions, but if possible assign the WAN DNS to point to your internal DNS server
3.Ethernet Interface: IP;.254 SN;255.255.255.0 DNS;.1 DG:<per ISPs/OEM, maybe blank>
4.Enable NAT
4a.Add the deny rules/filters described in the previous comment (blocking RPC and NetBIOS traffic) and any other service or secuirty specific filters/mappings/rules/etc.
4b.Add the following filter/mapping for DNS:
IP Protocol: UDP (protocol#: 17)
Direction: send recieve
Local Port: All/Any Ports
Remote Port: Fixed Port; 53
Local/internal computer/host:.1
Remote computer/host: ISPs DNS servers (if you cannot add multiple IPs or the subnet for all the ISP DNS servers you may have to make a filter for each external DNS server, all the same setting expect use the respective IP of each DNS server for the remote computer/host).

-DNS/WINS/DHCP server
1.Install DHCP, DNS and WINS
2.Config WINS
3.Config DNS Forward and Reverse primary lookup zones, allow dynamic updates NOTE: FOR YOUR ZONE NAME DO NOT USE TLDs (.com, .net, .org, etc. make one up <i.e. "end-users.network">, so your domain name for your internal network would be "end-users.network")
3a.Add ISP DNS servers to the forwarders list and disable recursion for those (no need to devovlve external queries)
3b.Enable WINS and WIN-R lookup
2.Configure the DHCP options as followed:
Enable DNS "A" and "PTR" record update for clients
Address Scope: 192.168.100.100 - 192.168.100.199
Lease Duration: (depends if your mobile hosts connect to other networks frequently)  If they do a shorter lease is better, but if they pretty much stay on that network, a longer duration is preferred.
Router/Default Gateway: 192.168.100.254
DNS Server: 192.168.100.1
WINS Server: 192.168.100.1
DomainName: (you DNS zone name) example.int
NBT Node: h
Any other options you require

-WAP
1.disable its dhcp server, nat, firewall, routing services
2.config strong WEP and MAC hardcoded ACL
3.You may have to enable DHCP relay, but check OEM docs
4.NetCfg: IP;.250 DG;.254 DNS;.1 WINS;.1
If you cannot bridge, just make sure it forwards any and all traffic betweek segments

Restart all services...all should be good.  This is by no mean all-incluseive, just a suggestive outline.  As Always backup all data and configurations befor servicing your hosts, networks or devices.  Have documention handy and do your homework, work on the frontend saves on the backend.

Let us know...
-Eric

Well, it appears to be working so far.  But if it's a less noisy protocol, why's it so SLOW!?  Every share I touch is extremely sluggish compared to NetBEUI.  Is that normal?

Sounds like normal behavior when there is a lot of NBT broadcasting and/or authentication protocol negotiation between local security authorities.

OK...this should speed things up and add reliability:
-Disable the "Computer Browser" service from all servers and clients, except one server (PDC preferred or the WINS/DNS server)
-Install WINS, DNS and DHCP
-Confure both a forward and reverse zone and have DNS query the WINS server for forward and reverse (WINS-R).  Increase the DNS WINS query result TTL value and configure to forward all other domain requests to your ISPs DNS servers, but disable recursion for the forwards.

Are you using AD?

-Eric

Actually, it's not abandoned, I just haven't had enough time to fully implement a proposed solution.  However, it does appear that the answer is NetBEUI cannot run over a WAP.

end-user,

How much more time do you need?

Turn123