I'm currently trying to access data on both directions of a serial port connected to an an app.
What i'm trying to do is:
ttymxc0 <-----> socat sniff <------> ttyV0 <------> Application
ttymxc0 is the real port and ttyV0 is the virtual one.
I found that socat command that worked on Ubuntu 16.04:
http://www.iheartrobotics.com/2010/02/debugginng-serial-interfaces.html
But when i use it on an embedded system using buildroot, i obtain this error:
socat -d /dev/ttymxc0,raw,echo=0 SYSTEM:'tee input.txt | socat - "PTY,link=/tmp/ttyV0,raw,echo=0,waitslave" | tee output.txt'
socat[3167.1996369920] E address "GOPEN..." in intermediate context, leftdirs=4, rightdirs=7, with 1 parameter(s) is not available
socat[3167.1996369920] W cannot restore terminal settings on fd 3: Bad file descriptor
I tried to look on the access properties of my files without success. It works when you don't ask to print input and output, but that's not useful for my usage
Any ideas of what could be different between buildroot and Ubuntu in this case?
You already answered your own question, but this a slightly modernized answer is:
$ socat -x -v /dev/ttyUSB0,rawer,b115200,crnl PTY,link=ttyV1,rawer,crnl
< 2022/01/12 15:34:47.845709 length=11 from=0 to=10
65 63 68 6f 20 48 65 6c 6c 6f 0a echo Hello.
--
> 2022/01/12 15:34:47.847937 length=12 from=0 to=11
65 63 68 6f 20 48 65 6c 6c 6f 0d 0a echo Hello..
--
> 2022/01/12 15:34:47.876068 length=7 from=12 to=18
48 65 6c 6c 6f 0d 0a Hello..
--
> 2022/01/12 15:34:47.905274 length=1 from=19 to=19
24 $
--
From the socat manual:
-v "Writes the transferred data not only to their target streams, but also to stderr. The output format is text with some conversions for readability, and prefixed with "> " or "< " indicating flow directions."
raw is obsolete and rawer "makes terminal rawer than raw option. This option implicitly turns off echo."
b115200 "sets the serial line speed to 115200 baud" which is a quite common settings. Of course set the correct one for your case.
Diego's answer is great if you're fine with socat's -v output format. However, if you'd prefer creating a separate device that's just a read-only version of the original device like myself - say, so that you can open minicom on the read-only device and let other software interact with the read-write device normally - I just came up with the following that works nicely.
socat /dev/ttyUSB0,rawer SYSTEM:'tee >(socat - "PTY,link=/tmp/foobar-ro,rawer" >%-) | socat - "PTY,link=/tmp/foobar-rw,rawer,wait-slave"'
That's complicated, so I'll break it down a bit. Logically it's this:
socat /dev/ttyUSB3,rawer SYSTEM:'tee [READ-ONLY PTY] | [READ-WRITE PTY]'
And it works roughly like so:
The first socat command sets up a bidirectional pipe between the first address (/dev/ttyUSB0) and second (the SYSTEM command).
Inside the SYSTEM command now, tee duplicates its stdin (i.e. the output of /dev/ttyUSB0) to both [READ-ONLY PTY] and to its own stdout, which we then pipe to [READ-WRITE PTY].
[READ-ONLY PTY] is created with a 2nd socat command where the first address is - (shorthand for socat's STDIO address type) and the second is a new PTY. We also make sure to close this 2nd socat command's stdout with >%-; this is what makes it read-only.
For a reason I don't quite understand, unless the 2nd socat's stdout is closed, tee seems to include the output from the process substitution in its own output. I'm not sure why tee would be reading from its arguments at all.
Finally, [READ-WRITE PTY] is created with a 3rd socat command similar to the 2nd. This 3rd socat's stdout becomes the output of the SYSTEM address in the 1st socat and is fed to the original device's input, completing the loop.
Related
On one host ldapsearch was taking 20 seconds to launch.
Even if I just asked it what its version number is, it still took 20 seconds:
time ldapsearch -VV
ldapsearch: #(#) $OpenLDAP: ldapsearch 2.4.44 (Sep 30 2020 17:16:36) $
mockbuild#x86-02.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/clients/tools
(LDAP library: OpenLDAP 20444)
real 0m20.034s
user 0m0.006s
sys 0m0.008s
This isn't a question about time to search - if I asked it to search, it would spend 20 seconds before it even starts searching.
Once it starts, the search succeeds and takes about the same time as it does when invoked from other hosts.
I tried adding various command line parameters.
The only thing that returned a different result was ldapsearch --help which returns basically instantly, suggesting that the problem wasn't in loading libraries or any such.
Running strace showed that the delay was in network traffic, specifically port 53 (DNS):
socket(AF_INET6, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3 <0.000038>
connect(3, {sa_family=AF_INET6, sin6_port=htons(53), inet_pton(AF_INET6, "... poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) <0.000011>
sendto(3, "..."..., 34, MSG_NOSIGNAL, NULL, 0) = 34 <0.000033>
poll([{fd=3, events=POLLIN}], 1, 5000) = 0 (Timeout) <5.005182>
The destination for the connect call turned out to be an IP address that was being set in /etc/resolv.conf.
The IP address was unreachable.
Removing the unreachable IP address from /etc/resolv.conf made the delay go away.
How to log from command line to a specific systemd log namespace?
When using Systemd to start a service, one can give
LogNamespace=myNamespace in combination with
StandardOutput=journal as part of the configuration in the unit file.
To see the output of this namespace, it is sufficient to call journalctl --namespace=myNamespace to see only output of this namespace.
With systemd-catit is possible to print directly from command line into the journal:
echo "Hello Journal!" | systemd-cat
The print "Hello Journal!" does show up in the default (anonymous?) namespace, which is visible with journalctl. It is not within any namespace and not visible when using journalctl --namespace=myNamespace.
To be more specific on the initial question:
When looking at journalct -f --namespace=myNamespace, how to make the output of a process started from command line (without systemd, just plain binary) visible in this view?
Something like echo "Hello Journal!" | systemd-cat --log-namespace=myNamespace
I use LogNamespaces to separate different application logs. If this is not the intended use, an answer which explains how to this in another (better) way is also accepted.
first find out the pid of your journald with your namespace.
ps aux|grep jou
root 243 0.0 0.6 56176 26212 ? Ss 10:06 0:01 /lib/systemd/systemd-journald
root 10214 0.0 0.3 42308 14740 ? Ss 11:34 0:00 /lib/systemd/systemd-journald DEBUG
our instance is DEBUG
next find out what socket that instance uses:
lsof -p 10214 |grep dev-log
systemd-j 10214 root 5u unix 0x0000000003787334 0t0 61560 /run/systemd/journal.DEBUG/dev-log type=DGRAM
now we are ready to log to the desired namespace:
logger -u /run/systemd/journal.DEBUG/dev-log HAHAHAHA
journalctl --namespace=DEBUG
Jan 22 11:35:46 myportal-deb root[10339]: HAHAHAHA
Jan 22 11:38:50 myportal-deb root[10559]: HAHAHAHA
I am analyzing some events against dns servers running unbound. In the course of this investigation I am running into traffic involving queries to the dns servers that are reported as having in some cases a source port between 1 and 1024. As far as my knowledge goes these are reserved for services so there should never be traffic originating / initiated from those to a server.
Since I also know this is a practice, not a law, that evolved over time, I know there is no technical limitation to put any number in the source port field of a packet. So my conclusion would be that these queries were generated by some tool in which the source port is filled with a random value (the frequency is about evenly divided over 0-65535, except for a peak around 32768) and that this is a deliberate attack.
Can someone confirm/deny the source port theory and vindicate my conclusion or declare me a total idiot and explain why?
Thanks in advance.
Edit 1: adding more precise info to settle some disputes below that arose due to my incomplete reporting.
It's definitely not a port scan. It was traffic arriving on port 53 UDP and unbound accepted it apparently as an (almost) valid dns query, while generating the following error messages for each packet:
notice: remote address is <ipaddress> port <sourceport>
notice: sendmsg failed: Invalid argument
$ cat raw_daemonlog.txt | egrep -c 'notice: remote address is'
256497
$ cat raw_daemonlog.txt | egrep 'notice: remote address is' | awk '{printf("%s\n",$NF)}' | sort -n | uniq -c > sourceportswithfrequency.txt
$ cat sourceportswithfrequency.txt | wc -l
56438
So 256497 messages, 56438 unique source ports used
$ cat sourceportswithfrequency.txt | head
5 4
3 5
5 6
So the lowest source port seen was 4 which was used 5 times
$ cat sourceportswithfrequency.txt | tail
8 65524
2 65525
14 65526
1 65527
2 65528
4 65529
3 65530
3 65531
3 65532
4 65534
So the highest source port seen was 65534 and it was used 4 times.
$ cat sourceportswithfrequency.txt | sort -n | tail -n 25
55 32786
58 35850
60 32781
61 32785
66 32788
68 32793
71 32784
73 32783
88 32780
90 32791
91 32778
116 2050
123 32779
125 37637
129 7077
138 32774
160 32777
160 57349
162 32776
169 32775
349 32772
361 32773
465 32769
798 32771
1833 32768
So the peak around 32768 is real.
My original question still stands: does this traffic pattern suggest an attack or is there an logical explanation for, for instance, the traffic with source ports < 1024?
As far as my knowledge goes these are reserved for services so there should never be traffic originating / initiated from those to a server.
It doesn't matter what the source port number is, as long as it's between 1 and 65,535. It's not like a source port of 53 means that there is a DNS server listening on the source machine.
The source port is just there to allow multiple connections / in-flight datagrams from one machine to another machine on the same destination port.
See also Wiki: Ephemeral port:
The Internet Assigned Numbers Authority (IANA) suggests the range 49152 to 65535 [...] for dynamic or private ports.[1]
That sounds like a port scan.
There are 65536 distinct and usable port numbers. (ibid.)
FYI: The TCP and UDP port 32768 is registered and used by IBM FileNet TMS.
I'm trying to use dcm4che for downloading images from the free http://www.dicomserver.co.uk/. I've cloned and checked out the 5.13.2 version and built it using mvn install. Now when I go into the dcm4che-assembly/target/dcm4che-5.13.2-bin/dcm4che-5.13.2/bin directory and try to download a StudyInstanceUID:
./movescu -c DCMQRSCP#www.dicomserver.co.uk:104 -m StudyInstanceUID=1.2.826.0.1.3680043.11.105 --dest STORESCP
I get the error:
...
(0000,0902) LO [Unknown Move Destination: STORESCP] ErrorComment
...
The error indicates that it can't connect to the the receiver. I've tried to run:
./storescp -b STORESCP:11112
without much success. I've also tried to run the dcmqrscp with similar outcomes.
My humble request: Please provide a working example of the movescu.
Details
I can get the findscu to work without issues, e.g.:
./findscu -c DCMQRSCP#www.dicomserver.co.uk:104 -m StudyInstanceUID=1.2.826.0.1.3680043.11.105 -r PatientID
gives:
(0008,0005) CS [] SpecificCharacterSet
(0008,0052) CS [STUDY] QueryRetrieveLevel
(0008,0054) AE [DCMQRSCP] RetrieveAETitle
(0010,0020) LO [PAT004] PatientID
(0020,000D) UI [1.2.826.0.1.3680043.11.105] StudyInstanceUID
Similarly the getscu command seems to work:
>./getscu -c DCMQRSCP#www.dicomserver.co.uk:104 -m StudyInstanceUID=1.2.826.0.1.3680043.11.105
Creates the following DICOM files:
ls 1* -lh
-rw-rw-r-- 1 max max 12M jul 7 12:16 1.2.276.0.7230010.3.1.4.39332053.7432.1527748041.31
-rw-rw-r-- 1 max max 150K jul 7 12:17 1.2.276.0.7230010.3.1.4.8323329.11391.1527939718.955155
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.100
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.104
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.108
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.112
-rw-rw-r-- 1 max max 6,0M jul 7 12:16 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.80
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.84
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.88
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.92
-rw-rw-r-- 1 max max 6,0M jul 7 12:17 1.2.826.0.1.3680043.9.6384.2.2087.20180322152557.400.96
Lastly, I'm sorry if this question falls into the duplicate category. After spending days without finding a working movescu example on either StackOverflow or the dcm4che-forum, I've given up searching. The goal is to have an example to use so that I can modify the underlying Java code for my own purposes. Also let me know if you're interested in the entire movescu dump.
Update
After Tarmo's helpful tip I tried to (1) use the correct AE & port and (2) change to Orthanc. Unfortunately I still can't retrieve an image from the dicomserver.co.uk but the Orthanc solution worked.
Below is the summary of the outcomes:
Alt. 1: Port & port compliance
As it seems part of my issue was RTFM-related:
Use any calling and called AE titles you like (making them specific to you will assist if logs need to be examined), but if you wish to use C-MOVE, ensure that the calling and destination AETs are the same, and that you listen on port 104.
My first attempt was to align the two AE-titles:
./movescu -c STORESCP#www.dicomserver.co.uk:104 -m StudyInstanceUID=1.2.826.0.1.3680043.11.105 --dest STORESCP
This does not work and it turns out that the destination port is random. At both ends (server log + local) one can find that the port was:
14:23:47,539 INFO - MOVESCU->APA(1): close Socket
[addr=www.dicomserver.co.uk/88.202.185.144,port=104,localport=57985]
The localport changes between each attempt. Things that I've tried so far:
Variants of --dest (1) STORESCP:104, (2) STORESCP$localhost:104, (3) other AE-titles
Starting up a SCP through sudo ./dcmqrscp -b STORESCP:104 --dicomdir /home/max/tmp/dcm (the sudo is due to the low port number) and calling with AE-title only as dest
Same as above but with the -b option: ./movescu -c STORESCP#www.dicomserver.co.uk:104 -b STORESCP#localhost:104 -m StudyInstanceUID=1.2.826.0.1.3680043.11.105 --dest STORESCP
Same as above without the SCP and with my local IP/external IP (no firewall changes made)
I've also tried USB-tethering through my phone to circumvent the router but the phone operated at IPv6 and not v4
It would still be nice to know how to set this up as it could be quite useful. My guess is that since C-MOVE provides the raw IP-address to the dicomserver the 104-port needs to be forwarded to the current machine. Being new to the DICOM-protocol I find many of these features somewhat cryptic...
Alt 2: Local Orthanc server (WORKS!)
Here's the full set-up for anyone that wants to get a test system up and running (using Ubuntu 18.04):
sudo apt install orthanc & check that the service is started systemsctl status orthanc.service
In /etc/orthanc/orthanc.json uncomment the line with: "sample" : [ "STORESCP", "localhost", 2000 ] and restart the server systemsctl restart orthanc.service
Go to http://localhost:8042 (unless you've changed the web-port at /etc/orthanc/orthanc.json)
Navigate into upload and find a dcm-file for uploading (you can find dcm-files to download here: https://www.dicomlibrary.com/ or you can use the getscu from above)
Drag and drop the dcm-file into http://localhost:8042/app/explorer.html#upload + press "Start the upload"
Go to patients and get the new StudyInstanceUID for the uploaded image
Start a SCP-service with the STORESCP and 2000 port that you allowed in the /etc/orthanc/orthanc.json, e.g. ./dcmqrscp -b STORESCP:2000 --dicomdir /home/max/tmp/dcm
Call the movescu with the -b to the above SCP with the new StudyInstanceUID (shortened below for readability), e.g.:
./movescu
-c ORTHANC#localhost:4242
-m StudyInstanceUID=1.2.826.0.1.3680043.8.....
-b STORESCP#localhost:2000
--dest STORESCP
And that's it!
Please read the C-MOVE information on the http://www.dicomserver.co.uk/ homepage again to figure out, how to set up your query. Your syntax for the command is correct, but some details are wrong.
Basically you need two things:
Your calling AE title must be the same as the destination AE title. You have them different at the moment
Your storescp must be accessible from the public internet on the same port, that you used to connect to dicomserver.co.uk, in your example that is 104. Their server needs to make a new TCP connection back to your computer for it to work.
I think it would be easier to install a lightweight PACS on your local machine to test your applications with (e.g. Orthanc). Getting DICOM C-MOVE to work over public internet is asking for trouble in my opinion.
I have a brand new Atmega2560 sitting on a board that I made. I'm trying to use a Sparkfun AVR Pocket Programmer to program the board with USBTiny/AVRdude but when I input avrdude -c usbtiny -p atmega2560 -v -v -v into the CMD for avrdude, I'm getting an error as seen below
avrdude: programmer operation not supported
avrdude: Using SCK period of 10 usec
CMD: [ac 53 00 00] [00 00 00 00]
CMD: [ac 53 00 00] [00 00 00 00]
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
I checked connections and the board is fine. I was able to program it with a friends AVR Pocket Programmer without issue. For some reason, this one isn't working. I programmed another board I have without issue so I don't think it's the pocket programmer. I would use his again, but he's in another state.
Any ideas?
So I ended up triple checking my connections and MOSI wasn't fully connected to the board. Strange.
Suggestions for those who run into this issue in the future:
Check connections. Double check connections. Triple check connections. Make sure the pad from the MCU is touching the pad of the board
Try slowing the speed of the read. ex: avrdude -c usbtiny -p atmega2560 -B 250
Make sure your avrdude is upto date - I'm currently using avrdude version 6.0.1
Make sure your drivers are up to date
From what I've read, with other peoples experiences, is that it is usually number 1 - the connections not being correct.
For others, if you changed your fuses and it stopped responding. You may have 'bricked' your MCU and need the programmer/debugger from AVR to unbrick it.