Re: Penguin Wireless N USB Adapter TPE-N150USBL
Quoting Brian (ad44@cityscape.co.uk):
> On Tue 05 May 2015 at 22:02:42 -0500, David Wright wrote:
>
> > Quoting Charles Kroeger (ckrogrr@frankensteinface.com):
> > >
> > > root@mundo:/home/charles# ifconfig -a
> > > eth0 Link encap:Ethernet HWaddr 00:1b:21:4f:60:49
> > > inet addr:192.168.0.102 Bcast:192.168.0.255 Mask:255.255.255.0
> > > inet6 addr: fe80::21b:21ff:fe4f:6049/64 Scope:Link
> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > > RX packets:1051 errors:0 dropped:0 overruns:0 frame:0
> > > TX packets:502 errors:0 dropped:0 overruns:0 carrier:0
> > > collisions:0 txqueuelen:1000
> > > RX bytes:291611 (284.7 KiB) TX bytes:82072 (80.1 KiB)
> > > Interrupt:17 Memory:fbfe0000-fc000000
> > >
> > > lo Link encap:Local Loopback
> > > inet addr:127.0.0.1 Mask:255.0.0.0
> > > inet6 addr: ::1/128 Scope:Host
> > > UP LOOPBACK RUNNING MTU:65536 Metric:1
> > > RX packets:55 errors:0 dropped:0 overruns:0 frame:0
> > > TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
> > > collisions:0 txqueuelen:0
> > > RX bytes:15256 (14.8 KiB) TX bytes:15256 (14.8 KiB)
> > >
> > > wlan0 Link encap:Ethernet HWaddr 00:c0:ca:72:68:d4
> > > UP BROADCAST MULTICAST MTU:1500 Metric:1
> > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> > > collisions:0 txqueuelen:1000
> > > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> > >
> > > wlan0:avahi Link encap:Ethernet HWaddr 00:c0:ca:72:68:d4
> > > inet addr:169.254.10.111 Bcast:169.254.255.255 Mask:255.255.0.0
> > > UP BROADCAST MULTICAST MTU:1500 Metric:1
> > >
> > > root@mundo:/home/charles# lsmod | grep ath
> > > ath9k_htc 52702 0
> > > ath9k_common 12687 1 ath9k_htc
> > > ath9k_hw 341687 2 ath9k_common,ath9k_htc
> > > ath 21417 3 ath9k_common,ath9k_htc,ath9k_hw
> > > mac80211 358182 1 ath9k_htc
> > > cfg80211 319971 3 ath,mac80211,ath9k_htc
> > > usbcore 134993 6
> > > usb_storage,ohci_hcd,ehci_hcd,ehci_pci,usbhid,ath9k_htc
> >
> > At this stage, I would run wicd-curses (not as root) and type P.
> > I would make sure the Wireless and Wired Interfaces were correctly
> > named wlan0 and eth0, set automatic reconnection and any other options
> > I wanted, save that, scan for APs with Fn5, select one and press ->
> > to configure it. I would remove the ethernet cable because I have
> > that set to take priority. After saving the configuration, I'd press
> > Return and hope to have a wireless connection come up.
>
> The wireless interface *does* exist *and* is named wlan0. The modules
> for the chip are present, The firmware for the device is loaded. All
> the basic conditions to estabish a connection with e/n/i are met.
Agreed. (Note that when I wrote "make sure the Wireless ... Interfaces
were correctly named wlan0", this is in the wicd configuration. wlan0
doesn't always get picked up at wicd installation. I don't know why.
It may be that an entry in /e/n/i causes it to be ignored for
configuration as well as operation.)
> If there is no connection (which does not happen here with a similar
> chipset) then there is a deeper problem.
Agreed. But I was trying to take one step at a time. I may be wrong
but I don't think I've yet seen anything posted that confirms a radio
signal being sent or received by the device, eg something from a
/sbin/iw... command. A screen showing an access point(s) might
inspire confidence, personally. (You're obviously familiar with the
chipset whereas I'm not.)
> wpasupplicant (on which wicd
> depends for its operation) and four lines in /e/n/i is about as basic
> as it gets.
I guess we need to see what wpa_supplicant says now that there's a
wlan0 to operate on. Hopefully more than "/sbin/wpa_supplicant daemon
failed to start".
> wlan0:avahi Link encap:Ethernet HWaddr 00:c0:ca:72:68:d4
>
> This also does not happen here.
Nor here.
> The OP's system has failed to get an
> IP address on the wlan0 interface and has been provided with one by
> avahi. Maybe the router and/or DHCP provision need exploring as a
> cause for this.
I know nothing about avahi. (Would I be right in thinking that it's
something to do with mDNS that I don't need? And that it would be
sensible to purge it?)
I don't know if 169.254.10.111 is something that was assigned by the
host, or came from outside in which case it might indicate some sort
of radio communication has been made. (Hence my statement above.)
Here's hoping the OP knows how to explore the router and/or DHCP provision.
Cheers,
David.
Reply to: