dlsantos / dnp3 Goto Github PK

PhysicalLayerAsyncTCPServer::DoOpen() passes the mEndpoint object that was 
originally used as the bind point for the mAcceptor object to 
mAcceptor.async_accept(), which will overwrite mEndpoint with the remote TCP 
endpoint of the most recently accepted connection.

Thus, if the mAcceptor were to become closed, and DoOpen() was called to reopen 
it, the mEndpoint passed to mAcceptor.bind() would be nonsense -- it would be 
the TCP endpoint of a recently connected remote host instead of a local TCP 
endpoint.

Transport layer rx logic is overzealous about asserting the other end is 
filling link layer frames to the greatest extent possible.

How the master handlings request/response style tasks needs to be refactored. 
The pattern is the same for all of them, therefore they shouldn't have unique 
states. Recommendation is to create an interface for defining tasks such as 
reset restart IIN, polls, time sync, etc.

1. Setup Slave to time sync at rate of 60 seconds
2. Wait until time sync occurs
3. Change the system date back 60 seconds
4. Wait until time sync occurs
5. Calculate the amount of time between steps (2) and (4)

The delay between steps (2) and (4) with step (3) injected is 120 seconds, not 
the expected 60 seconds.  This is due to the expires_from_now() absolute time 
reference used in TimerSourceASIO.cpp.  
https://github.com/gec/dnp3/blob/master/APL/TimerSourceASIO.cpp#L46

The expected behavior is that the sleep operation is relative, not absolute.  
So the time sync will always occur within 60 seconds, regardless of any jitter 
in or changes to the system clock that happen to occur within the 60 second 
window.

The DNP3 stack does not handle Analog Inputs as 32-bit with flags (Grp30Var1) 
and without flags (Grp30Var3).

The OpenDNP3 stack supports multiple stacks running at the same time.  However, 
the testset configuration files can only define a point-to-point connection.  
It would be beneficial if testset exposed this "multi-master / multi-slave" 
ability.

Request originally came from Dong Wei ([email protected]) via mailing list.

The current size of the libraries is fairly large for embedded systems.  Some 
features may be marked as "optional" during the build process to produce 
libraries of a reduced size.

For example, an embedded system will know if it is implementing a DNP3 Master 
or a DNP3 Outstation.  Having an optional '--disable-master' or 
'--disable-outstation' flag at configure time would prevent those components 
from being bundled, resulting in a smaller library size.

Current library sizes (Ubuntu 11.04, gcc 4.5.2, boost 1.46.1, OpenDNP3 
1.0.0-RC1):

libopendnp3_apl.so.0.0.0 -> 1096856
libopendnp3_dnp3.so.0.0.0 -> 1353416

Some additional categories of components could be optionally included:

--disable-level2
--disable-level3
--disable-master
--disable-slave
--disable-timesync
--disable-vto

Probably for 0.9.6 or > release.

The increment operator for IndexedWriteIterator uses the enum
IndexMode to determine how many bytes to increment the pointer.  If
the index size is IM_NONE, IM_1B, or IM_2B, the pointer is incremented
the correct 0, 1, or two bytes respectively.  If the index size is 4
bytes, the pointer is only moved three bytes since the value of IM_4B
is 3.  Here's a possible fix:

enum IndexMode
{
IM_NONE = 0,
IM_1B = 1,
IM_2B = 2,
IM_4B = 4
}

The DNP3 stack does not handle Counter Inputs as 32-bit values with flags 
(Grp20Var1) and without flags (Grp20Var5).

The following DNP3 object group/variations are required for Level 1 compliance 
but are missing:

Group0Var242 -> Device Attributes - device manufacturer's software version
Group0Var243 -> Device Attributes - device manufacturer's hardware version
Group0Var246 -> Device Attributes - user assigned ID code/number
Group0Var248 -> Device Attributes - device serial number
Group0Var250 -> Device Attributes - device manufacturer's product name and model
Group0Var252 -> Device Attributes - device manufacturer's name
Group0Var254 -> Device Attributes - non-specific all attributes request
Group0Var255 -> Device Attributes - list of attribute variations

IEEE Std 1815-2010, Table 132, Page 385

I was looking into an issue with the dnp3 java bindings and think I discovered 
a newly introduced bug in AsyncStackManger.

Around December APL/PhysicalLayerMap was updated to have an explict acquiredMap.

https://github.com/gec/dnp3/blob/master/APL/PhysicalLayerMap.cpp#L71

This is fine but ReleaseLayer is never called by the AsyncStackManager (as far 
as I can tell). It appears to only call PhysicalLayerManager::Remove when 
removing a port.

In the 1.0.0 version this wasn't an issue because PhysicalLayerManager::Remove 
had the "side effect" of cleaning up those maps.

https://github.com/gec/dnp3/blob/d86c3f6473573dee19a1c5bda697b56c151f0337/APL/Ph
ysicalLayerMap.cpp

IMO We should either make the contract for ReleaseLayer "harder" or get rid of 
that call altogether.

[deleted issue]

What steps will reproduce the problem?
1. Install TestSetInstaller_1.0.0_vcredist_x86.zip
2. Look for file with extension .xml in the folder where the program installs

What is the expected output? What do you see instead?

Expect to see default XML file for the test tool so the test tool would run.


What version of the product are you using? On what operating system?

- DNP TestSetInstaller 1.0 for Windows, on Windows 7, 64 bit, SP1

Please provide any additional information below.

- It's helpful that the .docx manual included with the installer says that the 
program is ready to go after installation, if only that were true.  No sample 
XML file = very hard to try to use this tool.

Here is a complete list of files that were installed on my system:

date                            size   filename
------------------------------  ------ ------------------------
04/05/2011  11:46 AM               339 EULA.rtf
04/05/2011  11:46 AM             1,406 square_dnp_16.ico
04/05/2011  11:46 AM             2,238 square_dnp_32.ico
04/05/2011  11:46 AM             3,774 square_dnp_48.ico
04/05/2011  11:46 AM            62,790 TestSetUserManual.docx
04/05/2011  11:46 AM           140,054 dnp_banner.bmp
10/03/2011  10:20 AM         1,052,672 TestSet.exe

What steps will reproduce the problem?
1. Abrupt disconnection of an outstation (i.e. yank a cat5 cable)


What is the expected output? What do you see instead?
Would expect port to fail quickly, but it hangs until the TCP send buffer fills 
up and the socket dies b/c of that.

TCP Keep alive is not the preferred remediation b/c the timeout is a 
system-wide parameter even though it can be turned on and off on a per socket 
basis.

A good strategy might be to hand the master/outstation an interface to reset 
the AsyncLinkRouter after a certain failure condition.

org.totalgrid.reef.* should be the only package tree in the JAR file, but 
reef.* is in there too

On a DNP3 outstation (slave), it would be useful to have a callback hook so 
that the user application can be passed any deadband values that are set for an 
Analog point by the DNP3 master.  The use of the LogEntry event mechanism would 
be one acceptable solution.

What steps will reproduce the problem?
1. Install the standard test set
2. Start both the slave and master
3. Attempt to issue a setpoint from the master

What is the expected output? What do you see instead?
I would expect the value to show up in the slave.  Instead one gets a not 
implemented message.

What version of the product are you using? On what operating system?
TS 0_9_0 on Windows 7

Please provide any additional information below.
Value shows up in the log(I think).  We had a valid master trying to send a 
setpoint - which failed.  We then tried DO_ONLY as the type of setpoint, which 
failed.  We then went back to the default XML files and used the test set 
master, which failed to issue the setpoint. 

The DNP3 stack does not handle Binary Inputs in packed format (Grp1Var1) and 
with flags (Grp1Var2).

What steps will reproduce the problem?
1. visit http://code.google.com/p/dnp3/
2. Click on "Repository on github" under the external links section

This links to https://github.com/greenenergycorp/dnp3, but that repo has be 
deprecated.  I believe it would be better if it linked directly to 
https://github.com/gec/dnp3

Build currently blowing up on something ASIO related in boost. It may have to 
do with cygwin specific preprocessor defines passed to G++ via -D.

The dependencies in the autotools arrangement aren't quite setup to support 
parallel builds with the standard "make -j X" option.

IOServiceThread::Run() does not log any exceptions thrown by io_service::run; 
instead, it prints them to standard output, which for some (daemon) 
applications means that the error is silently discarded.  It seems like such 
errors should be logged.

What steps will reproduce the problem?
1. enable link command status in slave xml
2. use master to change a BO or AO
3. run show on master and slave

https://github.com/greenenergycorp/dnp3/blob/master/TestSet/StackHelpers.cpp#L73
Line 73 should be shifted down line and passed the mdo 
(multiplexingdataobserver) rather than the pObs (that is the stacks 
dataobserver). The MultiplexingDataObserver just duplicates the changes from 
the terminal extensions so when you type "show" you see the exact same result 
as what the master should be seeing.

On the main wiki page, there is a link that points to the test coverage 
available on hudson:

"Over 400 individual test cases providing 85-90% test coverage"

This link needs to change to the new CI server.

The Analog events buffer was recently changed from a SingleEventBuffer to a 
TimeOrderedEventBuffer.  It would be useful for embedded systems to define the 
behavior of the TimeOrderedEventBuffer.  For example: (1) the maximum number of 
elements stored in the event buffer and (2) the overflow behavior -- signal the 
overflow or silently overwrite the oldest entry?

What steps will reproduce the problem?
1. Clone the git repository on a 64-bit Ubuntu system
2. cd dnp3
3. autoreconf -f -i
4. mkdir build && cd build
5. ../configure

What is the expected output? What do you see instead?
Expected output would be all the checks succeeding, and final line should look 
like this:
When ready, type 'make' to build.

Instead, I'm getting an error, although libboost-date-time is installed:
checking whether the Boost::Date_Time library is available... yes
configure: error: Could not find a version of the library!

What version of the product are you using? On what operating system?
OpenDNP3 v1.1.0 (not confident about it), commit 
7c07708c83e675c166bfc995865b9454fb910f20
OS: 64-bit Ubuntu 14.04.1 LTS, kernel:3.13.0-39-generic

Please provide any additional information below.
I have managed to compile successfully using this workaround:
Either run the config like this:
../configure --with-boost-libdir=/usr/lib/x86_64-linux-gnu
Or edit dnp3/configure and add the following line before $libsubdirs is used 
(line 4117 for me):
libsubdirs="lib/x86_64-linux-gnu $libsubdirs"

Building works fine using any of those :D

A proper fix should be done in the code to cause autoreconf to produce the 
correct configure script.

The issue exists in other pieces of software:
https://github.com/bitcoin/bitcoin/issues/3219

Two mechanisms:

1. AddVtoChannel/RemoveVtoChannel - raw access to the native VTO byte stream 
via a set of callbacks, used if the Master/Slave wants to terminate the VTO 
channel internally

2. StartVtoRouter/StopVtoRouter - binds a VTO byte stream with some 
PhysicalLayerAsyncBase object (like a TCP client/server connection)

A "print" kind of command would be very useful which'll allow an user to save 
the information pulled from slave using the show command.
Thanks

What steps will reproduce the problem?
1. Start testset under Linux system
2. Press Ctrl+D

Expected behavior is that testset exits as if given the "quit" command.  Actual 
behavior is that the prompt begins to display in an infinite loop.

1.0.0-RC2 on Ubuntu Linux 11.04 Desktop 64-bit.

The TCPServer class is used to accept new connections from a TCP client.  This 
is used for both Master/Slave stacks as well as VTO routers.  When used as a 
Master/Slave stack, it would be beneficial to have a single TCPServer instance 
continue to accept new connections.  This supports the case of multiple Masters 
trying to access one Slave instance, for example.

Slave: TCPServer port 20000
Master #1: TCPClient port 1234 -> Slave
Master #2: TCPClient port 1234 -> Slave

Currently, the Slave would need to instantiate multiple TCPServer instances.  
However, to support this, the full number of Masters needs to be established 
ahead of time.  In addition, the Master<-->port mapping on the slave side needs 
to be established up-front.  However, the new "address discovery" 
(UNKNOWN_ROUTE) log entry mechanism allows us to now have a single Slave 
register a TCPServer listener which then could continually accept new TCPClient 
connections from masters that don't need to be defined ahead of time.

The datatypes listed in APL/DataTypes.h can be very architecture-specific.  It 
would be better for portability to use the standard C99 types where available.  
Microsoft Visual C++ does not support the stdint.h specification, so either a 
MSVC->C99 abstraction layer could be introduced or we could rely on a 3rd party 
library (like Boost) to provide this for us.

The advantage to using the MSVC->C99 trick is that most programmers are 
familiar with the C99 datatype names (int8_t, uint32_t, etc.) since they are 
standardized.  This would make it easier for other developers to pick up the 
project, rather than learning Boost naming conventions.

A sample of what this MSVC->C99 layer might look like is in commit 
70fec26c28a920425da2094b7c40ee98690aefe4.

The testset interface does not currently support the use of deadband values (as 
best as I can tell from the online help.)  Adding the ability to read the 
current values set on the DNP3 outstation (slave) and to set new values would 
be useful for interfacing with a full DNP3 stack.

What steps will reproduce the problem?
1. Have testset exit when enter is pressed
2.
3.

What is the expected output? What do you see instead?

Should exit, doesn't do anything when enter is pressed. Fi a character is 
pressed before enter then it behaves correctly.

What version of the product are you using? On what operating system?


Please provide any additional information below.

"Layer with that name does,t exis Press enter to quit"

Doesn't work!!

During compile:

libtool: compile:  g++ -DHAVE_CONFIG_H -I. 
-I/usr/lib/jvm/java-6-openjdk/include -pthread -I/usr/include 
-DBOOST_TEST_DYN_LINK -DBOOST_ASIO_ENABLE_CANCELIO -DBOOST_REGEX_NO_LIB -g -O2 
-g -O2 -Wall -c APL/IOServiceThread.cpp  -fPIC -DPIC -o 
APL/.libs/IOServiceThread.o
APL/IOServiceThread.cpp: In member function 'virtual void 
apl::IOServiceThread::Run()':
APL/IOServiceThread.cpp:62:9: warning: variable 'num' set but not used 
[-Wunused-but-set-variable]

Investigate uncrustify:

http://uncrustify.sourceforge.net/

From [email protected]:

If an outstation fails to clear it's IIN time sync bit, the master
will continually (as fast as possible) send delay measurement and time
sync measurements.  I noticed this anomaly when running the testset
master against a slave from ASE.

possible resolutions:

Permanently disable the time sync task if an outstation doesn't clear the 
NeedTimeIIN after a proper write sequence.

or

Fail the task and retry at the normal interval.

Right now the default is NOT_SUPPORTED, even for the 2 controls/setpoints we 
have preconfigured in the default_slave.xml and this is confusing for new users.

Probably due to new vto additions. Investigate before 0.9.5-RC1