Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[DennisOlof1]

This could applies to ALL H/W revisions in the DAP-1360 series released but I am not sure of this, but the C1 suffers from the error described at the bottom of this post.

Hardware Version=C1
Firmware Version=3.02

This is the firmware that is pre-loaded into the unit when you buy it. And I think that H/W C1 was out everywhere sometime during summer 2012. The older H/W revisions are not in production any more.

Bought two of these DAP-1360 units to use in a WLAN network. One as a "access point" and the other as a "repeater". I wanted the WLAN range to be normal, and by using the repeater any device
like phone, ipad and so on could connect to the WLAN without any extra equipment. Before I bought this D-link product I did some research on the Internet and found that there where a lot of problems. I thought it was because of early H/W revisions but I was wrong. I am having some problems.

-----------------------------------------------------------------

General information1:

I have been testing and trying out the following modes that the device has.

Access Point mode - page 13
Wireless Client mode - page 14
Repeater mode - page 15

The repeater mode worked nice, great speed but was not stable enough for me. But this could be related to the error you get if you run one unit in "access point mode". I could not get the "bridge mode" or "bridge with AP mode" to work even though I have to identical units, H/W, firmware and all that.

It does seem that "access Point mode" and "wireless Client mode" are the most stable. And you can get around the need for a repeater function by doing this instead.

AP1 running on ch1 -> AP2 in client mode connected to AP1 -> From AP2 use a network TP cable and connect that to -> AP3 running on ch6

It does require 3 dap-1360 units but is a more universal and stable solution. Of course using units as standard APs with a LAN network as backbone is preferred, but this is not always possible.

These units are going to be used in a remote location and to ensure they are always working, use a power outlet timer, to power cycle the units every 24h. The problem is that because of the serious bug in the
current firmware (and this probably includes the older H/W revisions) this will not ensure 24h of problem free WLAN operations.

-----------------------------------------------------------------

General information2:

This is interesting, I have a older DWL-G700AP and by checking this file DWL_G700AP_fw_revB_v2_10r15_GPL_release_Sources_ALL_en2.zip it seems this unit too is running linux 2.4.18 and some other software, similar or the same as this, more up to date unit DAP-1360.

Here is some things I noticed from the startup of the DAP-1360 from the log file. And this could be related to the current bug (problem) with the firmware in the unit.

BusyBox v1.13.4
squashfs: version 4.0 (2009/01/31) Phillip Lougher
Realtek GPIO Driver for Flash Reload Default
Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x18002000 (irq = 23) is a 16550A
PPP generic driver version 2.4.2
MPPE/MPPC encryption/compression module registered
RTL8192C/RTL8188C driver version 1.6 (2011-07-18)
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Failed to initialize inotify: Function not implemented

One thing I noticed here and from viewing the DAP-1360A1_GPL_Code.rar file on the D-link site, is that a lot of things that run on the AP is a bit old. At least D-link could update software components for most of their hardware once a year, can not be that hard to fix this and just compile a new image so people can update their devices. Would be like having free bugfixes for their devices. On the other hand, if it works do not fix it. For example, busybox, squashfs and some other things are old, updating the linux drivers for the WLAN and LAN chips can not be a bad thing.

-----------------------------------------------------------------

Information from the log:

1. This might be errors or not, I do not know. This comes up a few times
and I do not know if it is normal or not.

"wlan0: Delete MC entry not found!" ? (in AP and Wireless Client mode) and it it just a few times so might not be a problem.

When in repeater mode i keep getting this all the time in the log

"D3 hot -> L1"

This could be all normal and no errors at all, but I do not know what this information is.

-----------------------------------------------------------------

The critical error that hangs the WLAN in the AP:

In order to test the devices as they where not stable. I have been running AP1 in "AP mode" and AP2 in "Wireless client mode". My computer that i use all the time is connected with a LAN cable to AP2 and the traffic goes over the WLAN to AP1 and out on the internet.

In AP2 "Wireless client" I get the following error message in the log (this is when AP1 crash). If I reboot AP1, AP2 does reconnect to AP1 and everything works again.

Errorlog from AP2 (wireless client) -> "wlan0: A STA is expired".

In AP1 "Access point mode" I get the following error message in the log:

rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: ===> Load_92c_Firmware
rlx-linux user.warn kernel: <=== Load_92c_Firmware
rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: 8192c firmware not ready
rlx-linux user.warn kernel: [PHY_ConfigMACWithParaFile][MACPHY_REG_92C]
rlx-linux user.warn kernel: ===> Load_92c_Firmware
rlx-linux user.warn kernel: <=== Load_92c_Firmware
rlx-linux user.warn kernel: 8192c firmware not ready


This keeps repeating, over and over. You can not access the device over the WLAN. It does work over LAN, so I can login to the device, I can ping a device on the internet using the ping test in the unit. So it seems to work fine, BUT is slow because the CPU is occupied with the looping error. It does respond to ping over the LAN but the respons times are up and down. Again because the unit in in a error state.

If the unit is software rebooted not long after the error has occurred the unit is back to normal and works fine, if you wait several hours to reboot the unit. It does not work, the only way to get it back to normal is to do a power cycle.

Can D-link investigate this issue and if possible fix it by releasing a new firmware ?

-----------------------------------------------------------------

P.S. To bad D-link does not have a option to send in crash reports, bug logs etc, would be a great way for D-link to get hold of the bug information from their users, this way saving them time and money not having to find the errors them selves.

[FurryNutz]

Link>Welcome!
What region are you located?
Any cordless house phones?
Any other WiFi routers in the area? Link> Use InSSIDer to find out. How many?

I recommend phone contacting DLink support directly, and ask for level 3 or higher support.

Let us know how it goes.

Good Luck.

[DennisOlof1]

I am located in Sweden, no cordless phones in house, and I have been using InSSIDer, there are just one or two weak WLANs here, but I am on my own channel. Plus the devices are configured for the old G standard. Forgot to add the information in my original post sorry. So if any engineer from D-link reads this, perhaps you have use for the information I have posted here.

It seems older APs with only B/G mode are much more stable and working better, from what I can tell on the information on the Internet. Why I do not know. But I only posted here for other users so they know about this error.

------------------------------

The AP1 Configuration.

Enable Wireless : Always (ticked box)
Wireless Mode : Access Point
Wireless Network Name : test1
802.11 Mode : Mixed 802.11n and 802.11g
Wireless Channel : 1
Enable Auto Channel Scan : Disabled
Channel Width : 20Mhz
Visibility Status : Visible

WPA Mode : WPA2 Only
Cipher Type : AES

Wireless MAC Clone : Not in use
WIFI Protected Setup : Disabled

Transmit Power : 100%
HT 20/40 Coexistence : Disable

WMM Enable : Enabled
Short GI : Enabled
IGMP Snooping :Enabled
WLAN Partition : Disabled


------------------------------

The AP2 Configuration.

Wireless Mode : Wireless Client
Wireless Type : Infrastructure
Wireless Network Name : test1
802.11 Mode : Mixed 802.11n and 802.11g
Wireless Channel : 1
Enable Auto Channel Scan : Disabled
Channel Width : 20Mhz
Visibility Status : Visible

WPA Mode : WPA2 Only
Cipher Type : AES

Wireless MAC Clone : Not in use
WIFI Protected Setup : Disabled

Transmit Power : 100%
HT 20/40 Coexistence : Disable

------------------------------

All other configuration options are set to standard, have not been changed. The problem is the logs show nothing, everything is working fine, until the crash happens. And I have been running under heavy load for some time now.

[FurryNutz]

DLink developers and engineers rarely visit these forums so if you want to make DLink aware of this, I highly recommend phone contacting DLink support and get this information to them.

Thank you for posting this information.

Good Luck.

[DennisOlof1]

Yeah, I understand that.

My experience is that most company's do not care that much about end consumer problems, if you are a business customer it is another matter. It is sad that dlink and others do not see the value of automated or semi-automated bug, crash, error -reporting systems in the devices they produce. This could be of great value by letting the end-users send in errors to them so they can fix potential bugs and so on, then they would not have to do so much work fixing errors. Money and time saver for company's.

But I do not blame dlink for that (or others), as I have learned that WLANs are not as reliable as a standard wired LAN network if you want to run it day and night without problems. WLAN can simply not compete with those requirements. Other dlink products, routers, switches never gave me any problems. Same goes for other brands.

Anyway, thanks for reply FurryNutz. I will probably get a older second hand DWL-G700AP as that has been running perfect day and night for more than three years, no problems at all. So my conclusion is that B/G WLAN products are more stable, why I do not know. Should make no difference if you configure modern WLAN products to use B/G and so on.

/Regards Dennis



 

[FurryNutz]

Good Luck.

[DennisOlof1]

I have decided to keep the units, I will see if my attempt at using power outlet cycling every 24h will make the units stable enough, to at least use the WLAN access for light to moderate Internet usage, should work. I am pleased with the units despite the fact of the errors I posted information on, best part is they do not get warm, probably because the industry has moved on to smaller size cpus and so on. This is a good thing as old units needed extra cooling.

I have now been successful using the two APs as "bridge", works great, easy to set up and no problems. But I did find that one of the "bridge with AP" does not work. And I will give a explanation why. First you can solve this by instead using four APs, using two of them as a "bridge" and then AP3 and AP3 connected independently to each LAN and that way providing WLAN for each LAN on two different channels.

"bridge with AP" only works for AP1, reason is that you can login to it, and use a computer connected to the LAN port, (or a switch and then connect other devices to that). When you use AP2 (in the same mode) it is not allocated a IP from the DHCP over the WLAN. This works well in the "bridged" mode, and you can connect to the two APs. But when in "bridge with AP" mode AP2 is not allocated a IP from the DHCP server, and you can't connect to it etc. Only if you set IP manual in the computer, and then you find out that the device does not receive a IP address.

Anyway I can not see the point of "bridge with AP" mode, because both APs must be on the same channel to create a "bridge" providing "access point mode" seems daft, that would just make the whole network even slower, and how can a "wireless client" know which of the APs it's connected to. I would just stick to the other option of having a separate "access point" on the two separate LANs, that in turn are connected by a WLAN bridge.

I am going to send report this to dlink and point them to this forum and this thread, and see what they have to say about it. The important part is my first post as this is a bad error, otherwise units work fine, and I am happy with them.

"repeater" works fine to but is unstable, the reason is that sometimes the units crash (could be because of the errors posting at the top) and the "access point" lost the configuration and had to be reset and reconfigured, that is not good. So avoid using "repeater" mode and use three APs instead, much safer and seems to work well.

This site seems to have all the different firmwares, and so on.

http://tsd.dlink.com.tw/

[FurryNutz]

Just be careful of using those FWs. They are not meant for just any region. 

[DennisOlof1]

FurryNutz, I am aware of that. Was unclear why I posted the URL. I was thinking more in the line of the option of viewing firmware release history and so on. You should of course get the firmwares from other sites just as you said. So you don't brick the unit and then have to buy a new one.

Messing around with firmware can damage the device. Get firmware from your local dlink site, that is the safest way if you need to update firmware.

[FurryNutz]

 

[DennisOlof1]

Posting the next update.

I have been running the three units for a while now, and the error I reported about has not happened again. So my setup seems stable. People should avoid repeater mode, but "access point" and "wireless client mode" seems rather stable.

AP1 ch1 in "access point mode", to AP2 ch1 in "wireless client mode", using a standard TP cabel to AP3 ch6 in "access point mode".

I am pretty pleased with these units and after the dilemma with a few issues, I posted about in the start of the thread. From what I can tell on the Internet, running units over PoE and having the option to "remotely" power cycle them is good, if you need stability or to avoid problems. A cheap way is using a standard power outlet timer, with battery memory to reset the units once every 24h to counteract any weird errors, bugs and other things. If everyone did that, I do not see any major issues with using WLANs in a home environment.

The only log entry that sometimes pops up is "wlan0: Delete MC entry not found!"

I guess, as long as the units are working you can ignore whatever it says in the logs. So there you have it. I will report back if there are any new errors but I think the original error, I posted about, is the most serious, other than that everything with the units seem to work great. I might give the repeater mode a try using my laptop for testing to see if I can catch any errors from the logs, and post them here.

------------------------

Additional information from my AP3. Seems interesting, and this time the firmware loaded ok, compared to my first post. I am starting to think that this initial error that locked up the unit had something to do with power saving mode or some sort of error connected to power saving mode, so when the device is not in use (traffic) during a prolonged period of time.

It goes into sleep mode, and when it wakes up it has to restart the wlan firmware, and when loading the firmware again. It does seem to work, my first post of the error was when the unit was in use. So there is some sort of error in the unit when the firmware need to be reloaded somehow, on the WLAN sida of the unit. I do not think it is a driver issue from realtek, it is something dlink does that puts the unit into a mode where it keeps trying to reload the WLAN firmware and fails, and keeps on doing this in a loop that never ends, until you restart the units by power cycling. Anyway here is how it looks when reload was successful.

21:55:51  D3 hot -> L1
20:39:29  Withdrawing address record for 192.168.2.73 on br0.
20:39:29  Withdrawing address record for 192.168.2.73 on br0.
20:39:30  br0: port 3(wlan0) entering disabled state
20:39:31  [PHY_ConfigMACWithParaFile][MACPHY_REG_92C]
20:39:31  ===> Load_92C_Firmware
20:39:31  <=== Load_92C_Firmware
20:39:31  br0: port 3(wlan0) entering forwarding state
20:39:32  br0: port 1(eth0) entering disabled state
20:39:32  br0: port 1(eth0) entering forwarding state
20:39:34  DAT b800350c:6803f
20:39:36  Registering new address record for 192.168.2.73 on br0.IPv4.
20:39:36  Registering new address record for 192.168.2.73 on br0.IPv4.
20:39:36  Withdrawing address record for 192.168.2.73 on br0.
20:39:36  Withdrawing address record for 192.168.2.73 on br0.
20:39:36  Registering new address record for 192.168.2.73 on br0.IPv4.
20:39:36  Registering new address record for 192.168.2.73 on br0.IPv4.
19:39:42  D3 hot -> L1

------------------------

[FurryNutz]

Hope they keep working well for you. 

[DennisOlof1]

Time to post another strange behavior from the logs, all three units are still working fine but I had to post this, strange I say ?

You can tell by the timestamp, it looks like AP1 (access point mode) and AP2 (wireless client) are arguing about the authentication back and forth, goes on for about 15min until the logs do not show anything, it is kind of strange thing. All the units have been running fine so far without any reboot, configuration and so on, I just check the logs from time to time.

-------------------
AP1 (access point)

Apr 16 19:40:34    wlan0: A wireless client is associated - C8:BE:19:5B:F1:ED
Apr 16 19:40:34    wlan0: WPA2-AES PSK authentication in progress...
Apr 16 19:40:34    wlan0: A wireless client is associated - C8:BE:19:5B:F1:ED
Apr 16 19:40:34    wlan0: Open and authenticated
Apr 16 19:41:36    wlan0: A wireless client is associated - C8:BE:19:5B:F1:ED
Apr 16 19:41:36    wlan0: WPA2-AES PSK authentication in progress...
Apr 16 19:41:36    wlan0: A wireless client is associated - C8:BE:19:5B:F1:ED
Apr 16 19:41:36    wlan0: Open and authenticated

Apr 16 20:01:18    wlan0: Open and authenticated
Apr 16 20:02:49    wlan0: A wireless client is associated - C8:BE:19:5B:F1:ED
Apr 16 20:02:49    wlan0: WPA2-AES PSK authentication in progress...
Apr 16 20:02:49    wlan0: A wireless client is associated - C8:BE:19:5B:F1:ED
Apr 16 20:02:49    wlan0: Open and authenticated

-------------------
AP2 (wireless client)

Apr 16 19:40:31    wlan0: Roaming...
Apr 16 19:40:31    wlan0: WPA-none PSK authentication in progress...
Apr 16 19:40:31    wlan0: Open and authenticated
Apr 16 19:41:33    wlan0: Roaming...
Apr 16 19:41:33    wlan0: WPA-none PSK authentication in progress...
Apr 16 19:41:33    wlan0: Open and authenticated
Apr 16 19:43:58    wlan0: Roaming...

Apr 16 20:02:54    wlan0: Roaming...
Apr 16 20:02:54    wlan0: WPA-none PSK authentication in progress...
Apr 16 20:02:54    wlan0: Open and authenticated
Apr 16 20:03:24    wlan0: Roaming...
Apr 16 20:03:24    wlan0: WPA-none PSK authentication in progress...
Apr 16 20:03:24    wlan0: Open and authenticated
Apr 16 22:43:59    wlan0: Delete MC entry not found!
Apr 16 22:44:11    wlan0: Delete MC entry not found!
Apr 16 22:44:11    wlan0: Delete MC entry not found!

-------------------

End of log data. Oh, I do hope this information is of use to dlink engineers if they happen to read this, I have not gotten around to sending them a e-mail. However I will still reboot the units every 24h as a precaution and to guard against errors.

 

[DennisOlof1]

So another update from the last time. I have been using the same setup, and so far, nothing has happened. AP1 and AP2 are still arguing about the authentication back and forth, from time to time, seems to be working fine though. But thats about it.

My conclusion so far (with exception of the initial error i reported about) is that running the unit on a wired network as a standard AP should give users no problems at all. I do not know how stable the linux operating system are over the long run. But other than that, seems to work great. So for my setup, I will be working towards a wired network and to use the units as standard AP, seems to be a safe bet, regardless of manufacturer of equipment. Even though ubiquiti are supposed to be better, from what I can tell, running a pure AP is the most stable and safe thing to do.

I did not have time to test the repeater mode again, but I do not think it will work any better than it did last time. This could be my last post about these units. I do hope anyone else reading this had some use for the information of that it did help you in someway.

Lets hope that dlink will release future firmware fixes or updates for this device, I know by looking at the firmware info from the older DWL-G700AP they fixed a huge number of bugs over time, and that unit was great (still is) as one can tell from the test / reviews on the Internet. Probably due to firmware fixes.

Oh, and remember, using access points as just a standard AP with LAN (or cable) as backbone network is as stable as you can get with WLAN AP units. Lets hope other dlink users find this information useful plus dlink them selves in hunting for bugs

[DennisOlof1]

Time for another update. A small one but still.

I am now running the system as described in first post. It seems to run fine, and I have put power cycle timers so the units are reboot every 24h just in case the firmware (or operating system) go crazy, at least it should be restored after 24h, that is better then nothing. Running as "AP" or "Wireless Client" does seem to prevent the units from loosing the settings or just locking up.

The only drawback so far, is that the speed on AP3 is cut in half. I did test the system with cable, so I know this is about right. Worse than the repeater mode but probably a lot more stable. This will give ipads, smart phones and other devices WLAN access. However if possible, I have come to the conclusion, it is much better to use a single "AP" for Internet access and then using other units around this "AP" as "Wireless Clients". And then connecting the devices with a small local LANs at each site. Even more stable and provides you with a lot more speed over the WLAN connection. The bonus here is you can use powerful antennas and get much greater coverage, better speeds, more stable connection.

I will probably post another update later. When I do not know.