mcip-list Mailing List for mcip
Management and Control Information Protocol
Brought to you by:
fjutscha
Menu
▾
▴
mcip-list — List for all and everything
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
|
| 2014 |
Jan
|
Feb
(4) |
Mar
(5) |
Apr
(2) |
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2015 |
Jan
(3) |
Feb
(2) |
Mar
(3) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(1) |
Dec
|
| 2016 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(3) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael K. <m-...@m-...> - 2017-03-22 13:18:37
|
Hi list, another Patch from MBR to make using sanitizer more easy. -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2017-03-22 10:59:25
|
Hello list, MBR found a bug with the sanitizer. The read strings were not terminated correctly, memory was corrupted. -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2017-02-02 21:32:13
|
Hi list, Am Wed, 1 Feb 2017 13:48:53 +0100 schrieb Markus Lauterbach <de...@ma...>: > On Wed, 1 Feb 2017 13:17:41 +0100 > Markus Lauterbach <de...@ma...> wrote: > > > On Tue, 31 Jan 2017 10:27:56 +0100 > > Michael Kress <m-...@m-...> wrote: > > > > > Hi list, > > > > > > this is a patch originally fixed by MBR: > > > If read() returns -1 and the errno says EAGAIN or EWOULDBLOCK, the > > > socket is not necessarily defective. > > > > > > > Looks good, but errno should only be checked > > if read returns -1 and not > > if read returns 0. Done. Please review the attached patch again. Thank you! -- Servus Michael |
|
From: Markus L. <de...@ma...> - 2017-02-01 12:48:51
|
On Wed, 1 Feb 2017 13:17:41 +0100
Markus Lauterbach <de...@ma...> wrote:
> On Tue, 31 Jan 2017 10:27:56 +0100
> Michael Kress <m-...@m-...> wrote:
>
> > Hi list,
> >
> > this is a patch originally fixed by MBR:
> > If read() returns -1 and the errno says EAGAIN or EWOULDBLOCK, the
> > socket is not necessarily defective.
> >
>
> Looks good, but errno should only be checked
> if read returns -1 and not
> if read returns 0.
>
Some code for a better explanation:
read_bytes = read(...);
if (read_bytes == -1) {
if (errno == EAGAIN || errno == EWOULDBLOCK)
return 0;
else
return -1;
}
else if (read_bytes == 0) {
return -1; /* eof */
}
else {
/* yeah, got some data */
}
> Markus
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> mcip-list mailing list
> mci...@li...
> https://lists.sourceforge.net/lists/listinfo/mcip-list
|
|
From: Markus L. <de...@ma...> - 2017-02-01 12:33:50
|
On Tue, 31 Jan 2017 10:27:56 +0100 Michael Kress <m-...@m-...> wrote: > Hi list, > > this is a patch originally fixed by MBR: > If read() returns -1 and the errno says EAGAIN or EWOULDBLOCK, the > socket is not necessarily defective. > Looks good, but errno should only be checked if read returns -1 and not if read returns 0. Markus |
|
From: Michael K. <m-...@m-...> - 2017-01-31 10:16:17
|
Hi list, this is a patch originally fixed by MBR: If read() returns -1 and the errno says EAGAIN or EWOULDBLOCK, the socket is not necessarily defective. -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2017-01-13 15:03:54
|
Hi Gerd, Am Fri, 13 Jan 2017 14:19:19 +0000 schrieb Gerhard Zenger <gz...@in...>: > libmcip.h enabled for c++. Have fun ;-) > > Cheers, > Gerd Applied. Thanks! -- Servus Michael |
|
From: Gerhard Z. <gz...@in...> - 2017-01-13 14:32:21
|
Hi mcippers, libmcip.h enabled for c++. Have fun ;-) Cheers, Gerd |
|
From: Michael K. <m-...@m-...> - 2016-01-18 16:22:01
|
Hi list, just removed a leftover // Being pedantic is not exclusively reserverd for the compiler :-) -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2016-01-18 16:15:56
|
Hello, Am Mon, 11 Jan 2016 15:46:26 +0100 schrieb Jean-Christophe Zeus <jc...@gm...>: > here is a patch for libmcip. I tried to use the library for sending > larger messages (over 8000 bytes) and failed miserably. Patch has been applied to master. Thank you for the patch and thanks to everybody engaged in testing and finding the bug! -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2016-01-18 16:15:06
|
Hello list, before creating a new .tar.gz including the previous patch, I want to add some minor cosmetic changes to the code: - set GNU C99 - set compile flag -pedantic - remove a stray ";" - be generous for the only bit we have: let it take 8 Bits instead only one -- Servus Michael |
|
From: Jean-Christophe Z. <jc...@gm...> - 2016-01-11 14:46:34
|
Hello everyone, here is a patch for libmcip. I tried to use the library for sending larger messages (over 8000 bytes) and failed miserably. After much trial and error, I figured that libmcip file-pointer arithmetic must be flawed: mcip_remove_telegram() with "SEARCH_NEXT_STARTBYTE" returned a position that was bogus: it was somewhere in the middle of the telegram, not _after_ the telegram according to the length specified. To fix this, I did the following: all pointers to the payload were changed from char to uint8_t. This fixed the issue. However, to hide this change in the API, I opted for the following approach: I changed all char pointers to void pointers, which are then cast to uint8_t in the function body. That way, users can continue to use the API as they did before. Best regards Jean-Christophe Zeus |
|
From: Michael K. <m-...@m-...> - 2015-11-11 14:14:54
|
Hello list, this patch contains three bugfixes: - in case a huge amount of data was transfered over MCIP the buffer has been computed wrong (libmcip -> remove_telegram()), as it did not respect the signed char) - scanbuild gets silenced in device.c - in config.c a possible comparision to NULL gets avoided in case the TCP port has been modified This was found by me but from colleages that are not on the mailing list. Please comment them. -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2015-10-07 11:31:39
|
Hello list, this removes another "usage after free" problem. Thanks to MBR again! -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2015-10-06 13:30:54
|
Hello list, this patches the same routine again, as the "use after free" problem was still not solved. -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2015-10-06 13:27:37
|
Hello list, this patches a bug in libmcip.c Thanks to MBR for detecting it! -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2015-06-19 12:13:51
|
Hello list, the previous patch solved the problem, that memory of a previously removed devices was still interpreted by the read buffer interpreter. Unfortunatelly it introduced a new problem. A device connected to MCIP, sent its "hello", continued with sending a command (like WRITE_WITHOUT_ACK) and immediatelly sent its "BYE" telegram and closed the socket. In case this happenes very fast or the program runs on a machine with load it is possible, that the telegrams after the hello payload are thrown away too early. This new patch restores the previous behaviour: - the read buffer of a device is read until there are no more characters in it - all read buffers of all devices are read one after the other New is: - In case a telegram is a "Bye" telegram (a device wants to disconnect), the read buffer loop for reading the buffer is discontinued as well as reading the read buffers of the other devices. -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2015-05-26 15:14:44
|
Hello list, attached is a patch that fixes handling a device removal. The for-loop with the state machine must not be continued in case a device has been removed. Instead of introducing new flags to abort the for-loop in such a case, I introduced a new state. A "bye" telegram does not remove a device driver immediatelly but only marks it as a zombie that can be removed at any time. -- Servus Michael |
|
From: Michael K. <m-...@m-...> - 2015-03-19 07:57:54
|
Hi Franz, Am Wed, 18 Mar 2015 11:32:36 +0100 schrieb Franz Fuchshuber <fra...@go...>: > i have updated my previously added patch. So just ignore the old > patch. This patch contains besides the functionality to register oids > to an remote server also a fix in the uds_deregister function. This is looking good! Thank you! Applied to master branch. -- Servus Michael |
|
From: Franz F. <fra...@go...> - 2015-03-18 10:32:44
|
Hi list, i have updated my previously added patch. So just ignore the old patch. This patch contains besides the functionality to register oids to an remote server also a fix in the uds_deregister function. Regards, Franz |
|
From: Franz F. <fra...@go...> - 2015-03-16 10:35:33
|
i have added a fuction which makes it possible to register oids via tcp to a remote mcip server. Regards, Franz |
|
From: Michael K. <m-...@m-...> - 2015-02-03 12:58:19
|
Am Tue, 3 Feb 2015 10:06:04 +0100 schrieb Markus Lauterbach <de...@ma...>: > On Wed, 28 Jan 2015 11:07:38 +0100 > Markus Lauterbach <de...@ma...> wrote: > Hi again, > > attached a new patch. After some discussions with Michael I > changed the default value of the new parameter 'TCP_bind' from > a blank value to 'all'. > The old syntax with 'TCP_bind=' is still working. > > Be aware that the usage of TCP_bind=<interface-name> needs root > privileges since SO_BINDTODEVICE is used. Patch applied and commited. Thank you! -- Servus Michael |
|
From: Markus L. <de...@ma...> - 2015-02-03 09:03:29
|
On Wed, 28 Jan 2015 11:07:38 +0100 Markus Lauterbach <de...@ma...> wrote: > Hi list, > > attached a patch with the following content > > - added feature: > mcipd TCP server is now able to listen only > on one interface, e.g. enp1s10 (checkout new parameter 'TCP_bind' > within docs/mcip.conf). If you want to listen on all > interfaces just leave the new value blank. > > - refactoring: > moved config specific functions from util.c into new file config.c > > - refactoring: > moved config specific variables into one struct > > feature add and refactoring within one commit, shame on me... > > ---- > ciao > Markus > > Hi again, attached a new patch. After some discussions with Michael I changed the default value of the new parameter 'TCP_bind' from a blank value to 'all'. The old syntax with 'TCP_bind=' is still working. Be aware that the usage of TCP_bind=<interface-name> needs root privileges since SO_BINDTODEVICE is used. ---- ciao Markus |
|
From: Markus L. <de...@ma...> - 2015-01-28 10:05:01
|
Hi list, attached a patch with the following content - added feature: mcipd TCP server is now able to listen only on one interface, e.g. enp1s10 (checkout new parameter 'TCP_bind' within docs/mcip.conf). If you want to listen on all interfaces just leave the new value blank. - refactoring: moved config specific functions from util.c into new file config.c - refactoring: moved config specific variables into one struct feature add and refactoring within one commit, shame on me... ---- ciao Markus |
|
From: Markus L. <de...@ma...> - 2015-01-28 09:37:59
|
On Wed, 28 Jan 2015 09:56:09 +0100 Michael Kress <m-...@m-...> wrote: > 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 > Hi Michael, accepted from my side. ciao Markus |
