So I flashed Alt-F to a DNS-321... :)

[Mr.H]

Hi all, first off I want to say Alt-F is a great piece of work! I've been jealous for quite some time because I have a DNS-321 (not a 323) and haven't been able to run it. After a while I thought I'd look into what it would take to adapt Alt-F to the 321...

So one night I decided to hook up a serial port, boot to U-boot and send over the Alt-F kernel. It seemed to come up just fine (with one exception that I didn't notice at first), so I decided to send the kernel and initrd to flash. Everything booted, and the web page loaded! Then I realized that I was unable to save any changes... I looked a little harder at the dmesg output and noticed the flash was not being correctly identified. As far as I can tell its only detecting 8mb and not the 16mb available thus not identifying the partitions like it should.

I've downloaded the source and successfully built it (revision 1924). I've been playing with the kernel config using the "make O=$BLDDIR linux26-menuconfig" command. I've tried some different settings but cannot seem to get the unit to detect the size properly. As far as my Linux experience goes I'm still learning, but I know enough to get myself into trouble :). So I was hoping someone here could help me out. 

I've attached the two dmesg logs. Here is the one section of the Alt-F dmesg that has me concerned:

physmap platform flash device: 00800000 at f4000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank
NOR chip too large to fit in mapping. Attempting to cope...
Amd/Fujitsu Extended Query Table at 0x0040
Using buffer write method
number of CFI chips: 1
Reducing visibility of 16384KiB chip to 8192KiB
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition information
Creating 5 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000010000 : "MTD1"
mtd: partition "MTD1" doesn't end on an erase block -- force read-only
0x000000010000-0x000000020000 : "MTD2"
mtd: partition "MTD2" doesn't start on an erase block boundary -- force read-only
0x000000020000-0x0000001a0000 : "Linux Kernel"
0x0000001a0000-0x0000007d0000 : "File System"
mtd: partition "File System" doesn't end on an erase block -- force read-only
0x0000007d0000-0x000000800000 : "u-boot"
mtd: partition "u-boot" doesn't start on an erase block boundary -- force read-only

Does anyone have an idea why this might be? Do any of the dns323 boxes have a 16mb flash chip?

Any help would be greatly appreciated!

Also as a side note, I've created a wiki page over at DNS323Wiki with some more information on the hardware/dmesg/etc. Still a work in progress... http://dns323.kood.org/dns-321

-Matt

[Joao Cardoso]

Good (and intrepid) job!

 

The dns323 hardware specifics can be found on

$BLDDIR/project_build_arm/dns323/linux-2.6.35.14/arch/arm/mach-orion5x/dns323-setup.c

I attach a substitute that should solve the flash partitioning issue, just replace the original dns323-setup.c with the attached one and rebuild the kernel. I have not done it!

You don't need to flash the new firmware again: if you are now running Alt-F you can produce a new firmware .bin file and use the "TryIt" button in the Firmware Updater (System->Firmware). Or you can just 'scp $BINARIES/zImage $BINARIES/rootfs.arm.cpio-sq.lzma root@nas:', (where BINARIES=$BLDDIR/binaries/dns323) and 'reboot'.

The changes are based on the dmesg output from the stock firmware, I have double check the changes, perhaps you should triple check them.

You might notice that in the stock firmware the flash partitions are not in ascending starting address order, mtd4 might be exchanged with mtd5, you have to check if the stock firmware mtdblock4/5 sizes and start addresses are the same as in the replacement (at run time).

You might also notice that the box MAC address is not recognized, look at dns323-setup.c:dns323_read_mac_addr() you have to search in the uboot flash partition (mtd4 or mtd5?) for the box real MAC address pattern (you know it, you have removed it from the stock dmesg output).

There are a lot of other things to grasp: are leds and buttons working? reboot/poweroff? Fan? temperature? (this must be OK) Disks? (was disks plugged? they don't seem to be detected)

Thanks and luck

Joao

[Mr.H]

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! I didn't have a HDD in the unit when I captured the last dmesg, that’s why one didn't show up. I've attached a new dmesg if it helps.

Thanks!

-Matt

[Joao Cardoso]

On Thursday, November 1, 2012 8:27:44 PM UTC, Mr.H wrote:

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?

Yes. Try replacing

mac_page = ioremap(DNS321_NOR_BOOT_BASE + 0x7d0000 + 196480, 1024);

with

mac_page = ioremap(DNS321_NOR_BOOT_BASE + 0x00f80000 + 0x0007ff80, 1024);

 

As far as everything else. LEDs, Poweroff, Reboot, Temp, and HDD detection are all working great!

What about the fan?

What does 

   cat /sys/class/hwmon/hwmon1/device/name

displays? To display the current fan speed, do

   cat /sys/class/hwmon/hwmon1/device/fan1_input

and

   echo <num> >  /sys/class/hwmon/hwmon1/device/pwm1

control the speed. Depending what fan controller is used, <num> can be a number between 0 and 255. Use low numbers, to not blowup the fan.

Now I only need to detect if the box is a 323 or a 321 and set the appropriate flash mappings. I think the best is to try to detect if the flash is a 8MB (DNS-323) or 16MB chip (DNS-321), but I don't (yet) know how to detect it.

By the way, for completeness and future reference, what hardware revision board is your DNS-321? 

Thanks,

Joao

[Mr.H]

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.

[Joao Cardoso]

On Friday, November 2, 2012 1:15:59 AM UTC, Mr.H wrote:

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.

Can't you turn it off? Using '0', perhaps?

 

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".

Damn! Of course it is a rev-A1 board, but most users will only see the outer label.

 

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?

We have to rely on hardware differences to distinguish one box from the other -- CPU type, amount of memory, temperature sensor, fan controller... so far the 321 seems to have the same exact characteristics of a 323-rev-C1 board (except from the flash memory capacity, but that is the issue).

Is everything still working as expected? Nothing new? Nothing missing?

 

I would love to make Alt-F DNS-321 ready.

Thanks for all your help! Let me know if there is anything you would like me to test out.

Thanks you for trying it!

 

[Mr.H]

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!

[Joao Cardoso]

On Thursday, November 8, 2012 6:03:56 PM UTC, Mr.H wrote:

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!

Can you please try the attached dns323-setup.c? ($BLDDIR/project_build_arm/dns323/linux-2.6.35.14/arch/arm/mach-orion5x)

It should identify the DNS-321 as a DNS323 rev-D1. Probably some things will not work OK, as Alt-F only deals with rev-A1/B1/C1 boards.

This is just a quick hack to identify the 321, if it works I will adjust Alt-F to deal with it as if a 323-rev-C1.

Thanks

[Mr.H]

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

[Joao Cardoso (Alt-F)]

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

 

[Mr.H]

Hi Joao,

Matt Hayden works. No need to give credit though... Just trying to help out. Thanks!

Matt

[Chris]

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?

[Joao Cardoso]

On Saturday, November 24, 2012 12:18:48 PM UTC, Chris wrote:

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?

Soon I will made an experimental release for the DNS-321.

But there are some risks involved, as I don't have a 321 for testing myself.

Matt had a serial cable, and could it as a last resort, in case something went wrong. Of course you can also buy a serial cable if something wrong happens, how are your soldering capabilities?

But I'm pretty confident that there will be no problems.

If you intend to use the experimental release for the 321, please let me know beforehand, as I'm interested in the results (and also with the 3TB disk results).

Joao

[Chris]

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,

Chris

[Joao Cardoso]

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).

One more "detail".

You might have noticed that Matt has a DNS-321 that is labeled in the exterior case, at the box bottom, as a rev-A2 board, but the hardware board in the box inside says it is a rev-A1 board:

    Matt said: Hardware version: the sticker on the outside of the unit says "H/w ver. A2" however the motherboard on the inside shows "Rev-A1".

What is your case? Please report what both the box outside label and the inside hardware board labels says. You have to open your box.

 

Thanks,

Joao

[Joao Cardoso]

On Saturday, November 24, 2012 5:59:16 PM UTC, Joao Cardoso wrote:

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).

It's now available at sourceforge. Read its README.txt! You have been warned!

It is a plain RC2, not able to be used with 3TB disks except if you are a linux command line expert.

Even if you are, I would appreciate if you would try the last RC3 snapshot after flashing RC2.

You should NOT flash the snapshot, instead you have to TryIt. You have been warned! Again, read its README.txt file and follow the discussion 

 

The main thing to be tested with the RC3 snapshoot is the Disk Partitioner, as Gaiko has already successfully tested the Disk Wizard.

Please report any RC3 snapshot results under its own thread.

Welcome to Alt-F Bleeding Edge :-)

[Chris]

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. 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."

It's been awhile since I tried hacking this thing, but I do remember gaining telnet access to it around when I purchased it. Is there something different I should be doing to attempt flashing?

[Mr.H]

Hi Joao,

I tried to upload this image and "Tryit". But after clicking on "Upload", it get the error "a112 Does not seems to be a firmware file for the DNS323 nor the CH3SNAS." I can split the firmware, send it via serial and try it that way if you'd like..

Chris,

I would hold off on flashing this at this point, at least until I can test it and make sure that everything comes up ok.. Unless you're willing to make a serial cable. I'll be available today to try it.

Thanks,

Matt

[Chris]

I think i'll pass on wiring a serial cable for now. I'm already thrilled that there's still active development, and there's good odds i'm going to be able to use 3TB drives with it in the near future.

[Joao Cardoso]

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.
>  
>  

[Joao Cardoso]

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.
>  
>  

[Joao Cardoso]

On Saturday, November 24, 2012 8:06:04 PM UTC, Joao Cardoso wrote:

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.

Yes, it was my fault.

I have rebuild the fw and downloaded it to sourceforge, under the same name (beware of browser cache effects!)

It happens that the 321 uses a firmware file with a signature of "Chopper", while the 323 uses "FrodoII", and I created the fw for the 321 as "FrodoII".

I have to fix the fw spliter/merger program, 'dns323-fw'.

Remember:

-the Alt-F-0.1RC2-DNS-321.bin is a plain RC2

--your box will be reported as a 323 rev-C1

-- it will not allow formatting 3TB disks (but you can use them if already formatted)

-- it will not allow flashing the D-Link 321 firmware back

-- you can use it to TRY (NOT flash) the latest RC3 snapshot

-- with the latest RC3 you will be able to

---format 3TB disks

---flash back the 321 D-Link fw. 

Please keep reporting back. I'm specially interested to know:

-your box and board hardware revision level (box bottom label, and inner circuit board rev)

-with the RC3 snapshot

--your box will be reported as a 321/323 rev-D1 hardware

--flashing back the D-Link fw works (ah, you can't, for security I have disable the Flash button)

--if the Disk Partitioner is able to partition 3TB disks

--post, attaching, not inline, the 'dmesg' and 'logread' command line output.

--report any oddity regarding the hardware, such as fan, temperature, buttons, leds...

Thanks

Joao

 

[Chris]

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.

Big Thanks (To both Joao and Matt)! Alt-F has made my 3yr old DNS-321 new again!

Chris

[Mr.H]

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

[Mr.H]

I guess it helps to actually attach the files :).. 

On Saturday, November 24, 2012 6:13:54 PM UTC-7, Mr.H 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:

[Joao Cardoso]

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.

 

I've attached the dmesg and logread. Note: I was running RC3 with 3tb disks already raided and formated (no important data on them). 

Good. Can you try the Disk Partitioner? You will loose the data, but you already know that. Chris could do that, I think he still has empty disks.

I will examine the attached logs tomorrow.

Shall a create a sub-forum, "The Bleeding Edge"? :-€ (did I create a new emoticon?)

I'll try building the latest snapshot and report back. 

The changes are not yet in SVN, so you will not be able to build the RC3 snapshot as it is distributed.

I don't commit often, I only commit when things are "stable".

And I get bored of working only on one subject, so there are several things in state of flux, not finished.

No, I'm not 18, pity on me :-)

Thanks and Sorry,

Joao

 

Thanks for all the help!

Matt

On Saturday, November 24, 2012 5:48:16 PM UTC-7, Chris wrote:

[Joao Cardoso]

On Sunday, November 25, 2012 12:48:16 AM UTC, 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).

Excellent!

 

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.

Please, before copying useful data to them, answer my previous post requests.

Thanks

Joao

[Joao Cardoso]

On Sunday, November 25, 2012 1:52:36 AM UTC, Joao Cardoso wrote:

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.

Hmmm, you was better as you was before, with your own build.

This is because Alt-F-0.1RC2-DNS-321.bin is a plain RC2 (released in Fev 2, 2012) just repacked to be able to be accepted by the D-Link firmware updater.

Thus, it has none of the fixes that we both worked on, as you might have noticed from the logs. 

Only the RC3 snapshot has such changes (and they are not yet on SVN).

So, and this is also for Chris, you shouldn't be able to save settings, and you shouldn't use it for flashing, as the flash partition table is incorrect.

Only the RC3 snapshot is built for the 321/323, but it can't be used to flash anything, as I have disabled  the Firmware Updater ability to flash.

And the RC3 snapshot should not be flashed nor used for flashing because there are unfinished changes made in the way how Alt-F root filesystem runs and how Alt-F will boot. For RC3 the root filesystem will run directly from flash, saving 6.5MB of RAM (not so small as it looks, it is 10% of the total).

This is a nightmare (three in the morning here), and I don't want to further turn it into Elm Street.

So, in the next days I will concentrate myself in finishing the new rootfs/boot stuff.

Matt, I advise you to either re-flash your own build with our changes or run the RC3 snapshot.

Chris, you should only use (TryIt, not FlashIt) the RC3 snapshot.

And it is on the RC3 snapshot that I need feedback (dmesg and logread), RC2 is history!

Welcome to Elm Street,

Joao,

PS-But, hey, it worked! DNS-321 normal users can now use Alt-F, as long as they use the RC3 snapshoot in the TryIt mode.

[Matt Hayden]

Hi Joao,

I've noticed the same thing. I'm working on a flash that Chris (and any onlookers) can use if the happened to flash the above. This will help him to get to the newest RC3 with the modifications already mentioned before.. I might need your help with getting the file accepted with the firmware updater though... get some sleep, tomorrow is a new day ;)

Matt

--
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.
 
 

[Chris]

I keep on getting an error when I try attaching the log files, however:

Firmware (RC2) was uploaded to existing DNS-321 with two 2x2tb drives (individual drives, ext2 not raid). The DNS-321 is hardware revision A2 (from the label).

I will take it apart tomorrow and check the circuit board.

It took quite awhile, but eventually fsck completed on both drives, and they were both mounted with the existing data visible (from telnet)

From services/smb, I renamed the drives and made them available through smb.

The existing data on both drives is now accessible from other systems.

[Chris]

[Matt Hayden]

Hi Chris,

Make sure you add an extension to the filename before you upload, (.txt).

We've identified some problems with the version you have flashed. We are going to work on a solution.. Hang tight and we should have a fix for you soon.. 

Thanks,

Matt

--

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.
 
 

[Chris]

OK, I think (hope) this would be the logs that Joao is interested in. I'm using (tryit) the RC3 test firmware. I've deleted/created partitions on a 3TB drive using both the wizard and the partition tool. It is a DNS-321/ A2 from the label. I wasn't able to get the cover off to see if there was any difference on the circuit board.

Thanks,

Chris

[Mr.H]

O good, you got it built. It looks like your flash and MAC are being correctly identified now. It looks good to me!

Matt

[Joao Sousa Cardoso]

On Sunday 25 November 2012 10:00:25 Chris wrote:
> OK, I think (hope) this would be the logs that Joao is interested in.

Yes, thanks.

The alt-f.log has all I need, including dmesg, logread, and many other system
status. Good you sent it.
You can disable it in Services->User->user, and generate a new log hitting the
StartNow button (but some diagnostics can only be captured at boot time, so it
must be "Boot Enabled" in that case)

Everything looks fine, except for some odd messages regarding the disks
partition tables and filesystems, but I assume that you was setting them up.

The next time you reboot examine the logs (System->Utilities->View Logs) to
see if there is something strange (like "sda? unknown partition table").

Now you can save settings. Remember to do it whenever you change some
settings. The system warns you in red, you can click the warning and go
straigh to the settings page.

Remember, you *have to* use the RC3 snapshoot in order to use the saved
settings. Upon reboot you have to load the RC3 snapshoot and TryIt again.
Always.

> I'm
> using (tryit) the RC3 test firmware. I've deleted/created partitions on a
> 3TB drive using both the wizard and the partition tool.

No issues? In none of the pages? No odd messages, such as "fdisk: device has
more than 2^32 sectors, can't use all of them"? Did they perform their jobs
right?

> It is a DNS-321/ A2
> from the label. I wasn't able to get the cover off to see if there was any
> difference on the circuit board.

Probably a rev-A1 board, as Matt box. When you have the opportunity... :-)

> Thanks,
>
> Chris

Everything looks right, nothing to fix, I will start commiting the changes.

Alt-F next port will be for the DNS-325, I have a brand new one. I only don't
know when...

Thanks Chris, and enjoy your new box.
Joao

[Drew Pfister]

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"

Not an issue for me, but just wanted to give you a heads up, and help with any testing you may need. 

[Matt Hayden]

Hey Drew,

Whats your HW ver? Also what version did you build?

-Matt

--
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.
 
 

[Mr.H]

Hey Joao,

I'm at a point where i can just send you my unit for testing, if it will help out :). I don't have any info on it and won't need it for another couple months... Its a dns321 with a ready made serial cable (obviously). Also it's loaded with 3tb disks, so you can test all your new innovations! :)

Just let me know where you are and it will be on its way to you.. I got the shipping ;)

Thanks for all your help!

Matt

[Drew Pfister]

Hardware A2

Flashed: Alt-F-0.1RC2-DNS-321

TryIt snapshot: Alt-F-0.1-snapshot-20121124

[Mr.H]

I got the same error with revision 2027.

[Joao Cardoso]

On Monday, December 31, 2012 4:31:38 AM UTC, Drew Pfister wrote:

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"

Thanks, I now have that fixed in SVN.

I will make a new RC3 snapshot soon

[Joao Cardoso]

On Monday, December 31, 2012 11:31:45 PM UTC, Mr.H wrote:

I got the same error with revision 2027.

Can you please try it now? commit 2028 should have it fixed.

 

[Mr.H]

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

[Lando Siregar]

same with C1
status.cgi: eval: line 1: C1: not found awk: cmd. line:1: Unexpected end of string status.cgi: eval: line 8: C1: 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/-/1dL0qI_QlOMJ.
 
 

--
ZerO13th

[Joao Cardoso]

On Wednesday, January 2, 2013 12:26:04 AM UTC, Mr.H wrote:

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

Sloppy coding. Now hopefully fixed, please try again (no need to create a brand new firmware, just copy the new status.cgi to /usr/www/cgi-bin)

Thanks,

Joao

[Mr.H]

Joao,

This is fixed now. Also it shows the device as a DNS-321 Rev-A1 on the status page. Nice!

Thanks,

Matt

[Drew Pfister]

How are you building a new snapshot?

Can you teach me how or link me to the new fixed one?

[Matt Hayden]

You can follow the instructions on the wiki here http://code.google.com/p/alt-f/wiki/HowToBuild 

From the sounds of it Joao is going to be releasing another snapshot soon. So it might just be worth it to wait if the above isn't an option. 

I could sent you the image I have, but I would be worried about any unforeseen consequences.. I wouldn't want you to brick your box.

Thanks,

Matt  

--

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.
 
 

[Drew Pfister]

Anyway you could build it and post it here?

Also, how close are we to having the RC3 firmware ready to flash permanently?

[Joao Cardoso]

On Thursday, January 3, 2013 1:00:13 AM UTC, Mr.H wrote:

You can follow the instructions on the wiki here http://code.google.com/p/alt-f/wiki/HowToBuild 

From the sounds of it Joao is going to be releasing another snapshot soon.

Available now.

1-Matt, do you know what does D-Link store in the mtd5 flash partition? The one named "Module"? 

Could it be that D-Link stores there some "add-ons"?

Can you 'dd' it and attach or publish the dd resulting file?

I was thinking in using it to store some packages, instead of using disk. This way some of the more popular packages would be resident in flash from the very beginning.

Perhaps transmission and/or minidlna, or avahi/netatalk?

2-Also, do you mind opening your box and trying to locate the flash chip? The wiki at http://dns323.kood.org/dns-321 says it is a "16 MB Micron M29W128GH", so one of the larger chips must have a 'M29W128GH' or similar label.

I have to be sure what it is (a NOR flash, not a NAND flash), because in the future I intend to run the Alt-F root filesystem directly from flash (kind of XIP), and that is only possible when using the NOR flash technology. That will save some 6.5MB of main RAM.

Thanks,

Joao

[Mr.H]

1. I remember looking at it when I was initially messing around and it was empty. I'll attach the mtd5 "dd" file. 

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.

Thanks for all your help!

Matt

[Joao Cardoso (Alt-F)]

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.

 

[Jason Szabo]

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.

At this point I will likely have to make a serial cable to see what's going on unless someone can suggest something else...please!

I found this page (http://dns323.kood.org/hardware%3Aserial) but I am not sure I have all the required parts. On hand, I have a standard null-modem serial cable and a USB-to-Serial adapter (generic labeled CP-US-03). What I am uncertain about is if I require a "level shifter" if I am using this USB-to-Serial dongle?

Thanks guys!

[Mr.H]

Hi Jason,

I'm not sure what would have happened to cause the unit to lose its ip... Maybe try scanning the subnet for it with nmap or angry IP scanner?

As for the serial cable. I used the instructions here and built it with a nokia ca-42 cable. You can get them on eBay pretty cheap. The pin out on the motherboard for the 321 is the same as the 323 mentioned here.

Matt 

[Joao Cardoso]

On Saturday, January 26, 2013 10:47:46 PM UTC, Jason Szabo wrote:

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.

You tested most things I could think of, but I still have some questions:

-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?

Joao

[Mr.H]

Hey Joao,

Thanks for all your input! When it comes to the back button I have not tested it at all. So i'm unsure of what it does even with the most current snapshot, let alone RC2. You do make a good point that if the IP is changed while in RC2 (or RC3) its still unknown if the change will stick. So if you did change it, maybe try the IP address it originally had.. 

Jason, if you can let me know if/how you had changed the IP, I can revert back to stock and try to simulate the actions you took... Maybe it could help shed some light on what happened.

Thanks,

Matt

[Jason Szabo]

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...

-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.

 

Yes, both LEDs flashed while I held-down the back-reset button and stopped after the unit rebooted and came-back-up...they are currently not flashing.
 

This is related with the only missing test: the front button, read the AboutButtonsAndLeds wiki and report back.

As stated above, the front-button test behaves as described on the wiki.
 

-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.

A valid question, but unfortunately, yes the PC was configured for the appropriate network (I've tried again to make sure).
 

-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?

I've always used 10.36.0.200 as a static IP for my DNS321. After flashing RC2, I was able to connect with this IP which was assigned under the stock DLink v1.03 firmware.
 

-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)

Correct, by static I mean truly static assigned in the web UI of the DLink stock firmware.

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.

I noticed that RC2 could not save any settings...I tried this prior to RC3 "try it" and I got an error relating to insufficient flash memory space to save the settings. So, I just went ahead and tried the RC3 snapshot.

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.

I'm almost certain that Alt-F RC2 is running as explained at the top of this post.

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.

Correct, this was the case...and I only tried this as a last resort as I suspected that this could be dangerous.

Hope you get it, it's three and a half in the morning here, I'm not fully functional.

I've beaten my head over this issue for hours and need to sleep on it as this usually yields positive results ;-) I will likely have to source some parts to make a serial cable compatible with my DNS321...but I have no issues with soldering or modifying cables. I was hoping that I could just use a CP-US-03 USB-to-Serial adapter straight to the connector on the DNS321 board...but I need to test the lines with a volt meter to ensure I am not exceeding the 3.3V max (don't want to fry the CPU)!
 

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?

Very likely, but the issue was present prior to resetting the unit via the back button. In any case, I will make a serial cable and hopefully we can sort the issue so that others don't encounter it in the future.

Thanks guys, and I appreciate the work you've put into this!!!

Cheers,



Jason

[Jason Szabo]

Matt, I'm not sure if my previous reply to this post went through so I'll re-post...

I did not change the IP address of my unit during any part of the procedure...I simply lost connectivity after saving setting in RC3 and rebooting. I followed the on-screen instructions of Alt-F (something along these lines)...

"Welcome to your first login to Alt-F, please configure your host settings, timezone, and disk configuration..."

After formatting a new 3TB drive and setting-up a user account, I hit "save settings" and rebooted...and was unable to connect after that.

Cheers,



Jason

[Joao Cardoso]

On Sunday, January 27, 2013 4:49:41 AM UTC, Jason Szabo wrote:

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...

So Alt-F is running, the box is not bricked, 'nmap' shows nothing, the issue is network related...

   try another network cable!

Yes, I know, you have not messed with it, you even tried a direct cable connection (using the same cable?), bla, bla... but give yourself another chance and use another network cable! Really!

Even when the above works (:-!) you can mount the disks on another linux box and take a look of an alt-f.log file on the root of each filesystem. Notice the date, to see if it was generated under RC2 or RC3. You can plug a USB pen and power up the box, the log file should be created (I'm not sure if RC2 creates it... it is on by default under RC3 and you have to disable its generation, but I'm not certain if it is on by default under RC2)

Joao

[Jason Szabo]

Thanks for the reply Joao,

I tried a few different network cables for the direct connection (cat5e, cat6, cross-over, etc.)...no change :-(

I was able to mount the drive that was in the unit during RC2 & RC3 initialization...and it looks like only RC3 has logging enabled by default. I've attached the log and have reviewed it...all seems okay. (Note, I had a typo in my previous posts, my internal network is 10.20.0.0/24 and the DNS321's IP is 10.20.0.200...this is correct, I just mixed it up with the one from work).

Maybe a second set of eyes will find something in the log...but I will try to rename the file and boot the unit to see if by chance RC2 produces a log (I'm not holding my breath though).

If this fails, I will order the Nokia CA-42 cable that Matt has suggested tomorrow and get a serial console going.

I appreciate your time in helping me with this guys!

Regards,



Jason


On Sunday, January 27, 2013 10:26:09 AM UTC-5, Joao Cardoso wrote

[Jason Szabo]

Come to think of it...

I will try customizing a fun_plug script to dump dmesg and some other
usefull logs/information. I believe this should work as long as the
script has the proper name, execution bit set and is dropped in the
root of the hard drive partition.

I can even try configuring eth0 using ifconfig within the fun_plug
script (after logging the original values). Any suggestions on what I
should collect if I can get this working?

Thanks!

On 1/27/13, Jason Szabo <jason...@gmail.com> wrote:
> Thanks for the reply Joao,
>
> I tried a few different network cables for the direct connection (cat5e,
> cat6, cross-over, etc.)...no change :-(
>
> I was able to mount the drive that was in the unit during RC2 & RC3
> initialization...and it looks like only RC3 has logging enabled by default.
>
> I've attached the log and have reviewed it...all seems okay. (Note, I had a
>
> typo in my previous posts, my internal network is 10.20.0.0/24 and the
> DNS321's IP is 10.20.0.200...this is correct, I just mixed it up with the
> one from work).
>
> Maybe a second set of eyes will find something in the log...but I will try
> to rename the file and boot the unit to see if by chance RC2 produces a log
>
> (I'm not holding my breath though).
>
> If this fails, I will order the Nokia CA-42 cable that Matt has suggested
> tomorrow and get a serial console going.
>
> I appreciate your time in helping me with this guys!
>
> Regards,
>
>
>
> Jason
>
>
> On Sunday, January 27, 2013 10:26:09 AM UTC-5, Joao Cardoso wrote
>>
>>

>> So Alt-F is running, the box is not bricked, 'nmap' shows nothing, the
>> issue is network related...
>>
>> try another network cable!
>>
>> Yes, I know, you have not messed with it, you even tried a direct cable
>> connection (using the same cable?), bla, bla... but give yourself another
>>
>> chance and use another network cable! Really!
>>
>> Even when the above works (:-!) you can mount the disks on another linux
>> box and take a look of an alt-f.log file on the root of each filesystem.
>> Notice the date, to see if it was generated under RC2 or RC3. You can plug
>>
>> a USB pen and power up the box, the log file should be created (I'm not
>> sure if RC2 creates it... it is on by default under RC3 and you have to
>> disable its generation, but I'm not certain if it is on by default under
>> RC2)
>>
>> 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/-/YUi6QrdbIbMJ.
>
>
>

--
Sent from my mobile device

[Joao Cardoso]

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.

[Joao Cardoso]

[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.

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.
 
 

[Joao Cardoso]

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

[Mr.H]

Haha I was wondering what happened to that post... Google groups is pretty buggy IMO. o well.

[Mr.H]

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. Even after restoring mtd0 with you script.. I'm going to look into this further.

Matt

[Joao Cardoso]

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.
>  
>  

[Matt Hayden]

Yes it does resort to DHCP. 

I used the command "loadsave_settings -rc"

Matt

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.

[Jason Szabo]

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!

[Joao Cardoso]

On Monday, January 28, 2013 3:16:33 AM UTC, Jason Szabo wrote:

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.

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...

 

 

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!

Sorry :-(

If possible, please don't resurrect the box before being able to do a post-mortem analysis.

Please, after you get it working, it is important that you don't change anything, not save settings (shouldn't be able to do it anyway), nothing at all, start inspecting the network setup using 'ifconfig', 'route -n', 'cat /etc/network/interfaces', 'cat /proc/cmdline', etc.

RC2 still has 'ethtool', so you can try to diagnose at that level using 'ethtool eth0', 'ethtool -S eth0'...

You can activate the alt-f.log generation you saw under RC3 by executing 'rcuser start'; if that fails, 'sh /etc/init.d/S99user start' will do it. The file will be found at the root of all mounted filesystems.

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?

Thanks,

Joao

[Jason Szabo]

On Sunday, January 27, 2013 10:53:17 PM UTC-5, Joao Cardoso wrote:

 

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...

I can't explain why it worked but I am 100% certain that after flashing RC2 I was able to connect with the original statically assigned IP (and DHCP was not used). 

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?

I will conduct a full post-mortem once I get the serial console working. Although I am not well versed with low-level programming...I have many years of experience with higher-level programming and scripting. I consider myself extremely proficient with 'NIX...been using it for over 12yrs both at home and at work :-D I will follow your suggestions and have no issues understanding the rc script where networking is configured.

The one PLUS about my troubles is that I'm confident my DNS321 is not bricked...just inaccessible. And once I have serial console access, we will have another DNS321 to test your development with. I'm happy to give back to the development efforts you guys have made.

Thanks again!
 

[Mr.H]

Hi Jason, 

I've updated the wiki at http://dns323.kood.org/dns-321 with detailed instructions for recovery to stock. It should give you some info to help you access your box once you get your serial cable setup. Feel free to post here with any questions and I'll try to help the best I can. Good luck!

Matt

[Jason Szabo]

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?

[Joao Cardoso]

On Thursday, February 7, 2013 3:12:32 PM UTC, Jason Szabo wrote:

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)

Only three wires? My CA-42 has four, one has to be used to power the usb adapter using the box power supply. Because of this, the box has to be power connected for the usb adapter to work.

But not all CA-42 are equal. Someone also reported a three wire model.

 

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.

You should. The linux kernel starts spiting messages to the serial console as soon as it starts, no configuration is needed (well.... yes, by default console=ttyS0,115200 is setup in the kernel command line)

And I think this to be the best way to start, usb adapter plugged in the desktop computer and to the box, the box power cord connected but the box powered off, kermit running and configured: now press the box power button and you should start seeing messages -- leave the breakin serial code for later.

 

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...

This might give some insight, don't know which... noise margins? exchanged tx/rx?

 

<<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.

try exchanging tx/rx for a few seconds?

 

At this point, I'm not sure if I have an issue with the cable...

when you twisted tx/rx together, do you see double echo when you type chars? You should, the one you typed and the one received from the tx->rx->console.

But it depends on how kermit "echo" is setup.

 

or my DNS321.

Any suggestions?

Don't give up, I'm sure that Matt also has some suggestions

Joao

[Joao Cardoso]

[GG sucks!]

Re: [Alt-F] Re: So I flashed Alt-F to a DNS-321... :)6:35 PM (2 hours ago)

On Thursday, February 7, 2013 12:54:32 PM UTC-5, Joao Cardoso wrote:

Only three wires? My CA-42 has four, one has to be used to power the usb adapter using the box power supply. Because of this, the box has to be power connected for the usb adapter to work.

But not all CA-42 are equal. Someone also reported a three wire model.

Ya, the cable I received has only 3 wires...but reading-up on this suggests that, in this case, the adapter should pull power from the USB port instead of the board. I will take apart the USB connector on the CA-42 when I get home to verify this and that the wires are in fact correct as I have probed them (RX vs TX).
 

And I think this to be the best way to start, usb adapter plugged in the desktop computer and to the box, the box power cord connected but the box powered off, kermit running and configured: now press the box power button and you should start seeing messages -- leave the breakin serial code for later.

[jc: The copy/paste truncated the message, and the original is now lost, sorry Mr. C]

[Jason Szabo]

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...

I've attached a quick dump of the boot process and need to go eat dinner with the family. I just wanted to get this up here so you have time to review it. I will complete a full diagnosis in a couple of hours.

Let me know if you'd like anything specific...other than what you have suggested previously.

Cheers,


Jay

[Joao Cardoso]

On Thursday, February 7, 2013 10:48:33 PM UTC, Jason Szabo wrote:

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!!!

Good news.

 

Onto the issue...it looks like a problem with the mtd partitions.

These errors are expected under RC2. You wouldn't be able to read or write settings in flash, and the MAC is wrongly detected.

 

As a result, the ethernet interface is not starting...

These errors also shown up in Matt, Chris and others dmesg.log, but they didn't avoid eth0 from coming up.

Notice that the first dmesg.log from Mat was a build from himself, not the flashed RC2 now available for the DNS-321. But there are other boot messages posted under this topic.

 The network driver in you box is loaded correctly:

MV-643xx 10/100/1000 ethernet driver version 1.4

mv643xx_eth smi: probed

net eth0: port 0 with MAC address 00:00:00:00:51:81

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 disabled

eth0: link down

eth0: link up, 1000 Mb/s, full duplex, flow control disabled

while in yours it fails:

ifup: ignoring unknown interface eth0

 

Another difference is in others logs the leds are registered

Registered led device: power:blue

Registered led device: right:amber

Registered led device: left:amber

while 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.

'ifup eth0' fails, the log says. Can you post /etc/network/interfaces contents?

For a DHCP setup box it should contain

# cat /etc/network/interfaces 

auto lo
  iface lo inet loopback

auto eth0
iface eth0 inet dhcp
  client udhcpc
  mtu 1500

while for a static setup it should say something like

# cat /etc/network/interfaces 

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

Can you try 'ifconfig eth0 up'? Does it fails? what does 'ifconfig' says afterwards?

Does 'ifconfig eth0 up 192.whatever.your.net.is' works?

Do you have a network cable attached? What does 'ethtools eth0' says? Or 'ethtools -S eth0'

Of course you can now just flash the stock firmware back, but I would like to diagnose the situation first.

Joao

[Jason Szabo]

On Thursday, February 7, 2013 8:44:00 PM UTC-5, Joao Cardoso wrote

The MAC is wrong, but it also occurs with others.

Yup, I believe I read in this forum that the incorrect MAC is fixed in RC3.
 

The difference is that in other logs:  

eth0: link up, 1000 Mb/s, full duplex, flow control disabled

eth0: link down

eth0: link up, 1000 Mb/s, full duplex, flow control disabled

while in yours it fails:

ifup: ignoring unknown interface eth0

This is because eth0 is not defined in /etc/network/interfaces...not sure how this got wiped-out.
 

Another difference is in others logs the leds are registered

Registered led device: power:blue

Registered led device: right:amber

Registered led device: left:amber

while 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.

Dunno why the LEDs are undefined. I currently don't have any disks inserted so this is expected.
 

Back to eth0.

eth0 is setup in different ways depending on several circumstances.

Looks like the /etc/network/interfaces file only contains a loopback entry and nothing else...
/ # cat /etc/network/interfaces
# Configure Loopback

auto lo
iface lo inet loopback

The issue seems to be that looking at /var/log/boot.log...the IP is being set via rcS from flash which is unsuccessful due to the missing interface definition in /etc/network/interfaces.
>>Feb  7 20:56:21 DNS-323 user.notice root: Feb  7 20:55:46 root: IP from flash-defaults
...and...
/ # ifup eth0

ifup: ignoring unknown interface eth0

However, I am able to use `loadsave_settings -rs` to obtain all my original config values and configure networking without any issues (see attached network_diag.txt).

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.

Have a look at the files I attached and let me know if there is anything you would like to try.

Thanks Joao!

[Joao Cardoso]

`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 testers, 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 -lf

no_defaults=$?

echo no_defaults=$no_defaults

It 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 ;-)

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.

No, that's OK, no Alt-F folder as there are no disks.

Try 'aufs.sh -l' and 'aufs.sh' by itself to see its usage.

...and all the changes are lost after reboot.

Yes. You can't save settings under RC2, flash is mounted as read only for safety, as the DNS-323 has 8MB of flash while the 321 has 16 MB.

The kernel detects the mismatch and mounts the flash partitions read-only.

 

Thanks,

Joao

[Jason Szabo]

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 -lf

no_defaults=$?

echo no_defaults=$no_defaults

It should print a no_defaults=1, because reading fails (the tar error, and the incomplete 'interface' file)

You are correct...no_defaults=1
 

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

[Joao Cardoso]

On Friday, February 8, 2013 5:30:18 AM UTC, Jason Szabo wrote:

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...

I think this to be the problem, not the static IP.

 

and did not notice any errors when saving.

DNS-321 users usually get an error here, because the flash has not enough space to hold both Alt-F and D-Link settings files.

As the DNS321 has the double space of flash you had no error.

 

I did try to save settings under RC2 but received a "no flash space available" error.

Yes, but you should not try that, because flash is wrongly setup under RC2.

 

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 -lf

no_defaults=$?

echo no_defaults=$no_defaults

It should print a no_defaults=1, because reading fails (the tar error, and the incomplete 'interface' file)

You are correct...no_defaults=1

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/interfaces

Does 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/foo

mount -o ro /dev/mtdblock0 /tmp/foo

oldest=$(cd /tmp/foo && ls -t set* | tail -1) # the oldest set_ file, probably ther one that causes problems

cp /tmp/foo/$oldest /tmp

umount /tmp/foo

tar -C /tmp/foo -xzf /tmp/$oldest # you should have errors like "tar: short read". If you don't, please say so

rm -f /tmp/foo/etc/web-secret /tmp/foo/etc/rsyncd.secrets /tmp/foo/etc/samba/credentials* /etc/msmtprc # contains sensitive info

tar -C /tmp/foo -czf foo.tgz .

rm -rf /tmp/foo

Now transfer the foo.tgz to your desktop and open it, look for other sensitive information and post it.

 

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...

Yes, because under RC3 the flash is correctly mapped and loadsave_settings is able to read and load settings.

but on reboot to RC2, I face the same issue.

Yes.

To recover your box, boot into RC3, goto System->Settings, ClearSettings (in flash), then SaveSettings (the current ones, to flash), then reboot.

Worked?

This may not work depending on how the flash mtd driver works. The idea is to erase the D-Link settings, so that the new settings file will be stored at the "beginning" of the flash and accessible under RC2.

But the mtd driver probably uses (flash) wear leveling, and will store the file scattered around the flash, using the flash sectors that have been less frequently used. Don't know, only trying...

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?

You can't use RC2 on the DNS-321.

You always have to TryIt RC3 (until RC3 is released, which I hope will be by the end of the current month -- no promises!)

Well, you can use RC2, but you will not be able to save any changes you made. As a matter of fact you should NOT EVEN TRY to save settings under RC2.

Joao

Thanks,



Jay

[Jason Szabo]

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/interfaces

Does 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/foo

mount -o ro /dev/mtdblock0 /tmp/foo

oldest=$(cd /tmp/foo && ls -t set* | tail -1) # the oldest set_ file, probably ther one that causes problems

cp /tmp/foo/$oldest /tmp

umount /tmp/foo

tar -C /tmp/foo -xzf /tmp/$oldest # you should have errors like "tar: short read". If you don't, please say so

rm -f /tmp/foo/etc/web-secret /tmp/foo/etc/rsyncd.secrets /tmp/foo/etc/samba/credentials* /etc/msmtprc # contains sensitive info

tar -C /tmp/foo -czf foo.tgz .

rm -rf /tmp/foo

Now 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.

[Jason Szabo]

Looking at the /etc/network/interfaces file more closely...the eth0 configuration was set to DHCP after the deletion of the file and loadsave_settings. Of course, because I cleared the setting last night...!!!

[Joao Cardoso]

On Friday, February 8, 2013 6:46:49 PM UTC, Jason Szabo wrote:

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/interfaces

Does it has the eth0 stanza?

Yes, this procedure now shows the eth0 stanza in /etc/network/interfaces

Odd... and the network doesn't turned up after issuing a 'ifup eth0'?

 

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/foo

mount -o ro /dev/mtdblock0 /tmp/foo

oldest=$(cd /tmp/foo && ls -t set* | tail -1) # the oldest set_ file, probably ther one that causes problems

cp /tmp/foo/$oldest /tmp

umount /tmp/foo

tar -C /tmp/foo -xzf /tmp/$oldest # you should have errors like "tar: short read". If you don't, please say so

rm -f /tmp/foo/etc/web-secret /tmp/foo/etc/rsyncd.secrets /tmp/foo/etc/samba/credentials* /etc/msmtprc # contains sensitive info

tar -C /tmp/foo -czf foo.tgz .

rm -rf /tmp/foo

Now 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?

No 

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.

Yes, I think that is the reason.

 

My apologies, I did not fully understand the workings of how Alt-F stored and read theses settings.

That's OK

 

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 range

Without 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?

Thanks,

Joao

[Jason Szabo]

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 range

Without 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

[Joao Cardoso]

On Friday, February 8, 2013 7:44:00 PM UTC, Jason Szabo wrote:

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 range

Without 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.

OK, fine. Everything is fine when The End is OK, as Hollywood used to say :-)

 

In your opinion, is there any value in me flashing back to stock D-Link FW and trying to reproduce the issue?

No, not really, thanks.

 

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?

Thanks Joao

Thanks Jason

Joao 

[Jason Szabo]

On Friday, February 8, 2013 3:13:56 PM UTC-5, Joao Cardoso wrote:

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 :-)

Agreed! I chalk-it-up as a learning experience.
 

 

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.

 
Ahhh, makes sense...I guess clearing settings first before saving them ensures they are written closer to the beginning of flash.
 

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

 
I'm extremely grateful that you have taken the time to write Alt-F...thank you! And Matt as well for adapting it for the DNS321!
 

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?

Yup, looks good. This should minimize issues for others...so long as they follow the instructions!

Let me know if you need any help testing your upcoming RC3 flash release. Now that I have serial console access...I am more than happy to give back and help test if needed.

Thanks for all your help!

Cheers,



Jay

[Drew Pfister]

I think I may have messed up :(

Flashed "tryit" with the 323 RC3.

Any way to bring it back to life? Have tried to power cycle, figured it would revert back to the RC2 snapshot.

[João Cardoso]

On Tuesday, September 3, 2013 2:34:28 AM UTC+1, Drew Pfister wrote:

I think I may have messed up :(

Flashed "tryit" with the 323 RC3.

??

You have to tell *exactly* what you have done and its sequence: what fw was flashed in the box, what fw was running, what file have you flashed, if the leds blink/are on, which one if any, if you have checked your DHCP server (usually your router) lease/clients web page, etc

[Brandon Hume]

On 09/ 3/13 03:29 PM, Jo�o Cardoso wrote:
> You have to tell *exactly* what you have done and its sequence: what
> fw was flashed in the box, what fw was running, what file have you
> flashed, if the leds blink/are on, which one if any, if you have
> checked your DHCP server (usually your router) lease/clients web page, etc

I worry what he did was flash the "reloaded" tarball as if it was a
firmware image. He'll be able to confirm, but if so...

[Drew Pfister]

Went here: http://sourceforge.net/projects/alt-f/files/Releases/0.1RC3/

Read this:

-If you already have Alt-F flashed, use Alt-F-0.1RC3-DNS-323.bin to upgrade to the new version.

Flashed this, using tryit:

Alt-F-0.1RC3-DNS-323.bin	2013-03-23	7.8 MB	123	i

Not in front of the NAS right now, but the LEDs looked normal last night. Could not find it listed as a client on my router.

[Drew Pfister]

Ok, good news. Messed with it when I got home and all was able to get it to revert back to RC2 by power cycling.

Now, what are the proper steps to get RC3 running on this?

[Mr.H]

Hi Drew, 

In your original post you said "Flashed "tryit" with the 323 RC3 version.." is this correct?

There is a version specifically for the 321 called "Alt-F-0.1RC3-DNS-321.bin" . Have you tried it?

-Matt 

[Drew Pfister]

When I try to flash that file I get the following:

"a112 Does not seems to be a firmware file for the DNS323 nor the CH3SNAS"

[João Cardoso]

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. 

[Drew Pfister]

You didn't yet answer my questions.

I have to assume things, and assuming wrongly can have nasty consequences.

 My apologies. I will be more precise in this response.

 

What I *think* that you have done, in this sequence:

1-Flashed, using the vendor's fw, an experimental RC2 made for the 321 

Correct 

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"

Partially correct. When I click upload after selecting the 321 bin file I get the error message immediately, it does not make it to the FlashIt/TryIt page. 

3-Loaded  Alt-F-0.1RC3-DNS-323.bin and used TryIt (NOT FlashIt)

Correct 

4-Couldn't connect to the box

Correct 

5-didn't try the front-button test to see if Alt-F was running (read the about buttons and leds wiki)

Correct, sorry for not reading the wiki 

6-your router didn't show a new IP assigned

Correct 

7-power cycle the box and RC2 reappeared

Correct 

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.

Thank you, good to know. 

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!

I'll ask a question regarding this at the bottom of my post. 

5-pitty, this is the first test to do, as has been said ad-nauseam in this forum

Again, my apologies 

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

Yes, DHCP was running on the box and the router was correctly assigning IP addresses to other devices. 

7-expected, as you was TRYING RC3

Right, this makes sense. 

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. 

 

Again, my apologies for being short with my replies. I greatly appreciate your time and help. 

So the bottom line is, I need to flash Alt-F-0.1RC3-DNS-323.bin using TRYIT mode 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?

[João Cardoso]

You are not flashing, you are trying it.

It's different, flashing is definitive, if it fails you need a serial port to (eventually...) recover the box

 

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?

When running RC3 any RC3*.bin file should be accepted.

1-load and TryIt Alt-F-0.1RC3-DNS-323.bin

2-try to connect to the box. If you reboot you should be back to RC2. As a safeguard, *don't* use the box reset recessed back button.

3-When/if you can connect to the box, load any RC3*.bin file and FlashIt

Of course, I don't have a 321 myself, so I was not able to test all this, I rely on 321 owners to confirm or not all this.

You might want to wait until someone with a 321 can confirm this.

Besides this thread, there are others regarding the 321, "inetd not running DNS-321" (read its last post), "DNS-321 Raid1 issues", etc.

[Drew Pfister]

Thank you for all of your help.

I was able to successfully flash RC3 onto the box last night and it is working great.