I've received one reply, and thanks again, but I had better remove the gzip-"inconsistency" related bloat from my own previous email... I need the previous text to make the remaining three important parts/issues/inconsistencies clearer and easier to check, and reply to, any of the three.
I will also reorder my quotes to get them easier to skip or skip to, since they are separate issues/inconsistencies. On 170501-18:17+0200, Miroslav Rovis wrote: ... First issue =========== (All first issue-related text have been removed here from all quotes from my previous message) ... Second issue ============ > Another part is actually on Wireshark mailing list. Pls. see: > > Filtering on (negated) frame.time_relative filters out wrong frame.number > https://www.wireshark.org/lists/wireshark-users/201704/msg00037.html > as well as my study at: > https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/git-devuan-mail-4.php That page has just been updated with clearer instructions. > (and the previous ones there, but I gave the last as it is simplest/fastest > to check) > > There is information that any advanced reader can easily provide by retracing > some of my steps there, and which would clear some uncertainties here. ... > ... That's a serious bug or a > serious malfunction in my Gentoo, the latter being most likely... > > And if it is the latter, it can only be one or the other way. One: the cause > is in some Gentoo packge. Two: it is an attack by some unknown means. > > ( > If Air-Gapped is some info, I did try and editcap (and the whole > Wireshark) behave in the same wrong way in my Air-Gapped too. > ... > ) > Third issue ========== The text it too much because the command line in which bash throw strange error is a long for loop. The main point is marked with short new text below. > This is one of a series of commands that I used to check one of the backups, > in three different instances of tar-gzip'd archive I checked (such as the > /root directory tar-gzip'd today), and which showed faultless upon > decompression in all the three instances, despite the three instances of > tar-gzip'd archives not being identical (as their SHA256 sums show): > > # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed > 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed > 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in > $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; > fi; done ; cd - ; done ; > > Now if I just place the cursor, by moving with Alt-F (skipping "words") and > Ctrl-F (skipping 1 char) to just after: > > "for i in $(ls -1d root_170430_g0n*.d/" in that command, > > and if I then hit Tab for completion on the experssion there, I get (and I'm > sorry for the mess, but that's what I get): > > g0n ~ # for i in $(ls -1d root_170430_g0n*.dbash: unexpected EOF while > looking for matching `)'bash: syntax error: unexpected end of > file//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in $(find > ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; fi; > done ; cd - ; done ; > > NOTE (at proofreading time): rechecked, I do get that same behavior the day > after (wrote most of this yesterday, still to send this morning). > > [[ > NOTE (before delayed sending): In fact, it is only this clone that exibits the > above Bash malfunctioning. I just checked the same for loop command (some six > paragraphs above) in my Air-Gapped master [1] (never any internet it sees, The [1] is important for understanding, especially this Bash issue in my Gentoo instance. Because in my Air-Gapped Gentoo instance that issue does not show at all. > longer workaround/detailed checking before updating it with stuff from > internet, sneakernet or optical media), and it is just fine. That line, simply > gave what it should: > > # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed > 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed > 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in > $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; > fi; done ; cd - ; done > root_170430_g0n_1.d// root_170430_g0n_2.d// root_170430_g0n.d// > # [[and the same command line was back here]] > > under exact same conditions/circumstances as the clone of my Air-Gapped. And > it's similar with some other completion issues: they seem non-existent in my > Air-Gapped. > ]] This is the main point (in my clone that I use for online): > IOW, first, Bash sullied the entire line, which is not very considerate of > Her, and second that's not some usual error. Just for clarity, it wrote this: > The error: > bash: unexpected EOF while looking for matching `)'bash: syntax error: > unexpected end of file > > (and it wrote it by overwriting, which I never used to see in Bash) ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | Anyone else such behavior as well? > > What's going on there?... Ah... Importantly: > > do any of you other users get some erratic unusual behavior like this with > Bash? > > Of course, I can move to the start of the line with Ctrl-A and then issue > Ctrl-K to clear and capture to the entire line and then issue Ctrl-Y to paste > it back, and no disorderly message remains, but Bash isn't behaving... > ... > ... if the reader has this bash version installed: > $ bash --version > GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu) > Copyright (C) 2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > > This is free software; you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > $ > they might be able to reproduce such kind of misbehavior. Else it's only in my Gentoo instance (and only the for-online clone, not in my Air-Gapped Gentoo instance). Fourth issue ============ > And finally, and this is what eix throws on any package that I would check: > > g0n ~ # eix memtest86+ > * sys-apps/memtest86 > Available versions: 4.3.7 (~)4.3.7-r1 {serial} > Homepage: http://www.memtest86.com/ > Description: A stand alone memory test for x86 computers ... > > Found 2 matches > Received SIGSEGV - you probably found a bug in eix. > Please proceed with the following few instructions and help us find the bug: > * install gdb (sys-devel/gdb) > * reemerge eix with FEATURES="nostrip" CXXFLAGS="-g -ggdb3" LDFLAGS="" > * enter gdb with "gdb --args eix your_arguments_for_eix" > * type "run" and wait for the segfault to happen > * type "bt" to get a backtrace (this helps us a lot) > * post a bugreport and be sure to include the output from gdb. ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | Anyone else gets this too? ... > --- > [1] My methods are still these: > Air-Gapped Gentoo Install, Tentative > https://forums.gentoo.org/viewtopic-t-987268.html > > and > > Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion > https://forums.gentoo.org/viewtopic-t-999436.html#7613044 > -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr
signature.asc
Description: Digital signature
