1. Home
  2. Wireless Networking
  3. can't file share files wirelessly over WRT54G router

can't file share files wirelessly over WRT54G router

I have a plain NETBIOS/NETBEUI file sharing network of 3 computers. The 2 desktops are wired. One runs OS/2 Warp, the other Win XP Pro. they are connected via a Linksys WRT54G version 2 router with the latest (Aug 05) firmware. Both desktops can access the internet via tcp/ip and share files with NETBIOS. I have not used netbios over tcpip because I like the security of having my file sharing not being routable.

I also have a Dell Inspiron 5650 with both wired and wireless adapters, set up with tcpip for internet access and NETBIOS for file sharing.

The problem is that while the Dell can access the internet wirelessly without problem, it cannot share files over the wireless connection. It cannot see or access the other computers, nor can the desktops see or access it. When I plug in via wired ethernet, file sharing works without problem.

I got the linksys configured for wep security, with a 26 digit password. I have tried changing the dell settings from shared to open and back, but nothing works. I've even tried to disable wireless security entirely to no avail.

I've had file sharing work wirelessly in the past with this router so I'm wondering what has changed. I may not have tried to share files since I did the firmware upgrade, so I"m wondering if something changed in firmware that would prevent me from sharing files.

Anyone have any suggestions for settings to try in the router and/or laptop to fix this? TIA

Reply to
Mark Klebanoff
Loading thread data ...

Maybe pure NetBios is not supported over the wireless. I don't know if you are gaining any security since an attacker could take over on the clients and then use it. You probably need to use the Netbios over TCP/IP.

Dan

Reply to
Dan

"Mark Klebanoff" hath wroth:

In theory, wireless is Layer 3 protocol neutral. Wireless is bridging and doesn't know anything about TCP/IP. The file sharing can be done with NETBEUI, IPX/SPX, or some other protocol, and it should still work. Note that for Windoze file sharing to function, NETBIOS must be running on top of some protocol. It's usually TCP/IP but can be NETBEUI. Make sure NETBIOS is enabled over NETBEUI.

The current version from Linksys is 4.20.7 dated 8/25/2005. I don't see anything in the release history that would affect this problem.

The question boils down to:

  1. What is different between the direct ethernet connection and wireless with respect to file sharing?
  2. What might be preventing NETBEUI file sharing on a specific interface?

Try:

  1. Do you have a working connection via wireless? There's no handy ping utility for NETBEUI, so you'll need ot rely on the supplied diagnostics. I can't find any useful way to test NETBEUI other than higher level sharing diagnostics such as: NET VIEW NETSTAT -an NBTSTAT -n If you see the rest of the network with these diagnostics, it's sorta working.

  1. Is NETBEUI properly installed on the DELL 5650? See:
    formatting link
    simple methinks.

  2. Do you have a working wireless connection? Not being able to share via NETBEUI might be indicative of no connectivity. The most common problem is WEP key failure. Use a Hex key, not an ASCII key, or temporarily test it with encryption disabled. If possible, you might try a different computer going through the wireless part of the puzzle. That will identify if the problem is with the Dell or the WRT54G.

  1. Try disabling the Windoze filewall on the Dell 5650. I don't think it will have any effect but it's worth a try.

  2. Did you properly enable/disable TCP/IP and NETBEUI in the adapter settings? This might account for the diffrence between wireless and wired. Control Panel -> Network Pull down the "Advanced" thingy on the menu bar at the top of the window. Check if the correct protocols are installed and bound to the adapter.
    formatting link
    make sure that Client for Microsloth Networks is installed and set to Windoze Locator for RPC/DNS services.

  1. It is possible that the WRT54G v2 is blocking broadcasts via the wireless interface. Try connecting directly to a remote share with: Start -> Run -> \\share_name You should get a directory listing even though Computers Near Me and NET VIEW show nothing.

  2. I'll assume that your Dell 5650 has SP2 and subsequent updates installed. There were a large number of network related bug fixes in SP2.

  1. Got any MAC filters enabled in the WRT54G? For that matter, got any IP filters that might be blocking TCP/IP traffic and taking other protocols with it? It's a stretch, but possible.

I sure wish there were a ping like utility that worked with NETBEUI. If all else fails, there's always sniffing the wireless connection and analyzing the capture file with Ethereal:

formatting link
that's far too much work for this problem.

Incidentally, I've run NETBEUI file sharing through various routers including a WRT54G v1.1 in the past without difficulties. It should work (famous last words).

Reply to
Jeff Liebermann

Well, it's worked in the past with this setup, so I'm trying to figure out what's changed. I already know how I can't do it, or how else to do it, but I want to know how I CAN do it.

Reply to
Mark Klebanoff

ping the other computers hooked up to the linksys by pinging their ip addresses (assigned by the dhcp server on the router).

There's no handy

When I type net view from one of the desktops it sees the laptop, but net view from the laptop finds nothing. nbtstat -n says no names in cache. I have no idea how to interpret netstat -an but I get a lot of tcp and ip sites

No, I can access the internet wirelessly and can ping the other local computers

The most

I don't have another wireless, unfortunately. I'll try turning off encryptataion.

The firewall has always been disabled. I use Zonealarm, but disabling that does not help

I think so.

Yes, it is.

I got "an unexpected network error occurred

Yes, it does. You don't suppose Bill Gates "fixed" NETBIOS, do you? He's done a lot worse to stifle competition.

I don't think so but I'll check

I agree, it has worked for me in the past.

Reply to
Mark Klebanoff

Now when I click on 'entire network" and then on the workgroup I see the laptop but I cannot access anything from it. Still not sure what's happening. I've confirmed that sharing's enabled

Reply to
Mark Klebanoff

Check your firwall settings... A common problem is that when an autoupdate is applied it changes settings...

Reply to
Peter Pan

"Mark Klebanoff" hath wroth:

(...)

Smells like a firewall problem, acts like a firewall problem, and probably is a firewall problem. If it only works in one direction, it's very likely a firewall problem (somewhere). I've had problems with Zonealarm that eventually required a total removal and reinstall to fix. I'm not sure this is one of those.

If nothing else appears as a better solution, try removing ZoneAlarm and rebooting. It seems a little drastic, but I don't have anything better to suggest.

Reply to
Jeff Liebermann

I removed zonealarm but to no avail.

Reply to
maxikins

snipped-for-privacy@os2bbs.com hath wroth:

Do you check that the Windows firewall didn't magically turn itself back on? Control Panel -> Windows Firewall

Well, that leaves few options.

  1. It might be the WRT54G. Temporarily replace with something else?
  2. Borrow a wireless laptop and try again?
  3. Sniff with Ethereal and see what's happening?
Reply to
Jeff Liebermann

What's Ethereal?

Reply to
Mark Klebanoff
[POSTED TO alt.internet.wireless - REPLY ON USENET PLEASE]

As always, "Google is your friend."

Reply to
John Navas

You need to do more than enable sharing. Find any suitable directory (not the entire hard disk) on your Dell and right click on the directory. Select "Sharing" and share the directory. Then, try viewing the laptop again from the other machines.

Reply to
Jeff Liebermann

If you don't know that, it will probably take far too long to explain how to use it and interpret the results. Packet sniffers are not for non-geeks. From a pervious URL in this thread:

formatting link

Reply to
Jeff Liebermann

Again that does not account for why I can share files with no problem via a wired ethernet hookup, but not with wireless.

BTW I checked again and confirmed that the bindings are set exactly the same for both wired and wireless adapters.

Reply to
Mark Klebanoff

I have on my laptop's desktop a shortcut to one of the folders on a desktop. I downloaded and installed ethereal and collected an output file when I tried to access that shortcut. For what it's worth the summary said that 25% was UDF, 25% NETBIOS, and 50% "other"

Here is the file. If anyone out there can interpret it, I'd be most appreciative. TIA. MK

Reply to
Mark Klebanoff

I've installed ethereal and collected the output when i tried to access a folder on another computer. The summary said 25% UDF, 25% NETBIOS and 50% other

Reply to
Mark Klebanoff

I've tried a couple of times to reply but don't seem to be able to get it posted. So I'm trying to reply via google. I downloaded a copy of ethereal, installed it on the laptop and generated a log when I tried to access one of the desktop folders from the laptop. I'm having a hard time attaching the log but I will mail it to you. The summary said 25% UDF, 25% NETBIOS, and 50% other, whatever that means. If anyone else would like to help out let me know and I'll mail it to them as well, and thanks.

Reply to
maxikins

I managed to convert the output to a text file and will post it in-line. If anyone can figure out what's bombing out I'd be appreciative

No. Time Source Destination Protocol Info 1 0.000000 GemtekTe_13:8e:70 NETBIOS- NetBIOS Name Query for MARKOS2P4

Frame 1 (61 bytes on wire, 61 bytes captured) IEEE 802.3 Ethernet Destination: NETBIOS- (03:00:00:00:00:01) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 47 Logical-Link Control NetBIOS Length: 44 bytes Delimiter: EFFF (NetBIOS) Command: Name Query (0x0a) Local Session No.: 0 (FIND.NAME request) Caller's Name Type: Unique name (0x00) Response Correlator: 0x0009 Query Name: MARKOS2P4 (Server service) MARKOS2P4 0x20 (Server service)

No. Time Source Destination Protocol Info 2 0.001051 Giga-Byt_52:88:fa GemtekTe_13:8e:70 NetBIOS Name Recognized - MARKOS2P4

Frame 2 (61 bytes on wire, 61 bytes captured) IEEE 802.3 Ethernet Destination: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Source: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Length: 47 Logical-Link Control NetBIOS Length: 44 bytes Delimiter: EFFF (NetBIOS) Command: Name Recognized (0x0e) State of name: No LISTEN pending, or FIND.NAME response Caller's Name Type: Unique name (0x00) Transmit Correlator: 0x0009 Receiver's Name: LAPTOP (Workstation/Redirector) LAPTOP 0x00 (Workstation/Redirector)

No. Time Source Destination Protocol Info 3 0.001078 GemtekTe_13:8e:70 Giga-Byt_52:88:fa NetBIOS Name Query for MARKOS2P4

Frame 3 (61 bytes on wire, 61 bytes captured) IEEE 802.3 Ethernet Destination: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 47 Logical-Link Control NetBIOS Length: 44 bytes Delimiter: EFFF (NetBIOS) Command: Name Query (0x0a) Local Session No.: 0x07 Caller's Name Type: Unique name (0x00) Response Correlator: 0x0009 Query Name: MARKOS2P4 (Server service) MARKOS2P4 0x20 (Server service) Sender's Name: LAPTOP (Workstation/Redirector) LAPTOP 0x00 (Workstation/Redirector)

No. Time Source Destination Protocol Info 4 0.002029 Giga-Byt_52:88:fa GemtekTe_13:8e:70 NetBIOS Name Recognized - MARKOS2P4

Frame 4 (61 bytes on wire, 61 bytes captured) IEEE 802.3 Ethernet Destination: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Source: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Length: 47 Logical-Link Control NetBIOS Length: 44 bytes Delimiter: EFFF (NetBIOS) Command: Name Recognized (0x0e) Local Session No.: 0x10 Caller's Name Type: Unique name (0x00) Transmit Correlator: 0x0009 Response Correlator: 0x0010 Receiver's Name: LAPTOP (Workstation/Redirector) LAPTOP 0x00 (Workstation/Redirector) Sender's Name: MARKOS2P4 (Server service) MARKOS2P4 0x20 (Server service)

No. Time Source Destination Protocol Info 5 0.002050 GemtekTe_13:8e:70 Giga-Byt_52:88:fa LLC U P, func=SABME; DSAP NetBIOS Individual, SSAP NetBIOS Command

Frame 5 (17 bytes on wire, 17 bytes captured) IEEE 802.3 Ethernet Destination: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 3 Logical-Link Control

No. Time Source Destination Protocol Info 6 0.003160 192.168.1.102 68.87.73.242 DNS Standard query A Markos2p4.net.nih.gov

Frame 6 (81 bytes on wire, 81 bytes captured) Ethernet II, Src: GemtekTe_13:8e:70 (00:90:4b:13:8e:70), Dst: LinksysG_6f:09:d8 (00:0c:41:6f:09:d8) Internet Protocol, Src: 192.168.1.102 (192.168.1.102), Dst:

68.87.73.242 (68.87.73.242) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 67 Identification: 0x59d3 (22995) Flags: 0x00 Fragment offset: 0 Time to live: 128 Protocol: UDP (0x11) Header checksum: 0x907f [correct] Source: 192.168.1.102 (192.168.1.102) Destination: 68.87.73.242 (68.87.73.242) User Datagram Protocol, Src Port: 1026 (1026), Dst Port: domain (53) Domain Name System (query) Transaction ID: 0xa039 Flags: 0x0100 (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries Markos2p4.net.nih.gov: type A, class IN Name: Markos2p4.net.nih.gov Type: A (Host address) Class: IN (0x0001)

No. Time Source Destination Protocol Info 7 0.051240 68.87.73.242 192.168.1.102 DNS Standard query response, No such name

Frame 7 (124 bytes on wire, 124 bytes captured) Ethernet II, Src: LinksysG_6f:09:d8 (00:0c:41:6f:09:d8), Dst: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Internet Protocol, Src: 68.87.73.242 (68.87.73.242), Dst: 192.168.1.102 (192.168.1.102) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 110 Identification: 0x8158 (33112) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 53 Protocol: UDP (0x11) Header checksum: 0x73cf [correct] Source: 68.87.73.242 (68.87.73.242) Destination: 192.168.1.102 (192.168.1.102) User Datagram Protocol, Src Port: domain (53), Dst Port: 1026 (1026) Domain Name System (response) Transaction ID: 0xa039 Flags: 0x8183 (Standard query response, No such name) 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... .... 0011 = Reply code: No such name (3) Questions: 1 Answer RRs: 0 Authority RRs: 1 Additional RRs: 0 Queries Markos2p4.net.nih.gov: type A, class IN Name: Markos2p4.net.nih.gov Type: A (Host address) Class: IN (0x0001) Authoritative nameservers net.nih.gov: type SOA, class IN, mname ns.nih.gov Name: net.nih.gov Type: SOA (Start of zone of authority) Class: IN (0x0001) Time to live: 15 minutes Data length: 31 Primary name server: ns.nih.gov Responsible authority's mailbox: dns.nih.gov Serial number: 8443 Refresh interval: 1 hour Retry interval: 10 minutes Expiration limit: 41 days, 16 hours Minimum TTL: 1 hour

No. Time Source Destination Protocol Info 8 0.449895 GemtekTe_13:8e:70 Giga-Byt_52:88:fa LLC U P, func=SABME; DSAP NetBIOS Individual, SSAP NetBIOS Command

Frame 8 (17 bytes on wire, 17 bytes captured) IEEE 802.3 Ethernet Destination: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 3 Logical-Link Control

No. Time Source Destination Protocol Info 9 1.100827 GemtekTe_13:8e:70 Giga-Byt_52:88:fa LLC U P, func=SABME; DSAP NetBIOS Individual, SSAP NetBIOS Command

Frame 9 (17 bytes on wire, 17 bytes captured) IEEE 802.3 Ethernet Destination: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 3 Logical-Link Control

No. Time Source Destination Protocol Info 10 2.052202 GemtekTe_13:8e:70 Giga-Byt_52:88:fa LLC U P, func=SABME; DSAP NetBIOS Individual, SSAP NetBIOS Command

Frame 10 (17 bytes on wire, 17 bytes captured) IEEE 802.3 Ethernet Destination: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 3 Logical-Link Control

No. Time Source Destination Protocol Info 11 3.454216 GemtekTe_13:8e:70 Giga-Byt_52:88:fa LLC U P, func=SABME; DSAP NetBIOS Individual, SSAP NetBIOS Command

Frame 11 (17 bytes on wire, 17 bytes captured) IEEE 802.3 Ethernet Destination: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 3 Logical-Link Control

No. Time Source Destination Protocol Info 12 5.507171 GemtekTe_13:8e:70 Giga-Byt_52:88:fa LLC U P, func=SABME; DSAP NetBIOS Individual, SSAP NetBIOS Command

Frame 12 (17 bytes on wire, 17 bytes captured) IEEE 802.3 Ethernet Destination: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 3 Logical-Link Control

No. Time Source Destination Protocol Info 13 8.561562 GemtekTe_13:8e:70 Giga-Byt_52:88:fa LLC U P, func=SABME; DSAP NetBIOS Individual, SSAP NetBIOS Command

Frame 13 (17 bytes on wire, 17 bytes captured) IEEE 802.3 Ethernet Destination: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 3 Logical-Link Control

No. Time Source Destination Protocol Info 14 11.105485 fe80::5445:5245:444f ff02::2 ICMPv6 Router solicitation

Frame 14 (119 bytes on wire, 119 bytes captured) Ethernet II, Src: GemtekTe_13:8e:70 (00:90:4b:13:8e:70), Dst: LinksysG_6f:09:d8 (00:0c:41:6f:09:d8) Internet Protocol, Src: 192.168.1.102 (192.168.1.102), Dst: 64.4.25.84 (64.4.25.84) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 105 Identification: 0x59d4 (22996) Flags: 0x00 Fragment offset: 0 Time to live: 128 Protocol: UDP (0x11) Header checksum: 0xc549 [correct] Source: 192.168.1.102 (192.168.1.102) Destination: 64.4.25.84 (64.4.25.84) User Datagram Protocol, Src Port: 1035 (1035), Dst Port: 3544 (3544) Teredo IPv6 over UDP tunneling Internet Protocol Version 6 Internet Control Message Protocol v6

No. Time Source Destination Protocol Info 15 11.185362 fe80::8000:f227:bffb:e6ab fe80::5445:5245:444f ICMPv6 Router advertisement

Frame 15 (151 bytes on wire, 151 bytes captured) Ethernet II, Src: LinksysG_6f:09:d8 (00:0c:41:6f:09:d8), Dst: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Internet Protocol, Src: 64.4.25.84 (64.4.25.84), Dst: 192.168.1.102 (192.168.1.102) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x20 (DSCP 0x08: Class Selector 1; ECN: 0x00) Total Length: 137 Identification: 0x5d3e (23870) Flags: 0x00 Fragment offset: 0 Time to live: 112 Protocol: UDP (0x11) Header checksum: 0xd19f [correct] Source: 64.4.25.84 (64.4.25.84) Destination: 192.168.1.102 (192.168.1.102) User Datagram Protocol, Src Port: 3544 (3544), Dst Port: 1035 (1035) Teredo IPv6 over UDP tunneling Internet Protocol Version 6 Internet Control Message Protocol v6

No. Time Source Destination Protocol Info 16 13.118114 GemtekTe_13:8e:70 Giga-Byt_52:88:fa LLC U P, func=SABME; DSAP NetBIOS Individual, SSAP NetBIOS Command

Frame 16 (17 bytes on wire, 17 bytes captured) IEEE 802.3 Ethernet Destination: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 3 Logical-Link Control

No. Time Source Destination Protocol Info 17 19.927912 GemtekTe_13:8e:70 Giga-Byt_52:88:fa LLC U, func=DM; DSAP NetBIOS Individual, SSAP NetBIOS Response

Frame 17 (17 bytes on wire, 17 bytes captured) IEEE 802.3 Ethernet Destination: Giga-Byt_52:88:fa (00:0d:61:52:88:fa) Source: GemtekTe_13:8e:70 (00:90:4b:13:8e:70) Length: 3 Logical-Link Control

Reply to
maxikins

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.