Showing posts with label wifi. Show all posts
Showing posts with label wifi. Show all posts

Saturday, June 15, 2019

Unicast ARP flooding WiFi - ultimately kernel module with Realtek

I've got a friend who's a landlord. She recently upgraded the WiFi in one of her units to fiber optic. As part of her deal from the vendor, she received a SmartRG DSL wifi modem/gateway, model SR515ac. It's a nice rig, but has a couple of hitches, one of them being the WiFi would only seem to operate in bursts: fast traffic, then nothing, 3 MB traffic, then nothing. Additionally, some client boxes would freeze up entirely when connected to WiFi.

Solution

The problem was ultimately found to be only in clients that were at the edge of the operating range of the WiFi signal and were Linux boxes with Realtek 8723's, with its notorious rtl kernel driver problems. Once these cards were replaced with Intel Ultimate N WiFi Link 5300 cards, using the iwlagn module, all the freezing problems disappeared. They were so far away from the router there were occasional connection problems, but no more kernel freezes.

troubleshooting

Attempting to capture the problem, tcpdump (tcpdump >>file.txt 2>&1) revealed repetitive Address Resolution Protocol (ARP) queries to all available 256 addresses, eg...
09:01:40.129620 ARP, Request who-has 192.168.28.6 tell 192.168.28.1, length 28
09:01:40.130517 ARP, Request who-has 192.168.28.7 tell 192.168.28.1, length 28
09:01:40.131435 ARP, Request who-has 192.168.28.8 tell 192.168.28.1, length 28
09:01:40.132354 ARP, Request who-has 192.168.28.255 tell 192.168.28.1, length 28
...instead of limiting itself to those addresses to which it had authorized an IP. The queries would begin again as soon as they reached the 255th address. Apparently there was no ARP cache, but maybe the problem was even worse.

Obviously, wifi requires the kernel (module) for kernel space, and wpa_supplicant driver for user-space. The former were discussed in the solution, and the latter are typically Wext (generic wireless extension) or nl80211.


Saturday, March 12, 2016

[solved] wpa_supplicant following system update

Looking at friend's monitor (running Arch), I saw his clock was behind, so I wanted to # ntpdate pool.ntp.org his system. It turned-out ntp hadn't been installed. I started with #pacman -S ntp, but dependency errors appeared -- the typical sign that a system needs updating. So, # pacman -Syu, and sure enough, it was at leas 4GB out of whack. Afterwards, all was good for adding ntp and running ntpdate. His clock updated.

The problem was, the first time he cycled power, his wifi didn't connect. I found I could easily connect his system manually (CLI) with
# wpa_supplicant -Dwext -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf &
or better...
# wpa_supplicant -Dnl80211 -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf &
So, WTF? One possibility was that, beginning in 2016, dhcpcd stopped connecting its built-in wpa_supplicant hook during dhcpcd install. It has to be done manually. There's also a second option, giving at least two solutions.

two solutions

  1. # systemctl disable wpa_supplicant.service
    # cp /usr/share/dhcpcd/hooks/10-wpa_supplicant /lib/dhcpcd/dhcpcd-hooks
    This puts dhcpcd in charge, calling and restarting wpa_supplicant, as needed. Make sure the right PID directory (if needed) and password are in /etc/wpa_supplicant/wpa_supplicant.conf, so it can negotiate security. Also, if dhcpcd is hanging looking for an IPV6 connection, a person can add the "-4" flag to the "ExecStart" command in /usr/lib/systemd/system/dhcpcd.service. Problem solved; back to rock solid wifi connection.
  2. Instead of putting dhcpcd in charge, put wpa_supplicant in charge, calling dhcpcd. This is not recommended since it requires a bunch of complicated custom shit described below

unit file

I checked systemd (systemctl list-unit-files) and, as expected, I saw that wpa_supplicant was no longer enabled. When I enabled wpa_supplicant, it created symlinks which were not straightforward ("epitest.fi"?), which I did not trust as helpful. So I wrote him a straightforward service unit file specific for initializing his wifi:
# nano /etc/systemd/system/johndoewifi.service

# custom wifi connect
# Arch location: /etc/systemd/system/johndoewifi.service
[Unit]
Description=wpa_supplicant wext wifi
Wants=network.target
After=network.target
# Before=network.target

# execute and run in background
[Service]
Type=forking
PIDFile=/var/run/wpa_supplicant.pid
ExecStart=/usr/bin/wpa_supplicant -Dwext -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf
# ExecStop=/usr/bin/wpa_supplicant -x

[Install]
WantedBy=multi-user.target

restart from user

You can get wpa_supplicant to run from user, with eg
# nano /etc/wpa_supplicant/wpa_supplicant.conf
# Allow users in the 'wheel' group to control wpa_supplicant
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
If John Doe is in the wheel group he can start wpa_supplicant no problema. However, it will fail, since he doesn't have authority to bring the interface UP or DOWN from userspace. That requires another kludge.
(source: Gentoo wiki)

Saturday, May 18, 2013

slacko 5.5 (puppy) and easy peasy on a hp110 mini

Links: GPTfdisk  Puppy User and Security

booting from USB


I downloaded the latest slacko ISO (5.5), and used UNetbootin to put the ISO onto a stick. I put in the stick and powered-up. F10 got me into the BIOS, but the BIOS did not detect the USB --- the HDD was the single boot option. The F1 key and cycling the BIOS eventually detected the USB. Each time thereafter, an F9 option to "change boot device order" appeared in the BIOS splash. Once the USB was detected, Slacko booted and installed quickly from it.

Next were attempts at a couple of Ubuntu based distros; Joli OS, and EasyPeasy. Both hung during auto-partitioning. Reckoning I had encountered the storied MBR/GPT conflict, I considered downloading GPTfdisk, but then I discovered an article which appeared to show how to remove the GPT manually. I processed these on both ends of the HDD, but the installs still hung at the same step.

Why was an Ubuntu installer hanging and a Slackware based installer not hanging? During installs, Ubuntu's installer script apparently relies on the POS gparted for the partitioning phase. Since Ubuntu installation screens are GUI, not CLI, gparted has no straightforward way to provide its failure information; gparted simply dies (exits) and hangs the installation. I was eventually able to guess it might be gparted only after Googling similar hangs. To verify, I exited the setup script and entered the live CD desktop. I then opened a terminal, su'ed up ("sudo passwd ubuntu", then "su") and ran gparted. Sure enough, gparted failed and exited. The failure:
Assertion (head_size <= 63) at ../../../libparted/labels/dos.c:659 in function probe_partition_for_geom() failed.
OK, the above explained why I couldn't see the failure, and why it didn't occur in Slackware, but what is this failure? Poor design, apparently. Certainly, the difference between a USB and a CDROM should be irrelevant for gparted to do its install job, but it obviously isn't. It is a nasty bug. I was only able to find one fix on my first chop at it, and that was designed for Verbatim brand USB's. I don't have a Verbatim USB. Nevertheless, cfdisk -z /dev/sdb got me partway there, and then I also formatted the USB with ext2 (mke2fs /dev/sdb1) just to be sure. I then ran UNetbootin on an EasyPeasy ISO. With this, I was able to install EasyPeasy (Ubuntu installer script) without issues. 3 lost hours.

UEFI (Unified Extensible Firmware Interface) Note:

I also booted Slacko from the USB on a 2013 laptop. For this, I found I had to enter the BIOS and disable UEFI booting prior to the USB, or even a CDROM, booting successfully.

Slacko: adding a user, logins, X-settings for user

Slacko's default GUI access is root, which makes sense for a live distro. So how to create users and which files are required for X (and Bash, etc) initilization for these users?

Create users (in this case "foo"), add them to groups, and set-up the home directory...
# mkdir /home/foo
# adduser foo
# nano /etc/group #(add foo to whatever)
# su foo
$ cp /boot/root/.bashrc /home/foo/
$ cp /boot/root/.Xdefaults /home/foo/
$ cp /boot/root/.Xresources /home/foo/
$ cp /boot/root/.fonts-cache1 /home/foo/
$ cp /boot/root/.gtkrc-2.0 /home/foo/
...then arrange for runlevels and booting logins.

First, to eliminate autologins to root, change the second line in \etc\inittab.
\etc\inittab
tty1::respawn:/sbin/getty -n -l /bin/autologinroot 38400 tty1
...to...
tty1::respawn:/sbin/getty 38400 tty1

Monday, May 30, 2011

wusb54g - ralink 2500

A family member running kernel 2.6.28.7 was having some problems with her older Linksys WUSB54G (Ralink 2500 chip). As seen in the photo, this is an external USB Wi-Fi card. When I installed her system (Zenwalk Slackware) back in 2009, ndiswrapper was the answer for this chip, which was posing problems for some Linux installations. It did fine, even with encryption and so on. Recently however, the relatives de-encrypted their network, probably so a visiting relative could use their network or during a Windows update, and the Linksys card was unable to associate with the LAN router once the network was keyless. This is a matter of opening or dropping the encryption configuration line and then ordering the remaining lines. However, over a telephone, implementing these kinds of changes required a lot of patience from my relative (thank you, Mom!). Ultimately, at least over the phone, it appeared there was no associating to this unencrypted network via ndiswrapper and using standard commands such as, say:
iwconfig wlan0 essid Foo
iwconfig wlan0 key open #(or using "off")
iwconfig wlan0 ap 00:20:etc
So it was a conundrum. We tried several different permutations, as noted above, before giving-up for the weekend.

Then I got to thinking about the old rt2500 driver. This driver is anachronistic, as all of these legacy Ralink cards now are managed directly in the kernel. But it is less anachronistic than ndiswrapper. Further, it would be a lot to ask a family member to update their entire system, a full Linux installation, with only telephone guidance. It looked like the middle ground would be to withdraw ndiswrapper and install the last/latest rt2500 driver to see if it was less finicky. Would the source for this older driver still be available. Turns out it was no longer available at the Ralink site. Summary: I couldn't travel to Mom's place to make the changes and it had been going slowly over the phone.

Solution: Linksys WUSB100

I locally purchased a WUSB100, id 1737:0078 ($15), to install onto my system, make configuration software, and then mail to her. There are two versions of WUSB100

Version 1 module rt2870sta

This site indicates that the the rt2870sta works with the following Linksys USBs:
USB: 1737:0070 Linksys WUSB100 v1 RangePlus Wireless Network Adapter [Ralink RT2870]
USB: 1737:0071 Linksys WUSB600N v1 Dual-Band Wireless-N Network Adapter [Ralink RT2870]
USB: 1737:0077 Linksys WUSB54GC v3 802.11g Adapter [Ralink RT2070L]
Noting that my 1737:0078 is not on that list

Version 2 - module rt2870 or rt3070?

Written on the back of the WUSB100 in my possession: FCCID Q87-WUSB100v2. Still began with the rt2870 since some were having success with this. The kernel would recognize it and assign ra0, but would not assign memory resources or allow connection. During this process, found there are at least two chips in version 2, the Belkin 050d:825b or what I have, the Ralink chip 1737:0078. I'm on the right track but, for the Ralink chip, it appears will have to go to the rt3070sta which means a patch is necessary. That will be my next weekend project. Meanwhile, I've also left the Belkin stuff here for those who have Belkins.
Ralink This is supposed to take care of the patch stuff according to this site
I believe the fix is to replace all instances of usb_buffer_alloc with usb_alloc_coherent and all instances of usb_buffer_free with usb_free_coherent. The instances I replaced were in include/os/rt_linux.h and os/linux/rt_usb_util.c.
Belkin

preinstalled driver attempts

Well before I compiled the rt3070sta module, I had hoped for the good luck of a driver included with the distro working. In favor of such a dream, the WUSB100 was detected by udevmonitor and lsusb. However, no module was being loaded. Thus, I looked in the wifi driver directory for useful drviers included with the distro:
$ls /lib/modules/2.6.28.7/kernel/drivers/net/wireless/
[snip] rtl8187.ko rt2x00 (directory) rtl8180.ko
$ls /lib/modules/2.6.28.7/kernel/drivers/net/wireless/rt2x00
rt2400pci.ko rt2500pci.ko rt2500usb.ko rt2x00lib.ko rt2x00pci.ko rt2x00usb.ko rt61pci.ko rt73usb.ko
I tried loading some of these with modprobe but the card continued to go unreachable. That is, in spite of modprobing these drivers in, the command
#ifconfig ra0 up (or wifi0, etc)
was yielding nothing. Back to the Google machine.

module rt2870sta attempts

Also before compiling the rt3070sta, I'd noticed some had success with the rt2870sta module and a few tweaks. It wasn't already onboard:
root[/]# find -iname rt2870*
root[/]#
  • downloaded rt3070sta, now deprecated, cached here (scroll down to "nightflier"'s post) and also here, along with some associated patches.
  • downloaded the rt2870sta source, now deprecated, here.This provided me with version2010_0709_RT2870_Linux_STA_v2.4.0.1.tar.bz2.
  • downloaded the firmware, same location. File is RT2870_Firmware_V22.zip.
  • The settings for rt2870sta.dat are explained here

rt2870sta compiling notes

most comprehensive link
Before compiling, be sure the card ID "1737:0078" is included in the card ID section. I located them by navigating to the top source directory and then
$ grep -r USB_DEVICE *
In my source, these statements were in /common/rtusb_dev_id.c. I added the line in there:
{USB_DEVICE(0x1737,0x0078)}, /* Linksys WUSB100v2 Pepsi */
(I like Pepsi, so whatever). In this fellow's source, they were in rt2870.h.
Still within the source directory, I also made the following change
$ geany /os/linux/config.mk
HAS_WPA_SUPPLICANT=y
HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=y
Blacklist any modules that might attempt to load and conflict.
# geany /etc/modprobe.d/blacklist
blacklist rt2x00usb
blacklist rt2x00lib
blacklist rt2500usb
Backed-up the default /etc/Wireless/RT2870STA/RT2870STA.dat
# cp /etc/Wireless/RT2870STA/RT2870STA.dat /etc/Wireless/RT2870STA/RT2870STA.bak.def
Compiling is a basic $make/#make install operation. Unzip and install the firmware, although I noted no significant change from before the firmware was installed to after.
# cp Download/RT2870_Firmware_V22/rt2870.bin /lib/firmware/
# chmod 555 /lib/firmware/rt2870.bin
After compiling, installation, and modprobing, it's good to run # depmod, so I did that as well. Zince I'm using Zlackware Zenwalk, added the MAC to /etc/iftab. Added the module and updated the kernel
# depmod

After all of this, the rt2870sta was a no-go. A deeper look, showed that it lacks product and bus information and was not even being assigned an IRQ or other resources. For example, compare it to the (working) Atheros card below
# lshw -C network
*-network
description: Wireless interface
product: AR242x 802.11abg Wireless PCI Express Adapter
vendor: Atheros Communications Inc.
physical id: 0
bus info: pci@0000:05:00.0
logical name: wifi0
version: 01
serial: 00:2e:xx:xx:xx:xx
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list logical ethernet physical wireless
configuration: broadcast=yes driver=ath_pci ip=192.168.1.2 latency=0 multicast=yes wireless=IEEE 802.11g
resources: irq:18 memory:f3100000-f310ffff
*-network
description: Wireless interface
physical id: 1
logical name: ra0
serial: 68:3e:xx:xx:xx:xx
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=RALINK WLAN driverversion=2.4.0.0 multicast=yes wireless=Ralink STA
  • it was suggested here, that a change had to be made in /etc/udev/rules.d/10-wusb100.rules, or that the file had to be created. The rule then called rt2870sta and it would then work with the "0078" version.
  • creating a softlink worked for this guy

Monday, February 8, 2010

Inspiron 7000 - Linksys WPC54G w/BCM4306

Links: Discussion on 43b module   b43 module installation (doesn't work)   b43 v. ndiswrapper  b43legacy issues  ndiswrapper solution   linksys WPC54G support


This is an install I'm working on with a friend's older Inspiron 7000. We dropped Zenwalk 6.0 (Slackware light) into the system and everything configured out-of-the box, except his PCMCIA Linksys WPC54G (version 1.2) card. This entry is meant as a trail of crumbs for how we solved it.

The legacy Linkys WPC54G card employs a Broadcom 4306 chip. I've never understood the impulse behind closed-source drivers for hardware. There are millions of Linux users; if Broadcom only produces a driver for Microsoft, at least make it open-source. Linux users can then easily design a good driver. They will want to buy Broadcom-based hardware.

Since the Broadcom driver was proprietary, any drivers/modules for it needed to be reverse engineered for Linux with some predictable results. For example, the b43 module described here didn't work. The fwcutter program appeared to properly extract info from bcmwl5.sys and install it into /lib/firmware; the card was detected by the kernel and apparently was semi-configured by the b43 module; but yet the card never fully initialized. This meant it came down to either the b43legacy module or, as a last resort, to using ndiswrapper on the driver coded for MSoft by Broadcom. You know, like back in 2004. But before we capitulated to ndiswrapper or b43legacy, we wanted to try fwcutter again with a more researched approach.

environment
$ uname -r
2.6.28.7

# lspci -vnn
06:00.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
Subsystem: Linksys WPC54G [1737:4320]
Flags: bus master, fast devsel, latency 64, IRQ 11
Memory at 1c000000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Kernel driver in use: b43-pci-bridge
Kernel modules: ssb


software
Understanding from above that we're dealing with the "4320" Broadcom chip, the b43 module should have worked previously; b43 is the recommended driver for the 4320 id. I decided to recompile fwcutter, this time making sure I had version "012" of fwcutter and version 4.150.10.5 of Broadcom's proprietary driver.

$ wget http://bu3sch.de/b43/fwcutter/b43-fwcutter-012.tar.bz2
$ wget http://mirror2.openwrt.org/sources/broadcom-wl-4.150.10.5.tar.bz2


success
Untarred and compiled fwcutter -- "$ make". Didn't even have to configure. Then, after untarring the driver, put the driver files in the folder with the fwcutter program and ran:

# ./b43-fwcutter -w /lib/firmware wl_apsta_mimo.o

Rebooted and the card came right up.

Sunday, November 23, 2008

wifi - ralink pci rt2600 drama

--(edited 20090421)--
I had occasion to reinstall Slackware the other day. Default distribution drivers for the ralink rt2600 are the rt61pci series drivers which seem to provide only flaky and, therefore, annoying connections.

drivers
First, retrieve the latest drivers from Ralink's linux page . For me, this was the 2008_0723_RT61_Linux_STA_v1.1.2.2.tar.bz2 driver. Unfortunately, the README was almost unintelligible, without even proper line returns. It only gives a portion of the necessary information, and hours are required to find the solution. Highly annoying. Taken together with the drivers, both the kernel source and headers are required. So:
a. drivers
b. kernel source
c. kernel headers

file changes
Prior to compiling, there are some changes, at least to these 2008 and 2009 versions. After copying Makefile.6 to Makefile, change the CFLAGS statement around line 28 to:

EXTRA_CFLAGS+= $(WFLAGS)
If you don't like to change the Makefile, you can export the KBUILD_NOPEDANTIC just prior to compiling, but this is a necessary environment variable, one way or the other.

Another change, this one suggested, is near the end of the rtmp_main.c file. Here, we want to change as follows: from
static INT __init rt61_init_module(VOID)
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
   return pci_register_driver(&rt61_driver);
#else
   return pci_module_init(&rt61_driver);
#endif
}
to this:
static INT __init rt61_init_module(VOID)
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
   return pci_register_driver(&rt61_driver);
#else
   return pci_register_driver(&rt61_driver);
#endif
}


environment
As noted above and described here, if you don't change the enviroment setting in the Makefile, you'll need to add
$export KBUILD_NOPEDANTIC=1
as a command just prior to compiling. For systems with csh and tcsh environments, the command is apparently
$setenv KBUILD_NOPEDANTIC 1

putting it together

$ tar -xvjf 2008_0723_RT61_Linux_STA_v1.1.2.2.tar.bz2
$ cd 2008*
$ cd Module
$ cp Makefile.6 Makefile
$ chmod 755 Configure
$ Configure
$ export KBUILD_NOPEDANTIC=1 (if you didn't change the Makefile)
$ make

Root up

# mkdir /etc/Wireless
# mkdir /etc/Wireless/RT61STA
# cp *.bin /etc/Wireless/RT61STA (three firmware files)
# cp sta.dat /etc/Wireless/RT61STA (configuration file)
# cp rt61.ko /lib/modules/<kernel>/kernel/drivers/net/wireless
final steps
# nano /etc/modprobe.d/blacklist
blacklist rt61pci
blacklist rt2x00pci
blacklist rt2x00lib (save and close)

# nano /etc/modprobe.d./modprobe.conf
alias ra0 rt61 (save and close)

# depmod -a