OpenWrt Forum Archive

Topic: weird nvram variable with non ascii chars

The content of this topic has been archived on 7 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

I do not know how I got that, but I have some kind of a non asci char variable name in my nvram. I you do a nvram show you can see the first part of the variables and on some point the console turn into garbage chars. I have to disconnect reset my xterm and connect regain a readable console.
Resetting to factory defaults (Reset button pressed for a long period) did not helped me. The nvram_clean.sh script from the faq section cleared many unneded variables but this wierd one survives. Any idea how I can get rid of that variable. I would not risk the nvram earase option if possible.
Maybe one linux guru know a command line to grep that nvram variable from the nvram show command and pipe it as an argument to an nvram unset command.

You may possibly revive your terminal by echoing ^V^O (echo <ctrl-v><ctrl-o>, the ^V will not show up).

To get hold of the weird NVRAM entry, you may try to "hexdump -C /dev/mtdblock/3 | more" and try to spot the entry -
since NVRAM is ordered by hash values the entries may appear unsorted (but in the same order "nvram show" gives),
and it's mostly clear-text (sequence of key=value, terminated by hex 00).
Please try to share the snippet involved *before* unsetting it. Tell us at which location you found it.

Since this survives a factory reset, it may be of general interest to track this down. Can you please supply the mtd map
from the syslog ("dmesg | grep 0x00")? There may be something wrong there which leads to partial flash corruption,
and may put your jffs in danger as well (in the worst case - just to make sure everything looks OK).

Can you check that the first 32K of your nvram partition (up to 0x8000) contains only hex ff's? If not, backup immediately...

Hi,
thx for the help.
with hexdump I found this (cut between the two \0, near the variable name that is the last not wiered output from nvram show):
I used hexdump with -c option, -C did not work in my busybox.

\0 340 032   E   3 317 321  \t 034
0009330   v   i 004 276 022 316 276   V 261   _ 247 241 350 345   <   +
0009340   C 231 022   O 207 024 241 277   [ 016 362 200   3 356   _   ]
0009350   =   5 207 317 353   >   >   v 037 317   w   R 350 024   \ 222
0009360 276 323   $  \r 027 033 333   - 345   C 255   < 340 036 343 026
0009370 022 211   _ 206 037 243   N 211   } 233   G   S  \b 364   5 304
0009380 273   z  \b   ! 031 203 016 200 366 214 034   K   6 360   q 273
0009390   T 206   K   q 327   p   c   2   t  \b 357   4   $ 256 204   c
00093a0   y 311 026 005 324 376 336  \b   ( 035 251 340   e 277 250   %
00093b0 270 314   u   R 254 037   &   0 213   v 177   T 034   4 016 207
00093c0 225 035   e   y   v   B   _ 020   o   6 303   m 370   5 217 223
00093d0 366   ,   8 356   Q   b   6   o 272 244 033 334 273 302 003 032
00093e0   9 020 364 237 270 325   h   +   j   Z 002   L 001   n 230  \a
00093f0 364   B   S 233 346 256 330  \b   , 265 305 261 211   P  \b 375
0009400 207 324 351 224 242   k 331   a 332 202 334   * 243   D 261 347
0009410 327 006   K 203 366 335   s   +   $ 005   X   m 362 326 226 016
0009420 001 255   & 234 345   ; 207 214  \b 002   @ 353 036   . 305 333
0009430 324 244   v 325  \a   ! 276 241   J 351   >   #  \a 250 031 346
0009440   ` 350 222 310 343 201 304   | 224 322   L 336   C 251 327   u
0009450 006 335 345   7 254   ,   4  \0   

Meanwhile I flashed with ddwrt 23sp1 (wiht resetting to factory values) to try if I got the same thing. It is still there. So I hope the output from dmesg is helpful anyway:

0x00000000-0x00040000 : "pmon"
0x00040000-0x003f0000 : "linux"
0x000ce170-0x0039638d : "rootfs"
0x003f0000-0x00400000 : "nvram"
0x003a0000-0x003f0000 : "ddwrt"

Router version is WRT54G v1.1

You say:
"Can you check that the first 32K of your nvram partition (up to 0x8000) contains only hex ff's? If not, backup immediately..."
do you mean this?

~ # hexdump -c /dev/mtdblock/3 | more
0000000 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377
*
0008000   F   L   S   H 310   Y  \0
I mean this is FF, if you use -C instead of -c what was not avail in my busybox.

But how do I unset the wiered value? How do I use that what I found in one byte characters as input for nvram unset?
I tried to unset that variable with
nvram unset \x1a\xe0\x33\x45\xd1\xcf\x1c\x09\x69\x76\xbe\x04\xce\x12\x56\xbe\x5f\xb1\xa1\xa7\xe5\xe8\x2b\x3c\x99\x43\x4f\x12\x14\x87\xbf\xa1\x0e\x5b\x80\xf2\xee\x33\x5d\x5f
but it is still there

(Last edited by aes on 7 Jun 2006, 20:29)

aes wrote:

0x00000000-0x00040000 : "pmon"
0x00040000-0x003f0000 : "linux"
0x000ce170-0x0039638d : "rootfs"
0x003f0000-0x00400000 : "nvram"
0x003a0000-0x003f0000 : "ddwrt"

I think you're on the wrong forum.

/Hello,
I have got a similar problem. I have two routers. Both Asus WL-500G Premium.

I have flashed one with openwrt-brcm-2.4-squashfs.trx and the other with openwrt-brcm-2.4-jffs2-4MB.trx

Output for squashfs one:

root@OpenWrt:~# dmesg | grep 0x00
 Amd/Fujitsu Extended Query Table v1.3 at 0x0040
0x00000000-0x00040000 : "pmon"
0x00040000-0x007f0000 : "linux"
0x000bc400-0x001b6000 : "rootfs"
0x007f0000-0x00800000 : "nvram"
0x001c0000-0x007f0000 : "OpenWrt"
root@OpenWrt:~#

nvram show _does not display_ any strange variables.

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

Output for jffs2 one:

root@OpenWrt:~# dmesg | grep 0x00
 Amd/Fujitsu Extended Query Table v1.3 at 0x0040
0x00000000-0x00040000 : "pmon"
0x00040000-0x007f0000 : "linux"
0x000c0000-0x007f0000 : "rootfs"
0x007f0000-0x00800000 : "nvram"
root@OpenWrt:~#

hexdump -C /dev/mtdblock/3

000084e0  2e 31 00 c7 4d 07 38 ee  41 80 eb 56 0a 70 dd 2a  |.1..M.8.A..V.p.*|
000084f0  01 f6 ab 05 58 4f 3d c0  7a 9a d2 5b 01 d6 d3 0e  |....XO=.z..[....|
00008500  b0 9e 33 e9 ce 63 d5 23  56 c1 61 bc 6d 35 d0 06  |..3..c.#V.a.m5..|
00008510  4f 1e 73 7f cf 1e eb 7b  32 a9 7e a2 2b e6 c4 7d  |O.s....{2.~.+..}|
00008520  b1 24 56 c4 9a 78 22 76  c4 9e d8 17 07 e2 ad 78  |.$V..x"v.......x|
00008530  2f 7a 3e 41 1d 2f b0 1e  a0 0d e6 4c fc 27 ea 36  |/z>A./.....L.'.6|
00008540  31 18 fc 94 eb 31 f3 29  d7 23 6b e2 af e0 33 31  |1....1.).#k...31|
00008550  58 37 f1 2f 38 ef 26 06  87 a6 10 c7 30 1f d0 06  |X7./8.&.....0...|
00008560  dd 29 be a3 e9 29 be a3  99 29 8e 9b 9d e2 3b 9a  |.)...)...)....;.|
00008570  9b e2 3b 9a 97 be 2f 7f  51 fe b2 f4 8a fc 55 f9  |..;.../.Q.....U.|
00008580  8f a4 cf 07 59 5f 34 c8  fa f2 41 d6 57 08 b2 be  |....Y_4...A.W...|
00008590  8b 20 f3 f5 82 cc 77 15  d4 79 99 66 dd 9e 69 d6  |. ....w..y.f..i.|
000085a0  7d 30 ad f3 32 4d ff e1  34 fd 35 e9 0d f1 78 9a  |}0..2M..4.5...x.|
000085b0  75 b4 a6 59 c7 a9 f4 b7  ea d7 51 bf 0b e9 ef e4  |u..Y......Q.....|
000085c0  bf 94 ff 5a fa ce 13 e8  7f 60 1d 40 1b bc 78 42  |...Z.....`.@..xB|
000085d0  7d eb 29 74 17 ef 28 68  83 67 26 5e 45 7e 13 83  |}.)t..(h.g&^E~..|
000085e0  e7 4f 95 57 1c 99 21 fd  62 03 1c fe 09 e7 13 b4  |.O.W..!.b.......|
000085f0  c1 be 89 ff c2 b8 26 06  9d 67 6c 9f 7c c6 76 cf  |......&..gl.|.v.|
00008600  73 b6 fb 9e b3 3d fe 9c  79 52 46 2f 61 ff 8c 0e  |s....=..yRF/a...|
00008610  d6 4c fc 0d d6 dd c4 e0  95 fa f5 d5 ef 5e fd 86  |.L...........^..|
00008620  42 cc 3f 12 62 fe 1d 13  63 6e 59 13 83 e5 90 f6  |B.?.b...cnY.....|
00008630  33 c4 73 52 0d f1 9c f4  42 dc c7 77 21 ee 63 5f  |3.sR....B..w!.c_|
00008640  3e 37 0c bd 80 f3 03 da  60 37 cc f3 7a 1e e6 79  |>7......`7..z..y|
00008650  7d 17 d6 bb f3 3f 5f f0  fc 0e 5e f0 fc 66 5f ea  |}....?_...^..f_.|
00008660  1e 82 c3 38 33 7b a0 0d  5e bc e4 78 bd 97 1c 00  |...83{..^..x....|
00009080  a5 bf a2 e2 5d 53 f1 96  95 9e dc 26 cf f7 7f 66  |....]S.....&...f|
00009090  4e 51 f7 78 da 35 96 3f  4c a2 67 1c c7 df 34 fa  |NQ.x.5.?L.g...4.|
000090a0  d6 b3 48 38 cb d9 b7 9c  ad 78 e7 1d dc 1d e7 9f  |..H8.....x......|
000090b0  93 16 50 54 d4 b7 29 4d  4d 6b 1a 06 db 90 96 c1  |..PT..)MMk......|
000090c0  a4 a6 61 a0 ad 69 68 63  5a 9a 30 38 30 30 30 30  |..a..ihcZ.080000|
000090d0  38 30 30 38 30 30 38 38  38 dc c0 c0 e0 e0 c0 70  |800800888......p|
000090e0  83 83 03 83 03 83 83 83  83 43 bf 4f be df 0e e4  |.........C.O....|
000090f0  93 df f7 f9 3e bf e7 f7  fc 7d 19 7a df b2 ec 61  |....>....}.z...a|
00009100  cb 1a 01 87 7f b4 2c 8f  89 c1 82 89 9f 59 d6 be  |......,......Y..|
00009110  89 c1 23 13 47 2c ab 61  62 b0 a3 f6 ae da 7d 0f  |..#.G,.ab.....}.|
00009120  10 23 8f ff 01 f3 39 26  fe d5 b2 26 4d 0c 86 c1  |.#....9&...&M...|
00009130  a1 f7 2c 6b 5e be a8 7c  71 c5 49 c5 29 f5 73 d5  |..,k^..|q.I.).s.|
00009140  2f a3 7e 39 f9 76 e5 2b  c8 b7 2f 5f 49 be 43 f9  |/.~9.v.+../_I.C.|
00009150  2a f2 55 e5 ab c9 d7 90  ef 58 be 96 7c 6d f9 4e  |*.U......X..|m.N|
00009160  e4 7b 2b 5f 57 be 73 f9  2e e4 eb c9 77 25 df b5  |.{+_W.s.....w%..|
00009170  7c 03 f9 6e e4 bb 95 cf  1a a5 6f 64 94 3e cf 28  ||..n......od.>.(|
00009180  7d be 51 fa fc a3 f4 05  e5 0b cb 17 91 6f 5e be  |}.Q..........o^.|
00009190  a8 7c 29 f9 d2 f2 6d c9  b7 3d ca 7d cc 8c 72 1f  |.|)...m..=.}..r.|
000091a0  73 f2 ed 19 fd 77 cb ca  1b 1d 2c 4a 2f 19 3d 61  |s....w....,J/.=a|
000091b0  59 65 a3 83 55 e9 75 e5  3d 52 de 86 f2 36 95 b7  |Ye..U.u.=R...6..|
000091c0  2d df bd d1 bf c3 fc 3e  80 0e 76 3c d4 f3 63 e4  |-......>..v<..c.|
000091d0  fe 18 f3 14 c7 98 e7 60  8c 79 4a 63 cc 53 91 af  |.......`.yJc.S..|
000091e0  2e 36 c5 96 fa b5 d5 ef  44 fd 4e d5 af 23 5f 4f  |.6......D.N..#_O|
000091f0  bc 14 07 c6 17 c2 fa 1b  1f e8 f3 22 de c3 fa 82  |..........."....|
00009200  36 18 f4 6a 7d bd 5a 5f  af d6 d7 cb fc 51 2f f3  |6..j}.Z_.....Q/.|
00009210  a7 e5 db 96 2f 23 df 8e  7c 59 f9 0a f2 15 e5 3b  |..../#..|Y.....;|
00009220  90 af 24 5f 59 be 9a da  eb 6a 6f aa df 8d 97 eb  |..$_Y....jo.....|
00009230  77 eb e5 fa dd 3c a4 7e  f7 90 fe fb 87 f4 5b e3  |w....<.~......[.|
00009240  cc 37 34 ce 7c be 71 fa  1c 31 38 4e ff cc 38 fd  |.74.|.q..18N..8.|
00009250  61 f9 23 f2 c7 e5 4b 8b  19 31 27 e6 c7 b9 6e 85  |a.#...K..1'...n.|
00009260  71 ae 5b 55 7a 5d 79 8f  94 b7 a1 bc 4d e5 3d 51  |q.[Uz]y.....M.=Q|
00009270  fb a9 da 3b ea 77 f5 21  19 f5 93 49 3f 7d 29 3f  |...;.w.!...I?})?|
00009280  7d ae 9f 79 d2 7e e6 c9  c8 d7 36 3a 78 62 74 93  |}..y.~....6:xbt.|
00009290  47 ba e7 11 75 df 23 ea  b9 47 f2 1b 3d 0b bf d1  |G...u.#..G..=...|
000092a0  c1 4b 13 2f a2 9f 89 c1  81 7c e5 09 fa 0e 27 e8  |.K./.....|....'.|
000092b0  3b 9e a0 af 35 41 df 85  89 7f c6 79 32 31 78 35  |;...5A.....y21x5|
000092c0  a1 7b 6d f4 af 91 c7 e8  e0 9d f4 f4 47 64 55 4c  |.{m.........GdUL|
000092d0  3a cc 9f 72 98 3f e7 30  ff ae c3 fc 87 0e f3 57  |:..r.?.0.......W|
000092e0  1c e6 af 3b ec d7 70 98  bf e9 30 7f 5b fa c8 c7  |...;..p...0.[...|
000092f0  e4 ae 98 17 cb 62 55 f4  04 38 ae 2f c0 71 dd 00  |.....bU..8./.q..|

Two variables...

The first 32K of nvram partition (up to 0x8000) contains only hex ff's on both devices.

If You need more output, please let me know.
Best regards

PS. No other firmware was used on these two routers. Only OpenWrt.
PS2. There is also a line that reads "=192.168.10.100". How do I get rid of it? It seems that it has no name...

aes wrote:

Hi,

I do not know how I got that, but I have some kind of a non asci char variable name in my nvram. I you do a nvram show you can see the first part of the variables and on some point the console turn into garbage chars. I have to disconnect reset my xterm and connect regain a readable console.
Resetting to factory defaults (Reset button pressed for a long period) did not helped me. The nvram_clean.sh script from the faq section cleared many unneded variables but this wierd one survives. Any idea how I can get rid of that variable. I would not risk the nvram earase option if possible.
Maybe one linux guru know a command line to grep that nvram variable from the nvram show command and pipe it as an argument to an nvram unset command.

Sounds like a conflict of locales (UTF-8 and ISO-whatever). I find the same thing happens on my lfs desktop box (iso-thingy) when I cat /dev/urandom).

It may in fact be an important variable, created with the wrong locale. If you are running Openwrt (as the forum implies) instead of DD-wrt (as your post implied), DD-wrt may have created an important variable that openwrt never changed, but they were based on different locales.

I have no idea, but it may be a possible reason

poly-p man

Having a similar issue. I have two lines in my nvram that I haven't seen before:

size: =1
l´½*

Here's a bigger chunk of the "nvram show" output in which the lines appear:

audio_PCM=1
wl0_gmode_protection=off
pa0b0=0x170c
size: =1
l´½*
wl0_maclist=
filter_tod6=
pa0b1=0xfa24

At first I thought it might be due to a buffer display error in PuTTY or something, but no:

root@grandpa:/etc# nvram show |grep '*'
size: 11666 bytes (21102 left)
private_shares=All_Partitions:*:comment:/foreign_shares
l´½*
root@grandpa:/etc#

As you can see, they aren't real variables in the form of [variable name]=[variable], so they can't be set or unset. And if I search the hexdump for the line with the "*", all I get is this:

root@grandpa:/etc# hexdump -C /dev/mtdblock/3 | grep '*'
*
0001a6c0  6c 6c 5f 50 61 72 74 69  74 69 6f 6e 73 3a 2a 3a  |ll_Partitions:*:|
0001a9b0  0a 6c b4 14 bd 2a 00 70  61 30 62 30 3d 30 78 31  |.l...*.pa0b0=0x1|
*

Why is it there? Should I be concerned?
Thanks.

The discussion might have continued from here.