Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Hello Vladimir, you are right! but I would have sworn I tried that (in fact, after writing the post I thought I have forgoten comment that "the issue" seems related to an UTF issue) Sorry and thank you! Regards Josep
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,...)
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).
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?
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
Hello! In fact, I had already tried the "Easy way", and there is no easy way (at least, not so easy). It seems that there is something missing, because after installing the llvm package, when building jancy it seems to go well... but eventually fails
(I do not know, but perhaps the available package for Arm have differences respect the "regular" x86-64 one)
Anyway, I will take the Way of the Samurai, and let you know what happens. Thank you, and regards!
Hello! I tried to build LLVM 11.0.1, but it eventually fails
I followed the same indications that are in the Jancy building guide: and then just "make" it. Do I have to do some different? Take into account that I have nearly zero knowledge about cmake and building process (and less than zero about LLMV), so perhaps I am missing some basic thing. Regards
Hello Vladimir, I tried it, but I found a problem. I tried to do tha same, but an error appears:
I think it could simple be a issue with the generation of the pcap file by the ioninja-hwr.
If instead of pipe the output, I save it to a file, and then open it with wireshark, the same error appears.
As complementary piece of info, the ethernet tap FW upgrade from the IONINJA works like a charm ... but in first place I tried the command line option and does not work: I issued the command and nothing seems to happen... after many time (> 30 min) I decided CTRL-C it (shiver down my spine). It terminates well, and then I tried the IONINJA option that works well, so nothing bad seems to have happend.
Let me know if I can provide more info.
Hello! Quite sure that this solves the issue. I try and confirm you that. Thank you! and -about the Ethernet tap- they are great news!!
Great news!! Thank you, I try it and tell you ASAP.
Hello again Vladimir! This is not a big issue for me, but I tell you, fyi, as could be useful to fix something. I tried to build Jancy in a aarm64 plataform (a Rasperry Pi 3 and a Rock64, with Arch Linux 64). I was able to build it (more details below), but when I "make test", there are many failed tests.
Looking inside the LastTest.log, I saw something I felt could be at the root of the problem, the SISSEGV event (I have no problem to provide you the file, if you want it)
As I commented, in fact, I have an issue when building it, the problem was when proceding to the "cmake" of de LLVM 3.4.2, then an error of triplet unknown is thrown an it said about use a more recent version of the config.guess and config.sub (the message even told about where you can wget them). Once updated, LLVM could be build.
Well, as I told you, it is not a big issue for me (as I am not sure if were going to use Jancy in those plataforms), but perhaps this info is useful to you, or could be indicative of other problems.
Also, I confirm that I am able to build Jancy on a Intel PC without problem (0 tests failed)
Hello Vladimir, finally I've a few minutes to try the build. There is a significant improvement!, but under the same type of test, there are still losses. This corresponds to 72 s capture (tcpdump on the interface vs hwc), and the displayed frames are ICMP ones (16 is the right value). And, logically, it remains the issue of the MAC address. I'd like to perform the same test, but under a slightly lower load, and also try using a more powerful platform as host for the ioninja-hwc, but I did not have time. Sorry. If (when) I eventually could, I will report you. Regards! Josep
Hello Vladimir! Well, unfortunatelly, I'm going to re-post more or less what I wrote yesterday, as I did try the new build, and I found that something seems not ok. I deleted the post because I realized that the link I was trying is a gigabit one (so, my mistake), but today I replied the test forcing a 100Mbit/s link, and I found a similar issue. Let me report you. Just starting to capture with the new build, I've the "feeling" that "something is lost / wrong". So I tried the following, I capture (tcpdump -i end0 -s0 -U -w - | TMPDIR=/root/tmp00 wireshark -k -i -) in the same interface that I put the tap (ioninja-hwc --ethernet-tap --pcap | TMPDIR=/root/tmp00 wireshark -k -i -). The pcap should be the same. Those two commands are issued in the same device. I've captured data for a minute -simultaneously-, and I filtered both pcaps preciselly. Also I have done "pings" to the device at the beginning and end of the capturing, in order to have some reference. The load is a bit large (there are a couple of X11 over SSH sessions) but it seems perfectly realistic case (the interface seems to work a 10 Mbit/s). Doing this, I saw that the "tcpdump" capture is 744k packets, whilst the ioninja-hwc is 133k. So many packets are lost Also, if I look for the pings, I can see that in the "tcpdump" there are all that I generated (from 172.31.25.2) and the replies, whilst with "ioninja-hwc" there are few pings. This is also useful to see that both pcaps are in sync. Also I attach a IO Graph for both cases: I have also checked the USB that it is used to connect the tap, and I is working as "Hi-Speed" (480 Mbit/s).
And (today), I also check the link speed
And the ethernet conversation, in which -again- it seems that many errors are injected in the ioninja-hwc pcap, (the tcpdump one is perfectly normal)
Well, this is a quite issue, as it seems not be reliable, and just -when you are using a tap- is because you are looking for some kind of problem on the "device under test", and you do not want to worry about the "tap" device.
If you need any more data, please let me know. I hope I did (again) something wrong and it is my fault (o -if I am right- that it would be easy to fix).
(ops... I wrote a quite long post, reporting an issue, but I think I did something basically wrong... let me check...)