I'm running Ubuntu 11.10 on a BeagleBone with an Edimax EW-7711UAn wifi adapter plugged into the USB port. I've configured /etc/network/interfaces and the wifi works, BUT:
The wlan0 interface doesn't always come up when booting the device. It comes up successfully about one in three attempts.
The interface sometimes goes down again, especially when not used for a while.
The /etc/network/interfaces file includes:
auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-ssid "Bodoni"
wpa-psk "<mypassword>"
In order to try to address point 1), I put the following in /etc/rc.local:
nohup sh -c "ifdown wlan0 && ifup wlan0"
But it hasn't seemed to help much. I'm guessing that the second problem might be connected with power management, so I might try turning that off in /etc/rc.local.
But does anyone have any thoughts on how I might get the wifi to come up reliably on boot? I'm running the BeagleBone headless with no Ethernet (it's on a robot) so it's important I get this fixed!
FYI, I'm using the default drivers - lsmod gives:
Module Size Used by
aes_generic 27837 2
arc4 1111 2
rt2800usb 12386 0
rt2800lib 45146 1 rt2800usb
crc_ccitt 1457 1 rt2800lib
rt2x00usb 10595 1 rt2800usb
rt2x00lib 39077 3 rt2800usb,rt2800lib,rt2x00usb
mac80211 228509 3 rt2800lib,rt2x00usb,rt2x00lib
cfg80211 167722 2 rt2x00lib,mac80211
rfkill 16703 1 cfg80211
binfmt_misc 6224 1
spidev 4620 0
I'm hoping not to have to compile a new driver because I haven't had much success with that!
I've had a similar problem with my BeagleBones using another wifi adapter using the rt2800usb driver. Specifically I am using a DLINK DWA-125 (HW Rev A2) which is based on the rt3070 chip.
Same exact symptoms that you are reporting if I plug the DWA-125 directly into the USB port on the BeagleBone.
BUT if I plug the adapter into a USB extension cable and then plug the extension cable into the BeagleBone USB port, everything works fine. I have done 100s of hours of Cloud9 development using this setup and no problems with Wifi whatsoever.
I am running the Angstrom distro - and I find the same issue on all three of last BB releases (4/22. 5/? and 6/18).
Length of USB extension cable doesn't seem to matter (at least between 1ft and 12ft - haven't tried anything below 1ft.)
I have 6 BeagleBones (4 ver A5 and 2 ver A6) - behavior is the same on all of these Beaglebones.
Also have 4 DWA-125 Rev A2 USB adapters - behavior is the same on all of these.
I have not experimented with other USB Wifi Adapters using the same or other chips/drivers. And I haven't spent the time to track down the root cause of this behavior - I have code to write!
But, give it a try in case your experience matches mine - its a quick and easy 'fix'.
---- Addendum:
I just tried an experiment with the Belkin N150 Micro USB Wifi Adapter - based on the rtl8192cu chip and the standard drivers that come with the 6/18 BeagleBone Angstrom distribution.
Got very similar behavior: The Wifi doesn't work at all when plugged directly into the USB port. But when plugged in via a 1ft USB extension cable, everything works fine.
I had the same problem. The best explanation i've found so far is this one from Adafruit
The main idea is that the Wifi dongle is destructed by the HDMI adapter, that is situated just under the USB slot. You have two workarounds in this case:
Put the Wifi-dongle as far as possible from the USB-slot by means of a cable
Disable the HDMI interface if you don't really need it!
Only the second option helped me.
Here are the steps:
> mkdir /mnt/boot
> mount /dev/mmcblk0p1 /mnt/boot
> nano /mnt/boot/uEnv.txt
Remove the # in front of the cape_disable command
##Disable HDMI
cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
I hope it will help you guys!
I've fixed the problem by removing the USB ESD spike protection IC (U10, TPD4S012). It should be wired between the USB connector and the CPU but it was placed after the USB connector on my board (rev. A4). I don't know if this is fixed on later revisions.
Update: this won't help much in some cases. Check this thread.
I had a similar problem for most of a year until I googled long enough to find
wicd
After setting things up with wicd my 5 beaglebones have been rock solid on my home network on wifi dongles from the back bedroom to the garage. /etc/network/interfaces is not the way to go. I must have tried hundreds of configurations and some seemed to last for a day or two. I do remember the doc gave a good default for interfaces, very barebones. And wicd runs your supplicant if ever needed.
It took me ages to get reliable WiFi on the BeagleBone. In the end, the answer was to use an Atheros dongle, since I had poor luck with RealTek and RALink chipsets. The NetGear WNA1100 works very reliably for me, in both Angstrom and Ubuntu. See my post here.
Related
I'm trying to get the onboard Broadcom bluetooth working in a Buildroot 2017.08 built linux on the Raspberry Pi Zero W. It's not showing me the adapter. Bluetooth USB dongles do work.
Things I've already done:
Added rpi-bt-firmware
Added Bluez-tools and Bluez5-utils
Kernel compiled with all sorts of Bluetooth support
Loaded bluetooth modules: bluetooth, bnep, btbcm, hci_uart
rfkill list (shows no bluetooth devices)
rfkill unblock bluetooth (just in case)
After boot I'm manually starting bluetoothd followed by bluetoothctl.
when I type "power on", "list" or "show" it does not give me any bluetooth controllers.
The hardware is working, on the same system I have Debian Jessie working fine with the bluetooth.
Also, given that USB bluetooth dongles work, I think the kernel is OK too.
What could possibly be the problem here??
Anything I could try to troubleshoot??
Anything I could install or add to make it work??
Anything is welcome at this point! :)
UPDATE
I have it working by running hciattach /dev/ttyAMA0 bcm43xx 921600 flow - at start-up. However, I have barely a clue what's going on here. Proper explanation will count as an answer.
I have also removed console=/dev/ttyAMA0 from the cmdline.txt, not sure though if that was necessary.
hciattach attaches serial HCI devices via UART to Bluez stack https://www.systutorials.com/docs/linux/man/8-hciattach/.
In your case the serial Broadcom HCI adapter is at /dev/ttyAMA0, so the command your run attaches it to Bluez as a bcm43xx HCI adapter.
Its probably done the same in your Debian Jessie setup.
English is not my mother language, but I hope you can understand me. I have bought a Raspberry Pi 2. I installed Raspbian and I bought a Wifi too. This one:
http://www.ebay.com/itm/271857752471?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
I'm new too use Raspberry and I've never use Raspbian and other 'Linux' distribution... So, my biggest problem is, that raspberry doesn't recognize my wifi. I've tried to download this package: http://driver.iigoal.com/drivers/SKU108764.rar
I've tried to do what is in the guide, but I can't... Perhaps can somebody write down a description (or a short video:)), how I need to do these things?
The WiFi adapter listing on eBay does not list Linux as a compatible OS, but it lists the driver as being Realtek RTL8192cu.
I researched a little about that driver in regards to raspbian and it should have two potential drivers. the first is built into the kernel/base installation. It's module is named 8192cu.ko.
A second option exists, though it appears to be a bit experimental that comes from an RTLwifi set.
Since this is a fresh installation, I would recommend starting fresh and ensuring that the WiFi dongle is plugged in during the Raspbian installation/first boot. This should ensure that it is identified and loaded properly.
If that does not work, I would recommend plugging in the rPi 2 with an ethernet cable and running updates to the system, that may help download anything it identifies as missing or old and other greater compatibility
Plug-in the wifi adapter to a usb port,open up a terminal on Raspberry pi and type
lsusb
it will display all the usb devices in the system.
if there is an entry for your wifi adapter then it is easy to make it work.
my raspberry pi work with hardware what you bought in eBay, without more configuration as: wifi-data in wpa-supplicant, if you use terminal:
sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
and write
network={
ssid="NETWORK_NAME"
psk="NETWORK_PASSWORD"
}
this is normal rule for wifi configuration in raspberry pi
I have a problem with USB WiFi dongle RT2870 on Raspberry Pi. This is KOM0640 (Quer) model, successfully detected by Linux Kernel mt7601Usta.ko module.
Specification of my Raspberry:
Latest Linux Raspbian distro with kernel 3.12.35+
WiFi dongle 148f:7601 Ralink Technology, Corp.
WiFi dongle is successfuly detected and can be used as client (connect with available access points).
My problem is to switch this USB WiFi dongle to AP (access-point) mode and enable HotSpot mode on Raspberry Pi. Here is result of iwconfig - I've tried to set access point mode by hand from command line:
root#raspberrypi:~/# iwconfig wlan0 mode master
Error for wireless request "Set Mode" (8B06) :
SET failed on device wlan0 ; Invalid argument.
I have read a lot of web pages with a lots of hints, but without success.
If you have any positive results on this issue, please let me know.
Thanks in advance!
Mediatek drivers dont support nl80211 and cant be used with hostapd.
Original drivers from mediatek.com site doesnt contain AP function. You have to compile driver from eywalink github repo.
After compiling/installing driver you can insert mt7601uap module and configure AP settings in /etc/Wireless/RT2870AP/RT2870AP.dat
You need a driver that supports master mode. You can get one from https://github.com/muratdemirtas/MT7601u. Good luck
This issue is driving me nuts. I am working on a project with some other guys who built the electronics. We have custom boards with an atmega 1284p. For USB cummunication with the 1284p we use a FTDI FT230X USB Bridge. This doesn't have DTR; RTS is used to reset the board using a capacitor (pretty much like with off the shelf arduinos).
The arduino bootloader is used, and we use mighty-1284p to upload. The board selected is "Original Mighty 1284p 8MHz". After installing the right FTDI drivers from http://www.ftdichip.com/Drivers/VCP.htm I can upload to the board from a mac. Linux has these drivers built into the kernel. However, I cannot upload to the board. AVR gives the following error:
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: Send: 0 [30] [20]
dmesg gives the following:
...
[ 51.299964] usbcore: registered new interface driver ftdi_sio
[ 51.300088] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
...
and lspci:
...
Bus 001 Device 006: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
...
The settings for the mac and linux machine are identical. On both I use arduino 1.0.5. Both do see the correct serial port.
I've seen many posts in this forum with similar problems, but have yet to find one with a solution that works for me. Holding reset, or clicking it just before uploading does not work. As suggested in some forums I have tried with removing brltty to no avail. I have tried uploading with the Arduino IDE, Eclipse with AVR plugin and AVR via command-line. None will work. I've tried it on different machines as well with different versions of ubuntu, and uploading works in none of them. Adding -c arduino to avrdude command doesn't do the trick either. Any ideas on how to fix this?
My user is part of the dialout group, and I can upload to other arduino boards (like duemilanove) without problems.
This question was originally asked here: http://forum.arduino.cc/index.php?topic=244363
You mentioned Ubuntu; are you doing this as a normal user?
If so, you may need to add your account to the correct group, the serial port device belongs to.
You can do that like this:
sudo usermod -a -G dialout yourself
then (easiest) logout and log back in again.
However, it is possible that it is called something other than dialout in the latest Ubuntu, I haven't checked. I can confirm it is still dialout here on Debian Wheezy.
(this is a little odd, though, if it works; usually you get a permission error instead...)
I know this is quite an old question, but in addition to the dialout group problem I've had issues with ModemManager interrogating anything that looks like a serial port (and screwing up programmers in particular because they're not expecting those bytes). I don't know if that's what's happening in your case but it's worth a shot for others who end up here.
I just removed it entirely (which is a large hammer, probably temporarily disabling it is best...):
sudo apt-get remove modemmanager
If you want to try disabling it, maybe:
sudo systemctl stop ModemManager.service
I have the following problem. My PC is very old and it has a built in ethernet port that doesn't work, not due to a misconfiguration, I think it's physically damaged. It didn't work in either Ubuntu or even on Windows. I have an ethernet PCI card which is the one I use. The problem is, for some odd reason, the card that does works sometimes changes from eth0 to eth1 and I have to run dhcpd as I don't always get an IP via DHCP. Now, the actual question is, is there some way to disable the card that doesn't work using its MAC address or something? I can't disable either eth0 or eth1 as I'm sure it's not always "pointing" to the same card.
Are they the same kind of chipset or different ones?
If they are differnt then probably the simplest solution would be to just blacklist the modules for that Ethernet chipset.
You will first need to find the module name (this is for eth0):
dmesg | grep eth0
See if you have something like the following:
[ 2.209295] r8169 0000:05:00.0: eth0: RTL8168d/8111d at 0xffffc90000c6e000, 00:24:1d:11:b6:64, XID 081000c0 IRQ 44
In my case 'r8169' is the module name. You can also see a list of currently loaded modules with 'lsmod' so check that it appears in there.
Next you need to black list the module. There is an entry on the Arch wiki for that.
Fellow archer here; I have a method I use to disable my nVidia graphic card's HDMI port audio chip based on its hardware pci id; perhaps you could apply the same approach to your nic:
Find the ethernet's pci id:
$ lspci | grep Eth
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05)
Find the corresponding directory:
$ find /sys/devices -name *00:19.0
/sys/devices/pci0000:00/0000:00:19.0
There should be a file named "remove" in that directory.
You can disable the device at startup by editing /etc/rc.local
echo 1 > /sys/devices/pci0000:00/0000:00:19.0/remove
On second thought; this may not work in your case if modules get loaded prior to /etc/rc.local finishing... it would do you little good to have /dev/eth0 and /dev/eth1 assigned in the "wrong" order and then have /etc/rc.conf disable one of them... you could still end up with your prefered nic as eth1. This used to be a problem with alsa on multiple sound cards so methods were devised to assign the numbering of the cards via module parameters. Perhaps the module itself allows this?
I'm gathering from your description this in an onboard NIC. The best solution would be to disable it in the motherboard BIOS rather than the OS. The method for this varies by manufacturer but I'm sure you could find a manual for your model online somewhere.
I'm confused it didn't show up: In case you don't need the low level solution proposed by cjpembo, you can just use
ip link set dev <interface name> down
You get them via ip link show.