[Linuxptp-devel] phc2sys,

[Stefan Lange]

Hello linuxptp community,

thank you for your work.

We are experiencing a problem using the timemaster application with PTP
synchronizing to two ethernet ports. In detail I suspect the problem to
be connected to the phc2sys autoconfiguration mode.

We are not sure if this is caused by
- wrong command line parameters / config files on our side
- an inherent disablity of the respective applications for this use case
- a bug
The levels of likeliness are likely to decrease from top to bottom.

#########################
### setup description ###
#########################

Our setup is as follows:

The hardware is a custom board with a NXP P2020 PowerPC CPU. The CPU
provides 3 MACs and one PTP Clock. The CPUs MACs provide hardware
timestamping functionality.
The device shall act as a PTP slave only.
For redundacy reasons, one PTP Grandmaster Clock Master Clock is
attached to our device's eth1, another PTP Grandmaster Clock Master
Clock is attached to our device's eth2.
The ntp server (a regular server pc) is currently connected to eth0.

The timemaster application basically spawns the applications ptp4l,
phc2sys and ntpd (instead of cronyd in our case).
The effect seen is the same, whether ptp4l, phc2sys and ntpd are called
manually or via timemaster.
To make this issue more understandable, I will only display the console
dumps for the manual calling of the applications here. The issue is not
attributed to the timemaster application itself.

##########################################
### problem description / console logs ###
##########################################

We are calling the respective applications in the following order (in
different ssh sessions):

1. ptp4l:
/usr/bin/ptp4l -l 7 -f /var/run/timemaster/ptp4l.0.conf.bak -H -i eth1
-i eth2 -m

Config file:
# cat /var/run/timemaster/ptp4l.0.conf.bak
[global]
slaveOnly 1
domainNumber 0
uds_address /var/run/timemaster/ptp4l.0.socket
message_tag [0:eth1+eth2]

It is very rudimentary and a copy of the config file created by the
timemaster when we first ran into this problem.

ptp4l correctly syncs /dev/ptp0 to one of the grandmaster clocks:

***@cp61850:/var/log# pmc -u -b 0 'GET PORT_DATA_SET'
sending: GET PORT_DATA_SET
00d093.fffe.274a5e-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
portIdentity 00d093.fffe.274a5e-1
portState SLAVE
logMinDelayReqInterval 0
peerMeanPathDelay 0
logAnnounceInterval 1
announceReceiptTimeout 3
logSyncInterval 0
delayMechanism 1
logMinPdelayReqInterval 0
versionNumber 2
00d093.fffe.274a5e-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
portIdentity 00d093.fffe.274a5e-2
portState LISTENING
logMinDelayReqInterval 0
peerMeanPathDelay 0
logAnnounceInterval 1
announceReceiptTimeout 3
logSyncInterval 0
delayMechanism 1
logMinPdelayReqInterval 0
versionNumber 2

Debug prints of ptp4l are attached.

2. phc2sys:
/usr/bin/phc2sys -l 7 -a -r -R 1.00 -m -z
/var/run/timemaster/ptp4l.0.socket -t [0:eth1+eth2] -n 0 -E ntpshm -M 0

resulting in following debug output:
phc2sys[28965.849]: [0:eth1+eth2] config item (null).uds_address is
'/var/run/timemaster/ptp4l.0.socket'
phc2sys[28965.850]: [0:eth1+eth2] config item (null).ntpshm_segment is 0
phc2sys[28965.850]: [0:eth1+eth2] config item (null).step_threshold is
0.000000
phc2sys[28965.850]: [0:eth1+eth2] config item
(null).first_step_threshold is 0.000020
phc2sys[28965.850]: [0:eth1+eth2] config item (null).max_frequency is
900000000
phc2sys[28965.851]: [0:eth1+eth2] config item (null).ntpshm_segment is 0
phc2sys[28965.851]: [0:eth1+eth2] config item (null).step_threshold is
0.000000
phc2sys[28965.851]: [0:eth1+eth2] config item
(null).first_step_threshold is 0.000020
phc2sys[28965.851]: [0:eth1+eth2] config item (null).max_frequency is
900000000
phc2sys[28965.851]: [0:eth1+eth2] config item (null).ntpshm_segment is 0
phc2sys[28965.851]: [0:eth1+eth2] config item (null).step_threshold is
0.000000
phc2sys[28965.851]: [0:eth1+eth2] config item
(null).first_step_threshold is 0.000020
phc2sys[28965.851]: [0:eth1+eth2] config item (null).max_frequency is
900000000
phc2sys[28966.852]: [0:eth1+eth2] reconfiguring after port state change
phc2sys[28966.852]: [0:eth1+eth2] selecting eth2 for synchronization
phc2sys[28966.852]: [0:eth1+eth2] selecting CLOCK_REALTIME for
synchronization
phc2sys[28966.853]: [0:eth1+eth2] selecting eth1 as the master clock
phc2sys[28966.853]: [0:eth1+eth2] phc offset -6283178 s0 freq +0
delay 680
phc2sys[28966.853]: [0:eth1+eth2] phc offset 5 s0 freq +0
delay 2130
phc2sys[28967.853]: [0:eth1+eth2] phc offset -6285375 s0 freq +0
delay 680
phc2sys[28967.853]: [0:eth1+eth2] phc offset 5 s0 freq +0
delay 2170
phc2sys[28968.853]: [0:eth1+eth2] phc offset -6287640 s0 freq +0
delay 680
phc2sys[28968.854]: [0:eth1+eth2] phc offset 5 s0 freq +0
delay 2130
...

3. ntpd
/usr/sbin/ntpd -u ntp:ntp -g -n -c /var/run/timemaster/ntp.conf.bak

Config file:
# cat /var/run/timemaster/ntp.conf.bak
includefile /etc/ntp.conf
server 192.168.11.100 minpoll 6 maxpoll 10
server 127.127.28.0 minpoll 2 maxpoll 2 mode 1
fudge 127.127.28.0 refid PTP0

It is very rudimentary and a copy of the config file created by the
timemaster when we first ran into this problem.

resulting in following debug output:
20 Mar 15:48:15 ntpd[12373]: ntpd ***@1.3265 Wed Jan 25 14:36:50 UTC
2017 (2): Starting
20 Mar 15:48:15 ntpd[12373]: Command line: /usr/sbin/ntpd -u ntp:ntp -g
-n -c /var/run/timemaster/ntp.conf.bak
20 Mar 15:48:15 ntpd[12373]: proto: precision = 0.780 usec (-20)
20 Mar 15:48:15 ntpd[12373]: minpoll: provided value (2) is out of range
[3-255])
20 Mar 15:48:15 ntpd[12373]: Listen and drop on 0 v6wildcard [::]:123
20 Mar 15:48:15 ntpd[12373]: Listen and drop on 1 v4wildcard 0.0.0.0:123
20 Mar 15:48:15 ntpd[12373]: Listen normally on 2 lo 127.0.0.1:123
20 Mar 15:48:15 ntpd[12373]: Listen normally on 3 eth0 192.168.11.247:123
20 Mar 15:48:15 ntpd[12373]: Listen normally on 4 eth1 192.168.1.236:123
20 Mar 15:48:15 ntpd[12373]: Listen normally on 5 eth2 192.168.91.220:123
20 Mar 15:48:15 ntpd[12373]: Listen normally on 6 lo [::1]:123
20 Mar 15:48:15 ntpd[12373]: Listen normally on 7 eth0
[fe80::2d0:93ff:fe27:4a5d%3]:123
20 Mar 15:48:15 ntpd[12373]: Listen normally on 8 eth1
[fe80::2d0:93ff:fe27:4a5e%4]:123
20 Mar 15:48:15 ntpd[12373]: Listen normally on 9 eth2
[fe80::2d0:93ff:fe27:4a5f%5]:123
20 Mar 15:48:15 ntpd[12373]: Listening on routing socket on fd #26 for
interface updates
20 Mar 15:48:16 ntpd[12373]: SHM: stale/bad receive time, delay=-37s
20 Mar 15:48:17 ntpd[12373]: SHM: stale/bad receive time, delay=-37s
20 Mar 15:48:18 ntpd[12373]: SHM: stale/bad receive time, delay=-37s
(continuing..)

Obviously there is a problem with the leap seconds.
In my understanding, phc2sys should "translate" the PHC's TAI into UTC
and provide this to the ntpd via the SHM.
"In hardware time stamping mode, ptp4l announces use of PTP time scale
and PHC is used for the stamps. That means PHC must follow PTP time
scale while system clock follows UTC. Time offset between these two is
maintained by phc2sys."
[phy2sys manpage]

The ntpd only synchronises to the ntp server 192.168.11.100, not the PTP
clock:

***@cp61850:~# ntpq -c peers
remote refid st t when poll reach delay offset
jitter
==============================================================================
*192.168.11.100 131.188.3.221 2 u 5 64 1 0.384 1.938
0.001
SHM(0) .PTP0. 0 l - 8 0 0.000 0.000
0.000

However the grand master clock and ntp server are set correctly to the
correct UTC resp. TAI times.

The above behaviour is the same if eth1 or eth2 are unplugged before or
after the calling of the applications.

For investigation, further tests were performed:

#########################################################
### comparative test 1: ptp4l using only eth1 or eth2 ###
#########################################################

For a test, the basic setup (### problem description ###) is repeated
with ptp4l using only one ethernet interface:

/usr/bin/ptp4l -l 7 -f /var/run/timemaster/ptp4l.0.conf.bak -H -i eth1 -m

Order and syntax of the other applications' calling are the same as above.

The ntpd error message
SHM: stale/bad receive time, delay=-37s
does not appear.

ntpd correctly syncs to the PTP Clock:

***@cp61850:~# ntpq -c peers
remote refid st t when poll reach delay offset
jitter
==============================================================================
+192.168.11.100 131.188.3.222 2 u 4 64 1 0.185 1.010
0.001
*SHM(0) .PTP0. 0 l 3 8 1 0.000 6.986
0.001

The behaviour is the same if eth2 instead of eth1 is used by ptp4l.

##############################################################
### comparative test 2: call phc2sys with -w instead of -a ###
##############################################################

For a test, the basic setup (### problem description ###) is repeated
with phc2sys flags -w instead of -a (autoconfiguration disabled).

# /usr/bin/phc2sys -l 7 -w -r -R 1.00 -m -z
/var/run/timemaster/ptp4l.0.socket -t [0:eth1+eth2] -n 0 -E ntpshm -M 0
-s /dev/ptp0

Order and syntax of the other applications' calling are the same as above.

The ntpd error message
SHM: stale/bad receive time, delay=-37s
does not appear.

ntpd correctly syncs to the PTP Clock:

***@cp61850:~# ntpq -c peers
remote refid st t when poll reach delay offset
jitter
==============================================================================
+192.168.11.100 131.188.3.222 2 u 4 64 1 0.185 1.010
0.001
*SHM(0) .PTP0. 0 l 3 8 1 0.000 6.986
0.001


##################
### discussion ###
##################

It seems there is a problem with the autoconfiguration featue of phc2sys
in combination with ptp4l working with two ethernet interfaces.

Can anyone confirm this behaviour?

Did we make mistakes with the application flags and/or config files,
respectively is there a solution by changing these?


Best regards,
Stefan
--
Stefan Lange
Entwicklung

___________________________________________________________
GateWare Communications GmbH
!ACHTUNG, NEUE ADRESSE!
Friggastr. 2, D-90461 NÃŒrnberg
Germany

Tel: +49 (0) 911 / 946016-190
Fax: +49 (0) 911 / 946016-80

Eingetragene Rechtsform : GmbH
Sitz und Registergericht: Amtsgericht NÃŒrnberg HRB 18334
GeschÀftsfÌhrer : Wolfgang Haubner

Web: http://www.gateware.de
E-Mail: ***@gateware.de
___________________________________________________________

Diese E-mail kann vertrauliche Informationen enthalten. Falls Sie diese
E-Mail irrtÃŒmlich erhalten haben, informieren Sie bitte unverzÃŒglich den
Absender und löschen Sie diese E-Mail von jedem Rechner, auch von den
Mailservern. Jede Verbreitung des Inhalts, auch die teilweise Verbreitung,
ist in diesem Fall untersagt. Außer bei Vorsatz oder grober FahrlÀssigkeit
schließen wir jegliche Haftung fÃŒr Verluste oder SchÀden aus, die durch
Viren befallene Software oder E-Mails verursacht werden.

This e-mail may contain confidential information. If you received this
e-mail in error, please contact the sender and delete this e-mail from your
computer, including your mailservers. Any dissemination, even partly, is
prohibited. Except in case of gross negligence or wilful misconduct we
accept no liability for any loss or damage caused by software or e-mail
viruses.

[Richard Cochran]

If I understood correctly, then in your setup phc2sys will use the
UTC/TAI offset provided by the GM...
What do you see when you query TIME_PROPERTIES_DATA_SET ?

Thanks,
Richard

[Stefan Lange]

Hello Richard,

these are the respective outputs:

***@cp61850:~# pmc -u -b 0 'GET TIME_PROPERTIES_DATA_SET'
sending: GET TIME_PROPERTIES_DATA_SET
00d093.fffe.274a5e-0 seq 0 RESPONSE MANAGEMENT
TIME_PROPERTIES_DATA_SET
currentUtcOffset 37
leap61 0
leap59 0
currentUtcOffsetValid 0
ptpTimescale 1
timeTraceable 0
frequencyTraceable 0
timeSource 0xa0

***@cp61850:~# pmc -u -b 0 'GET PORT_DATA_SET'
sending: GET PORT_DATA_SET
00d093.fffe.274a5e-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
portIdentity 00d093.fffe.274a5e-1
portState SLAVE
logMinDelayReqInterval 0
peerMeanPathDelay 0
logAnnounceInterval 1
announceReceiptTimeout 3
logSyncInterval 0
delayMechanism 1
logMinPdelayReqInterval 0
versionNumber 2
00d093.fffe.274a5e-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
portIdentity 00d093.fffe.274a5e-2
portState LISTENING
logMinDelayReqInterval 0
peerMeanPathDelay 0
logAnnounceInterval 1
announceReceiptTimeout 3
logSyncInterval 0
delayMechanism 1
logMinPdelayReqInterval 0
versionNumber 2

***@cp61850:~# date
Wed Mar 22 07:55:46 UTC 2017

***@cp61850:~# phc_ctl /dev/ptp0 get
phc_ctl[660.715]: clock time is 1490169383.798251169 or Wed Mar 22
07:56:23 2017


With ptp4l only working with one ethernet interface,
TIME_PROPERTIES_DATA_SET is identical:

***@cp61850:~# pmc -u -b 0 'GET TIME_PROPERTIES_DATA_SET'
sending: GET TIME_PROPERTIES_DATA_SET
00d093.fffe.274a5f-0 seq 0 RESPONSE MANAGEMENT
TIME_PROPERTIES_DATA_SET
currentUtcOffset 37
leap61 0
leap59 0
currentUtcOffsetValid 0
ptpTimescale 1
timeTraceable 0
frequencyTraceable 0
timeSource 0xa0


Best regards,

Stefan

Post by Richard Cochran
If I understood correctly, then in your setup phc2sys will use the
UTC/TAI offset provided by the GM...
What do you see when you query TIME_PROPERTIES_DATA_SET ?
Thanks,
Richard

--
Stefan Lange
Entwicklung

___________________________________________________________
GateWare Communications GmbH
!ACHTUNG, NEUE ADRESSE!
Friggastr. 2, D-90461 Nürnberg
Germany

Tel: +49 (0) 911 / 946016-190
Fax: +49 (0) 911 / 946016-80

Eingetragene Rechtsform : GmbH
Sitz und Registergericht: Amtsgericht Nürnberg HRB 18334
Geschäftsführer : Wolfgang Haubner

Web: http://www.gateware.de
E-Mail: ***@gateware.de
___________________________________________________________

Diese E-mail kann vertrauliche Informationen enthalten. Falls Sie diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte unverzüglich den
Absender und löschen Sie diese E-Mail von jedem Rechner, auch von den
Mailservern. Jede Verbreitung des Inhalts, auch die teilweise Verbreitung,
ist in diesem Fall untersagt. Außer bei Vorsatz oder grober Fahrlässigkeit
schließen wir jegliche Haftung für Verluste oder Schäden aus, die durch
Viren befallene Software oder E-Mails verursacht werden.

This e-mail may contain confidential information. If you received this
e-mail in error, please contact the sender and delete this e-mail from your
computer, including your mailservers. Any dissemination, even partly, is
prohibited. Except in case of gross negligence or wilful misconduct we
accept no liability for any loss or damage caused by software or e-mail
viruses.

[Richard Cochran]

Post by Stefan Lange
sending: GET TIME_PROPERTIES_DATA_SET
00d093.fffe.274a5e-0 seq 0 RESPONSE MANAGEMENT
TIME_PROPERTIES_DATA_SET
currentUtcOffset 37
leap61 0
leap59 0
currentUtcOffsetValid 0

The offset is not valid. The problem lies in the GM.

Post by Stefan Lange
ptpTimescale 1
timeTraceable 0
frequencyTraceable 0
timeSource 0xa0

Thanks,
Richard

[Stefan Lange]

Hello Richard,

I manually corrected the GM properties by setting them on the GM device:

pmc -u -b 0 'SET GRANDMASTER_SETTINGS_NP
clockClass 248
clockAccuracy 0xfe
offsetScaledLogVariance 0xffff
currentUtcOffset 37
leap61 0
leap59 0
currentUtcOffsetValid 1
ptpTimescale 1
timeTraceable 0
frequencyTraceable 0
timeSource 0xa0
'

I restarted ptp4l, phc2sys and ntpd on the slave device and see:

***@cp61850:~# pmc -u -b 0 'GET TIME_PROPERTIES_DATA_SET'
sending: GET TIME_PROPERTIES_DATA_SET
00d093.fffe.274a5e-0 seq 0 RESPONSE MANAGEMENT
TIME_PROPERTIES_DATA_SET
currentUtcOffset 37
leap61 0
leap59 0
currentUtcOffsetValid 1
ptpTimescale 1
timeTraceable 0
frequencyTraceable 0
timeSource 0xa0

However, the message

SHM: stale/bad receive time, delay=-37s

still persists. Behaviour is as described in the first post.

Maybe there is still something wrong with my GM configuration..


Anyway I still can not see why the setup would work with ptp4l using
only 1 ethernet interface or phc2sys non-autoconfig, even given there
was (or maybe still is) a problem in the GM configuration.


For testing I currently have a board identical to the slave device
acting as the Grandmaster Clock. This since I do currently not have
access to our Meinberg GM clock.

eth1 of the GM device is connected to a switch. From the switch, cables
go to eth1 and eth2 of the slave device.

However, as described, unplugging eth1 or eth2 before or after starting
ptp4l has no effect on the presence of this phenomenon.


Is there some more diagnosis I can do? Did I misconfigure something on
the GM side that can explain the effects seen?


Best regards,

Stefan

[Richard Cochran]

Post by Stefan Lange
Anyway I still can not see why the setup would work with ptp4l using
only 1 ethernet interface or phc2sys non-autoconfig, even given there
was (or maybe still is) a problem in the GM configuration.

Sorry, I misread your original post. I missed the fact the error only
appears when using 2 interfaces.

So, this must be a bug with "phc2sys -a" ...

Thanks,
Richard

[Miroslav Lichvar]

Post by Stefan Lange
phc2sys[28966.852]: [0:eth1+eth2] selecting eth2 for synchronization
phc2sys[28966.852]: [0:eth1+eth2] selecting CLOCK_REALTIME for
synchronization
phc2sys[28966.853]: [0:eth1+eth2] selecting eth1 as the master clock
phc2sys[28966.853]: [0:eth1+eth2] phc offset -6283178 s0 freq +0
delay 680
phc2sys[28966.853]: [0:eth1+eth2] phc offset 5 s0 freq +0
delay 2130
phc2sys[28967.853]: [0:eth1+eth2] phc offset -6285375 s0 freq +0
delay 680
phc2sys[28967.853]: [0:eth1+eth2] phc offset 5 s0 freq +0
delay 2170
phc2sys[28968.853]: [0:eth1+eth2] phc offset -6287640 s0 freq +0
delay 680
phc2sys[28968.854]: [0:eth1+eth2] phc offset 5 s0 freq +0
delay 2130

I think the interleaving of the offset explains what is happening
here. phc2sys is synchronizing the system clock to eth1 via SHM and
at the same time it is synchronizing eth2 to eth1 via the same SHM.
The eth1-sys sample is immediately overwritten by the eth1-eth2
sample, which is what ntpd sees and complains about timestamps from
future.

I guess phc2sys needs to be improved to detect interfaces sharing the
same clock.

Note that the SHM servo (using one segment) can meaningfully work only
with two clocks, i.e. it can't be used in a jbod setup.

[Miroslav Lichvar]

Post by Miroslav Lichvar
I guess phc2sys needs to be improved to detect interfaces sharing the
same clock.

Stefan, could you please try the patch I just sent to the list?
I don't have a HW I could test this on. Considering how long this bug
survived, I guess very few people actually do :).

[Stefan Lange]

Hi Miroslav,

I compiled and tested your patch.

Unfortunately it did not change / improve the behaviour.


I added some debug output that may give a little more insight:

LIST_FOREACH(clock id: 0, device: CLOCK_REALTIME, &node->clocks, list)
node->master->clkid: ffffffd3, device: eth1
phc2sys[4637.685]: [0:eth1+eth2] phc offset 1468 s0 freq +0
delay 680

LIST_FOREACH(clock id: ffffffcb, device: eth2, &node->clocks, list)
node->master->clkid: ffffffd3, device: eth1
phc2sys[4637.685]: [0:eth1+eth2] phc offset 5 s0 freq +0
delay 2130

LIST_FOREACH(clock id: ffffffd3, device: eth1, &node->clocks, list)
node->master->clkid: ffffffd3, device: eth1
!update_needed

As you wrote:

"I think the interleaving of the offset explains what is happening
here. phc2sys is synchronizing the system clock to eth1 via SHM and
at the same time it is synchronizing eth2 to eth1 via the same SHM.
The eth1-sys sample is immediately overwritten by the eth1-eth2
sample, which is what ntpd sees and complains about timestamps from
future.

I guess phc2sys needs to be improved to detect interfaces sharing the
same clock."


It seems your patch does not work because eth1 and eth2 have a different clockid (which is not ideal since both actually use the same physical clock).

Debugging showed that the if-query
"if (node->master->clkid == clock->clkid)"
is not entered at all, respectively caught by the previous
"if (!update_needed(clock))".


Not sure if there is an elegant way to solve this without affecting too much of the basic linuxptp source code..

Best regards,
Stefan

Post by Miroslav Lichvar
Stefan, could you please try the patch I just sent to the list?
I don't have a HW I could test this on. Considering how long this bug
survived, I guess very few people actually do :).

[Miroslav Lichvar]

Post by Stefan Lange
Hi Miroslav,
I compiled and tested your patch.
Unfortunately it did not change / improve the behaviour.
LIST_FOREACH(clock id: ffffffcb, device: eth2, &node->clocks, list)
node->master->clkid: ffffffd3, device: eth1
phc2sys[4637.685]: [0:eth1+eth2] phc offset 5 s0 freq +0

Oh, I see. The ID encodes the file descriptor, not the PHC index.

Can you please try the V2 patch?

[Stefan Lange]

Hi Miroslav,

great, the V2 patch works well with me. Thanks a lot.

I also tested unplugging and plugging the involved ethernet interfaces.
phc2sys correctly reconfigures after port state changes and switches to
the available interface.


I also successfully re-tested the regular -w and single interface
options that already worked before:

/usr/bin/phc2sys -l 7 -w -r -R 1.00 -m -z
/var/run/timemaster/ptp4l.0.socket -t [0:eth1+eth2] -n 0 -E ntpshm -M 0
-s /dev/ptp0

and

ptp4l -i eth1 -l 5 -m -p /dev/ptp0 -f /etc/ptp_default.cfg
resp.
ptp4l -i eth2 -l 5 -m -p /dev/ptp0 -f /etc/ptp_default.cfg
with
/usr/bin/phc2sys -l 7 -a -r -R 1.00 -m -z
/var/run/timemaster/ptp4l.0.socket -t [0:eth1+eth2] -n 0 -E ntpshm -M 0


Any suggestions for further testing?


The source code of the patch also looks good to me, however someone else
with more experience than me should do a review.

Best regards,
Stefan

[Richard Cochran]

Post by Stefan Lange
great, the V2 patch works well with me. Thanks a lot.

I am going to merge this patch.

With your permission, Stefan, I would like to give you credit in the
commit message with a tag like this:

Reported-by: Stefan Lange <***@gateware.de>

Thanks,
Richard

[Stefan Lange]

Hello Richard,

allright, thanks again.

Regards,
Stefan