Forum Users

With the excellent work from Chuna, we now have for you the full source code for the 8181 Chipset Access Point

This source code is to be used with CAUTION as inproper use may cause your 802.11B Access Point useless.

Please only use the source code if you fully understand that it can void your warranty.

With that said, if you would like to use the source code, it is now available on the Minitar Download page.

The file size is 97 Megabytes so it is not a small download.

We appreciate the patience of the community who have been waiting for this release.

Regards

The Minitar Crew!

All,

We have found the following useful bits of information while investigating this source release.

1. Please note that if you are following the INSTALL/README files in this distrubution to build the source there is one small mistake.

Part 7 in the INSTALL file in the rtl8181-linux-1.7 folder should read like
7. Build system
- cd linux-2.4.18
gateway mode: make
AP 16M/2M : make AP=1
AP 8M/1M : make AP_8M=1
- cd rtkload
- make
- ==> 'rtkrom' is the linux image
==> 'linux.bin' is the image, which could be booted by Realtek boot code

As you have to recompile the kernel in the same fashion you did earlier.

2. The MNWAPB is listed as the "AP 8M/1M" device.

3. The Test Board that the documentation refers too is actually the MNWAPB with the Serial Port modification. Information on how todo this serial port modification can be found here and here.

S.

First of all,

Thank you guys for your work in trying to persuade RealTek to release bits of their source. I highly appreciate the efforts and pressure you did on RealTek, and I'm sure others do, too.

However, there is something important I just simply have to say now, at this point.
Maybe I'm blind - by looking at the contents of the tarball at http://www.minitar.com/downloads/rtl8181-sdk-1.6.zip, I surprisingly came to conclusion that there's almost NO difference, as for the amount of source code released, compared to earlier mnwapb_source.zip from RealTek !
The most important part - the source for rtl8181 and wireless part itself - IS STILL NOT THERE !!!
This means the technical implications are still here, not to mention that noone is
able to do modifications in the RTL8181/wireless part source at all.
But whats most important, by this, RealTek clearly demonstrates that it likes to BLATANTLY VIOLATE GPL license.
The Linux kernel itself is under GPLv2 license, and at this point, the only way to get the _real_ source for kernel-tied parts from the RealTek is fill a complaint against them with subject of abusing GPLv2, which I'm about to pursue.
Hopefully all the other users that dont like GPL violations, will do the same.
People, we need to unite on this subject - noone may ignore valid licences, and RealTek is no exception.

What can one do with the abovementioned sdk-1.6 ? Clearly - nothing but recompile the part of the code. And/or change a few kernel-related or userspace-related parts.
What is this useful for ? For changing userspace programs - well, one can do reusing the firmware images from Edimax and AboCom already. In other words, the source of the kernel is really useless for any serious modder unless all its parts will be made available in full source code form.

I'm going to Cc info about this case to Linus directly, and to some other organisations that are active on the GPL enforcement field. Very sad, but this is the only way how I can defend my rights to use the code with conformance to the GPL.
Note - everyone using the abovementioned SDK without full source is participating in GPL violation, too.

RealTek should chose any proprietary OS, and not Linux, if they dont care about license Linux comes out with.

Jan, developer

We have mentioned the fact that the code I think you are referring too is missing from the source. Realtek acknowledged that they do not feel it is necessary for them to provide this code as it is proprietory code they have written from scratch themselves to support their own chipset.

At least a few other communities members I have talked to agree with them.

If you feel this isn't the case then by all means raise it with them.

S.

jrm,

Be my guest and lodge the complaint to Linux. We have done our best and Realtek tells us that wireless part is propreitary and is not part of the GPL and a few other Linux guys have also agreed the fact they dont have to release any part of the wireless code.

If you feel they are in breach go ahead and start the process of your complaint.

I'm afraid but jrm is right, they have modified sources of linux kernel (GPLv2 license), so they must give all sources. There is no way to make parts of linux kernel image proprietary.I'm going to write to them about that because it's clear violation of GPLv2 license.
Anyway big thank you for pushing them to release at least something. Maybe we together can push them to release all code one day.

I dont think neither of you are right, you guys are reading snippets of the GPL and then cutting and pasting one form to suit the needs. Just like the bible, people interpret in various forms. No one has yet to give me a CLEAR answer. TO be honest this whole GPL thing is quite confusing the way it is written.

Read up on what others are saying on the Wireless Bit:

QUOTE (Sam @ Oct 27 2003, 01:31 PM)
It should be pointed out, that it as long as the wifi driver code hasn't been released under GPL, then it is ok for it to be released in binary-only form - that's the whole idea behind module tainting in the Linux kernel.



This is true.. IF the drivers in question are loaded as modules at runtime. (even then it's spurious) however. that is not the case here. wireless_lan.o is STATICALLY linked into the kernel on these devices in this case linus's exclusion on binary only modules would seem to me at least to not apply.

The wireless driver do have module_init code so it's possible they could be kept closed if the module is loaded from userspace and not compiled into the kernel that would possibly bring them into compliance however. mm.o kernel.o mm.o fpu_emulator.o are derived from .c files distributed with the mainline kernel so by my reading source needs to be released for these.


But like I said feel free to email Realtek on this and I would certainly like to know as I have spoken to a couple of Linux experts and they seem to think its all clean

Chuna,

This seems to be the same case like with LINKSYS/CISCO APs.
And nope, I think GPL speaks clearly, at least in this case - I dont see any reference to module_init() there. Finally, the libraries in 'rtl8181' are statically linked into the kernel, as you've said. I'll see what I can do, but unless an authority (not a linux expert, but FSF) tells me this is NOT the GPLv2 violation, then, it still is, in my eyes.
Well, lets see.

Jan

jrm,

Agreed. Let me know what the GPL folks say and if you need my help PM me. Whilst you may have to take it up with Realtek, I dont want to burn any bridges as you can understand.

The wireless driver for the RTL8181 chipset has been availiable as a binary only driver for some time. That probably has to be taken up seperately, as the Minitar AP isn't the only one affected.

Perhaps we should set up a fund at SourceSupport.org to reverse engineer the RTL8181 wireless part itself.

edit: !@#$ my own brain! Drivers exist for the RTL8180, but no such thing exists for the RTL8181.

Yes finally its great work i had some of the RTL8181 boards and i was able to port all my application
and it works better then before.

Belracu

I was gooing to try 2.6 kernel on the rtl board and found that the wireless lan drivers are still
missing in the source ... In the kernel source directory... I just see object files ....in "rtkload" rtl8181"
"rtkload-bz2" floders ..................

Is there any other way i can use 2.6 kernel on this board for testing

On binary modules:

Here's a simple test to see if you've got the 'complete' source code for the kernel, minus the binary module:
Compile the kernel they gave you with everything you need to load the modules.
insmod the module.

If the module loads, then they've probably given you the code they are obligated to give you.

If not, then there's a good chance that the module is violating the kernel module API and is integrated with the kernel proper. Then I think they should be requierd to release it, since IMHO that would make their complete kernel a derivative work.

IANAL, of course, but I'm thinking back to the linksys router's broadcom driver, which places a good deal of code in kernel proper. I wonder what's going on with that now?

Hey Chuna & team,
Smile.. you're on Slashdot!
http://slashdot.org/article.pl?sid=04/03/16/0045232
--mihnea

We know... we thought it was a DOS attack when we saw how slow everything was working on the webpage yesterday!

Then when you have 144 people on the forum at one time and your bandwidth to the site tripples...

Amazing what a slashdot can do!

Hopefully more people will become interested and push Realtek for a full source release... at the very least, it might push more people towards helping out at rtl8181.sourceforge.net

AAaargh, I have tried to play with it abit, and I have found out thad there is missing whole arch directory in kernel sources! Instead of it there are some:
rtl8181/arch.a
and
rtl8181/arch-8m.a

Well I wouldn't care that much if it wasn't bugged ..
I have tried to get ntpdate working, It works, but sometimes I get this error:
# ntpdate 10.152.16.1
Looking for host 10.152.16.1 and service ntp
host found : 10.152.16.1
Unable to handle kernel paging request at virtual address 00000000, epc == 00004
Oops in fault.c:do_page_fault, line 205:
..... etc dump here ...

And after this something is very wrong, because i get this error for example if I try
to ping and some more:
# ping 10.152.16.1
PING 10.152.16.1 (10.152.16.1): 56 data bytes
64 bytes from 10.152.16.1: icmp_seq=0 ttl=255 time=240.0 ms
Unable to handle kernel paging request at virtual address 00000000, epc == 00004
Oops in fault.c:do_page_fault, line 205:

I have to reboot the device ..

1) If the wireless part of the source is released can it all be compiled and uploaded via the web interface???

2) Is it possible just to DECOMPILE? or Reverse Engineer like someone else suggested earlier? I think you would probably have more luck with that than realtek giving you their code..

Dear alll...

Please help me....
has anyone setup traffic accounting/biling system based on minitar (rtl8181) by using external radius (any Radius server like FreeRadius, MeritRadisu)


Or have you any source or link... were ever i can finde helpfull information

THANKS A LOT!...

More a question for the modification forum insider.

I have not seen anyone however do that so far with the MNWAPB.

SB