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).
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.
Regards! Josep
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...)
Hello Vladimir, Thank you! From my side, I am not in a hurry, so take your time in order to do it in the most convenient way for you. Also, for the record, I wrote the post very quickly, and I forgot to mention another advantages I find to your tap. Besides less cabling and no "external" power supply required, it is also nice do not use an ethernet interface in the host device (it is easier to find USB ports, and RJ45 are increasingly hard to find in PC), and also -specially if you end up with an external USB to RJ45 converter attached to the PC- there are some chances that these NIC does not support promiscuous mode, so you can not use for capturing. Regards Josep
Hello! I've been trying an Ethernet tap. I've been working with other ones (eg the Dualcomm one) but I prefer the ioninja approach, because is less messy connecting it, as it uses a "simple" USB cable instead of a Ethernet + power cable in the other cases. But I found some serious troubles. For me it is vital to be able to use it to feed directly Wireshark. Let me report you:
it seems that ioninja-hwc does not timestamp the frames. E.g. I tried "ioninja-hwc --ethernet-tap --pcap | wireshark -k -i -". It works, but the timestamp is weird Doing something similar with, for example, tcpdump (tcpdump -i any -s0 -U -w - | wireshark -k -i -), gives a correct timestamp
the former ioninja-hwc command usually "stops" capture packets a few seconds after start. Again I compared that with what happens using the "tcpdump", and using "ioninja-hwc" it usually happens after capturing a few hundreds of frames, whilst with "tcpdump" there is no problem after capturing hundreds of thousands. In some way, ioninja-hwc (+wireshark) seems to work better if firstly a .pcap file is generated, and then open (ioninja-hwc --ethernet-tap --pcap > tmp.pcap) . But this is quite inconvenient, as what I want is "live capture". As I commented, the usual is found this problem, but it seems that in some cases it works well for more time or indefinitely (?). Using named pipes (mkfifo) does not change the behavior. I did this test in my dear Raspberry+Arch system. Then, I did it also in Windows, and at first I thought that it works well (as it works several minutes ok), but then I forced more traffic through the interface (not to much, simply doing a "find /" on the device which is "sniffed" (which is accessed via ssh)), and then the same problem shows up
I also found a problem with the "ioninja" main application in my Linux platform (not in Windows). If I tried to open a "Ethernet-tap session", a shared library error appears... ... I tried to download previous versions of libpcap, and then use "LD_PATH_LIBRARY" acordingly, but I was unable to workaround the issue. Anyway, for me, in first instance, it would be more important to solve the problems related to "live capture" with wireshark
Hello Vladimir!, I was going to tell you that I had tried the tdevmon and everything went smoothly: it builds ok, I was able to install the kernel module and the program works perfectly capturing data from the serial device. And, then I found that you have already prepared the ioninja "main" program. I have quickly tried, and I found no problem Thank you very much! also, FYI, as I commented, I did this on a Rock64 plataform, with Arch Linux Arm. Eventually (soon), I will also tried it on a Raspberry. If I find any issue, I will tell you. Regards, and thank you again!
Ok! Do not worry! In the mean time, if I need it, I would -with some care- use the ioninja-hwc as it seems to work well. If I found anything unexpected, I will let you know. Regards and thank you!
Hello Vladimir, I've done a quick tests. ioninja-hwc: I have tested it with a (1) serial-tap, and it worked ok. tdevmon: I found one error compiling the kernel module. It gave a "incompatible-pointer-type" error. The same kind we saw before, in this same email chain, perhaps it is something related.
(I've checked that the linux-headers and the kernel version match)
Just fyi, also I tried the "GUI" ioninja, and it gave me an error when "JITting", e.g., going to use the "serial tap" plug-in... but perhaps it is normal and expected, as we have just been talking about the "ioninja-hwc" (and "tdevmon")
Regards!
Hello Vladimir! Thank you! Of course, I will be glad to test them! For me, it is more important the ioninja-hwc, as what I want to do is deploy a device with a serial tap attached to it. Regards
@vladimir thank you!
ops... when I wrote "SO" I meant "OS" ("linux")... I'm a bit dyslexic (and I my language so it goes this acronym), and I did it really quickly
Hello Vladimir, The problem is that it seems that it is not possible to run the 32 bit version on the box if the linux version is 64 bits. For example, the Arch Arm SO for Raspberry 4 is available in 32 and 64 bits. So I could run ioninja-hwc if the SO is the 32 bits version, but it does not run in the 64 bit SO version. The problem is that for other boxes (eg, I am testing a Rock64) there is only available the 64 bits version of ArchArmLinux SO... An it seems that it is difficult to find 32 bits SO for ARMv8 plataforms. I tried to find an alternative to ArchArm for this Rock64 SBC, and look into AOSC and Armbian, but I think that they are also 64 bits versions. The reason I am using a Rock64 is basically availability, I tried to find Raspberries, but they are out of stock. Regards!