Modify

Opened 3 years ago

Closed 3 years ago

#18992 closed defect (fixed)

Incorrect model string on Netgear WNDR3700v2

Reported by: NeoRaider Owned by: developers
Priority: normal Milestone:
Component: base system Version: Trunk
Keywords: Cc:

Description

The model string in /tmp/sysinfo/model is NETGEAR NDR3700v2 instead of NETGEAR WNDR3700v2.

Looking at /lib/ar71xx.sh, it tries to find the model string starting at byte 56 of the ART. The following is the start of the ART of a WNDR3700v2 I was provided with. As you can see, the model string starts at byte 55 instead of 56.

This is because the actual internal model string starts a byte 41 and is 29763654+16+64WNDR3700v2 on the WNDR3700v2 and 29763654+16+128WNDR3800 on the WNDR3800.

00000000  a0 21 b7 bb 05 37 a0 21  b7 bb 05 38 a0 21 b7 bb  |.!...7.!...8.!..|
00000010  05 39 33 33 35 32 35 37  33 30 32 4b 59 31 31 34  |.9335257302KY114|
00000020  35 33 30 33 31 30 41 00  02 32 39 37 36 33 36 35  |530310A..2976365|
00000030  34 2b 31 36 2b 36 34 57  4e 44 52 33 37 30 30 76  |4+16+64WNDR3700v|
00000040  32 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |2...............|
00000050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

I can write a patch to fix this myself, but getting the ART of a few similar devices like the WNDRMAC and WNDR3800CH would be great to ensure that I don't introduce new bugs.

Attachments (0)

Change History (7)

comment:1 Changed 3 years ago by anonymous

Some models (depending on uboot version?) need to read model with offset. But only some.

comment:2 Changed 3 years ago by hnyman

I have 3700v1, 3700v2 and 3800, and in all of those the ID string is read ok.

Actually, in my 3700v1 and 3700v2 there is no ID string at that location. Instead the art partition data stops after the serial number (2KY114530310A in your case).

If you look at the routine in https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/base-files/lib/ar71xx.sh#L36 , you notice that e.g. 3700v2 is expected to have ff's there.

There have every now and then been a few cases like yours in the forum discussions and here, but I think that they are exceptions (e.g. newest production batches, or refurbished, or something. Probably manufactured after the factory's routines have already been modified to include the new stuff in 3800.)

comment:3 Changed 3 years ago by hexa-

ART of WNDR3800v1
https://www.linuxlounge.net/~martin/openwrt/art-wndr3800v1.dump

edit: oops, you got that covered. nvm.

Last edited 3 years ago by hexa- (previous) (diff)

comment:4 follow-up: Changed 3 years ago by NeoRaider

Okay, so there are different software revisions of the 3700v2. Some contain the model string in the ART and others just have that part filled with 0xff...

Does anyone have a WNDRMAC and can provide an ART dump?

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

Replying to NeoRaider:

Okay, so there are different software revisions of the 3700v2. Some contain the model string in the ART and others just have that part filled with 0xff...

Does anyone have a WNDRMAC and can provide an ART dump?

Based on the function, WNDRMAC usually contains ff chars except that the last one is "N".

3700/3800 series has been here for several years and the current detection function generally works ok, or there would have been frequent complaints earlier.

Feel free to propose a patch to detect the "abnormal" 3700v2 versions, but without destroying the compatibility with the mainstream devices.

comment:6 Changed 3 years ago by NeoRaider

I plan to look at the whole string starting at byte 41 instead of 56 for my fix. For that reason I'd like to know what bytes 41 to 56 look like on the WNDRMAC so I don't break it.

comment:7 Changed 3 years ago by blogic

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