mcip-list — List for all and everything

[mcip-list] Patch: file descriptor inheritage

[Michael K. <m-...@m-...>]

Hello list,

attached a minor patch that changes two things:
- do not let child processes inherit file descriptors
- change check sequence: check for NULL before checking for value

-- 
Servus
  Michael

Re: [mcip-list] Patch: added a few failsaves to libmcip

[Christian T. <chr...@go...>]

Hi,

looks good.
As i was involved in finding the segfault, i can confirm this patch.

Greetings,
Hawk

Am 31.10.2014 um 09:39 schrieb Michael Kress:
> Hello list,
>
> this almost trivial patch adds just a few "if" to libmcip in case a
> program using libmcip does not segfault too easily.
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> mcip-list mailing list
> mci...@li...
> https://lists.sourceforge.net/lists/listinfo/mcip-list

[mcip-list] Patch: added a few failsaves to libmcip

[Michael K. <m-...@m-...>]

Hello list,

this almost trivial patch adds just a few "if" to libmcip in case a
program using libmcip does not segfault too easily.

-- 
Servus
  Michael

Re: [mcip-list] Patch: let MCIP packets get a size up to 65535 bytes

[Christian T. <chr...@go...>]

Hi,

looks good.
Accepted from my side.

Regards,
Hawk

Am 16.07.2014 10:54, schrieb Michael Kress:
> Hello list,
>
> Am Mon, 14 Jul 2014 11:06:42 +0200
> schrieb Christian Tomahogh <chr...@go...>:
>
>> Hi,
>>
>> the patch as is makes sense and looks (without testing) correct.
>>
>> But there is an issue:
>> In libmcip there is the function mcip_read_data (libmcip/libmcip.c,
>> line 249).
>> This function is most likely used by the driver/application to read
>> the data from the mcip demon. This function does only accept data
>> until a maximum of 4096 bytes. If the amount of data exceeds 4096
>> bytes, this function will cause the application to discard the whole
>> mcip packet (line 272).
> Very true, thank you for the tip.
> Attached is a new patch.
>
>> So IMHO this patch only makes sense if the libmcip is patched
>> accordingly (within the same patch) because without a patched library
>> current applications (using this library) won't benefit from the
>> change.
> The old patch alone would not cause harm. The applications would not
> benefit, but not break, as they already have the limitation to 4kByte.
>
> What definitely has to be changed in applications (if not done yet):
> mcip_read_data() can be successful and yet not read the complete
> telegram. Up to now in our applications it is an error, when the
> telegram could not be read at once. I will change that anyway, but
> this has nothing to do with this mailing list.
>
> Thanks again for paying attention!
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
>
>
> _______________________________________________
> mcip-list mailing list
> mci...@li...
> https://lists.sourceforge.net/lists/listinfo/mcip-list

Re: [mcip-list] Patch: let MCIP packets get a size up to 65535 bytes

[Michael K. <m-...@m-...>]

Hello list,

Am Mon, 14 Jul 2014 11:06:42 +0200
schrieb Christian Tomahogh <chr...@go...>:

> Hi,
> 
> the patch as is makes sense and looks (without testing) correct.
> 
> But there is an issue:
> In libmcip there is the function mcip_read_data (libmcip/libmcip.c,
> line 249).
> This function is most likely used by the driver/application to read
> the data from the mcip demon. This function does only accept data
> until a maximum of 4096 bytes. If the amount of data exceeds 4096
> bytes, this function will cause the application to discard the whole
> mcip packet (line 272).

Very true, thank you for the tip.
Attached is a new patch.

> So IMHO this patch only makes sense if the libmcip is patched 
> accordingly (within the same patch) because without a patched library 
> current applications (using this library) won't benefit from the
> change.

The old patch alone would not cause harm. The applications would not
benefit, but not break, as they already have the limitation to 4kByte.

What definitely has to be changed in applications (if not done yet):
mcip_read_data() can be successful and yet not read the complete
telegram. Up to now in our applications it is an error, when the
telegram could not be read at once. I will change that anyway, but
this has nothing to do with this mailing list.

Thanks again for paying attention!

-- 
Servus
  Michael

Re: [mcip-list] Patch: let MCIP packets get a size up to 65535 bytes

[Christian T. <chr...@go...>]

Am 14.07.2014 09:31, schrieb Markus Lauterbach:
> On Sun, 13 Jul 2014 10:48:08 +0200
> Michael Kress <m-...@m-...> wrote:
>
>> Hello list,
>>
>> there is an artificial limit of 1500 bytes for a MCIP packet. The
>> length byte of the protocol is defined to be 2 bytes long, so this
>> limit does not make sense.
>>
>> The attached patch sets the maximum size of a packet to 65535 bytes.
>>
>> When MCIP reads from a device it needs a temporary buffer. This buffer
>> stays at a length of 4 kByte for the first read attempt - the size of
>> a RAM page. Most of the MCIP telegrams are typically only a few bytes
>> long, so the read will most likely get the whole telegram in one
>> chunk. In case of short telegrams the behaviour and thus the
>> performance should stay identical as without the patch.
>>
>> When MCIP once again reads from a device, because the telegram was too
>> long to be read at the first time, the temporary buffer will up to
>> 65535 bytes. This increases the chance, that a telegram can be read
>> completely at the second read() instead of further read chunks each
>> of 4 kByte. The disadvantage is, that on relatively slow connections
>> (e.g. TCP devices) read() still will only get a few bytes and the huge
>> temporary buffer is useless. I still prefer the huge temporary buffer,
>> because
>> - 64 kByte is not too huge on modern hardware
>> - the temporary buffer is released quite fast again, so it is mostly a
>>    performance issue
>> - long telegrams are seldom
>> - on RAM critical machines the limit can be reduced with #define
>> MCIP_MAX_READ_BUFFER
>>
>>
> Hi Michael,
>
> this patch does really make sense. Did not have tested it yet, but
> accepted from my side anyway.
>
> ciao
>   Markus
>

Hi,

the patch as is makes sense and looks (without testing) correct.

But there is an issue:
In libmcip there is the function mcip_read_data (libmcip/libmcip.c, line 
249).
This function is most likely used by the driver/application to read the 
data from the mcip demon. This function does only accept data until a 
maximum of 4096 bytes. If the amount of data exceeds 4096 bytes, this 
function will cause the application to discard the whole mcip packet 
(line 272).

So IMHO this patch only makes sense if the libmcip is patched 
accordingly (within the same patch) because without a patched library 
current applications (using this library) won't benefit from the change.

Regards,
Christian

Re: [mcip-list] Patch: let MCIP packets get a size up to 65535 bytes

[Markus L. <de...@ma...>]

On Sun, 13 Jul 2014 10:48:08 +0200
Michael Kress <m-...@m-...> wrote:

> Hello list,
> 
> there is an artificial limit of 1500 bytes for a MCIP packet. The
> length byte of the protocol is defined to be 2 bytes long, so this
> limit does not make sense.
> 
> The attached patch sets the maximum size of a packet to 65535 bytes.
> 
> When MCIP reads from a device it needs a temporary buffer. This buffer
> stays at a length of 4 kByte for the first read attempt - the size of
> a RAM page. Most of the MCIP telegrams are typically only a few bytes
> long, so the read will most likely get the whole telegram in one
> chunk. In case of short telegrams the behaviour and thus the
> performance should stay identical as without the patch.
> 
> When MCIP once again reads from a device, because the telegram was too
> long to be read at the first time, the temporary buffer will up to
> 65535 bytes. This increases the chance, that a telegram can be read
> completely at the second read() instead of further read chunks each
> of 4 kByte. The disadvantage is, that on relatively slow connections
> (e.g. TCP devices) read() still will only get a few bytes and the huge
> temporary buffer is useless. I still prefer the huge temporary buffer,
> because
> - 64 kByte is not too huge on modern hardware
> - the temporary buffer is released quite fast again, so it is mostly a
>   performance issue
> - long telegrams are seldom
> - on RAM critical machines the limit can be reduced with #define
> MCIP_MAX_READ_BUFFER
> 
> 

Hi Michael,

this patch does really make sense. Did not have tested it yet, but
accepted from my side anyway.

ciao
 Markus

[mcip-list] Patch: let MCIP packets get a size up to 65535 bytes

[Michael K. <m-...@m-...>]

Hello list,

there is an artificial limit of 1500 bytes for a MCIP packet. The
length byte of the protocol is defined to be 2 bytes long, so this limit
does not make sense.

The attached patch sets the maximum size of a packet to 65535 bytes.

When MCIP reads from a device it needs a temporary buffer. This buffer
stays at a length of 4 kByte for the first read attempt - the size of a
RAM page. Most of the MCIP telegrams are typically only a few bytes
long, so the read will most likely get the whole telegram in one chunk.
In case of short telegrams the behaviour and thus the performance
should stay identical as without the patch.

When MCIP once again reads from a device, because the telegram was too
long to be read at the first time, the temporary buffer will up to
65535 bytes. This increases the chance, that a telegram can be read
completely at the second read() instead of further read chunks each of 4
kByte. The disadvantage is, that on relatively slow connections (e.g.
TCP devices) read() still will only get a few bytes and the huge
temporary buffer is useless. I still prefer the huge temporary buffer,
because
- 64 kByte is not too huge on modern hardware
- the temporary buffer is released quite fast again, so it is mostly a
  performance issue
- long telegrams are seldom
- on RAM critical machines the limit can be reduced with #define
MCIP_MAX_READ_BUFFER


-- 
Servus
  Michael

Re: [mcip-list] Patch: log to syslog

[Markus L. <de...@ma...>]

Hi Michl,

last but not least,

On Thu, 3 Apr 2014 17:10:23 +0200
Michael Kress <m-...@m-...> wrote:

> Hello list,
> 
> the appended patch causes, that MCIP will logs to syslog when no
> explicit log file has been configured. If a syslog daemon is present,
> that daemon can take care of log rotating.
> 

syslog is a good idea. Didn't tested it but I think this works fine.

Ciao
 Markus

[mcip-list] Patch: log to syslog

[Michael K. <m-...@m-...>]

Hello list,

the appended patch causes, that MCIP will logs to syslog when no
explicit log file has been configured. If a syslog daemon is present,
that daemon can take care of log rotating.

-- 
Servus
  Michael

Re: [mcip-list] Fix the linker error while compiling the register example on desktop

[Shang-Feng Y. <sto...@gm...>]

Hello Michael,

I tried and found linking error with gcc version 4.6.3 on two different
machines both running Ubuntu 12.04 LTS. However, it compiles smoothly with
a MIPS cross-compile toolchain based on gcc version 4.3.3. I'm not sure
what's the cause of that, but, in my experience, gcc tends to fail to pass
the -l flags to linker if they are not placed at the end of the command
line. Sometimes, even the order of the -l flags will cause some strange
linking error.

Anyway, thanks!

Best Regards,
Shang-Feng Yang


2014-03-23 19:14 GMT+08:00 Michael Kress <m-...@m-...>:

> Hi Shang-Feng,
>
> Am Sun, 23 Mar 2014 12:29:45 +0800
> schrieb Shang-Feng Yang <sto...@gm...>:
>
> > Recently I tried to build MCIP on desktop environment for testing, and
> > found that the linker error while compiling the register example
> > happened again. I made the attached trivial patch to fix that.
> >
> > By the way, I found that cross-compiling toolchains seem to be more
> > tolerating toward this kind of problem. The register example was built
> > flawlessly using some cross-compiling toolchain for MIPS.
>
> this is odd. We compiled it on different machines for x86 and for ARM
> and never run into such a thing. What gcc version do you use?
>
> Nevertheless your patch will go into the repository. Thank you for
> sharing!
>
> --
> Servus
>   Michael
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> mcip-list mailing list
> mci...@li...
> https://lists.sourceforge.net/lists/listinfo/mcip-list
>
>

Re: [mcip-list] Fix the linker error while compiling the register example on desktop

[Michael K. <m-...@m-...>]

Hi Shang-Feng,

Am Sun, 23 Mar 2014 12:29:45 +0800
schrieb Shang-Feng Yang <sto...@gm...>:

> Recently I tried to build MCIP on desktop environment for testing, and
> found that the linker error while compiling the register example
> happened again. I made the attached trivial patch to fix that.
> 
> By the way, I found that cross-compiling toolchains seem to be more
> tolerating toward this kind of problem. The register example was built
> flawlessly using some cross-compiling toolchain for MIPS.

this is odd. We compiled it on different machines for x86 and for ARM
and never run into such a thing. What gcc version do you use?

Nevertheless your patch will go into the repository. Thank you for
sharing!

-- 
Servus
  Michael

[mcip-list] Fix the linker error while compiling the register example on desktop

[Shang-Feng Y. <sto...@gm...>]

Hello list,

First of all, this is in fact a re-submit of the patch to the list.
I'd made some mistakes when sending the previous mail such that the
mail seemed not to be forward by the list. If the mail with the same
title was in fact forwarded to the list, please ignore this mail.
Sorry for the trouble.

Recently I tried to build MCIP on desktop environment for testing, and
found that the linker error while compiling the register example
happened again. I made the attached trivial patch to fix that.

By the way, I found that cross-compiling toolchains seem to be more
tolerating toward this kind of problem. The register example was built
flawlessly using some cross-compiling toolchain for MIPS.


Thanks and happy hacking!


-- 
Shang-Feng Yang

[mcip-list] Fix the linker error while compiling the register example on desktop

[Shang-Feng Y. <sto...@gm...>]

Hello list,

Recently I tried to build MCIP on desktop environment for testing, and
found that the linker error while compiling the register example happened
again. I made the attached trivial patch to fix that.

By the way, I found that cross-compiling toolchains seem to be more
tolerating toward this kind of problem. The register example was built
flawlessly using some cross-compiling toolchain for MIPS.


Thanks and happy hacking!

-- 
Shang-Feng Yang

[mcip-list] Bugfix for TCP devices, that send telegrams to private OIDs

[Michael K. <m-...@m-...>]

Hello list,

devices connected to MCIP via TCP are not allowed to send telegrams to
devices with OIDs lower than 1000. This should ensure some privacy
amongst all devices connected to MCIP via UDS.

If such a telegram is sent its buffer is currently cleared twice. The
patch fixes this, so the telegram will only be removed once (in
process_telegram()).

This would actually not be a problem, but unfortunately there is too
less fail check in reset_buffer(). This also is fixed.

The third diff is merely a translated ToDo comment.

-- 
Servus
  Michael

Re: [mcip-list] mcip_send() should send header and payload not with two send() commands

[Christian T. <chr...@go...>]

Hi,

looks good.
This patch is already applied in a test application which runs without 
problems for two days now.

Christian


Am 26.02.2014 08:34, schrieb Michael Kress:
> Hello,
>
> this patch should improve performance of packet transmissions and
> reduce the volume of traffic. mcip_send() should not use two separate
> send() commands, because on very slow connections to MCIP with high
> latency (e.g. GPRS) it could be possible, that header and payload is
> transported in separate IP packets. This means at least 40 Bytes
> addidtionally for IP and TCP header.
>
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> mcip-list mailing list
> mci...@li...
> https://lists.sourceforge.net/lists/listinfo/mcip-list

[mcip-list] mcip_send() should send header and payload not with two send() commands

[Michael K. <m-...@m-...>]

Hello,

this patch should improve performance of packet transmissions and
reduce the volume of traffic. mcip_send() should not use two separate
send() commands, because on very slow connections to MCIP with high
latency (e.g. GPRS) it could be possible, that header and payload is
transported in separate IP packets. This means at least 40 Bytes
addidtionally for IP and TCP header.

-- 
Servus
  Michael

Re: [mcip-list] patch - unlikely null pointer dereference

[Michael K. <m-...@m-...>]

Hi,

Am Fri, 7 Feb 2014 13:39:04 +0100
schrieb Markus Lauterbach <de...@ma...>:

> attached is a small null pointer dereference fix.
> Not very likely that this happens but some static source code tools
> are very strict ;-)

ACK. Makes sense, as there is already the check for NULL.

Thanks!

-- 
Servus
  Michael

[mcip-list] patch - unlikely null pointer dereference

[Markus L. <de...@ma...>]

Hi all,

attached is a small null pointer dereference fix.
Not very likely that this happens but some static source code tools
are very strict ;-)

Ciao
 Markus

Re: [mcip-list] Patch with cosmetics

[Markus L. <de...@ma...>]

On Thu, 7 Nov 2013 13:23:48 +0100
Michael Kress <m-...@m-...> wrote:

> Hi all,
> 
> Am Wed, 6 Nov 2013 15:39:53 +0100
> schrieb Michael Kress <m-...@m-...>:
> 
> > Hi all,
> > 
> > this patch is a simple cosmetics patch to silence some issues from
> > the tool scan-build.
> 
> Shang-Feng suggested a modification to the previous patch:
> > There is an assumption in the current code segment that open() will
> > return "0" since 0, 1, and 2 were closed before calling open(). This
> > could be a little risky if, for some reason in the future
> > development, some other open() calls were added before that one,
> > the verification would fail. Using dup2() could avoid this, and,
> > since dup2() will check the validity of nullfd, and also close 0,
> > 1, and 2 if necessary, the code could be a little more concise than
> > the current implementation.
> 
> I think that would be better. Attached is the patch with the
> modificiation.
> 

Hi,

usage of dup2 sounds good.

Markus

Re: [mcip-list] Patch with cosmetics

[Michael K. <m-...@m-...>]

Hi all,

Am Wed, 6 Nov 2013 15:39:53 +0100
schrieb Michael Kress <m-...@m-...>:

> Hi all,
> 
> this patch is a simple cosmetics patch to silence some issues from the
> tool scan-build.

Shang-Feng suggested a modification to the previous patch:
> There is an assumption in the current code segment that open() will
> return "0" since 0, 1, and 2 were closed before calling open(). This
> could be a little risky if, for some reason in the future development,
> some other open() calls were added before that one, the verification
> would fail. Using dup2() could avoid this, and, since dup2() will
> check the validity of nullfd, and also close 0, 1, and 2 if
> necessary, the code could be a little more concise than the current
> implementation.

I think that would be better. Attached is the patch with the
modificiation.

-- 
Servus
  Michael

Re: [mcip-list] Patch for better cross compiling

[Markus L. <de...@ma...>]

On Wed, 6 Nov 2013 15:12:07 +0100
Michael Kress <m-...@m-...> wrote:

> Hi all,
> 
> this trivial patch should set the chosen CFLAGS in every gcc command
> line for compiling as well as for linking.
> 

Hi Michael,

looks good to me.

Markus

[mcip-list] Patch with cosmetics

[Michael K. <m-...@m-...>]

Hi all,

this patch is a simple cosmetics patch to silence some issues from the
tool scan-build.

-- 
Servus
  Michael

[mcip-list] Patch for better cross compiling

[Michael K. <m-...@m-...>]

Hi all,

this trivial patch should set the chosen CFLAGS in every gcc command
line for compiling as well as for linking.

-- 
Servus
  Michael

Re: [mcip-list] Patches zum Sichten, Ticket-System

[Christian T. <chr...@go...>]

Hi zusammen,

gelesen und von meiner Seite aus OK.
Aber was ist mit dem Kommentarzeichen in Patch 3. Kommt das auch ins Repo?
Das hat er zu Testzwecken rausgenommen, OK. Aber eigentlich sollte die
Zeile schon drin bleiben.

Gruß,
Hawk
Am 27.04.2013 11:15 schrieb "Michael Kress" <m-...@m-...>:

> Hallo beinand,
>
> bei Sourceforge kann man beim MCIP Projekt nun Tickets anlegen. Es kann
> zum Melden von Bugs benutzt werden, ohne erst der Mailing-Liste
> beitreten zu müssen. Shang-Feng Yang hat ein paar Patches, die er dort
> als Tickets hinterlegt hat:
>
> http://sourceforge.net/p/mcip/tickets
>
> Bei Patch 3 ist ein Kommentarzeichen drin, das er zu Testzwecken
> eingeführt hat. Wenn ihr mit den Patchen ansonsten einverstanden seid,
> dann commite ich das in das Repo, wobei dieses Kommentarzeichen dann
> entfernt wird.
>
> Weiterhin sollten wir bei der Mailing-Liste als zentrales Medium
> bleiben. Das Ticket-System ist lediglich ein weiteres Medium, um
> Rückmeldungen, Wünsche oder Bugs aufnehmen zu können.
>
> --
> Servus
>   Michael
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> _______________________________________________
> mcip-list mailing list
> mci...@li...
> https://lists.sourceforge.net/lists/listinfo/mcip-list
>