ipw-firmware (Intel Pro/Wireless 2100 Driver) Help



Hi All,

I am having issues with the ipw-firmware working correctly. Under my
windows partition, I see lots of wireless networks around my
apartment, but when I get on my FreeBSD partition and do an ifconfig
ipw0 scan, nothing shows up. Here's how I've been trying to check it
(as root):

# ipwcontrol -i ipw0 -r
Radio is ON
# ifconfig ipw0 scan
SSID BSSID CHAN RATE S:N INT CAPS
RONJON 00:13:46:a9:6d:30 6 54M 60:0 100 EPS
Ulia 00:0d:88:eb:c5:f6 9 54M 26:0 100 EPS
baba 00:09:5b:fb:c2:a8 11 54M 19:0 100 EPS
Rainear21 00:0f:66:4c:1e:8f 11 54M 15:0 100 EP
ASHOK 00:04:e2:a6:92:c9 6 54M 15:0 100 EPS
2WIRE550 00:12:88:dd:2e:e9 6 54M 23:0 100 EPS


Then I configure for RONJON with the following:
#ifconfig ipw0
ipw0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::204:23ff:fe6b:37ad%ipw0 prefixlen 64 scopeid 0x5
inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:04:23:6b:37:ad
media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)
status: no carrier
ssid RONJON channel 6
authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpowmax 100
bintval 100

I used dhclient to set everything up beyond the encryption stuff. I
have also tried disabling wep encryption on my wireless router to make
sure wlan_wep is not the problem.

Here's the outcome of pings:

# ping www.google.com
ping: cannot resolve www.google.com: Host name lookup failure
# ping 66.102.7.99
PING 66.102.7.99 (66.102.7.99): 56 data bytes
^C
--- 66.102.7.99 ping statistics ---
133 packets transmitted, 0 packets received, 100% packet loss

The last ping was waited on for about 5 minutes before I gave up.

# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
^C
--- 192.168.0.1 ping statistics ---
17 packets transmitted, 0 packets received, 100% packet loss

The last ping is for my router.

I know it can communicate with the router as this is what I get via a dhclient:

# dhclient ipw0
DHCPREQUEST on ipw0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.100 -- renewal in 302400 seconds.

Any other type of traffic seems to wig out the connection.

Anyone have any ideas on what's going on? I have been at this for
quite some time, and I can't get it figured out. Any help on any
other ways of debugging would be most appreciated.

Thanks!
Jon
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Wireless Network in Public Places Options
    ... >which are running mostly WRT54G hardware with alternative firmware. ... >which VLAN the packets need to stay inside. ... >with wireless as it cuts down on excessive broadcast traffic. ... But I was assuming that you understood that ping uses ...
    (microsoft.public.win2000.networking)
  • Re: Wireless Network in Public Places Options
    ... >which are running mostly WRT54G hardware with alternative firmware. ... >which VLAN the packets need to stay inside. ... >with wireless as it cuts down on excessive broadcast traffic. ... But I was assuming that you understood that ping uses ...
    (microsoft.public.win2000.networking)
  • Re: ping time out trouble , help
    ... Ping packets get lost discontinuously. ... whether there is any device in the scope that interfere the wireless. ... please also check how it works if you PING with small MTU. ...
    (microsoft.public.windows.server.sbs)
  • ICMP Ping being lost between kernel and the ping program.
    ... I'm having a weird intermittent problem with ping. ... We're a small wireless ISP with 40ish customers -- each of whom has a cheap ... picky one has a problem, other times they both have the problem. ... I can even capture the text description of or the raw contents of packets ...
    (Linux-Kernel)
  • Re: winsock error
    ... Ping sends 3 packets of data to a destination IP (or ... then my internet connection worked... ... wireless its ... Winsock and reboot), I would guess the next thing to check is the ...
    (microsoft.public.windowsxp.general)