Modify

Opened 5 years ago

Closed 5 years ago

#12956 closed defect (fixed)

DIR 825 C1 will not boot

Reported by: apc Owned by: developers
Priority: normal Milestone: Chaos Calmer 15.05
Component: base system Version: Trunk
Keywords: DIR 825 C1 boot Cc:

Description

Flashed Feb 4th and Feb 5th snapshots. Tried both squashfs and jffs2. Used backup loader after a 60/60/60 reset. After reboot, LAN leds are off, power/WAN leds are off, and WPS led blinks. WPS led Blinking stops after a few minutes and remains on. Router is completely unresponsive and can only be recovered with a new flash via backup loader. Router flashes correctly back to stock or ddwrt.

As per conversation here: https://forum.openwrt.org/viewtopic.php?id=42058 , Feb 1st snapshot was working OK. Issue must have been introduced in last few days.

Attachments (1)

config_sorted.txt (11.1 KB) - added by apc 5 years ago.
names of name-value pairs (in form of name=value 0x3d 0x00) in second 64K of boot mtd

Download all attachments as: .zip

Change History (26)

comment:1 Changed 5 years ago by apc

Checked out source for Barrier Breaker r35412 and rebuilt. Flashed. Same issue. Router seems to start OK (and backup loader is thankfully reachable) but after what seems to be HW init, all leds OFF but for D-Link led and flashing WPS led. GPIO issue? Kernel panic?

Not sure if relevant, but ddwrt refuses to write (flash) the openwrt *.bin image. If done via UI, router reboots back to ddwrt (no flash was done). If done via command line, error:

root@DD-WRT:~# write openwrt-ar71xx-generic-dir-825-c1-squashfs-factory.bin linux
openwrt-ar71xx-generic-dir-825-c1-squashfs-factory.bin: Bad trx header

Image issue? initramfs issue?

comment:2 follow-up: Changed 5 years ago by Halo2

Feb 1st was not working for you but for a dir-835a1, so its not said that the newer builds are the reason.
At least you have to flash the -sysupgrade image from dd-wrt, not the -factory one.
Funny if it really works only for the 835a1 and not for the 825c1 (for which I did it, but knowing that the images for both will be the same (because even the firmware id tag is the same on both models)).

Not thinking that its the reason, but as the other user seems to have updated from dd-wrt I propably better tell that I appended the identification tag and not filled the last bytes of the factory image with it, like the original firmware does (strangely and in contrast to firmwares for other models).
So you can try to flash -sysupgrade from dd-wrt and/or move the last 26 bytes (26bytes) inwards so that the file has 16318464 bytes afterwards.

comment:3 in reply to: ↑ 2 ; follow-ups: Changed 5 years ago by apc

Replying to Halo2:

Feb 1st was not working for you but for a dir-835a1, so its not said that the newer builds are the reason.
At least you have to flash the -sysupgrade image from dd-wrt, not the -factory one.
Funny if it really works only for the 835a1 and not for the 825c1 (for which I did it, but knowing that the images for both will be the same (because even the firmware id tag is the same on both models)).



Completely agree. That is what I find baffling to the point of it being annoying. Does these images work on a DIR-835-A1 but not on a DIR-825-C1? I have a 835, but it is working fine w/ddwrt as is and I don't want to start tinkering with it as well.


Not thinking that its the reason, but as the other user seems to have updated from dd-wrt I propably better tell that I appended the identification tag and not filled the last bytes of the factory image with it, like the original firmware does (strangely and in contrast to firmwares for other models).



I have tried both the -sysupgrade and the -factory bin's. Same behaviour. ddwrt UI doesn't seem to do much (reboot is rather quick).

I now know why write doesn't work, as these images don't have the trx header. So I tried mtd instead:

mtd -r linux openwrt-ar71xx-generic-dir-825-c1-squashfs-sysupgrade.bin linux

This almost bricked the router. It took several 30/30/30 resets to get the backup loader again.


So you can try to flash -sysupgrade from dd-wrt and/or move the last 26 bytes (26bytes) inwards so that the file has 16318464 bytes afterwards.



Not sure I understand what you mean about this (the editing). Do you mean taking the firmware id and moving it after the 0xDEADCODE marker (this trimming the file by 26 bytes)? Or just removing the tag altogether?

Thanks for the comments!

comment:4 in reply to: ↑ 3 Changed 5 years ago by anonymous

Replying to apc:

This almost bricked the router. It took several 30/30/30 resets to get the backup loader again.



By this I mean: router completely unresponsive to pings to either 192.168.1.1 or 192.168.0.1 (from 192.168.1.2 and 192.168.0.2, respectively). D-Link LED on. Power LED blinking. WPS led off.

I gave it half an hour in such state to no avail, so it doesn't seem to be something temporary.

I would really like to hear from another DIR-825-C1 owner. Everything I have read points to 825c1 and 835c1 being the same thing (plus black paint and an extra antenna), but somehow my 825 severely dislikes these images. Hopefully it's not just this one.

Cheers!

comment:5 in reply to: ↑ 3 ; follow-up: Changed 5 years ago by Halo2

Replying to apc:

I now know why write doesn't work, as these images don't have the trx header. So I tried mtd instead:

mtd -r linux openwrt-ar71xx-generic-dir-825-c1-squashfs-sysupgrade.bin linux

This almost bricked the router. It took several 30/30/30 resets to get the backup loader again.

:-(

Think you mean mtd -r write openwrt-ar71xx-generic-dir-825-c1-squashfs-sysupgrade.bin linux ?

I additionally used mtd -e linux -r write openwrt-... some time ago but I think that should not matter.

So you can try to flash -sysupgrade from dd-wrt and/or move the last 26 bytes (26bytes) inwards so that the file has 16318464 bytes afterwards.


Not sure I understand what you mean about this (the editing). Do you mean taking the firmware id and moving it after the 0xDEADCODE marker (this trimming the file by 26 bytes)? Or just removing the tag altogether?

The factory and original images have 00DB120AR9344-RT-101214-00 at the end. In the original fw of this 2 models its not appended like for firmwares of other models from them.
In the openwrt factory file it is appended. So it is that tag length bigger. (The original file ends at the partition size of 16318464 bytes.)
Just because you wrote only of dd-wrt to openwrt and not from factory to openwrt. And I also don't know how it would behave on this model with the more logic appending style.

(DD-wrt seems to have or had linux partition bigger (so it propably goes into lang partition) but I can only tell this if you post the output of:

dmesg

Creating 7 MTD partitions on ???
and/or
Kernel command line: ???
)

comment:6 in reply to: ↑ 5 Changed 5 years ago by apc

Replying to Halo2:

Hi again!


Think you mean mtd -r write openwrt-ar71xx-generic-dir-825-c1-squashfs-sysupgrade.bin linux ?



Yes, sorry. Dyslexia runs in the family. It practically gallops. That was it. I didn't try the erase flag.


Just because you wrote only of dd-wrt to openwrt and not from factory to openwrt. And I also don't know how it would behave on this model with the more logic appending style.



I see what you mean.

I removed the tag & flashed again. Same issue. Tried both the -factory (without the tag) and the -sysupgrade (as is). ddwrt UI applies them (both), reboot (rather quickly), and boot back into ddwrt. mtd takes its time, eventually reboots, and the router is dead.

I am only guessing, but it seems that it boots directly into backup loader, but takes about 1h (or several 30/30/30 resets) to become responsive at 192.168.0.1. It always comes back OK after reflashing ddwrt or stock. Seems like it is busy with something and needs to finish whatever that is before the IP stack responds to a ping.

More interesting, when it does boot back into ddwrt, all settings from before flash are active. The flash process is not touching nvram (maybe that was obvious to you but I just thought that through).


If I flash directly from backup loader (with -factory bin) it just jams with the WPS led on.


(DD-wrt seems to have or had linux partition bigger (so it probably goes into lang partition) but I can only tell this if you post the output of:

dmesg

Creating 7 MTD partitions on ???
and/or
Kernel command line: ???



Here it is:

found squashfs at 10F000
Creating 8 MTD partitions on "ar7240-nor0":
0x000000000000-0x000000020000 : "RedBoot"
0x000000020000-0x000000fd0000 : "linux"
0x00000010f000-0x000000db0000 : "rootfs"
0x000000db0000-0x000000fd0000 : "ddwrt"
0x000000fd0000-0x000000fe0000 : "nvram"
0x000000ff0000-0x000001000000 : "board_config"
0x000000000000-0x000001000000 : "fullflash"
0x000000000000-0x000000020000 : "fullboot"

Kernel command line: console=ttyS0,115200 root=1f02 rootfstype=squashfs noinitrd init=/sbin/init

So linux area (rootfs+ddwrt) is 16,449,536 bytes in size, no? That should be enough for openwrt-ar71xx-generic-dir-825-c1-squashfs-factory.bin (size 16,318,490) to fit in. Not sure why it is split in three.

Now, kernel command line has root=1f02... does that make sense? ddwrt works, so I guess it's OK.


Thank you so much for your help!

comment:7 follow-up: Changed 5 years ago by Halo2

Thank you for the mtd partition info.
Like i thought, the same as I found with dir-835 on dd-wrt.

As of
http://www.wikidevi.com/wiki/D-Link_DIR-835_rev_A1
its

Creating 7 MTD partitions on "ath-nor0":
0x000000000000-0x000000010000 : "u-boot"
0x000000010000-0x000000020000 : "nvram"
0x000000020000-0x000000fb0000 : "linux"
0x000000160000-0x000000fb0000 : "rootfs"
0x000000fb0000-0x000000fe0000 : "LANG"
0x000000fe0000-0x000000ff0000 : "MAC"
0x000000ff0000-0x000001000000 : "ART"

So dd-wrt overwrites part of the lang partition and also stores an own nvram partition at the end of that space.
I didn't want to touch the lang partition, and I thought the 196608 Bytes are not needed on an exceptional big flash anyways, and additionally I can keep the original firmware size by doing so. (Openwrt also does not use an extra partition to save settings anymore.)
So thats the reason why dd-wrt's settings do not get overwritten by openwrt.
(Also dd-wrt's rootfs begins earlier because they left less space for kernel.)

I've meant flashing the -factory image from original firmware (if needed propably with the tag moved by its length (26bytes) to achieve original firmware size, if they really don't cut the tag anymore as on their other models). But I believe you will get the same result as with mtd :-/.

So the strange thing is:
dd-wrt had support for dir-825-c1, someone found out dir-835-a1 is the same and it worked.
I thought so lets add dir-825-c1 to openwrt. Did that, and we got response it works on dir-835-a1 (like I thought it will).
But the second response is from you, who have real problems on dir-825-c1.

I have none of them, both are not avalaible here currently, so I can test nothing. (Where did you get yours? both?)

So response from tcrisall (i.e. how he migrated to openwrt) or anyone who has tried it on dir-825-c1 would be highly appreciated!
And hopefully someone else can look into this.
Because it's my first port, and I'm not sure if a dir-835-a1 will run this config at all? Or propably theres an overseen difference on these two models, which oddly leads to a problem. (Then a quick fix could be to rename all to dir-835-a1 ;-) .)

Seems like a serial connection to the board is needed too see where the problem occurs on boot time. Propably you're someone who likes to do this?

comment:8 in reply to: ↑ 7 ; follow-up: Changed 5 years ago by apc

Replying to Halo2:

I've meant flashing the -factory image from original firmware (if needed propably with the tag moved by its length (26bytes) to achieve original firmware size, if they really don't cut the tag anymore as on their other models). But I believe you will get the same result as with mtd :-/.



Let me give that a try at night. I'll trim the -factory bin to exact same size as as stock version and try with/without the firmware tag, flashing via backup loader. At least now I'm confident this messes up the router but doesn't brick it (fingers crossed).


dd-wrt had support for dir-825-c1, someone found out dir-835-a1 is the same and it worked.



Yes, and I can confirm that ddwrt works well for both.


I thought so lets add dir-825-c1 to openwrt. Did that, and we got response it works on dir-835-a1 (like I thought it will).
But the second response is from you, who have real problems on dir-825-c1.



Hopefully I am not an isolated case. Both units seem very similar, but after opening both they're not identical. LEDs for sure are not; maybe they're just not soldered in but I think it goes deeper than that. That might explain the blinking WPS led which I had never seen before. I really think GPIOs might not be the same, and/or there is additional code in ddwrt to "guess" some parameters such as MAC addresses. Maybe the ath9k driver is crashing on the different radio chip. No clue; I'm too new at this.


I have none of them, both are not available here currently, so I can test nothing. (Where did you get yours? both?)



eBay. :) A guy was selling 825-B1s at an interesting price. Bought one, liked it, and asked for a second one. The one that came in next surprised me by being a C1. I am very interested in OpenWRT for the C1 as it has twice the RAM vs the B1. I use it more like a server than a router (the 835 is my main WiFi router).


Seems like a serial connection to the board is needed too see where the problem occurs on boot time. Probably you're someone who likes to do this?



Would that get us a boot log like what is available for 835 here?
http://www.wikidevi.com/wiki/D-Link_DIR-835_rev_A1

I'm game. Any pointers of what I need to look at on board to get serial enabled and connected? How do I get started?


Thanks!!

comment:9 in reply to: ↑ 8 ; follow-up: Changed 5 years ago by Halo2

Replying to apc:

Replying to Halo2:


Let me give that a try at night. I'll trim the -factory bin to exact same size as as stock version and try with/without the firmware tag, flashing via backup loader. At least now I'm confident this messes up the router but doesn't brick it (fingers crossed).

I've meant from the web gui of stock firmware.
You don't have to test it without the tag there.
First I would test it with -factory.bin as it is. If it does not work you can trim it by the tag size (than its stock versions size) and overwrite the end with the tag (than its like the stock version of this particular models..)).

Hopefully I am not an isolated case. Both units seem very similar, but after opening both they're not identical. LEDs for sure are not; maybe they're just not soldered in but I think it goes deeper than that. That might explain the blinking WPS led which I had never seen before. I really think GPIOs might not be the same, and/or there is additional code in ddwrt to "guess" some parameters such as MAC addresses. Maybe the ath9k driver is crashing on the different radio chip. No clue; I'm too new at this.

Wonder that leds are not the same. Thanks for the info!
So if they use different GPIO's thats very interesting. Because I didn't saw anything in dd-wrt about that. Propably I should look it up again.
I wanted the status led to be d-link:orange:power. And I didn't know which gpio wps led had (dd-wrt didn't knew it either).
As nobody checked my conversion (for which I asked, because I've never done it) there might be a failure, even they were from dir-825-c1 code.. .

What I can do is to compile an Image without any gpio. Would be a great step if that works.
After that we can activate wlan leds and see if they are the reason, or the buttons, or usb (leds) (,or the rest).

eBay. :) A guy was selling 825-B1s at an interesting price. Bought one, liked it, and asked for a second one. The one that came in next surprised me by being a C1. I am very interested in OpenWRT for the C1 as it has twice the RAM vs the B1. I use it more like a server than a router (the 835 is my main WiFi router).

Yea the B1 is with the fastest old cpu and two ar9280 (so first gen atheros n chips) while the c1 has one of their latest cpus with integrated 2.4GHz n (so the extra chip is only for 5GHz).

Would that get us a boot log like what is available for 835 here?
http://www.wikidevi.com/wiki/D-Link_DIR-835_rev_A1

Yes, we will get a boot log then, so this would be a great hint where it hangs.

I'm game. Any pointers of what I need to look at on board to get serial enabled and connected? How do I get started?

http://wiki.openwrt.org/toh/d-link/dir-825 describes the pin layout (without stating for which revision) (and remembers to use a 12V<->3.3V converter). But unfortunately does not show where they are on the board. But propably you'll find them. Look up pages of other hardware too see how this is implemented.

Thanks!!

Thank you too!

comment:10 in reply to: ↑ 9 ; follow-up: Changed 5 years ago by apc

Replying to Halo2:

Hiya!

I've meant from the web gui of stock firmware.
You don't have to test it without the tag there.
First I would test it with -factory.bin as it is. If it does not work you can trim it by the tag size (than its stock versions size) and overwrite the end with the tag (than its like the stock version of this particular models..)).



Tested.
-factory as is: stock UI will not flash.
-factory trimmed by 26 bytes (with ID at end): UI will flash, router crashes with flashing WPS led.


Wonder that leds are not the same. Thanks for the info!


Yes. The 825 C1 has all the leds the 825 B1 has. The 835 has only two. Most important, the shared ones not in the same spot (that is, power on 825 C1 is all the way to the left, while power on 835 A1 is somewhat in the middle). So either different wiring at PCB layer, or different GPIOs for sure.


So if they use different GPIO's thats very interesting. Because I didn't saw anything in dd-wrt about that. Propably I should look it up again.



I may be wrong. You definitely know more about this that I do. I can code, but openwrt and especially ddwrt source code is too obfuscated for me.


What I can do is to compile an Image without any gpio. Would be a great step if that works.



I think something is causing a kernel panic. I don't thing GPIOs would be enough for that. I'll gladly test any images you want to send my way, but I'm loath to set you on a futile task.


http://wiki.openwrt.org/toh/d-link/dir-825 describes the pin layout (without stating for which revision) (and remembers to use a 12V<->3.3V converter). But unfortunately does not show where they are on the board. But propably you'll find them. Look up pages of other hardware too see how this is implemented.



Found the serial header. It is a no-brainer, you can see it on the picture on the site (http://wiki.openwrt.org/_detail/toh/d-link/dir825-c1-board.jpg?id=toh%3Ad-link%3Adir-825 - roughly in the middle).

I need an adapter. Just ordered a CP2102, but it will take a few days (weeks?) to get here. In the meantime I will solder a four pin header on the board. Once I get everything ready I will post a comment here.

Cheers!

comment:11 in reply to: ↑ 10 ; follow-up: Changed 5 years ago by Halo2

Replying to apc:

Replying to Halo2:

Hiya!

First I would test it with -factory.bin as it is. If it does not work you can trim it by the tag size (than its stock versions size) and overwrite the end with the tag (than its like the stock version of this particular models..)).


Tested.
-factory as is: stock UI will not flash.
-factory trimmed by 26 bytes (with ID at end): UI will flash, router crashes with flashing WPS led.

Thank you for testing that!
And very funny that they now really implemented it that (in my opinion bad) way.
So I will fix the image generation some time.

Wonder that leds are not the same. Thanks for the info!


Yes. The 825 C1 has all the leds the 825 B1 has. The 835 has only two. Most important, the shared ones not in the same spot (that is, power on 825 C1 is all the way to the left, while power on 835 A1 is somewhat in the middle). So either different wiring at PCB layer, or different GPIOs for sure.

So if they use different GPIO's thats very interesting. Because I didn't saw anything in dd-wrt about that. Propably I should look it up again.


I may be wrong. You definitely know more about this that I do. I can code, but openwrt and especially ddwrt source code is too obfuscated for me.

What I can do is to compile an Image without any gpio. Would be a great step if that works.


I think something is causing a kernel panic. I don't thing GPIOs would be enough for that. I'll gladly test any images you want to send my way, but I'm loath to set you on a futile task.

There were a few things I was unsure about. By removing all except necessary stuff I will know if its some of this.
Not much work.
Also I'm using r35412 for that, just in case ;-).

Just asking myself how to provide you with the currently compiling test images.

http://wiki.openwrt.org/toh/d-link/dir-825 describes the pin layout (without stating for which revision) (and remembers to use a 12V<->3.3V converter). But unfortunately does not show where they are on the board. But propably you'll find them. Look up pages of other hardware too see how this is implemented.


Found the serial header. It is a no-brainer, you can see it on the picture on the site (http://wiki.openwrt.org/_detail/toh/d-link/dir825-c1-board.jpg?id=toh%3Ad-link%3Adir-825 - roughly in the middle).

Ah, yeah, how could I have overseen that.

I need an adapter. Just ordered a CP2102, but it will take a few days (weeks?) to get here. In the meantime I will solder a four pin header on the board. Once I get everything ready I will post a comment here.

:-)

Cheers!

comment:12 in reply to: ↑ 11 ; follow-up: Changed 5 years ago by apc

Replying to Halo2:

Hi again,

There were a few things I was unsure about. By removing all except necessary stuff I will know if its some of this.
Not much work.
Also I'm using r35412 for that, just in case ;-).

Just asking myself how to provide you with the currently compiling test images.

Well, I just googled around and found this site:

https://www.yousendit.com/

I have never used it before, but it allows you to register without gimmicks (no credit cards or such), has some storage space, can be accessed via browser (no funny binaries to download or install, only some flash to deal with) and can provide you with a direct download URL.

Try this, for example (this is the 3.00 stock firmware trimmed by 26 bytes):

https://www.yousendit.com/download/UW14WWVndWM1R05qQThUQw

I only ask you to please post here the MD5SUM checksums of any files you send to make sure they get to me complete and untouched. For file above:

72c9ca93a51a125e9d36de62cad20b6c *openwrt-ar71xx-generic-dir-825-c1-squashfs-factory-trimmed.bin

If you have any better ideas, I'm all ears.

Thanks again!

comment:13 in reply to: ↑ 12 ; follow-up: Changed 5 years ago by Halo2

Replying to apc:

Replying to Halo2:

Well, I just googled around and found this site:

https://www.yousendit.com/

I have never used it before, but it allows you to register without gimmicks (no credit cards or such), has some storage space, can be accessed via browser (no funny binaries to download or install, only some flash to deal with) and can provide you with a direct download URL.

If you have any better ideas, I'm all ears.

Does not seem bad, except that you have to cancel the trial before it expires.
Either I do that and cancel trial right after submitting, or which I would prefer - I get your mail address and use a similar service which sends you the links after I uploaded the files (they are ready in 1 too 2 hours).

comment:14 follow-up: Changed 5 years ago by Halo2

Also I'd like to have a backup of the art partition

cat /proc/mtd (too see its number (board_config), I guess 5?)
cat /dev/mtd5 > /tmp/art.bin

On these series another approach was used by the manufacturer to store mac adresses, but I want to see if there are ones too.
(Cause dd-wrt still has code to add an interface with an mac stored there (like on the reference design). But I think that remained just as an accident or because it does not matter.).

More correctly I don't need the backup, just the first 12 bytes, because thats where the mac adresses would be.

Or you just look at them yourself and tell me if that are mac adresses and if dd-wrt has an Interface with one of them (would be the second one incremented by 5) or not.

comment:15 in reply to: ↑ 13 Changed 5 years ago by apc

Replying to Halo2:

Hi again!

Does not seem bad, except that you have to cancel the trial before it expires.
Either I do that and cancel trial right after submitting, or which I would prefer - I get your mail address and use a similar service which sends you the links after I uploaded the files (they are ready in 1 too 2 hours).

Checked it... that one is free. No expiry. No charges.

Anyways, you can also try emailing me here please: firmwaretest825 at gmail.com

Also I'd like to have a backup of the art partition


Router is being stubborn after last flash (nothing out of the ordinary) so I'll reflash ddwrt at night and send you details about the ART.

Cheers!

comment:16 in reply to: ↑ 14 ; follow-up: Changed 5 years ago by apc

Replying to Halo2:

Hi again!

Or you just look at them yourself and tell me if that are mac adresses and if dd-wrt has an Interface with one of them (would be the second one incremented by 5) or not.


Here is an interesting one for you...

There are two MAC address at the beginning of the ART partition. They look nothing like the MAC address located on the sticker on the bottom of the unit nor what ddwrt reports. Not even close.

So I decided to dump all relevant /dev/mtd's and take a look at each. Here is the map:
root@DD-WRT:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00010000 "RedBoot"
mtd1: 00fb0000 00010000 "linux"
mtd2: 00ca1000 00010000 "rootfs"
mtd3: 00220000 00010000 "ddwrt"
mtd4: 00010000 00010000 "nvram"
mtd5: 00010000 00010000 "board_config"
mtd6: 01000000 00010000 "fullflash"
mtd7: 00020000 00010000 "fullboot"

The RedBoot or fullboot dumps (mtd0 and mtd7, they are identical, expected) are 128K in length. The first 64K have the UBoot code (looks code-ish enough to me, anyways, I don't read MIPS). The second 64K though has a series of 0x3D 0x00 terminated strings. Exactly at the 64K mark (offset 0x0x10000) there is what looks like a marker: HSLF. After that it's mostly readable text.

Further past the 64K offset I found the following strings (I modified the MAC addresses to give you an idea of their sequence and left the OUI):

Offset - String
0x0107B2 - sys_lan_mac=B8:A3:86:00:00:01
0x013867 - wan_mac=B8:A3:86:00:00:02
0x013D28 - wlan1_mac=B8:A3:86:00:00:03
0x014808 - lan_mac=B8:A3:86:00:00:01
0x018305 - sys_wan_mac=B8:A3:86:00:00:02
0x018921 - wlan0_mac=B8:A3:86:00:00:01

I've attached a "config_labels.txt" file. It contains all the names found in the file for your reference.

I cannot telnet to my 835 from here to see if it has the same setup but will check at night. I am guessing that in the 835 the CALDATA partition has valid MAC addresses, but the 825 does not.

ddwrt seems to have some hacks to go around this issue. On an 825B1 (I can telnet to it from here) I see this in dmesg:
<3>[ 7.560000] ath: phy1: eeprom contains invalid mac address: 07:71:82:xx:xx:xx
<3>[ 7.570000] ath: phy1: random mac address will be used: 8a:54:59:xx:xx:xx

I'll check at night if indeed that is a valid MAC or if ddwrt is just pulling MAC addresses out of its hat, which would help explain why some routers work with that and not with OpenWrt.

More to come.

Cheers!

Changed 5 years ago by apc

names of name-value pairs (in form of name=value 0x3d 0x00) in second 64K of boot mtd

comment:17 in reply to: ↑ 16 ; follow-up: Changed 5 years ago by Halo2

0x000000fe0000-0x000000ff0000
Offset 0x4 and 0x18 is where I think you'll find "mac adresses"?
Special dir-825 thing that there are ones. Both openwrt and dd-wrt are using them.

Thank you for confirming about the two at the beginning of the art partition. (currently not used, was unsure about the second in dd-wrt)
The other two should be at offset 0x1000 and 0x5000. (used ones)

I think you got the values of the "stock nvram"? (see original partition table, dd-wrt seems to be not "exact")
Propably the adresses are used by stock Firmware.

comment:18 in reply to: ↑ 17 ; follow-up: Changed 5 years ago by apc

Replying to Halo2:

Hi!

0x000000fe0000-0x000000ff0000
Offset 0x4 and 0x18 is where I think you'll find "mac adresses"?
Special dir-825 thing that there are ones. Both openwrt and dd-wrt are using them.


Yes. You are right. Both on 825 and 835 the correct addresses are there.

Offset 0x00 has either "A1" or "C1" (for 835 & 825 respectively). Offset 0x2c has the string "0x14" for both. Everything else in that range is zero.

The other two should be at offset 0x1000 and 0x5000. (used ones)


Not sure what you mean about these two... everything else in the 0x000000fe0000-0x000000ff0000 range is zero.

Thank you for the test files. I will give them a try during the weekend.

Cheers!

comment:19 in reply to: ↑ 18 ; follow-up: Changed 5 years ago by Halo2

Replying to apc:

Replying to Halo2:

The other two should be at offset 0x1000 and 0x5000. (used ones)


Not sure what you mean about these two... everything else in the 0x000000fe0000-0x000000ff0000 range is zero.

Yeah my mistake. These are the offsets in the art partition for caldata.

comment:20 in reply to: ↑ 19 Changed 5 years ago by apc

Replying to Halo2:

Replying to apc:

Replying to Halo2:

The other two should be at offset 0x1000 and 0x5000. (used ones)


Not sure what you mean about these two... everything else in the 0x000000fe0000-0x000000ff0000 range is zero.

Yeah my mistake. These are the offsets in the art partition for caldata.


Hmmm... not sure if it is relevant, but although there are MAC addresses in binary at those offsets, they are the "wrong" MAC addresses that do not correspond to what is on the label and but do match what is found at the beginning of the art partition.

Seems like for this model a new standard was set to store the MAC addresses at 0xfe0004 & 0x18, but no one bothered to clear old MAC data from the caldata. The MAC addresses there are of the form 00:18:e7 (usually for DIR 825-B1) while valid ones are b8:a3:86 (DIR 825-C1).

Probably not relevant to why this thing is crashing, but misleading enough.

Cheers!

comment:21 Changed 5 years ago by Halo2

As already stated in the forum the switch config was wrong (WAN acts as LAN port..).
The correct one will find its way into trunk soon.

comment:22 Changed 5 years ago by anonymous

DIR-835-A1 seems to work well for me with r35608 (upgraded from OEM) except a couple minor issues (LED config, system name, txpower). I filed separate tickets for those. OpenWrt Wiki & TOH updated to reflect support.

MAC addresses seem correct to me and match the bottom of the router. I did notice that WAN/LAN/WL0 all have the same MAC address though, which I think was the same as OEM firmware. WL1 is the same MAC incremented by 1 on the last digit.

comment:23 Changed 5 years ago by Halo2

By the way, do the wlan leds (2.4GHz and 5.GHz) work on dir-825-c1?

comment:24 Changed 5 years ago by Halo2

Always booted but switch config was "swaped".
Already fixed, so ticket can be closed!

comment:25 Changed 5 years ago by jow

  • Resolution set to fixed
  • Status changed from new to closed

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.