LinuxQuestions.org - will redhat or centos work with a zyxel g-302 card?

- Red Hat (https://www.linuxquestions.org/questions/red-hat-31/)

- - will redhat or centos work with a zyxel g-302 card? (https://www.linuxquestions.org/questions/red-hat-31/will-redhat-or-centos-work-with-a-zyxel-g-302-card-499291/)

will redhat or centos work with a zyxel g-302 card?

The chip-set is Realtek 8185L.

The card is supposed to work with Linux. It has a penguine on the box and everything.

It certainly will not work with debian. How do I check if it will actually work with Redhat or CentOS?

The card is supposed to work with Linux. It has a penguine on the box and everything.
Doesn't guarantee a thing to me. I could show you one with a Devil on it. Doesn't guarantee he'd actually materialise to do my bidding.

It certainly will not work with debian. How do I check if it will actually work with Redhat or CentOS?
Drivers are not a distribution but a kernel thing. In your case, it could be a kernel + Wintendo binary driver + NDISwrapper thing. Please first check out the LQ HCL: http://www.linuxquestions.org/hcl/ first, then search the LQ fora for similar threads and if that doesn't yeild a thing try http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/.

How I Got A Driver For The ZyXEL 802v3 / RTL8185 to work

The penguin on the box got me too; that plus the fact that the card was only ten bucks...

The answer your question is "sort of". It *won't* work with the Linux driver that's on the CD, at least, not as shipped, under Fedora Core 6; the reason for that is a kernel module devel issue primarily.

I did manage to get it working with this driver after doing some hacking: /projects/rtl8180-sa2400 at sourceforge.net (sorry; the forum software won't let me post this link any other way).
A few caveats, however: you have to grab the CVS version of the code; somewhere in the docs for this thing I found a note stating that the .tar.gz packages would not work with kernels newer than - I think it was 2.6.8 - pretty old, anyway. I did that like this:

Code:

cvs -d:pserver:anonymous@rtl8180-sa2400.cvs.sourceforge.net:/cvsroot/rtl8180-sa2400 login

then

Code:

cvs -z3 -d:pserver:anonymous@rtl8180-sa2400.cvs.sourceforge.net:/cvsroot/rtl8180-sa2400 co -P rtl8180-sa2400-dev

Next, being the eternal optimist, having noted that the default ifname created by the driver is "wlan%d", I created /etc/sysconfig/network-scripts/ifcfg-wlan0:

Code:

# rtl8185 wireless NIC Interface Config

# -----------------------------------------------------------

# DEVICE : interface name : wlan%d, eth%d, ath%d, etc.  This

# driver defaults to wlan%d and this is the first wireless NIC

# in the system to we're "wlan0"

DEVICE=wlan0

# BOOTPROTO : static, bootp, dhcp ; at least initially I would

# strongly suggest keeping this set to "static"

BOOTPROTO=static

# IPADDR : dotted-decimal IPv4 address; eg., 192.168.1.5 ; set

# it if you're using static addressing

IPADDR=

# If the b'cast addr for this network is something unusual

# then set it; otherwise, just use the default...

#BROADCAST=

# NETMASK : dotted-decimal IPv4 netmask; shouldn't have to set

# it explicitly unless it's something unusual.  For ex., if

# IPADDR=192.168.1.5, NETMASK defaults to 255.255.255.0

#NETMASK=

# NETWORK : dotted-decimal IPv4 address of network interface is

# on; shouldn't have to set it expicitly unless it's something

# unusual.  Defaults varies w/addr type; eg., if IPADDR is

# 192.168.1.5 then NETWORK defaults to 192.168.1.0

#NETWORK=a.b.c.d

# Either "yes" or "no"; I would strongly suggest setting this

# to "no" initially

ONBOOT=no

# I've only tried this driver so far w mode == Managed

MODE=Managed

# I've only tried this driver so far w explicit ESSID

ESSID=name_of_my_AP

# Driver needs MAC of AP above if it's not being broadcast;

# I've only tried driver so far w this explicitly specified.

# Value is passed thru by ifup-wireless to iwconfig

IWCONFIG=ap XX:XX:XX:XX:XX:XX

# Set channel to same channel AP is using...

CHANNEL=11

# Rate can be fixed or "Auto"; so far, I've only used "Auto"

RATE=Auto

# WEP key; "man iwconfig" for more.  So far, I've only tested

# driver with 128-bit WEP

KEY=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

# Set this to "open" unless using WPA, etc.

SECURITYMODE=open

The next step I took was to fix the driver so it would compile;
this involves making a few changes to r8180_core.c and to Makefile:

Code:

--- rtl8180-sa2400-dev/r8180_core.c        2005-05-28 05:34:35.000000000 -0400

+++ rtl8180-sa2400-dev.new/r8180_core.c        2006-12-03 00:35:22.000000000 -0500

@@ -134,16 +134,26 @@

 MODULE_AUTHOR("Andrea Merello <andreamrl@tiscali.it>");

 MODULE_DESCRIPTION("Linux driver for Realtek RTL8180 / RTL8185 WiFi cards");

 

-MODULE_PARM(ifname,"s");

-MODULE_PARM_DESC(devname," Net interface name, wlan%d=default");

+// LJM Sun Dec  3 00:32:09 EST 2006

+// Convert MODULE_PARM to module_param

+//

+//MODULE_PARM(ifname,"s");

+module_param(ifname,charp,044);

+// LJM s/devname/ifname/

+//    Apparently someone left the description as "devname", changed

+//    everything else to ifname.

+MODULE_PARM_DESC(ifname," Net interface name, wlan%d=default");

 

-MODULE_PARM(hwseqnum,"i");

+//MODULE_PARM(hwseqnum,"i");

+module_param(hwseqnum,int,044);

 MODULE_PARM_DESC(hwseqnum," Try to use hardware 802.11 header sequence numbers. Zero=default");

 

-MODULE_PARM(hwwep,"i");

+//MODULE_PARM(hwwep,"i");

+module_param(hwwep,int,044);

 MODULE_PARM_DESC(hwwep," Try to use hardware WEP support. Still broken and not available on all cards");

 

-MODULE_PARM(channels,"i");

+//MODULE_PARM(channels,"i");

+module_param(channels,int,044);

 MODULE_PARM_DESC(channels," Channel bitmask for specific locales. NYI");

Code:

--- rtl8180-sa2400-dev/Makefile        2005-04-25 12:35:30.000000000 -0400

+++ rtl8180-sa2400-dev.new/Makefile        2006-12-03 01:21:00.000000000 -0500

@@ -58,8 +58,13 @@

 2.4: 

        make -C $(KSRC) SUBDIRS=$(PWD) modules

 

+# LJM Sun Dec  3 00:35:01 EST 2006

+# LJM append "kmod" (or pretty much any other name) to MODVERDIR; it's where

+#    the .mod files for each .ko module will go.  Under the current version

+#    of the kernel (2.6.18), MODVERDIR is initially cleared out by the

+#    kernel's Makefile, so, if SUBDIRS == MODVERDIR, your code is toast...

 2.6:

-        $(MAKE) -C $(KSRC) SUBDIRS=$(PWD) MODVERDIR=$(PWD) modules

+        $(MAKE) -C $(KSRC) SUBDIRS=$(PWD) MODVERDIR=$(PWD)/kmod modules

 

 clean:

        rm -f *.mod.c *.mod *.o .*.cmd *.ko .*.flags

I also updated the docs:

Code:

--- rtl8180-sa2400-dev/INSTALL        2004-12-14 13:16:34.000000000 -0500

+++ rtl8180-sa2400-dev.new/INSTALL        2006-12-03 01:35:03.000000000 -0500

@@ -42,19 +42,31 @@

 3.2 Module loading (order is important)

 

 for user convenience a ./module_load script is provided.

-Anyway if you want to do manually:

 

-sudo insmod ieee80211-r8180_crypt.ko

-# you may or may not have to do this following step, Knoppix needs it

-sudo insmod /usr/src/linux/lib/crc32.ko

-# you will also need ARC4 support in kernel or by loading module

+If you prefer to load them manually, become the superuser:

+  su -

+etc.; "su -" has the advantage of setting root's PATH so you'll more likely

+than not have insmod, lsmod, rmmod, etc.

+

+Alternatively, you can load each module via sudo:

+  sudo insmod <modulename.ko>

 

-sudo insmod ieee80211_crypt_wep.ko

-sudo insmod ieee80211-r8180.ko 

-sudo insmod r8180.ko

+insmod ieee80211_crypt-r8180.ko

+# you may or may not have to do this following step, Knoppix needs it

+insmod /usr/src/linux/lib/crc32.ko

+# you will also need ARC4 support in kernel or by loading module; this is

+# necessary under Fedora Core 6 (FC6):

+insmod /lib/modules/$(uname -r)/kernel/crypto/arc4.ko

+insmod ieee80211_crypt_wep-r8180.ko

+insmod ieee80211-r8180.ko

+insmod r8180.ko

 

 Once the above is done, you can do some checks to verify if all went

-OK:

+OK.  Note that if you have provided an interface configuration script with

+a name that matches the interface brought up (hopefully) by the previous

+commands: eg., /etc/sysconfig/network-scripts/ifcfg-wlan0: if the system

+hotplug magic is working correctly, the interface will come up on its own,

+and be visible via ifconfig, iwconfig, etc.

 

  Doing

After making the above changes, I ran make - from a bash shell prompt:

Code:

make V=1 | tee out.log 2>&1

Note that I used "Makefile" and not the "Makefile26" that's also there. Once everything had compiled (it didn't take long), I loaded the modules, as root, as follows; note that load order is extremely important:

Code:

insmod ieee80211_crypt-r8180.ko

insmod /lib/modules/$(uname -r)/kernel/crypto/arc4.ko

insmod ieee80211_crypt_wep-r8180.ko

insmod ieee80211-r8180.ko

insmod r8180.ko

I loaded each one manually, checking "dmesg" and /var/log/messages ("tail /var/log/messages") after loading each one.

When they were all loaded, "iwconfig wlan0" showed a working interface, which I was able to bring up with "ifconfig wlan0"; upon confirming that it worked with "ping" ("ping -I wlan0 some.where.else"), I shut down my wired ethernet NIC ("ifconfig eth0 down"), confirmed via route that I no longer had a defaut gateway, and added a new one ("route add default gw aa.bb.cc.dd"); once the switchover from one card to the other was complete, I load-tested the driver fairly extensively and it neither broke nor did anything else out of the ordinary with the exception of the signal strength reported by iwconfig fluctuating a lot; given that the card seemed to work with consistent speed, I would tend to think this was a bug in the code that reports signal strength, signal to noise ratio, etc. to iwconfig but I've not yet confirmed that.

Returning to the caveats mentioned earlier, another is that this driver, while it works, is apparently 802.11b only; the card is supposedly a/b/g. Another caveat is that, while ndiswrapper will load the Windows drivers for this card with the only indication of there being a problem using the stock FC6 kernel (currently 2.6.18-1.2849.fc6 as of this writing) being the warning from ndiswrapper that the kernel was built with the "4K stacks" option enabled and indicates that that apparently breaks many drivers, and ifconfig, iwconfig, dmesg, etc. all show what appears to be a working card, it isn't; it just sits there and does nothing (though the stats do seem to show that initially the card did handle some traffic).

I plan on rebuilding the kernel sans the 4K stacks option in the very near future and seeing if that clears up the problem; I'll post a note regarding what happened when I do.

Good luck with this; I'll try to help if anyone tries this and runs into any problems.

- Larry (HowDoIProgramIt)

Quote:

Originally Posted by HowDoIProgramIt

I plan on rebuilding the kernel sans the 4K stacks option in the very near future and seeing if that clears up the problem; I'll post a note regarding what happened when I do.

Any progress, Larry? ..by the way, it cracks me up that the forum has entitled you a "Newbie".. ..when will forum servers have AI good enough to detect "this person knows what they're talking about"?? :D

Anyone know where/how I can find if ZyXEL G-302 v3 PCI has the same chipset?

I'm also happy to report (to any googlers out there) that the card fits in the low-profile PCI slot of my small form factor Dell Optiplex GX620. You have to cut through the bracket (I used a cut-off wheel on a dremel tool). Don't worry--the heat from cutting didn't damage my card. (Verified using the WinXP drivers--dual boot) Not often actual sparks go flying before a succeseful card install :D Word of caution: don't use Dell's metal fake bracket as a template--an actual card seats down lower. I'd originally bent the card & made a slot for the mounting screw, but in the end it didn't fit. I just cut my bend off. Friction holds it pretty tight, without the screw, though my airflow may be messed up a tad with the extra 1cm hole in the back.

Anyone out there with ndiswrapper experience? I can't get it to work.

I tried ndiswrapper and the 8185L WinXP drivers that came with the CD. modprobe ndiswrapper does NOT crash FC6, and dmesg | grep ndiswrapper gives lines to suggest that the driver gets loaded. However, the card's LED do not turn on & there is no wlan0 device. I know the drivers work, because I'm using them right now via XP

Too tired to troubleshoot right now

Reference: the fedora ndiswrapper wiki
the linuxant 16K stack packages

Follow the link to the "install" page on ndiswrapper wiki
... And I can't tell if the 16k stack stuff is working. I installed the RPM for my kernel, but ... nothing obvious happened.

Quote:

Originally Posted by TokyoYank

I'm in the same boat you're in... same card... same driver... same results.

Sorry it took so long for me to get back to you on this; hopefully this'll still be of some use to you...

Quote:

Originally Posted by TokyoYank

He he - yeah, I thought that was pretty funny, it's sort of like getting carded at my age. FWIW, I too wish the state of computing would improve a bit faster though...

Quote:

Originally Posted by TokyoYank

Anyone know where/how I can find if ZyXEL G-302 v3 PCI has the same chipset?

Sorry, can't help you there; if you do find out though ...
Good going w the low-pro mod!

As far as the driver's concerned, I did some hacking; at this point, I'd have to say that card was ten bucks well spent. It runs at full "G" speeds; hasn't missed a beat.

Grab the latest code from sourceforge's CVS server, it should be on ZyXEL's server by now too, and build it. It loads and runs at full G speeds, encryption works, ... The code in the driver that reports signal strength, etc. back to iwconfig still doesn't work (primarily because it isn't all there yet). The other people working on the project have moved on to a different chip; they'll probably be checking back in on the 8185 code from time to time, but if getting that part of the driver to work is important to you then it's probably going to be a DIY thing.

Give it a rip, I think you'll find it works surprisingly well. (Uh, you are using a 2.6 kernel, right?) There's also about no way to avoid gaining a decent understanding of how drivers in general and networking work on Linux. If you run into any problems trying to build it or get it to load, post back here; I'll check this page more regularly.

- Larry

Working so far, but need a simple working ifcfg-wlan0

Hi Larry,

Thanks! I've followed your instructions (running on Mandriva 2007, 2.6.17 kernel) and everything worked as advertised.

I'm able to load the modules, and no obvious errors are reported. After loading r8180.ko, the ACT light blinks on the card.

The problem now is that I don't have a working ifcfg-wlan0 file. Your example file includes various encryption-related info (e.g. MAC addresses) which I don't need. All I want is to be able to connect to a local unencrypted wireless router. Can you offer a complete (i.e. no settings need to be tweaked) ifcfg-wlan0 which would work for this purpose?

Thanks again,

Chuck

Quote:

Originally Posted by chuckmessenger

I'm really happy to hear that it worked; I was hoping I had documented everything correctly, and pretty sure that I had, but nevertheless... I also know how much instructions that don't work suck and was hoping like heck I hadn't done that to anyone.

Personally, I was pleased at the card's throughput; mine screams... I would probably be happy with it even if I had paid more than nine bucks USD for it.

Quote:

The problem now is that I don't have a working ifcfg-wlan0 file. Your example file includes various encryption-related info (e.g. MAC addresses) which I don't need. All I want is to be able to connect to a local unencrypted wireless router. Can you offer a complete (i.e. no settings need to be tweaked) ifcfg-wlan0 which would work for this purpose?

Thanks again,

Chuck

Try this one; you'll have to change the SSID to match the one your system's using (sorry, there's no way around that - at least, not that I'm aware of). Same with "CHANNEL"; just set it to match what your router is set to (in "b" mode). That should do it...

Code:

# ZyXEL G-302v3 802.11a/b/g Wireless NIC

DEVICE=wlan0

ONBOOT=yes

BOOTPROTO=dhcp

ESSID=<whatever your SSID name is>

MODE=managed

CHANNEL=11

SECURITYMODE=open

IPV6INIT=no

The subversion link to check out the latest version of the code is:
svn co https://rtl-wifi.svn.sourceforge.net/svnroot/rtl-wifi

My card only works with the r8180.ko driver, too; the docs, etc. that came along with the code seemed to imply that the r8187 driver was the one to use - from what I can tell, that's not applicable to the cards you or I have.

Hope that works for you (and glad the driver does); let me know if that config file (I'm pretty sure on Mandiva it would go in /etc/sysconfig/network-scripts/ifcfg-wlan0) - if it doesn't, post back, send me a PM, etc. and I'll try and help you resolve it.

- Larry

Quote:

Originally Posted by HowDoIProgramIt

.. I haven't had a chance to try out your instructions yet. The network card is my only net connection, which makes downloading CVS slightly more complicated.. ..also, I've had to educate myself on how to use patch. My natural inclination is to learn as little as possible on a daily basis. :)

The path from the diff snip you posted makes it really easy to patch, right? (no -pNUM is needed?) patch's man page seems to have a superflouous "<", so does this look correct?

% cd _my_CVS_tree_base_
% vi patchfile
==> cut and paste a codesnip from above, one of those starting with "---"
% patch -i patchfile

.. Also, a link for others learning about patch.

thanks

Hi Larry,

Thanks for the suggestion. Since I posted, I figured out a little more. One problem I'm working with is that I don't actually have a wireless router. I'm planning on using this computer on the road (Vacation-style road trip), to get fleeting net connections where possible. I'm depending on my neighbors to supply me with test connections. I have 2 such neighbors, apparantly. Unfortunately, one has an encrypted router. The other is unencrypted, which is great, except that both routers are operating on channel 6! What're the chances! (well, actually, 1 in 12 or so, but still...) Also, the unencrypted router has no ESSID (i.e. ESSID is blank, as reported by iwlist).

So, looks like I'm going to have to acquire a wireless router box in order to make more progress. But it does look like it will work...

BTW: It is a very sad thing that the box shows a penguin with Linux on it, but the included Linux driver doesn't actually work. No doubt, it once worked on one of their wireless cards, on some Linux configuration. Great. This sort of thing really gives Linux a black eye. Seems to me a card shouldn't be able to advertise with The Penguin unless the driver is already included with one or more major distros -- i.e. works out-of-the-box (assuming, of course, that the driver code was also conveniently available for others to compile)

Thanks again for your efforts. It's people like you that make Linux usable at all!

To the previous poster -- asking about patch: I didn't use patch, myself. I simply made the small number of required changes by hand (didn't bother with the documentation changes).

- Chuck

Quote:

Originally Posted by TokyoYank

.. I haven't had a chance to try out your instructions yet. The network card is my only net connection, which makes downloading CVS slightly more complicated...

Yeah, that is a bit of a problem... Unfortunately, there's no easy way to supply LKML (loadable kernel module) type drivers; they pretty much have to be built against the currently running kernel in any given machine.

Note that there are exceptions to that rule, though; ZyXEL could have made an effort to support the most common current kernels, though, using, for example, dkms.

But, then, as chuckmessenger noted, it would have been nice if, at the least, the code they provided had worked "out of the box".

Quote:

The path from the diff snip you posted makes it really easy to patch, right? (no -pNUM is needed?)

The "-p" argument to patch depends upon where you have your source files in relation to where you have the patch, and how the patch was originally generated (eg., where the files where when you first ran "diff -Naur" or whatever command you used to generate the patch). That sounds a whole lot worse than it is; if I'm not 100% certain as to what value I need to pass patch for "-p", 9 times out of 10, I'll use patch's "--dry-run" option (every version of GNU patch I've used has had this little gem, others may too). Also, "-i" and "<" serve, more or less, the same purpose; they specify the source of the patch (patch defaults to stdin unless "-i" + the name of a file is passed to it).

Code:

patch -p0 --dry-run < some.patch

or, the (generally) equivalent:

Code:

patch -p0 --dry-run -i some.patch

Quote:

patch's man page seems to have a superflouous "<", so does this look correct?

% cd _my_CVS_tree_base_
% vi patchfile
==> cut and paste a codesnip from above, one of those starting with "---"
% patch -i patchfile

AFAIK you can't use patch without "-p"; I just tried it out of curiosity, and patch refused to work.

As this is getting off-topic, I don't want to delve too far into it (diff and patch); however, this is the example I revert to when I get stuck with "patch" and/or "diff", you might want to try it:

Code:

mkdir dirWithMyChanges

mkdir pristineSources

Write a quick "hello.c", and copy it to both directories. Put a few other files in one or the other (or both), too, if you want. Stick with text files; others can be accommodated, but that's probably better left for another thread; this is already getting far enough off-topic.

Then, change "dirWithMyChanges/hello.c" so it's slightly different than the other "hello.c". Then:

Code:

diff -Naur pristineSources dirWithMyChanges > the.patch

"the.patch" should now contain a complete set of instructions which patch will use to make every file in ./pristineSources match, exactly, every file in ./dirWithMyChanges. Invoke patch in either of two ways:

Code:

patch -p0 < the.patch

Code:

patch -p0 -i the.patch

(or ... -i ./the.patch, etc.)

Now, look at the files in both directories; they should match each other.

Note that even though I'm pretty sure I know what's going to happen at this point, I would still, out of force of habit, first do:

Code:

patch -p0 --dry-run < the.patch

just to make sure all was well.

Quote:

Originally Posted by chuckmessenger

... except that both routers are operating on channel 6! What're the chances! (well, actually, 1 in 12 or so, but still...)

Actually, they're better than you think; there are only 3 channels in 1 - 11 that aren't overlapping (basically, there are three "bands", each of which is "cut up" into channels - page 13 of the .pdf document at:
http://www.cs.st-andrews.ac.uk/~tris...s-networks.pdf
has a nice visual of how that works).

You'll likely find that if your card is set to, say, channel 2, and the WAP is set to channel 1, that you have connectivity; how much the settings being dead-on seems to vary a lot from manufacturer to manufacturer.

Quote:

Also, the unencrypted router has no ESSID (i.e. ESSID is blank, as reported by iwlist).

The person(s) who own the router that appears open may have disabled "SSID broadcast"; by default, most routers used to broadcast their SSIDs every so many seconds. For security reasons, though, a lot of network admins will turn that "feature" off.

It's possible that the WAP you're seeing either had that off by default (from the factory), or the owner inadvertently turned it off, etc. Or, it might be operating in a different mode; I'm not positive, but I don't think SSID is used in all configurations (such as peer to peer, etc.)

As far as I know, you won't be able to establish a connection from your PC to it without that value, though.

Quote:

So, looks like I'm going to have to acquire a wireless router box in order to make more progress. But it does look like it will work...

Yeah, it's always something. Usually "something" that costs more $$. From what you've said so far, though, it definitely sounds like it'll work. Good news == with wireless "N" coming out, I've seen quite a few b/g WAPs for under $75.

Quote:

BTW: It is a very sad thing that the box shows a penguin with Linux on it, but the included Linux driver doesn't actually work. No doubt, it once worked on one of their wireless cards, on some Linux configuration. Great. This sort of thing really gives Linux a black eye. Seems to me a card shouldn't be able to advertise with The Penguin unless the driver is already included with one or more major distros -- i.e. works out-of-the-box (assuming, of course, that the driver code was also conveniently available for others to compile)

Amen to that. While it's true that a kernel-module driver either has to be compiled for each system it's going to be used on, or a "solution" like dkms has to be employed, they could have bothered to include pre-built .ko's for the more common distros + kernels. And dkms.

Or, at the very least, made sure that the code on the CD worked, and worked without any problems. That was what infuriated me more than anything. I don't mind having to build my own kernel modules; I do mind having to track down the code, though, particularly in this day and age when hardware mfgrs don't bother to publish the specs for their products; if you get them, its because you pulled some teeth.

Of course, the fact that the US Govt - particularly the FCC - makes it difficult, if not flat-out illegal, for a US company to disseminate that information to US end-users, doesn't help anything either. On the plus side, when push came to shove, Realtek *finally* found a way to get that info out in various (legitimate) ways...

Good luck with that, and your future endeavors!

- Larry

Can you post your modified driver?

Can you post your modified driver?