Hello,
I'm trying to colorize an hex log, and I find a estrange behaviors.
E.g. I can colorize ok some bytes:

but others are not colorized at all

and, in a weird case, a value (0x77) colorize two bytes (0x77 and 0x57)

It seems that colorizes better low values (below 0x80) than high ones.

Another thing that could affect (?), could be that the log has been captured using "odd" parity... but ... not sure about it, as it colorizes correctly if I use 0x01 or 0x03

Regards!
Josep

Ops...and a very simple question,
what is the "Dual Hex Line size"? I tried it, and I -very quicly- try to find if there is any place where is described, but I do not find out.

Thank you, regards!

And hello again!
as today I am here writing
is there any news about a new version on Ethernet Tap?
I think you were working on it.... for me the real needed feature that I need for this kind of device it that it should be "transparent" in poweroff state. In our applications, it is critical do not cut the communications in any case, so if we install a -eg- EthernetTap it is importat that the communications do not cut even if the serialtap goes off.

(and, problably, this new Ethernet Tap would include other improvements... some memory for catching the packets, Gb,...)

Regards!
Josep

Hello again

One of the devices that we want to monitor has a TTL serial port, but with a strange customization. Its RX circuit is "regular", but the TX circuit is "inverted"... I do not know why... perhaps there is a real reason, perhaps they try to avoid use standard components...

Anyway, I am interested in capturing this communication using the SerialTap. I know (I did it before in lab) I could simply use an transistor in order to invert it, but this solucion is inconvenient when used in field (with real devices in operation), as we want that the setup that stands installed be clean and simple (and, eg, using the transitor solution, I have somehow to find a "5V Vcc")

I do not know it it would be possible to add an option in order to do this at "serialTap" level (eg. add an option to be able to consider some signals inverted, and apply some kind of "xor 1" over this circuits).

Regards!
Josep

Hello!
Again I am capturing in a remote location, without good communications, using a simple raspberry and a Serial Tap. It is permanently capturing as we are trying to catch a "sporadic" issue.
As communications are bad, we are "chunking" the logs, in order to be able to download just the piece of log in which the issue eventually occurs. Now, we are chunking it "restarting" the ioninja-hwc process every 2 hours. It is easy using the systemd capabilities (using RuntimeMaxSec), but a side efect is that we have to set a minimun restart timeout (2 min), in order to avoid that the unit goes permantly disabled if a error happens (mainly, during installation, the raspberry is powered up before the serial tap is connected...).

Well, my point is, perhaps you could consider to add an option in the "ioninja-hwc" in order to allow "fragment" the logs (some similar, or simpler, to the opcions "-C" / "-G" available in tcpdump).

Regards!

Hello! About your last post (2-jul), I will try it!
And about the previous one (1-jul; 04:16), sorry but I did not see it and I write my post -later- without been aware of it (I did it very quickly, and I was a bit confused at that moment because I spent some time finding the the thread and wandering if all was a dream (I am getting older, and I am not sure of nothing ). All in all, my post was not very coherent with what you said about having "mutable" dynamic layouts, well, I think that this could be useful, and if it is something possible without a really big difficulties/chages, I think that could be eventually useful in some cases, as you point out.
Regards!
Josep

Hello @vladimir
Thank you very much for your detailed explanation, as always it is very illustrative!!
Ok! More or less, I have the feeling that it was going to be as you comment, that the main purpose and utility of this construction is for parsing (in fact, my first impression is that it should be used inside the ioninja app (for ioninja scripts), and could not be used in "plain jancy", I was happy when I see that in fact could be used "alone").
As you said, I was thinking of using it for parsing and generating frames (IEC60870-5-103 frames), but, as you point out, it is perhaps not really very useful when constructing a frame.
Again, thank you!
Regards!
Josep

Hello!
I tried to use dylayout in "plain jancy", as it seem possible and in the changelog it is declared that replaces dynamic structs (that are interesting! but in some cases falls a bit short... I remember asking you -sometime ago- because I tried to implement a IEC103 frame generator, and it was not directly possible)

Well, I perform a quick try of the dylayout solution, and it seems even more interesting!! but I have some doubts about its use. At a very basic level

For instance, for the following code

int main()
{
        char *aa = new char[10];
        aa[0]=0x01;
        jnc.DynamicLayout layout(aa,4);

        dylayout (layout) {
                dyfield int16_t myChar;
                printf("%04d",myChar);
                // myChar = 3;          // (q1) cannot store into const location
        }
        // printf("%d",myChar);         // (q2) out of scope (expected...)
        // printf("%d",layout.myChar);  // (q2) not a member (also quite expected... but then, how?)
        return 0;
}

That works well. But,:
q1. is it possible to assign a value to a "dyfield"?
q2. is it possible to access to the "DynamicLayout" elements outside of the dylayout section?

Regards!
Josep

I confirm that the Easy Way works perfectly. Thank you and regards!
Josep

Hello Vladimir!

Using named pipes works perfectly. I quickly perform the same test I did, in three platforms: a Rasperry PI4, a Rock64 and a quite old PC (Pentium T4300 @ 2.10GHz) with Linux.

The results seems really good! Hats off!! because the task did not seem easy.

I will put some of my typical screens below, but basically: there are no estrange MAC in the conversations screen; all ICMP are in place; the captured bytes are aligned; the average MByte/s are about 7 (Rock64 cap), 25 (R PI4 cap) and 32 (x86-64 cap) and in all cases the results are coherent... Overall: "the feeling" is that all is ok

As you point out in one of your first emails, it seems not possible to have a identical pcap from tcpdump and a tap (eg. I see that the tap capture has Ethernet Frame checks, and these tcpdump ones do not (so the byte counter are different), I have doubts about how the NIC/kernel/tcpdump works, and also how frames are managed at the TAP and how are sent to the host; it seems that there are jumbo (and superjumbo.) frames (in the x84, in the tcpdump, it seems that there are many really big jumbograms); etc... (please forgive me if I said some incorrect, because this is a bit above my expertise... feel free to correct me)

Well, I put below some of the captured data fyi. Thank you, and congratulations for your work!
Regards
Josep

Rock64 - TCPDUMP

Rock64 - Tap

Raspberry PI 4 - TCPDUMP

Raspberry PI 4 - Tap