Hi Joao,
Your modification worked great! The flash is properly detected and the settings now save correctly.
When it comes to the MAC address, it's still not being detected. I'm not a programmer but I've looked at the source you mentioned and I believe its looking in the wrong spot. The MAC is located in /dev/mtdblock4 but its between 0x7ff80 and 0x7ff90. Now, I came up with this by dd-ing mtdblock4 to a file and opening that file with a hex editor, will that work?
As far as everything else. LEDs, Poweroff, Reboot, Temp, and HDD detection are all working great!
OK. The fix for the MAC address worked. It's now displaying properly.
The fan is working. There seems to be two speeds, low is 127 and lower, high is 128 and above.
Here is the output of "cat /sys/class/hwmon/hwmon1/device/name":
/ # cat /sys/class/hwmon/hwmon1/device/name
dns323c-fan
The status web page shows an idle temp of 44c. That's with one bay populated. I'm not sure how to tell if it's correct...
Hardware version: the sticker on the outside of the unit says "H/w ver. A2" however the motherboard on the inside shows "Rev-A1".
As far as identifing the unit, if I remember right the 321 is the only box that runs the processor at 400MHz. Everything else is 500 and above? Maybe that could help?
Thanks for all your help! Let me know if there is anything you would like me to test out.
Hi Joao,Yes setting it to 0 will turn the fan off.Everything seems to be working great. I haven't come across any problems. I'll keep playing with it and let you know if I find anything..Thanks!
On Thursday 15 November 2012 16:03:06 Mr.H wrote:
> Sorry for the delay getting back to you. I've rebuilt using you new
> dns323-setup.c. I did the "tryit" for the flash and recorded the output.
> Let me know if you need anything else, I'm glad to help where I can.
>
> Please see attachment.
>
> Matt
...
> messages.txt
...
> Machine: D-Link DNS-321/323
...
> DNS-323: Identified HW revision D1
OK, so the DNS-321 is correctly identified and reported as a rev-D1 board.
> root: Board: Unknown
...
> root: Unsupported Unknown board
...
> root: Starting sysctrl: Fail.
These errors happen because the rev-D1 board is not yet correctely handled.
This is merely cosmetic, as it will be handled as a rev-C1 DNS-323.
The only place where this really matters is in the Firmware Updater page, in order to accept a DLink made DNS-321 firmware file, if the user wants to revert back to the stock firmware.
Ah, and I have to fix the Firmware Updater page in order to only accept fw files for the right hardware.
How do you want me to give you credits? Mr.H? Matt?
Thanks,
Joao
I've got a DNS-321, and purchased a 3TB drive during the Black Friday sales: To discover that the existing firmwares weren't going to be able to handle it.Any idea when the above changes are going to be incorporated into the alt-f release?
I'm OK with using it as an experimental release: I don't normally write anything to the contents of the drives in the DNS-321, I primarily use it as a media server, and have the drives set as individual disks with the contents all copied to duplicate hard drives kept offline rather then using raid 1. Worst case it bricks, and I have to replace it with newer hardware that I was going to need to do at some point anyways: I'm not going to lose data contents.I have a serial cable and a soldering iron... Can I solder? Yes, with about a 25% chance of messing up (so not perfect).
Thanks,
On Saturday, November 24, 2012 3:05:23 PM UTC, Chris wrote:I'm OK with using it as an experimental release: I don't normally write anything to the contents of the drives in the DNS-321, I primarily use it as a media server, and have the drives set as individual disks with the contents all copied to duplicate hard drives kept offline rather then using raid 1. Worst case it bricks, and I have to replace it with newer hardware that I was going to need to do at some point anyways: I'm not going to lose data contents.I have a serial cable and a soldering iron... Can I solder? Yes, with about a 25% chance of messing up (so not perfect).
Thanks,OK, I'm preparing a RC2 so that you can flash it using the box own firmware updater, so you don't need a serial port (yet, I hope).
On Nov 24, 2012 7:23 PM, "Chris" <cleac...@gmail.com> wrote:
>
> Not sure if i'm doing something incorrectly, but i've downloaded the image you created (Alt-F-0.1RC2-DNS-321.bin) and tried using the update firmware option from the Dlink to flash it.
>
> I'm currently running v1.03/ from label h/w version A2.
have you checked the circuit board rev?
When I try and send it, I get a standard error: "The uploaded file was not accepted by the DNS-321. Please return to the previous page and select a valid upgrade file."
That's probably my fault. I will check the procedure and build it again. Probably only late night or tomorrow.
> --
> You received this message because you are subscribed to the Google Groups "Alt-F" group.
> To post to this group, send email to al...@googlegroups.com.
> To unsubscribe from this group, send email to alt-f+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/alt-f?hl=en.
> To view this discussion on the web visit https://groups.google.com/d/msg/alt-f/-/eWTL7lf2rIQJ.
>
>
On Nov 24, 2012 8:14 PM, "Mr.H" <bob...@gmail.com> wrote:
>
> Hi Joao,
>
> I tried to upload this image and "Tryit". But after clicking on "Upload", it get the error "a112
yes, RC2 cant flash it. The a112 is the firmware signature, and I think that is the source if the problem, as until now it was a single numeric digit. So, probably the firmware spliter /merger is in error.
the signature is not recognized by the dlink updater, and I want to distribute a fw that will be accepted.
If might try to split and them merge a standard dlink fw file, and see if it matches the original. that is my plan.
(currently using two thumbs on a smart phone)
> --
> You received this message because you are subscribed to the Google Groups "Alt-F" group.
> To post to this group, send email to al...@googlegroups.com.
> To unsubscribe from this group, send email to alt-f+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/alt-f?hl=en.
> To view this discussion on the web visit https://groups.google.com/d/msg/alt-f/-/ScF2FqUf8tMJ.
>
>
On Nov 24, 2012 7:23 PM, "Chris" <cleac...@gmail.com> wrote:
>
> Not sure if i'm doing something incorrectly, but i've downloaded the image you created (Alt-F-0.1RC2-DNS-321.bin) and tried using the update firmware option from the Dlink to flash it.
>
> I'm currently running v1.03/ from label h/w version A2.have you checked the circuit board rev?
When I try and send it, I get a standard error: "The uploaded file was not accepted by the DNS-321. Please return to the previous page and select a valid upgrade file."
That's probably my fault. I will check the procedure and build it again. Probably only late night or tomorrow.
I reverted back to stock and flashed your RC2. I've attached the dmesg and logread. Note: I was running RC3 with 3tb disks already raided and formated (no important data on them).I'll try building the latest snapshot and report back.Thanks for all the help!Matt
On Saturday, November 24, 2012 5:48:16 PM UTC-7, Chris wrote:
I reverted back to stock and flashed your RC2.
I've attached the dmesg and logread. Note: I was running RC3 with 3tb disks already raided and formated (no important data on them).
I'll try building the latest snapshot and report back.
Thanks for all the help!Matt
On Saturday, November 24, 2012 5:48:16 PM UTC-7, Chris wrote:
I've successfully uploaded the new image you've created to the dlink, and right now it's running a disk check on the existing drives (2x2TB).
Once that completes, i'm going to make sure I can access them, and then try the RC3 snapshot. If that comes up OK, i'll replace one of the drives with a 3TB and start copying the desired contents over to it.
On Sunday, November 25, 2012 1:13:54 AM UTC, Mr.H wrote:I reverted back to stock and flashed your RC2.Great. So it worked.
--
You received this message because you are subscribed to the Google Groups "Alt-F" group.
To post to this group, send email to al...@googlegroups.com.
To unsubscribe from this group, send email to alt-f+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/alt-f?hl=en.
To view this discussion on the web visit https://groups.google.com/d/msg/alt-f/-/1zBJzhaL6-oJ.
--
You received this message because you are subscribed to the Google Groups "Alt-F" group.
To post to this group, send email to al...@googlegroups.com.
To unsubscribe from this group, send email to alt-f+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/alt-f?hl=en.
To view this discussion on the web visit https://groups.google.com/d/msg/alt-f/-/nS16N6kczDgJ.
--
You received this message because you are subscribed to the Google Groups "Alt-F" group.
To post to this group, send email to al...@googlegroups.com.
To unsubscribe from this group, send email to alt-f+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/alt-f?hl=en.
To view this discussion on the web visit https://groups.google.com/d/msg/alt-f/-/6oxDh2_F334J.
Joao,I have flashed the RC2 on my DNS-321, let the disk check run and mount my drives then did TryIt with the RC3 snapshot. Everything is working well from what I can tell so far.Only glitch I have is it looks like it is unable to read the device temperature with RC3 but was with RC2.I see this: "awk: /sys/class/hwmon/hwmon1/device/temp1_input: No such file or directory awk: cmd. line:1: Unexpected end of string cat: can't open '/sys/class/hwmon/hwmon0/device/fan1_input': No such file or directory expr: syntax error sh: °C/°F: bad number sh: °C/°F: bad number sh: °C/°F: bad number sh: bad number sh: bad number sh: bad number"
I got the same error with revision 2027.
--
You received this message because you are subscribed to the Google Groups "Alt-F" group.
To post to this group, send email to al...@googlegroups.com.
To unsubscribe from this group, send email to alt-f+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/alt-f?hl=en.
To view this discussion on the web visit https://groups.google.com/d/msg/alt-f/-/1dL0qI_QlOMJ.
New error: status.cgi: eval: line 1: D1: not found awk: cmd. line:1: Unexpected end of string status.cgi: eval: line 1: D1: not found sh: °C/°F: bad number sh: °C/°F: bad number sh: °C/°F: bad number sh: bad number sh: bad number sh: bad number
--
You received this message because you are subscribed to the Google Groups "Alt-F" group.
To post to this group, send email to al...@googlegroups.com.
To unsubscribe from this group, send email to alt-f+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/alt-f?hl=en.
To view this discussion on the web visit https://groups.google.com/d/msg/alt-f/-/QzRon1pj1u0J.
You can follow the instructions on the wiki here http://code.google.com/p/alt-f/wiki/HowToBuildFrom the sounds of it Joao is going to be releasing another snapshot soon.
On Saturday 12 January 2013 13:26:13 Mr.H wrote:
> 1. I remember looking at it when I was initially messing around and it was
> empty. I'll attach the mtd5 "dd" file.
I couldn't do anything with it, it must be empty (full of a repeating pattern of 0xff, as its 4MB was compressed to only 4KB).
> There are some optional packages that can be installed on the Dlink firmare
> (torrent client and whatnot). But I never installed them so I'm not sure if
> that is where they would go. I can go back to stock and test it if you
> would like.
>
> I agree that would be a great use of the space.
>
>
> 2. I've verified that it is correct model. I'll attach some pictures. I've
> been meaning to update that wiki with them but just haven't gotten to it
> yet. They're a little blurry, I can retake them if needed.
Yes, that's a NOR flash chip.
Unrelated and not really important:
Currently DNS-321 users don't have the chance of using the "reloaded" method, only flash Alt-F.
Do you (DNS-321 users) think that it will be advantageous to have that capability?
I'm reluctant, as "reloaded" sometimes fails without explanation, and that might discourage users from trying/flashing Alt-F...
As I don't have a DNS-321 myself, in order to test the reloaded kernel module the box has to be running the stock D-Link firmware, a ext2 disk has to be available (or does the DNS-321 supports ext3?), and a serial port available for debugging.
Anyway I enclose the needed reloaded-2.6.22.7.ko kernel module for those that want to try -- just uncompress the Alt-F-0.1RC2.tar file in the root of the disk filesystem, which creates the 'alt-f' folder (lower case), drop the attached kernel module there, make the 'fun_plug' file executable, reboot the box and watch the diagnostics in the serial port (some alt-f log files might also be created in the filesystem root).
Thanks,
Joao
PS-Again, attaching using Google Groups under a Chrome beta on linux failed. Using e-mail.
Hello,
I'm hoping that someone can help me out. Here's my scenario...
-I have a DNS-321 externally labeled version A2 (with a rev-A1 board).
-I flashed the Alt-F-0.1RC2-DNS-321.bin firmware...no issues.
-I uploaded the most recent Alt-F-0.1-snapshot-20130112.bin and hit "Try It"...reboot...no issues.
-All was good and I used the wizard to format a single Seagate 7200 3TB drive to RAID1 (degraded)...no issues.
-At this point I wanted to see if everything came-up fine after a reboot so I saved my settings and rebooted...
-After which I lost connectivity to the unit via its previous statically assigned IP address :-/
-I verified my DHCP logs and did not see any new requests...even tried a crossover cable to connect to 192.168.0.32 and 192.168.1.240-254...nothing!
-I tried to reset the unit by holding the small reset button on the back for 20seconds in hopes that that I could get access back...no luck.
-When you pressed the back button, did both the front amber leds start flashing? The first time you did it! If they did flash, do they still flash now?
If leds don't flash, then Alt-F is/was not running, and the settings was not cleared.
This is related with the only missing test: the front button, read the AboutButtonsAndLeds wiki and report back.
-When you directly connect a cable between the box and a PC, trying the 192.168.1.240-254 IP range, was the PC configured for that network? Stupid question, I know, but one has to explore everything.
-After flashing RC2 the first time, what IP did you use to access the box? The customary statically assigned IP? Or other, DHCP assigned IP?
-When you say "statically assigned IP address", do you mean a truly static IP assigned in the box, or a fixed IP supplied by DHCP and based on the box MAC? (the box MAC is incorrect under RC2)
RC2 on the 321 can't store settings, as the flash memory mappings are different from the 323. But the first flash partition, the one used to save and retrieve settings, partly overlaps, so _eventually_ it can be used...I'm almost sure that RC2 can't read settings, but there is the faint possibility that some D-Link settings (sibs.conf, which contains the box static IP) could be read. Thus the above question about the IP used right after flashing. Also, RC2 can't almost certainly clear settings, but again, there is the possibility that certain parts of the flash could be written, thus the question about the leds flashing the first time and still flashing now.
The term coined by D-Link about the back button action, "factory reset", is misleading, as it makes you believe that the settings clear is driven by hardware; it is not, there is a programs running that reacts on the button press, and if that program is not running then the settings are not cleared and the leds don't blink. That's why I always ask people to do the front button test: if leds link as expected, then Alt-F is running, and the issue is a network one.
The back button has however a more drastic action, trying to write to the flash memory, which is *wrongly* mapped. So, it can be dangerous to do it while running RC2, and is why I ask if the leds flash the first time you pressed it but not now.
Hope you get it, it's three and a half in the morning here, I'm not fully functional.
I think that the only difference between you and the other people that tried Alt-F on the 321 is that you had a static IP and that you pressed the back button under RC2.321 guys, is this assumption correct?
Thanks Matt & Joao for your replies!
I'm a little surprised that things went awry considering that the RC2 flash and RC3-snapshot "try it" completed without any issue. I'm quite comfortable using custom firmware and have done so for years on my routers (WRT54G), media front-ends (WD-LiveTV), and PS3...never ran into any major issues.
Mat, I did "nmap" the entire 192.168.0.0/24, 192.168.1.0/24, and 10.36.0.0/24 (my local LAN subnet) and didn't find any trace of an active IP that was unaccounted for. At this point I think there is an issue with the current state of my DNS321 settings preventing networking from starting (or being configured) properly. I know almost for certain that the Alt-F (RC2) firmware is running on my DNS321 as the front-button test (right-drive LED flash followed by a left-drive LED flash) is functioning as described on the DNS323 how-to-install page. Also, when I insert a formated drive containing data, I can see fsck run against the drive (long blinking drive LED).
Joao, to answer your questions...
On Jan 27, 2013 11:23 PM, "Jason Szabo" <jason...@gmail.com> wrote:
>
> Come to think of it...
>
> I will try customizing a fun_plug script to dump dmesg and some other
That will not work, Alt-F does not process such scripts.
It will process only an user specified script, but that is to be configured, and the script name is stored in flash.
But it is a good idea to have a default script name and execute it if it is found and not disabled.
Meanwhile I'm afraid that you have to assemble a serial port.
> To unsubscribe from this group and stop receiving emails from it, send an email to alt-f+un...@googlegroups.com.
> To post to this group, send email to al...@googlegroups.com.
Hi Jason,I've been working to try to get a solution for you. I've reverted back to stock and have tried to follow steps you took but have not been able to reproduce your issue. I'll keep messing around and let you know if I come up with anything.As for the fun_plug script, it looks like Alt-f doesn't execute it as the stock firmware does. I created one but it doesn't get executed.Joao,I've tested the reset button on the back. Under RC3 it looks like it wipes out the mtd0 partition. I was able to restore it by running your "loadsave_settings -rc" script. However when running RC2, the button seems to just reboot the unit. Which would make sense because it doesn't recognize any of the mtd partitions.
Thanks,Matt
To view this discussion on the web visit https://groups.google.com/d/msg/alt-f/-/RchWmH0QfhIJ.
[This message was sent as SPAM to the moderator list. After I approve it, it vanished, appearing as "This message has been deleted.". Why don't Google Groups use the same spam filters they use in Google Mail?]
On Mon, Jan 28, 2013 at 12:21 AM, Mr.H <bob...@gmail.com> wrote:Hi Jason,I've been working to try to get a solution for you. I've reverted back to stock and have tried to follow steps you took but have not been able to reproduce your issue. I'll keep messing around and let you know if I come up with anything.
On Jan 28, 2013 2:37 AM, "Mr.H" <bob...@gmail.com> wrote:
>
> Hi Joao,
>
> You bring up an interesting point. I don't know how RC2 was getting the correct IP originally but it was. Whats funny, is that ever since i did the rear button reset under RC3, RC2 will not find the static IP anymore.
but it resorts to use DHCP, right?
Even after restoring mtd0 with you script..
what do you mean?
I'm going to look into this further.
>
> Matt
>
>
> On Sunday, January 27, 2013 7:16:21 PM UTC-7, Joao Cardoso wrote:
>>
>>
>>
>> On Monday, January 28, 2013 1:58:51 AM UTC, Joao Cardoso wrote:
>>>
>>> [This message was sent as SPAM to the moderator list. After I approve it, it vanished, appearing as "This message has been deleted.". Why don't Google Groups use the same spam filters they use in Google Mail?]
>>>
>>>
>>> On Mon, Jan 28, 2013 at 12:21 AM, Mr.H <bob...@gmail.com> wrote:
>>>>
>>>> Hi Jason,
>>>>
>>>> I've been working to try to get a solution for you. I've reverted back to stock and have tried to follow steps you took but have not been able to reproduce your issue. I'll keep messing around and let you know if I come up with anything.
>>
>>
>> From the log Jason sent, RC3 is reading the box IP from flash (the "root: IP from sib.conf" line), and this means that it is using the same IP the box had under the D-Link fw (the sib.conf file is one of the D-Link files in flash, and it holds, among other things, the static box IP)
>>
>> Will RC2 be able to read that file from flash? I don't think so, but only seeing the RC2 logs, enabled under Services->User, user Configure)
>> Jason, after you flashed RC2, do you remember what IP you used to access the box?
>>
>> To reproduce all that, you have to assign a static IP under the D-Link fw(*), save settings, then continue with flashing RC2, then TryIt RC3, keep the static IP under Setup Host (you did it, right Jason?), save settings (will that succeed without clearing settings first?), and ten reboot.
>>
>> Jason, is this right?
>>
>> (*) There are two possibilities here, use as static IP the one the box currently has, not in the range of the DHCP pool, or use a static IP in the range of the DHCP pool. What was your situation Jason?
>>
>> Joao
>
> --
> You received this message because you are subscribed to the Google Groups "Alt-F" group.
> To post to this group, send email to al...@googlegroups.com.
> To unsubscribe from this group, send email to alt-f+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/alt-f?hl=en.
> To view this discussion on the web visit https://groups.google.com/d/msg/alt-f/-/-3W_HhE_Ic0J.
>
>
To unsubscribe from this group and stop receiving emails from it, send an email to alt-f+un...@googlegroups.com.
To post to this group, send email to al...@googlegroups.com.
Will RC2 be able to read that file from flash? I don't think so, but only seeing the RC2 logs, enabled under Services->User, user Configure)Jason, after you flashed RC2, do you remember what IP you used to access the box?
To reproduce all that, you have to assign a static IP under the D-Link fw(*), save settings, then continue with flashing RC2, then TryIt RC3, keep the static IP under Setup Host (you did it, right Jason?), save settings (will that succeed without clearing settings first?), and ten reboot.Jason, is this right?
(*) There are two possibilities here, use as static IP the one the box currently has, not in the range of the DHCP pool, or use a static IP in the range of the DHCP pool. What was your situation Jason?
Thanks Matt for your efforts to reproduce my issue. I was hopeful that the fun_plug script would work (didn't realize that Alt-F didn't behave in the same manner here as the stock FW...I tried it regardless and it's a no-go here as well!
On Sunday, January 27, 2013 9:16:21 PM UTC-5, Joao Cardoso wrote:Will RC2 be able to read that file from flash? I don't think so, but only seeing the RC2 logs, enabled under Services->User, user Configure)Jason, after you flashed RC2, do you remember what IP you used to access the box?After flashing RC2, I was able to access the web UI and ssh via the statically assigned IP under the DLink stock FW.
To reproduce all that, you have to assign a static IP under the D-Link fw(*), save settings, then continue with flashing RC2, then TryIt RC3, keep the static IP under Setup Host (you did it, right Jason?), save settings (will that succeed without clearing settings first?), and ten reboot.Jason, is this right?
Correct, this is the exact procedure that I followed.
(*) There are two possibilities here, use as static IP the one the box currently has, not in the range of the DHCP pool, or use a static IP in the range of the DHCP pool. What was your situation Jason?
I used the current box's static IP not in my DHCP range...all my network's static IP's are truly static outside my DHCP range. I would have thought that if a static IP could not be set for whatever reason...that one of the attempts would resort to DHCP...but I've looked at my logs and don't see any requests from the DNS321.
I'm ordering the CA-42 cable as we speak...hopefully it will arrive in the next few days...I miss my little NAS!
After flashing RC2, I was able to access the web UI and ssh via the statically assigned IP under the DLink stock FW.That is odd, because RC2 can't read the flash partition where sibs.conf is stored, and that would resort to DHCP being used, as Matt has confirmed...
If possible, please don't resurrect the box before being able to do a post-mortem analysis.
...
I don't know what your linux expertise is, but the network setup is done at boot time by the /etc/init.d/rcS script, from line 94 until line 213 Are you able to follow it?
Hi Matt, Joao,
I received a generic CA-42 cable that I ordered from dx[dot]com yesterday...it took 10days via expedited shipping from China :-)
Unfortunately, I was unable to get a serial console working and am hoping that you guys can offer some suggestions.
Here's the process I followed (thanks Matt for the wiki page)...
1. All work was done using an ESD mat and wrist-straps (as ESD as possible ;-)
2. Confirmed cable pin-out using multimeter...pin8-GND(white)...pin7-TX(green)...pin6-RX(blue)
3. Plugged-in USB end of CA-42 and confirmed voltage...RX=3.460V...TX=much lower(don't remember the exact reading)
4. Verified that USB device was detected and Prolific drivers loaded...
[1733336.113898] usb 2-1.8.3: new full-speed USB device number 103 using ehci_hcd
[1733336.223711] usbcore: registered new interface driver usbserial
[1733336.223727] USB Serial support registered for generic
[1733336.223757] usbcore: registered new interface driver usbserial_generic
[1733336.223760] usbserial: USB Serial Driver core
[1733336.224836] USB Serial support registered for pl2303
[1733336.224862] pl2303 2-1.8.3:1.0: pl2303 converter detected
[1733336.226337] usb 2-1.8.3: pl2303 converter now attached to ttyUSB0
[1733336.226357] usbcore: registered new interface driver pl2303
[1733336.226359] pl2303: Prolific PL2303 USB to serial adaptor driver
5. Connected to /dev/ttyUSB0 using kermit/screen and watched the RX voltage drop as I typed in the terminal
6. Performed loop-back test by twisting RX+TX cables together and typing in terminal...characters were echo'ed back
7. Configured ~/.kermrc as specified on wiki page Matt had posted
8. Powered-on the DNS321, connected molex connector, and plugged USB port into my Linux desktop
9. Attempted to connect to console via kermit and hit <enter> a few times...even tried the break-out code
10. Verified the voltage at the solder points on top of board to ensure the molex connector I used made proper contact and was in proper order
I am not getting any response from the DNS321...I've even tried rebooting the unit and don't see anything in the console.
The button/LED test for ALT-F still behaves as expected and I am able to reboot/power-off the unit as described on the wiki page.
The one thing I did notice, is when I have the CA-42 cable connected and the DNS321 powered-off (but with the power cord connected)...I see a bunch of garbled characters returned in the console...
<<see attached image>>
I also tried to connect to the serial console using a WindowsXP Laptop after installing the Prolific PL2303 Windows drivers.
I was still unable to get any response when attempting to connect via HyperTerm/PuTTY.
At this point, I'm not sure if I have an issue with the cable...
or my DNS321.
Any suggestions?
Good news Joao & Matt,
I took apart the USB connector and would you believe that the RX&TX wires were soldered in reverse on the adapter chip!!! That's what you get when relying on cheap knock-off cables ;-)
So, the pin-out on the phone connector was correct...and it was reversed at the USB end. Swapping the RX&TX wires gives me console...whoot!!!
Onto the issue...it looks like a problem with the mtd partitions.
As a result, the ethernet interface is not starting...
MV-643xx 10/100/1000 ethernet driver version 1.4mv643xx_eth smi: probednet eth0: port 0 with MAC address 00:00:00:00:51:81
eth0: link up, 1000 Mb/s, full duplex, flow control disabledeth0: link downeth0: link up, 1000 Mb/s, full duplex, flow control disabled
ifup: ignoring unknown interface eth0
Registered led device: power:blueRegistered led device: right:amberRegistered led device: left:amber
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
client udhcpc
mtu 1500
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.76
netmask 255.255.255.0
broadcast 192.168.1.255
mtu 1500
gateway 192.168.1.254
The MAC is wrong, but it also occurs with others.
The difference is that in other logs:eth0: link up, 1000 Mb/s, full duplex, flow control disabledeth0: link downeth0: link up, 1000 Mb/s, full duplex, flow control disabledwhile in yours it fails:ifup: ignoring unknown interface eth0
Another difference is in others logs the leds are registeredRegistered led device: power:blueRegistered led device: right:amberRegistered led device: left:amberwhile in your log they are not.
You have no disks, while others have, that explains other differences.You sent a console dump, while other logs are the results of the dmesg and logread commands obtained after boot.
Back to eth0.eth0 is setup in different ways depending on several circumstances.
Perhaps one of the major issues is the missing /Alt-F dir or link...
/ # aufs.sh -n
/Alt-F does not exist or is not a symbolic link, exiting.
...and all the changes are lost after reboot.
`loadsave_settings -rs` reads sib.conf, that is a D-Link file that contains network related parameters when the box is assigned a static IP.
That is the difference between you and other testes, I think: you had a static IP configured under D-Link, others had DHCP.I'm right?
When you was under RC3 and saved settings, you didn't clear settings before saving settings, right? Any error when saving settings?
What I think that is happening, is that 'loadsave_settings -lf' returns success but in effect it fails.The "tar: short read " error indicates this failure (settings are stored in a compressed tar archive), while the the "IP from flash-defaults" message means that no_defaults = 0, which is set by 'loadsave_settings -lf' on success.In this situation, rcS assumes that configuration files where correctly read and does an 'ifup eth0' that fails because, by hazard, /etc/network/interfaces does not has the eth0 stanza defined (it is shipped with only lo0 defined, the eth0 one is created by rcS).
So, what is the output of::loadsave_settings -lfno_defaults=$?echo no_defaults=$no_defaultsIt should print a no_defaults=1, because reading fails (the tar error, and the incomplete 'interface' file)
Why does 'loadsave_settings -lf' fails and `loadsave_settings -rs` don't? Because sib.conf is stored at the flash "start", it is still readable, while Alt-F settings file is stored at the flash end, not accessible (at least not totally) under RC2.I have to continue this tomorrow, please wait a little more before restoring the box to life, I need to diagnose why loadsave_settings is returning success (if I'm right, which I'm, of course ;-)
On Thursday, February 7, 2013 11:40:00 PM UTC-5, Joao Cardoso wrote:`loadsave_settings -rs` reads sib.conf, that is a D-Link file that contains network related parameters when the box is assigned a static IP.That is the difference between you and other testes, I think: you had a static IP configured under D-Link, others had DHCP.I'm right?
Correct, I had a static IP assigned under the stock D-Link FW.When you was under RC3 and saved settings, you didn't clear settings before saving settings, right? Any error when saving settings?
Nope, I did not clear the settings prior to saving them...
and did not notice any errors when saving.
I did try to save settings under RC2 but received a "no flash space available" error.
What I think that is happening, is that 'loadsave_settings -lf' returns success but in effect it fails.The "tar: short read " error indicates this failure (settings are stored in a compressed tar archive), while the the "IP from flash-defaults" message means that no_defaults = 0, which is set by 'loadsave_settings -lf' on success.In this situation, rcS assumes that configuration files where correctly read and does an 'ifup eth0' that fails because, by hazard, /etc/network/interfaces does not has the eth0 stanza defined (it is shipped with only lo0 defined, the eth0 one is created by rcS).
This makes sense.So, what is the output of::loadsave_settings -lfno_defaults=$?echo no_defaults=$no_defaultsIt should print a no_defaults=1, because reading fails (the tar error, and the incomplete 'interface' file)You are correct...no_defaults=1
rm /etc/network/interfaces
loadsave_settings -lf
cat /etc/network/interfaces
Why does 'loadsave_settings -lf' fails and `loadsave_settings -rs` don't? Because sib.conf is stored at the flash "start", it is still readable, while Alt-F settings file is stored at the flash end, not accessible (at least not totally) under RC2.I have to continue this tomorrow, please wait a little more before restoring the box to life, I need to diagnose why loadsave_settings is returning success (if I'm right, which I'm, of course ;-)
After manually setting the network configuration, I was able to login to the webUI and "try it" for RC3 again. All my previous settings were restored...
but on reboot to RC2, I face the same issue.
Also, I'm just curious...but if I wanted to change settings for RC2 then I would have to go back to the DLink stock FW...make my changes and re-flash RC2?
Thanks,
Jay
So loadsave_settings is working OK.But then I'm puzzled, because in this situation the "root: IP from flash-defaults" message should not appears.One last try, then you can try to recover the box following the indications I give bellow.After a reboot into RC2, and before setting up network or changing anything else:
rm /etc/network/interfaces
loadsave_settings -lf
cat /etc/network/interfacesDoes it has the eth0 stanza?
I will need also a set of settings, please do (not marking as code because GG stores hidden chars in it. Luckily I tested the script!)mkdir /tmp/foomount -o ro /dev/mtdblock0 /tmp/foooldest=$(cd /tmp/foo && ls -t set* | tail -1) # the oldest set_ file, probably ther one that causes problemscp /tmp/foo/$oldest /tmpumount /tmp/footar -C /tmp/foo -xzf /tmp/$oldest # you should have errors like "tar: short read". If you don't, please say sorm -f /tmp/foo/etc/web-secret /tmp/foo/etc/rsyncd.secrets /tmp/foo/etc/samba/credentials* /etc/msmtprc # contains sensitive infotar -C /tmp/foo -czf foo.tgz .rm -rf /tmp/fooNow transfer the foo.tgz to your desktop and open it, look for other sensitive information and post it.
On Friday, February 8, 2013 12:50:58 PM UTC-5, Joao Cardoso wrote:So loadsave_settings is working OK.But then I'm puzzled, because in this situation the "root: IP from flash-defaults" message should not appears.One last try, then you can try to recover the box following the indications I give bellow.After a reboot into RC2, and before setting up network or changing anything else:
rm /etc/network/interfaces
loadsave_settings -lf
cat /etc/network/interfacesDoes it has the eth0 stanza?
Yes, this procedure now shows the eth0 stanza in /etc/network/interfaces
I will need also a set of settings, please do (not marking as code because GG stores hidden chars in it. Luckily I tested the script!)mkdir /tmp/foomount -o ro /dev/mtdblock0 /tmp/foooldest=$(cd /tmp/foo && ls -t set* | tail -1) # the oldest set_ file, probably ther one that causes problemscp /tmp/foo/$oldest /tmpumount /tmp/footar -C /tmp/foo -xzf /tmp/$oldest # you should have errors like "tar: short read". If you don't, please say sorm -f /tmp/foo/etc/web-secret /tmp/foo/etc/rsyncd.secrets /tmp/foo/etc/samba/credentials* /etc/msmtprc # contains sensitive infotar -C /tmp/foo -czf foo.tgz .rm -rf /tmp/fooNow transfer the foo.tgz to your desktop and open it, look for other sensitive information and post it.
Crap, I think I messed-up last night :-/ While I was playing around in the WebUI in RC3...I tried "Clear Settings" thinking that it would clear my current configuration...not remove the saved configuration archives!!! Looks like I inadvertently removed all saved settings as /dev/mtdblock0 is empty. Is there by chance a backup location for these saved setting?
This is likely why loadsave_settings was working OK when I sent you the output of no_defaults=1 yesterday...and why now removing /etc/network/interfaces and `loadsave_settings -lf` correctly restores the eth0 stanza.
My apologies, I did not fully understand the workings of how Alt-F stored and read theses settings.
If there is no backup of the saved settings, I can try to reproduce the issue...but likely my situation was a transient one depending on the fragmentation of flash and where saved settings were written at the time.
Let me know as I will wait to hear back before restoring my box.
Well, if eth0 didn't go up in RC2 after a reboot without settings, then my proposal will not work, as my proposal is just to clear settings in RC3 :-(Without any settings, RC2 should ask for a DHCP IP lease:# get an ip using the following priority:# 1st, use kernel cmd line ip= (kexec or fonz reloaded)# 2nd, use defaults stored in flash# 3d, try to read vendor sib.conf# 4th, try to use a dhcp server# 5th, find and use a non-used ip address from 192.168.1.254 to 230 rangeWithout any settings 4 and then 5 would be tried.If you are in that situation now, no settings at all and eth0 did not automatically setup, can you please post the RC2 reboot logs, together with 'ifconfig' and /etc/network/interfaces?
On Friday, February 8, 2013 2:12:27 PM UTC-5, Joao Cardoso wrote:Well, if eth0 didn't go up in RC2 after a reboot without settings, then my proposal will not work, as my proposal is just to clear settings in RC3 :-(Without any settings, RC2 should ask for a DHCP IP lease:# get an ip using the following priority:# 1st, use kernel cmd line ip= (kexec or fonz reloaded)# 2nd, use defaults stored in flash# 3d, try to read vendor sib.conf# 4th, try to use a dhcp server# 5th, find and use a non-used ip address from 192.168.1.254 to 230 rangeWithout any settings 4 and then 5 would be tried.If you are in that situation now, no settings at all and eth0 did not automatically setup, can you please post the RC2 reboot logs, together with 'ifconfig' and /etc/network/interfaces?
Nope not anymore, I just didn't notice that DHCP had kicked-in as I was using the serial console. Looks like after clearing the settings, eth0 comes-up again in RC2 via DHCP.
In your opinion, is there any value in me flashing back to stock D-Link FW and trying to reproduce the issue?
Could it have been some settings in the stock FW that spawned this incident?
How are settings stored and read in the stock FW?
If not, then I suspect that the root cause of this issue was where settings were saved in flash under RC3.
Thanks Joao
Nope not anymore, I just didn't notice that DHCP had kicked-in as I was using the serial console. Looks like after clearing the settings, eth0 comes-up again in RC2 via DHCP.OK, fine. Everything is fine when The End is OK, as Hollywood used to say :-)
Could it have been some settings in the stock FW that spawned this incident?I think that the culprit was to not clear settings under RC3 before saving settings.
How are settings stored and read in the stock FW?As plain files, but how/when I don't know. Nor how does the backup in mtd1 works.That's why I wrote Alt-F, give thanks to D-Link for their half a dozen proprietary closed source binaries. As if there are any significant trade secrets in them :-o
If not, then I suspect that the root cause of this issue was where settings were saved in flash under RC3.I rewrote the README in sourceforge, do you mind reading it and comment if necessary?
I think I may have messed up :(
Flashed "tryit" with the 323 RC3.
You didn't yet answer my questions.I have to assume things, and assuming wrongly can have nasty consequences.
What I *think* that you have done, in this sequence:1-Flashed, using the vendor's fw, an experimental RC2 made for the 321
2-Loaded Alt-F-0.1RC3-DNS-321.bin, tryed FlashIt or TryIt and got the message "a112 Does not seems to be a firmware file for the DNS323 nor the CH3SNAS"
3-Loaded Alt-F-0.1RC3-DNS-323.bin and used TryIt (NOT FlashIt)
4-Couldn't connect to the box
5-didn't try the front-button test to see if Alt-F was running (read the about buttons and leds wiki)
6-your router didn't show a new IP assigned
7-power cycle the box and RC2 reappeared
Comments:
2- "a112 Does not seems to be a firmware file for the..." is the expected result, the 321 fw is not accepted by RC2.
3-it should run OK, this is the correct way of doing things. You was NOT flashing, you was TRYING it.After having RC3 running in TryIt mode, you could flash RC3. DON'T USE RC2 to flash the 321!
5-pitty, this is the first test to do, as has been said ad-nauseam in this forum
6-was you even using DHCP in the box? You could also try to do a direct cable connection to a computer, no DHCP server in the computer, setting the computer IP to 192.168.1.100, the box assigns itself 192.168.1.254 if not configured for a static IP. This could be done if 5 didn't work
7-expected, as you was TRYING RC3
What has also been said ad-nauseam in this forum is to try a back-button (recessed reset) button. This wouldn't work with the experimental RC2, but should work with RC3, if 5 above works.An explanation: all released RC3*.bin files have identical contents, only their signatures are different.This is needed to make the vendor's firmware accept the file; once flashed, Alt-F will accept its own signature and the vendor's signature files.As RC2 has no 321 support, it does not accepts its fw files, but RC3 will accept fw files made for the 321 and 323 (and its Conceptronics and Fujitsu-Siemens "variants")Owners of a 321 box with the vendor's firmware should use the Alt-F-0.1RC3-DNS-321.bin directly, without any further steps.Your situation is different because you are running an experimental RC2.Now: I'm violating the rule “The quality of the answer is directly proportional to the amount of work you put into the question”.I spent some 20 minutes assuming, thinking and writing all this, reviewing it twice, please do the same when replying.
on my current RC2 build.Once I confirm that I can connect to the NAS using that firmware and it is operating correctly I then need to flash using FLASHIT mode.My question is, do I use the same Alt-F-0.1RC3-DNS-323.bin again for FLASHIT or a different version?