Posts Tagged ‘Realtek’

How to install Toshiba Satellite L40 B14 Wireless Adapter ( ID 0bda:8197 Realtek Semiconductor Corp. RTL8187B) on Ubuntu and Debian Linux

Thursday, April 28th, 2011

https://www.pc-freak.net/images/toshiba-satellite-l40

How to install Toshiba L40 B14 Wireless Adapter ( ID 0bda:8197 Realtek Semiconductor Corp. RTL8187B) on Ubuntu and Debian Linux
I've been struggling for more than 10 hours to fix up issues on a Ubuntu Maverick-Meerkaat with a rtl8187B Wireless Adapter

The RTL8187B almost drove me mad. I could see the wlan0 which meant the kernel is detecting the device, I could even bring it up with ifconfig wlan0 up , however when I tried it in gnome's network-manager or wicd the wireless networks were not showing up.

Trying to scan for networks using the commands:


ubuntu:~# iwlist wlan0 scan

was also unsuccesful, trying to bring up and down the wireless wlan0 interface with:


ubuntu:~# iwconfig wlan0 up

or


ubuntu:~# iwconfig wlan0 down

Both returned the error:
iwconfig: unknown command "up" and iwconfig: unknown command "down"

Running simply iwconfig was properly returning information about my Wireless Interface wlan0 :


wlan0 IEEE 802.11bg ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off

The exact information I could get about the wireless device was via the command:


ubuntu:~# lsusb | grep realtek
Bus 001 Device 002: ID 0bda:8197 Realtek Semiconductor Corp. RTL8187B Wireless Adapter

Trying manually to scan for wireless networks from console or gnome-terminal with command returned also the below weird results:


ubuntu:~# iwconfig wlan0 scan
iwconfig: unknown command "scan"

More oddly tunning wlan0 interface with commands like:


ubuntu:~# iwconfig wlan0 mode managed
ubuntu:~# iwconfig wlan0 essid ESSID
ubuntu:~# iwconfig wlan0 rate 11M

were succesful …

I read a bunch of documentation online concerning the wireless card troubles on Ubuntu, Gentoo, Debian etc.

Just few of all the resources I've read and tried are:

http://rtl-wifi.sourceforge.net/wiki/Main_Page (Returning empty page already a lot resource)
http://rtl8187b.sourceforge.net (A fork of rtl-wifi.sourceforge.net which is still available though it was not usable)

Some of the other resources which most of the people recommended as a way to properly install the RTL8187B wireless driver on linux was located on the website:

http://datanorth.net/~cuervo/rtl8187b/ (Trying to access this page returned a 404 error e.g. this page is no-longer usable)

I found even a webpage in Ubuntu Help which claimed to explain how to properly install and configure the RTL8187B wireless driver on which is below:

https://help.ubuntu.com/community/WifiDocs/Device/RealtekRTL8187b

Even the Ubuntu help instructions were pointing me to the broken cuervo's website URL

Anyways I was able to find the rtl8187b-modified-dist.tar.gz online and made a mirror of rtl8187b-modified-dist.tar.gz which you can download here

Another rtl8187b driver I found was on a toshiba website made especailly for the wireless linux drivers:

http://linux.toshiba-dme.co.jp/linux/eng/pc/sat_PSPD0_report.htm

The questionable file which was claimed to properly be able to make the Realtek Semiconductor Corp. RTL8187B Wireless Adapter to work out was called rl8187b-modified-804.tar.gz.
I've made a mirror of rtl8187b-modified-804.tar.gz is here

None of the driver archives rtl8187b-modified-dist.tar.gz and rl8187b-modified-804.tar.gz that was supposed to make the Toshiba L40 realtek wireless to work out, after compiling and installing the drivers from source worked out …

Both archives produced plenty of error messages and it seems on newer kernels like the one on this notebook:

Linux zlatina 2.6.35-28-generic #50-Ubuntu SMP Fri Mar 18 19:00:26 UTC 2011 i686 GNU/Linux, they're no longer usable.

The compile errors I got when I tried compiling the rtl8187b driver provided by the archive rtl8187b-modified-dist were:


root@ubuntu:/home/zlatina/rtl8187b-modified# sh makedrv
rm -fr *.mod.c *.mod *.o .*.cmd *.mod.* *.ko *.o *~
make -C /lib/modules/2.6.35-28-generic/build M=/home/zlatina/rtl8187b-modified/ieee80211 CC=gcc modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.35-28-generic'
scripts/Makefile.build:49: *** CFLAGS was changed in "/home/zlatina/rtl8187b-modified/ieee80211/Makefile". Fix it to use EXTRA_CFLAGS. Stop.
make[1]: *** [_module_/home/zlatina/rtl8187b-modified/ieee80211] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.35-28-generic'
make: *** [modules] Error 2
rm -fr *.mod.c *.mod *.o .*.cmd *.ko *~
make -C /lib/modules/2.6.35-28-generic/build M=/home/zlatina/rtl8187b-modified/rtl8187 CC=gcc modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.35-28-generic'
scripts/Makefile.build:49: *** CFLAGS was changed in "/home/zlatina/rtl8187b-modified/rtl8187/Makefile". Fix it to use EXTRA_CFLAGS. Stop.
make[1]: *** [_module_/home/zlatina/rtl8187b-modified/rtl8187] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.35-28-generic'
make: *** [modules] Error 2
root@ubuntu:/home/zlatina/rtl8187b-modified#

Another driver I tried which was found on aircrack-ng.org's website was rtl8187_linux_26.1010.zip

Here are the error messages I experienced while I tried to compile the realtek wireless driver from the archive rtl8187_linux_26.1010.0622.2006


compilation terminated.
make[2]: *** [/home/zlatina/rtl8187_linux_26.1010.0622.2006/beta-8187/r8187_core.o] Error 1
make[1]: *** [_module_/home/zlatina/rtl8187_linux_26.1010.0622.2006/beta-8187] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.35-28-generic'
make: *** [modules] Error 2
make: *** [modules] Error 2

I tried a number of fix ups hoping to solve the compile error messages, but my efforts were useless, as it seems many things has changed in newer Ubuntu versions and they could no longer be compiled.

As I realized I couldn't make the native drivers provided by the above sources compile, I decided to give a try to the Windows drivers for Realtek 8187B with ndiswrapper, a link for download of Realtek 8187B (RTL8187B_XP_6.1163.0331.2010_Win7_62.1182.0331.2010_UI_1.00.0179 is found here

I untarred the
RTL8187B_XP driver
and used ndiswrapper to load driver like so:


root@ubuntu:~# tar -zxvf
RTL8187B_XP_6.1163.0331.2010_Win7_....L.tar.gz
root@ubuntu:/home/zlatina/RTL8187B#
root@ubuntu:/home/zlatina/RTL8187B# cd Driver/WinXP
root@ubuntu:/home/zlatina/RTL8187B/Driver/WinXP# ndiswrapper -i net8187b.inf

In order to test the RTL8178B Windows driver I used:


root@ubuntu:~# ndiswrapper -l
net8187b : driver installed
device (0BDA:8197) present (alternate driver: rtl8187)

To finally load the Windows XP RTL8187B driver on the Ubuntu I used again ndiswrapper:


root@ubuntu:~# ndiswrapper -m

Further on I used the ndisgtk graphical ndiswrapper interface to once again test if the Windows driver is working on the Ubuntu and it seemed like it is working, however still my wicd was unable to find any wireless network ….

There were many online documentation which claimed that the driver for rtl8187b works out of the box on newer kernel releases (kernel versions > 2.6.24)

Finally I found out there is a driver which is a default one with the Ubuntu e.g. rtl8187.ko , I proceeded and loaded the module:


root@ubuntu:~# modprobe rtl8187

I also decided to check out if the hardware switch button of the Toshiba Satellite L40 notebook is not switched off and guess what ?! The Wireless ON/OFF button was switched OFF!!! OMG …

I switched on the button and wicd immediately started showing up the wireless networks …

To make the rtl8187 module load on Ubuntu boot up, I had to issue the command:


root@ubuntu:~# echo 'rtl8187' >> /etc/modules

Voila after all this struggle the wireless card is working now, it's sad I had to loose about 10 hours of time until I come with the simple solution of using the default provided ubuntu driver rtl8187 , what is strange is how comes that it does not load up automatically.

Thanks God it works now.

FreeBSD Jumbo Frames network configuration short how to

Wednesday, March 14th, 2012

FreeBSD Jumbo Frames Howto configure FreeBSD

Recently I wrote a post on how to enable Jumbo Frames on GNU / Linux , therefore I thought it will be useful to write how Jumbo Frames network boost can be achieved on FreeBSD too.

I will skip the details of what is Jumbo Frames, as in the previous article I have thoroughfully explained. Just in short to remind you what is Jumbo Frames and why you might need it? – it is a way to increase network MTU transfer frames from the MTU 1500 to MTU of 9000 bytes

It is interesting to mention that according to specifications, the maximum Jumbo Frames MTU possible for assignment are of MTU=16128
Just like on Linux to be able to take advantage of the bigger Jumbo Frames increase in network thoroughput, you need to have a gigabyt NIC card/s on the router / server.

1. Increasing MTU to 9000 to enable Jumbo Frames "manually"

Just like on Linux, the network tool to use is ifconfig. For those who don't know ifconfig on Linux is part of the net-tools package and rewritten from scratch especially for GNU / Linux OS, whether BSD's ifconfig is based on source code taken from 4.2BSD UNIX

As you know, network interface naming on FreeBSD is different, as there is no strict naming like on Linux (eth0, eth1, eth2), rather the interfaces are named after the name of the NIC card vendor for instance (Intel(R) PRO/1000 NIC is em0), RealTek is rl0 etc.

To set Jumbro Frames Maximum Transmission Units of 9000 on FreeBSD host with a Realtek and Intel gigabyt ethernet cards use: freebsd# /sbin/ifconfig em0 192.168.1.2 mtu 9000
freebsd# /sbin/ifconfig rl0 192.168.2.2 mtu 9000

!! Be very cautious here, as if you're connected to the system remotely over ssh you might loose connection to it because of broken routing.

To prevent routing loss problems, if you're executing the above two commands remotely, you better run them in GNU screen session:

freebsd# screen
freebsd# /sbin/ifconfig em0 192.168.1.2 mtu 9000; /sbin/ifconfig rl0 192.168.1.2 mtu 9000; \
/etc/rc.d/netif restart; /etc/rc.d/routed restart

2. Check MTU settings are set to 9000

If everything is fine the commands will return empty output, to check further the MTU is properly set to 9000 issue:

freebsd# /sbin/ifconfig -a|grep -i em0em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000freebsd# /sbin/ifconfig -a|grep -i rl0
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000

3. Reset routing for default gateway

If you have some kind of routing assigned for em0 and rl0, network interfaces they will be affected by the MTU change and the routing will be gone. To reset the routing to the previously properly assigned routing, you have to restart the BSD init script taking care for assigning routing on system boot time:

freebsd# /etc/rc.d/routing restart
default 192.168.1.1 done
add net default: gateway 192.168.1.1
Additional routing options: IP gateway=YES.

4. Change MTU settings for NIC card with route command

There is also a way to assign higher MTU without "breaking" the working routing, e.g. avoiding network downtime with bsd route command:

freebsd# grep -i defaultrouter /etc/rc.conf
defaultrouter="192.168.1.1"
freebsd# /sbin/route change 192.168.1.1 -mtu 9000
change host 192.168.1.1

5. Finding the new MTU NIC settings on the FreeBSD host

freebsd# /sbin/route -n get 192.168.1.1
route to: 192.168.1.1
destination: 192.168.1.1
interface: em0
flags: <UP,HOST,DONE,LLINFO,WASCLONED>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 9000 1009

6. Set Jumbo Frames to load automatically on system load

To make the increased MTU to 9000 for Jumbo Frames support permanent on a FreeBSD system the /etc/rc.conf file is used:

The variable for em0 and rl0 NICs are ifconfig_em0 and ifconfig_rl0.
The lines to place in /etc/rc.conf should be similar to:

ifconfig_em0="inet 192.168.1.1 netmask 255.255.255.0 media 1000baseTX mediaopt half-duplex mtu 9000"
ifconfig_em0="inet 192.168.1.1 netmask 255.255.255.0 media 1000baseTX mediaopt half-duplex mtu 9000"

Change in the above lines the gateway address 192.168.1.1 and the netmask 255.255.255.0 to yours corresponding gw and netmask.
Also in the above example you see the half-duplex ifconfig option is set insetad of full-duplex in order to prevent some duplex mismatches. A full-duplex could be used instead, if you're completely sure on the other side of the host is configured to support full-duplex connections. Otherwise if you try to set full-duplex with other side set to half-duplex or auto-duplex a duplex mismatch will occur. If this happens insetad of taking the advantage of the Increase Jumbo Frames MTU the network connection could become slower than originally with standard ethernet MTU of 1500. One other bad side if you end up with duplex-mismatch could be a high number of loss packets and degraded thoroughout …

7. Setting Jumbo Frames for interfaces assigning dynamic IP via DHCP

If you need to assign an MTU of 9000 for a gigabyt network interfaces, which are receiving its TCP/IP network configuration over DHCP server.
First, tell em0 and rl0 network interfaces to dynamically assign IP addresses via DHCP proto by adding in /etc/rc.conf:

ifconfig_em0="DHCP"
ifconfig_rl0="DHCP"

Secondly make two files /etc/start_if.em0 and /etc/start_if.rl0 and include in each file:

ifconfig em0 media 1000baseTX mediaopt full-duplex mtu 9000
ifconfig rl0 media 1000baseTX mediaopt full-duplex mtu 9000

Copy / paste in root console:

echo 'ifconfig em0 media 1000baseTX mediaopt full-duplex mtu 9000' >> /etc/start_if.em0
echo 'ifconfig rl0 media 1000baseTX mediaopt full-duplex mtu 9000' >> /etc/start_if.rl0

Finally, to load the new MTU for both interfaces, reload the IPs with the increased MTUs:

freebsd# /etc/rc.d/routing restart
default 192.168.1.1 done
add net default: gateway 192.168.1.1

8. Testing if Jumbo Frames is working correctly

To test if an MTU packs are transferred correctly through the network you can use ping or tcpdumpa.) Testing Jumbo Frames enabled packet transfers with tcpdump

freebsd# tcpdump -vvn | grep -i 'length 9000'

You should get output like:

16:40:07.432370 IP (tos 0x0, ttl 50, id 63903, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 85825:87285(1460) ack 668 win 14343
16:40:07.432588 IP (tos 0x0, ttl 50, id 63904, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 87285:88745(1460) ack 668 win 14343
16:40:07.433091 IP (tos 0x0, ttl 50, id 63905, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 23153:24613(1460) ack 668 win 14343
16:40:07.568388 IP (tos 0x0, ttl 50, id 63907, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 88745:90205(1460) ack 668 win 14343
16:40:07.568636 IP (tos 0x0, ttl 50, id 63908, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 90205:91665(1460) ack 668 win 14343
16:40:07.569012 IP (tos 0x0, ttl 50, id 63909, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 91665:93125(1460) ack 668 win 14343
16:40:07.569888 IP (tos 0x0, ttl 50, id 63910, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 93125:94585(1460) ack 668 win 14343

b.) Testing if Jumbo Frames are enabled with ping

Testing Jumbo Frames with ping command on Linux

linux:~# ping 192.168.1.1 -M do -s 8972
PING 192.168.1.1 (192.168.1.1) 8972(9000) bytes of data.
9000 bytes from 192.168.1.1: icmp_req=1 ttl=52 time=43.7 ms
9000 bytes from 192.168.1.1: icmp_req=2 ttl=52 time=43.3 ms
9000 bytes from 192.168.1.1: icmp_req=3 ttl=52 time=43.5 ms
9000 bytes from 192.168.1.1: icmp_req=4 ttl=52 time=44.6 ms
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 2.397/2.841/4.066/0.708 ms

If you get insetad an an output like:

From 192.168.1.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)

--- 192.168.1.1 ping statistics ---
0 packets transmitted, 0 received, +4 errors

This means a packets with maximum MTU of 1500 could be transmitted and hence something is not okay with the Jumbo Frames config.
Another helpful command in debugging MTU and showing which host in a hop queue support jumbo frames is Linux's traceroute

To debug a path between host and target, you can use:

linux:~# traceroute --mtu www.google.com
...

If you want to test the Jumbo Frames configuration from a Windows host use ms-windows ping command like so:

C:\>ping 192.168.1.2 -f -l 8972
Pinging 192.168.1.2 with 8972 bytes of data:
Reply from 192.168.1.2: bytes=8972 time=2ms TTL=255
Reply from 192.168.1.2: bytes=8972 time=2ms TTL=255
Reply from 192.168.1.2: bytes=8972 time=2ms TTL=255
Reply from 192.168.1.2: bytes=8972 time=2ms TTL=255
Ping statistics for 192.168.1.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2ms

Here -l 8972 value is actually equal to 9000. 8972 = 9000 – 20 (20 byte IP header) – 8 (ICMP header)