В Sun, 18 Sep 2011 21:30:09 +0300 Roman Yeryomin <leroi.li...@gmail.com> пишет:
> On 18 September 2011 20:51, Alexander Gordeev <lasa...@lvk.cs.msu.su> wrote: > > В Fri, 16 Sep 2011 18:06:15 +0300 > > Roman Yeryomin <leroi.li...@gmail.com> пишет: > > > >> On 16 September 2011 17:51, Alexander Gordeev <lasa...@lvk.cs.msu.su> > >> wrote: > >> > В Fri, 16 Sep 2011 17:41:37 +0300 > >> > Roman Yeryomin <leroi.li...@gmail.com> пишет: > >> > > >> >> On 16 September 2011 01:40, Alexander Gordeev <lasa...@lvk.cs.msu.su> > >> >> wrote: > >> >> > В Fri, 26 Aug 2011 04:30:43 +0300 > >> >> > Roman Yeryomin <leroi.li...@gmail.com> пишет: > >> >> > > >> >> >> This method is much more stable than reading dd's output via stdin. > >> >> > > >> >> > What kind of problems do you have with piping dd's output to stdin? > >> >> > > >> >> > >> >> It outputs garbage very frequently and maccalc fails to convert the > >> >> mac (and as a consequence uci-default script fails to set the real mac > >> >> address). Try dd without piping to maccalc and you'll see. > >> >> I've noticed this bug on ramips platform and can't say anything about > >> >> other boards. > >> > > >> > Well, then this is probably a bug in dd? Or uClibc? Or kernel? > >> > Ok, I'll try to reproduce it. Can you please tell me what exactly is > >> > happening? > >> > > >> > >> Two different reads: > >> root@OpenWrt:/# dd bs=1 skip=262148 count=6 if=/dev/mtd0 > >> "u�������6+0 records in > >> 6+0 records out > >> root@OpenWrt:/# dd bs=1 skip=262148 count=6 if=/dev/mtd0 > >> "u���6+0 records in > >> 6+0 records out > >> > >> I don't think this is the bug in dd/kernel/uclibc - it would probably > >> expose when writing to a file too. > >> Maybe it's something with busybox. I'm not sure of cause. > > > > The bug is in maccalc. It does a single read() and expects to get > > everything in one shot which doesn't happen sometimes. The patch is > > attached. It fixes the problem according to my tests. > > > > I don't know whether Roman's change is necessary anymore. What do you > > think, Roman? > > > > I think how it can be that you can't read 6 bytes from stdin in one > attempt but can do it from file? Quite easyly. BTW you shouldn't even expect to read() 6 bytes from file at once. For example: $ strace -f -e trace=read,write sh -c 'dd if=/dev/urandom bs=1 count=6 | cat > /dev/null' ... [pid 9661] read(0, <unfinished ...> ... [pid 9660] read(0, "}", 1) = 1 [pid 9660] write(1, "}", 1) = 1 [pid 9661] <... read resumed> "}", 32768) = 1 [pid 9661] write(1, "}", 1) = 1 [pid 9660] read(0, <unfinished ...> [pid 9661] read(0, <unfinished ...> [pid 9660] <... read resumed> "\320", 1) = 1 [pid 9660] write(1, "\320", 1) = 1 [pid 9661] <... read resumed> "\320", 32768) = 1 [pid 9660] read(0, <unfinished ...> [pid 9661] write(1, "\320", 1) = 1 [pid 9660] <... read resumed> "x", 1) = 1 [pid 9661] read(0, <unfinished ...> [pid 9660] write(1, "x", 1) = 1 [pid 9661] <... read resumed> "x", 32768) = 1 [pid 9661] write(1, "x", 1) = 1 [pid 9661] read(0, <unfinished ...> [pid 9660] read(0, "\36", 1) = 1 [pid 9660] write(1, "\36", 1) = 1 [pid 9661] <... read resumed> "\36", 32768) = 1 [pid 9661] write(1, "\36", 1) = 1 [pid 9660] read(0, <unfinished ...> [pid 9661] read(0, <unfinished ...> [pid 9660] <... read resumed> "\24", 1) = 1 [pid 9660] write(1, "\24", 1) = 1 [pid 9661] <... read resumed> "\24", 32768) = 1 [pid 9661] write(1, "\24", 1) = 1 [pid 9661] read(0, <unfinished ...> [pid 9660] read(0, "\372", 1) = 1 [pid 9660] write(1, "\372", 1) = 1 [pid 9661] <... read resumed> "\372", 32768) = 1 [pid 9661] write(1, "\372", 1) = 1 [pid 9661] read(0, "", 32768) = 0 ... cat tries to read 32768 but gets 1 byte on every read. And, well, please read 'man 2 read'. > It doesn't "happen sometimes", it's about 50 to 70% of failed reads. > And it's not about the boards - I've tested on 3 completely different > ones. Ok, it happens often. The more the value of the fix is. > I think that there is something to do with terminal translating binary > information into something unexpected. I forgot to mention that error > occurs when there are _more_ symbols in stdout (see above). Also note > that in both reads there are exactly 6 bytes reported by dd. I think, you'd rather do no conclusions from binary output to a console. I did that: root@wimaxstore:/tmp# for i in 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9; do dd bs=1 skip=46 count=6 if=/dev/mtd2 2>/dev/null | hexdump -C | head -n 1; done 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| 00000000 00 0c 43 30 52 66 |..C0Rf| root@wimaxstore:/tmp# for i in 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9; do dd bs=1 skip=46 count=6 if=/dev/mtd2 2>/dev/null | maccalc bin2mac; done failed to read from stdin 00:0c:43:30:52:66 00:0c:43:30:52:66 failed to read from stdin 00:0c:43:30:52:66 00:0c:43:30:52:66 failed to read from stdin 00:0c:43:30:52:66 00:0c:43:30:52:66 failed to read from stdin failed to read from stdin 00:0c:43:30:52:66 00:0c:43:30:52:66 failed to read from stdin failed to read from stdin 00:0c:43:30:52:66 failed to read from stdin failed to read from stdin After this it was clear to me that the error is in maccalc. Then I fixed it: root@wimaxstore:/tmp# for i in 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9; do dd bs=1 skip=46 count=6 if=/dev/mtd2 2>/dev/null | maccalc bin2mac; done 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 00:0c:43:30:52:66 > I'll test your patch. Yes, please. -- Alexander
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
