Fixed IP address for R5C9B is 10.1.10.204. Data collection program noted that sending
data address changed from 10.1.10.204 to 172.17.0.4 just over two days ago. System last
restart was about 78 days ago. I have log files available. IP address seems to be assigned to
docker
Hello TerryD,
yes, please, if you could send the log files it would be the best, so we can investigate a bit deeper.
In the meanwhile, have you tried this procedure for setting a Static IP described in the manual?
https://manual.raspberryshake.org/staticip.html
Let’s see, from the log files it appears that all systems are operating nominally, and from the file myshake.out it is possible to see it in the eth0 section that the IP address is the first you wrote:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.1.10.204 netmask 255.255.255.0 broadcast 10.1.10.255
Raspberry Shake servers are receiving the data without issues, what is the precise problem that your data collection program (can you tell us which program are you using?) is experiencing?
I am using a Windows C program of my own construction (from scratch) to
collect and store raw data.
I read the UDP data using “recvfrom()”
which provides the sending IP address of the received data.
I can confirm that the sending IP address is 172.17.0.4 by looking at
the raw IP packet data
with WireShark so I have some confidence that this isn’t an artifact of
my program.
I logged onto the system with putty and issued
putty.log (3.53 KB)
hi,
and there are no problems with receiving your data?
i’m still trying to figure out what your problem is, or what your question might be.
by the way, you might want to have a look at the UDP data-casting functionality to pick up the raw data, it comes in a much more straightforward format, is python-accessible, and is the intended high-level way to do this. no need to write low-level C programs since the raw data is exposed at a higher level.
glad your system continues to work as it should.
cheers,
richard
[ivor] ivor https://community.raspberryshake.org/u/ivor Leader
August 20hi,
and there are no problems with receiving your data?
Well, to me, network security is an issue worthy of concern. When I
start seeing
data on my network wire from an unexpected source, that encourages me to
investigate.
While mine is just a home network with a variety of devices I know that
there
is interest in having Raspberry Shake devices on school and library and
corporate
networks that have ample reason to be concerned about network security.
In a former lifetime I was employed by Google with an assignment in
infrastructure security.
i’m still trying to figure out what your problem is, or what your
question might be.by the way, you might want to have a look at the UDP data-casting
functionality to pick up the raw data, it comes in a much more
straightforward format, is python-accessible, and is the intended
high-level way to do this. no need to write low-level C programs since
the raw data is exposed at a higher level.
I have similar python based data collection software running our
original 50 Hz 1D in Kapa’au, HI.
Unfortunately the DSL network doesn’t let me monitor that system from
San Jose, CA
as well as I would like so I cannot tell if that system has exhibited
similar issues
I’m an old-school guy (76 years old this month) and enjoy working with
raw data.
You may remember we first worked on some UDP data issues in June 2018.
There
were UDP drop-out issues and we exchanged some python code then.
Sometimes I use
hi,
yes, i do remember that contact some years ago. i really can’t say why your detection program switched IP’s, but it’s really of no security concern. either your program will detect the data coming from the Pi itself (your 10… address), or from the docker container from where the data is being emitted from (172…).
both are correct, and both are safe; there really is no security concern in this regard.
cheers, and happy birthday,
richard
[ivor] ivor https://community.raspberryshake.org/u/ivor Leader
August 20hi,
yes, i do remember that contact some years ago. i really can’t say why
your detection program switched IP’s,
The detection program did not switch IP addresses. The Raspberry Shake
switched the IP address that it uses
to send the UDP data stream. The detection program noted and reported
the change.
but it’s really of no security concern. either your program will
detect the data coming from the Pi itself (your 10… address), or from
the docker container from where the data is being emitted from (172…).both are correct, and both are safe; there really is no security
concern in this regard.
Well, we will just disagree. It isn’t that I can see/verify that the
data is originating from the
Raspberry Shake, it is that data started originating from an unexpected
source and this
would trigger an alert by some network intrusion detection systems and
this could lead
to a Raspberry Shake being removed from a school/library/corporate network.
i would supplement the detection of intrusion routine to include that the 172.17 ip address range is valid, since this is also an IP address that the shake can send its data from.
i too am curious why this would suddenly change, for no reason i’m aware of. but again, it’s not a security issue just because the reporting program goes from an external IP to an internal IP at the data packet level; i can guarantee that nothing on the Shake changed to cause the reporting differences you see. i can only imagine this must be something related to the TCP networking protocol and how it decides to advertise this; that this happens does not suddenly make it a security risk, curious as it may be.
exhibiting changing / strange behaviour, on the other hand, is a different question: this can indeed cause suspicion; which, after some investigation, would reveal itself to be not a problem at all.
r-
I think we can close this.
It is worth noting that both the 172.17.0.4 and 10.1.10.204 addresses
are “unroutable” and are not
public IP addresses. What is concerning to a security administrator is
that the data being exported
show up on an IP address and an ethernet address that were not
previously used. This would look
exactly like an unauthorized data exfiltration activity from a
previously unknown device.
Terry