Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenWrt rtl8188eu v4.1.8_9499 package (mac80211) #110

Open
Noltari opened this issue Apr 1, 2015 · 26 comments
Open

OpenWrt rtl8188eu v4.1.8_9499 package (mac80211) #110

Noltari opened this issue Apr 1, 2015 · 26 comments

Comments

@Noltari
Copy link
Contributor

@Noltari Noltari commented Apr 1, 2015

Hello,

I'm trying to add support for rtl8188eu v4.1.8_9499 on OpenWrt directly as a kernel module.
Here's what I've got so far: http://files.noltari.es/openwrt/rtl8188eu/rtl8188eu_package_v1.tgz

However, I get an exception right after loading the firmware (tested on Raspberry Pi 1 and 2): http://pastebin.com/jJyNnjPr

Any ideas?

@lwfinger

This comment has been minimized.

Copy link
Owner

@lwfinger lwfinger commented Apr 1, 2015

The lack of traceback info in the oops message makes it difficult. The patch below should make it easier to see which argument of _rtw_memcmp() is at fault, and the back path. If this patch is not intelligible, set me E-mail at Larry.Finger@lwfinger.net, and I will send it as an attachment to return mail. Note: Except for the last line, all the bullets in the patch should be replaced by pluses. The last one is a space. Too bad that GitHub does not allow the attaching of text files.

diff --git a/os_dep/osdep_service.c b/os_dep/osdep_service.c
index a3bec2f..8410a6f 100644
--- a/os_dep/osdep_service.c
+++ b/os_dep/osdep_service.c
@@ -555,6 +555,16 @@ void rtw_mfree2d(void *pbuf, int h, int w, int size)

int _rtw_memcmp(void *dst, void *src, u32 sz)
{

  •   if (!src) {
    
  •           printk("src pointer in %s is NULL\n", **func**);
    
  •           dump_stack();
    
  •           return false;
    
  •   }
    
  •   if (!dst) {
    
  •           printk("dst pointer in %s is NULL\n", **func**);
    
  •           dump_stack();
    
  •           return false;
    
  •   }
    
    /* under Linux/GNU/GLibc, the return value of memcmp for two same mem. chunk is 0 */
    if (!(memcmp(dst, src, sz)))
    return true;
@Noltari

This comment has been minimized.

Copy link
Contributor Author

@Noltari Noltari commented Apr 1, 2015

I'm building a new firmware right now with those changes.

However, I've already located the problem: https://github.com/lwfinger/rtl8188eu/blob/v4.1.8_9499/os_dep/ioctl_cfg80211.c#L2008

I tried disabling CONFIG_P2P in autoconf.h and the exception didn't appear.
After that, I can only scan once, then the WiFi stops working no matter what I do. If I unplug the dongle I get several exceptions until the Raspberry restarts itself.

@Noltari

This comment has been minimized.

Copy link
Contributor Author

@Noltari Noltari commented Apr 1, 2015

[ 53.995525] dst pointer in cfg80211_rtw_scan+0xd0/0x5ac [8188eu] is NULL
Yup, ssids->ssid is NULL

@Noltari

This comment has been minimized.

Copy link
Contributor Author

@Noltari Noltari commented Apr 1, 2015

Here's a new version of the package with the patch you gave me and the null pointer fix, in case anyone wants to test it: http://files.noltari.es/openwrt/rtl8188eu/rtl8188eu_package_v2.tgz

After fixing the null pointer the results are the same as the ones I had when I disabled CONFIG_P2P.

@lwfinger

This comment has been minimized.

Copy link
Owner

@lwfinger lwfinger commented Apr 1, 2015

Is that null pointer fix something that should be in the regular repo, or was it something that only applied to your port?

The ARM architecture has some alignment requirements that are not present in x86. These usually show up in the alignment of the private storage arrays at the end of a header, but they could be in other places. From some reading that I just did, /proc/sys/debug/alignment can control the behavior of the system when such errors occur. Most of the discussion concerned user processes, but I think that the kernel operates in the mode where garbage results may occur. The command 'cat /proc/sys/debug/alignment' should show you the current state.

@Noltari

This comment has been minimized.

Copy link
Contributor Author

@Noltari Noltari commented Apr 1, 2015

Thanks for the info, I will try on x86 (VirtualBox) and see what happens.
I'll also look at "/proc/sys/debug/alignment".

Edit: about the null pointer fix it would probably be sane to apply it to the regular repo. Do you want me to send a PR?

@lwfinger

This comment has been minimized.

Copy link
Owner

@lwfinger lwfinger commented Apr 1, 2015

After looking at your null pointer fix, I think it is a band aid. That pointer cannot be null, and we need to learn why. That is the fix we need.

@Noltari

This comment has been minimized.

Copy link
Contributor Author

@Noltari Noltari commented Apr 1, 2015

This is what I get on x86: http://pastebin.com/4yEKYjqs

It's kinda weird, since there's no memcmp on rtw_cfg80211_surveydone_event_callback...

@lwfinger

This comment has been minimized.

Copy link
Owner

@lwfinger lwfinger commented Apr 2, 2015

It likely is in some in-lined routine. In that x86 machine and if gdb is available, then do the following:

gdb 8188eu
l *rtw_cfg80211_surveydone_event_callback+0x161

That second line starts with a lower-case el, not a one.

Is the main source exactly the same as my git repo?

@Noltari

This comment has been minimized.

Copy link
Contributor Author

@Noltari Noltari commented Apr 2, 2015

I ran gdb on my build machine using 8188.eu and this is what I got:
http://pastebin.com/gvUPd26v
Again the ssids->ssid null pointer...

And yes, the package is directly using the source from your repo, and the only changes made are the patches I've provided (Makefile and rtw_memcmp). BTW, I removed the ssids->ssid null pointer fix as you said it wasn't the root of the issues.

@lwfinger

This comment has been minimized.

Copy link
Owner

@lwfinger lwfinger commented Apr 2, 2015

To follow up a bit, ssids is set by the line "struct cfg80211_ssid *ssids = request->ssids;". The definition of cfg80211_ssid is

struct cfg80211_ssid {
u8 ssid[IEEE80211_MAX_SSID_LEN];
u8 ssid_len;
};

It seems that the results of the scan are not being supplied correctly to cfg80211.

One area of concern is that I have only run this version of the driver as a module - never built into the kernel. As I recall, it is possible have modules with the openWRT kernel. If you reconfigure this code as a module, does anything change?

@Noltari

This comment has been minimized.

Copy link
Contributor Author

@Noltari Noltari commented Apr 2, 2015

Actually it's built as an autoloaded kernel module, not right into the kernel.

@lwfinger

This comment has been minimized.

Copy link
Owner

@lwfinger lwfinger commented Apr 2, 2015

The 8188eu-y entries in your Makefile make it look as if you are building it into the kernel. Is the openWRT build system that different?

@Noltari

This comment has been minimized.

Copy link
Contributor Author

@Noltari Noltari commented Apr 3, 2015

I based that Makefile on the mwlwifi & mt76 wifi drivers present in OpenWrt.
However, it's built as a kernel module and not directly into the kernel, you can see that on the package Makefile I provided.

@hoatienii

This comment has been minimized.

Copy link

@hoatienii hoatienii commented Apr 16, 2015

I have error when compile:
make[5]: *** [/home/dinhchuc/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_uClibc-0.9.33.2_eabi/linux-brcm2708/rtl8188eu-4.1.8_9499_20150323/os_dep/ioctl_cfg80211.o] Error 1
make[4]: *** [module/home/dinhchuc/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_uClibc-0.9.33.2_eabi/linux-brcm2708/rtl8188eu-4.1.8_9499_20150323] Error 2
make[4]: Leaving directory /home/dinhchuc/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_uClibc-0.9.33.2_eabi/linux-brcm2708/linux-3.10.49' make[3]: *** [/home/dinhchuc/openwrt/build_dir/target-arm_arm1176jzf-s+vfp_uClibc-0.9.33.2_eabi/linux-brcm2708/rtl8188eu-4.1.8_9499_20150323/.built] Error 2 make[3]: Leaving directory/home/dinhchuc/openwrt/package/kernel/rtl8188eu'
make[2]: *** [package/kernel/rtl8188eu/compile] Error 2
make[2]: Leaving directory /home/dinhchuc/openwrt' make[1]: *** [/home/dinhchuc/openwrt/staging_dir/target-arm_arm1176jzf-s+vfp_uClibc-0.9.33.2_eabi/stamp/.package_compile] Error 2 make[1]: Leaving directory/home/dinhchuc/openwrt'
make: *** [world] Error 2

@hoatienii

This comment has been minimized.

Copy link

@hoatienii hoatienii commented Apr 16, 2015

I get newest trunk to compile, no error but can't work as AP or client mode

@lwfinger

This comment has been minimized.

Copy link
Owner

@lwfinger lwfinger commented Apr 16, 2015

If you are talking about the "master" branch, it does not implement cfg80211 calls. As a result, it will not work with any hostapd newer than version 0.8. The v4.1.8 branch works with the newest hostapd using the cfg80211 driver calls.

I have no idea what is going wrong with your build of v4.1.8. You only listed the errors output by make. What I need is the error message that gcc output.

The final problem will be with the build for ARM architecture. The driver builds and works for x86. It fails for PPC, a big-endian architecture. That is a problem I work on when I get time. I have not tested on ARM, and there may be issues with the USB core code, or with this driver. Alignment problems come to mind.

Finally, why did you put in that question about the mt7601u? That is a totally different driver, manufacturer, and hardware.

@hoatienii

This comment has been minimized.

Copy link

@hoatienii hoatienii commented Apr 16, 2015

Thank you your reply!
This driver can not work on ARM, i will not try compile agian for Raspberry.
Sorry i post wrong question about mt7601, i will delete post.

@lwfinger

This comment has been minimized.

Copy link
Owner

@lwfinger lwfinger commented Apr 16, 2015

I did not say that the driver can never work on ARM. I merely said that it has not been tested.

@hoatienii

This comment has been minimized.

Copy link

@hoatienii hoatienii commented Apr 17, 2015

Ok, i will try another time. Still wait now! :)

@hoatienii

This comment has been minimized.

Copy link

@hoatienii hoatienii commented Apr 24, 2015

I scan network from raspberry pi run Openwrt with rtl8188eu, It can find network but not connect.

firewall.cfg04dc81
firewall.cfg04dc81.network=lan

firewall.cfg06dc81
firewall.cfg06dc81.network=wan wan6 wwan

network.wwan=interface
network.wwan.proto=dhcp

wireless.cfg033579 #Section removed

wireless.radio0
wireless.radio0.disabled=0

wireless.cfg053579=wifi-iface
wireless.cfg053579.bssid=C0:4A:00:4D:30:F4
wireless.cfg053579.device=radio0
wireless.cfg053579.encryption=psk2
wireless.cfg053579.key=xxxxxxx
wireless.cfg053579.mode=sta
wireless.cfg053579.network=wwan
wireless.cfg053579.ssid=BVCH&CC

@rickbase1

This comment has been minimized.

Copy link

@rickbase1 rickbase1 commented Sep 22, 2015

Hello,

I am having problems trying to add an rtl8188eu USB modem to my Openwrt Chaos_Calmer 15.05 build, running on an RPi2. I see in some forums that it will not work, but I am hoping this driver might do the trick.

I have been able to config a modem with the rtl8192/mac80211 driver but really want to use the high power Alfa AWUS036NHV that uses the rtl8188eu chipset.

Will this allow the RTL8188eu modem to work with Openwrt 15.05?
If so, how would I download it? I have not had any luck installing apt or dkms on openwrt using opkg.

Can it be installed with opkg, and if so what would the command look like?

Thanks

Rick

@lwfinger

This comment has been minimized.

Copy link
Owner

@lwfinger lwfinger commented Sep 23, 2015

You will need to get the source from this repo and build (compile) the driver. No, it cannot be installed with opkg as no one provides the driver as such a package.

What does 'uname -r' report as the kernel version? If it is newer than 3.12, then there is a driver already in the kernel. All you would need to do is enable it when you build the kernel.

@sajohn

This comment has been minimized.

Copy link

@sajohn sajohn commented Sep 23, 2015

Hello lwfinger,
Is there an open source firmware available for 802.11 AC any chip from RTL? Do you have a info/contact if this is not available as open source by via signing NDA?

@lwfinger

This comment has been minimized.

Copy link
Owner

@lwfinger lwfinger commented Sep 23, 2015

Realtek's firmware is not available in source form. It is only issued in binary form with a license to copy freely.

I have no NDAs with Realtek, nor do I want any. I have no idea about whom to contact.

@rickbase1

This comment has been minimized.

Copy link

@rickbase1 rickbase1 commented Sep 24, 2015

                                                                                  Thanks LW, that is what I expected. My linux learning curve is still pretty steep. I have been trying to build my antenna tracking arduino/pi2 project on top of the openwrt kernel but as memory is not a limiting factor for me I  think I will just go back to Raspbian and ‎build on that.Linux rocks! And thanks to guys like you anyone can learn it.CheersRick                                                                                                                                                                                                                                                                                                                                        Sent from my BlackBerry 10 smartphone.                                                                                                                                                                                                                From: lwfingerSent: Wednesday, September 23, 2015 2:03 PMTo: lwfinger/rtl8188euReply To: lwfinger/rtl8188euCc: rickbase1Subject: Re: [rtl8188eu] OpenWrt rtl8188eu v4.1.8_9499 package (mac80211) (#110)You will need to get the source from this repo and build (compile) the driver. No, it cannot be installed with opkg as no one provides the driver as such a package.

What does 'uname -r' report as the kernel version? If it is newer than 3.12, then there is a driver already in the kernel. All you would need to do is enable it when you build the kernel.

—Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.