From Newsgroup: comp.protocols.time.ntp

--0000000000002f132e063dbaac21
Content-Type: text/plain; charset="UTF-8"

Hi,

Request your comments.

I see the following error in the server, with sha256 keys: "receive: drop:
bad EF length"
The client and server are both 4.2.8.p18, same version. I see the client is sending 32 bytes MAC + 4 bytes key id.

Why is the server rejecting this mac ? should MAC be reduced to 20 bytes ?
Why is the same p18 version in client and server not compatible ?

Any help/pointers much appreciated.

Thanks,
Murugesh

--0000000000002f132e063dbaac21
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>Request your comments.</div><div><b= r></div><div>I see the following error in the server, with sha256 keys: &qu= ot;<span style=3D"color:rgb(0,0,0)">receive: drop: bad EF length&quot;</spa= n></div><div>The client and server are both 4.2.8.p18, same version. I see = the client is sending 32 bytes MAC=C2=A0+ 4 bytes key id. =C2=A0</div><div>= <br></div><div>Why is the server rejecting this mac ? should MAC be reduced=
to 20 bytes ?</div><div>Why is the same p18 version in client and server n=
ot compatible ?</div><div><br></div><div>Any help/pointers much appreciated= .</div><div><br></div><div>Thanks,</div><div>Murugesh</div><div><br></div><= div><br></div></div>

--0000000000002f132e063dbaac21--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--0000000000003567ce063dd97e99
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 1, 2025, 03:21 murugesh pitchaiah <[email protected]> wrote:

Why is the server rejecting this mac ? should MAC be reduced to 20 bytes ?


The MAC is too long and it should be trucated to 16 or 20 bytes long.

Why is the same p18 version in client and server not compatible ?


I do not know, my best guess is that the code missed a truncation.



--0000000000003567ce063dd97e99
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 1, 2025, 03:21 murugesh pitc= haiah &lt;<a href=3D"mailto:[email protected]">murugesh.pitchaia= [email protected]</a>&gt; wrote:</div><div dir=3D"ltr" class=3D"gmail_attr"><br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_qu= ote"><div dir=3D"ltr"><div>Why is the server rejecting this mac ? should MA=
C be reduced to 20 bytes ?</div></div></div></div></blockquote></div></div>= <div dir=3D"auto"><br></div><div dir=3D"auto">The MAC is too long and it sh= ould be trucated to 16 or 20 bytes long.</div><div dir=3D"auto"><br></div><= div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir= =3D"ltr"><div>Why is the same p18 version in client and server not compatib=
le ?</div></div></div></div></blockquote></div></div><div dir=3D"auto"><br>= </div><div dir=3D"auto">I do not know, my best guess is that the code misse=
d a truncation.</div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quot= e_container"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"= gmail_quote">
</div></div>
</blockquote></div></div></div>

--0000000000003567ce063dd97e99--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--000000000000945198063ddaa429
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi James,

Thanks for your reply.

Initially I had 4.2.8.p12 client. It was sending MAC of size 20 bytes along with keyid 4 bytes. But for that, the p18 server reported error "MAC
length error, received 24 not 36".

Assuming the p18 expects MAC without truncation I tried p18 for client. Now having p18 client and p18 server.

P18 client sending 32 plus 4. But p18 server reporting "bad EF length".

Thanks,
Murugesh

On Wed, 3 Sept, 2025, 5:32=E2=80=AFam James Browning, <[email protected]=

wrote:

On Mon, Sep 1, 2025, 03:21 murugesh pitchaiah <
[email protected]> wrote:

Why is the server rejecting this mac ? should MAC be reduced to 20 bytes =

?

The MAC is too long and it should be trucated to 16 or 20 bytes long.

Why is the same p18 version in client and server not compatible ?

I do not know, my best guess is that the code missed a truncation.

--000000000000945198063ddaa429
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi James,<div dir=3D"auto"><br></div><div dir=3D"auto">Th= anks for your reply.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"aut= o">Initially I had 4.2.8.p12 client. It was sending MAC of size 20 bytes al= ong with keyid 4 bytes.=C2=A0 But for that, the p18 server reported error &= quot;MAC length error, received 24 not 36&quot;.</div><div dir=3D"auto"><br= ></div><div dir=3D"auto">Assuming the p18 expects MAC without truncation I = tried p18 for client. Now having p18 client and p18 server.</div><div dir= =3D"auto"><br></div><div dir=3D"auto">P18 client sending 32 plus 4. But p18=
server reporting &quot;bad EF length&quot;.</div><div dir=3D"auto"><br></d= iv><div dir=3D"auto">Thanks,=C2=A0</div><div dir=3D"auto">Murugesh</div></d= iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl= ass=3D"gmail_attr">On Wed, 3 Sept, 2025, 5:32=E2=80=AFam James Browning, &l= t;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wr= ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><div cl= ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 1, 20= 25, 03:21 murugesh pitchaiah &lt;<a href=3D"mailto:murugesh.pitchaiah@gmail= .com" target=3D"_blank" rel=3D"noreferrer">[email protected]</a>= &gt; wrote:</div><div dir=3D"ltr" class=3D"gmail_attr"><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir= =3D"ltr"><div>Why is the server rejecting this mac ? should MAC be reduced =
to 20 bytes ?</div></div></div></div></blockquote></div></div><div dir=3D"a= uto"><br></div><div dir=3D"auto">The MAC is too long and it should be truca= ted to 16 or 20 bytes long.</div><div dir=3D"auto"><br></div><div dir=3D"au= to"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l= tr"><div class=3D"gmail_quote"><div dir=3D"ltr"><div>Why is the same p18 ve= rsion in client and server not compatible ?</div></div></div></div></blockq= uote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I do not kno=
w, my best guess is that the code missed a truncation.</div><div dir=3D"aut= o"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt= r"><div class=3D"gmail_quote">
</div></div>
</blockquote></div></div></div>
</blockquote></div>

--000000000000945198063ddaa429--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------jCuDCeO0MhdiqXrDrS7Kpdzd
Content-Type: multipart/mixed; boundary="------------Mic94HPB0lo00JkdJjD0Whev";
protected-headers="v1"
From: Martin Burnicki <[email protected]>
To: murugesh pitchaiah <[email protected]>,
James Browning <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Subject: Re: SHA256 MAC with ntp 4.2.8.p18
References: <CAOu9RAcaCW7MEurs2FqmD6ZnUVMtNvjJMsZbKCDfviTg2fQDZw@mail.gmail.com>
<CAOu9RAepVz7b-fUXx=[email protected]>
<CAHLN9Pdh2_6K+f-s4y7BHPLyxL6gR5fG4qz13rR_WaBX=[email protected]>
<CAOu9RAccoL65TDSmMMQCmhbxWTUK21wCPOWtb-79s7goDrhLxg@mail.gmail.com> In-Reply-To: <CAOu9RAccoL65TDSmMMQCmhbxWTUK21wCPOWtb-79s7goDrhLxg@mail.gmail.com>

--------------Mic94HPB0lo00JkdJjD0Whev
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGkgTXVydWdlc2gsDQoNCkFzIGZhciBhcyBJIGtub3csIG50cGQgZnJvbSBudHAub3JnIGRv ZXNuJ3QgcmVhbGx5IHN1cHBvcnQgU0hBMjU2Lg0KDQpXb3VsZCBpdCBiZSBwb3NzaWJsZSB0 byB1c2UgQUVTMTI4Q01BQyBpbnN0ZWFkPyBUaGF0J3Mgc3VwcG9ydGVkIHdlbGwgYnkgDQpu dHBkLg0KDQoNClJlZ2FyZHMsDQoNCk1hcnRpbg0KDQoNCm11cnVnZXNoIHBpdGNoYWlhaCB3 cm90ZToNCj4gSGkgSmFtZXMsDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQo+IA0K PiBJbml0aWFsbHkgSSBoYWQgNC4yLjgucDEyIGNsaWVudC4gSXQgd2FzIHNlbmRpbmcgTUFD IG9mIHNpemUgMjAgYnl0ZXMgDQo+IGFsb25nIHdpdGgga2V5aWQgNCBieXRlcy7CoCBCdXQg Zm9yIHRoYXQsIHRoZSBwMTggc2VydmVyIHJlcG9ydGVkIGVycm9yIA0KPiAiTUFDIGxlbmd0 aCBlcnJvciwgcmVjZWl2ZWQgMjQgbm90IDM2Ii4NCj4gDQo+IEFzc3VtaW5nIHRoZSBwMTgg ZXhwZWN0cyBNQUMgd2l0aG91dCB0cnVuY2F0aW9uIEkgdHJpZWQgcDE4IGZvciBjbGllbnQu IA0KPiBOb3cgaGF2aW5nIHAxOCBjbGllbnQgYW5kIHAxOCBzZXJ2ZXIuDQo+IA0KPiBQMTgg Y2xpZW50IHNlbmRpbmcgMzIgcGx1cyA0LiBCdXQgcDE4IHNlcnZlciByZXBvcnRpbmcgImJh ZCBFRiBsZW5ndGgiLg0KPiANCj4gVGhhbmtzLA0KPiBNdXJ1Z2VzaA0KPiANCj4gT24gV2Vk LCAzIFNlcHQsIDIwMjUsIDU6MzLigK9hbSBKYW1lcyBCcm93bmluZywgPHBlc3NpbXVzMTky QGdtYWlsLmNvbSANCj4gPG1haWx0bzpwZXNzaW11czE5MkBnbWFpbC5jb20+PiB3cm90ZToN Cj4gDQo+ICAgICBPbiBNb24sIFNlcCAxLCAyMDI1LCAwMzoyMSBtdXJ1Z2VzaCBwaXRjaGFp YWgNCj4gICAgIDxtdXJ1Z2VzaC5waXRjaGFpYWhAZ21haWwuY29tIDxtYWlsdG86bXVydWdl c2gucGl0Y2hhaWFoQGdtYWlsLmNvbT4+DQo+ICAgICB3cm90ZToNCj4gDQo+ICAgICAgICAg V2h5IGlzIHRoZSBzZXJ2ZXIgcmVqZWN0aW5nIHRoaXMgbWFjID8gc2hvdWxkIE1BQyBiZSBy ZWR1Y2VkIHRvDQo+ICAgICAgICAgMjAgYnl0ZXMgPw0KPiANCj4gDQo+ICAgICBUaGUgTUFD IGlzIHRvbyBsb25nIGFuZCBpdCBzaG91bGQgYmUgdHJ1Y2F0ZWQgdG8gMTYgb3IgMjAgYnl0 ZXMgbG9uZy4NCj4gDQo+ICAgICAgICAgV2h5IGlzIHRoZSBzYW1lIHAxOCB2ZXJzaW9uIGlu IGNsaWVudCBhbmQgc2VydmVyIG5vdCBjb21wYXRpYmxlID8NCj4gDQo+IA0KPiAgICAgSSBk byBub3Qga25vdywgbXkgYmVzdCBndWVzcyBpcyB0aGF0IHRoZSBjb2RlIG1pc3NlZCBhIHRy dW5jYXRpb24uDQo+IA0KDQotLSANCk1hcnRpbiBCdXJuaWNraQ0KDQpTZW5pb3IgU29mdHdh cmUgRW5naW5lZXINCg0KRW1haWw6IG1hcnRpbi5idXJuaWNraUBtZWluYmVyZy5kZQ0KUGhv bmU6ICs0OSA1MjgxIDkzMDktNDE0DQpMaW5rZWRpbjogaHR0cHM6Ly93d3cubGlua2VkaW4u Y29tL2luL21hcnRpbmJ1cm5pY2tpLw0KDQpNRUlOQkVSRyBGdW5rdWhyZW4gR21iSCAmIENv LiBLRw0KTGFuZ2UgV2FuZCA5DQozMTgxMiBCYWQgUHlybW9udCwgR2VybWFueQ0KDQpSZWdp c3RyeSBDb3VydDogQW10c2dlcmljaHQgSGFubm92ZXIgMTcgSFJBIDEwMDMyMg0KTWFuYWdp bmcgRGlyZWN0b3JzOiBOYXRhbGllIE1laW5iZXJnLCBEYW5pZWwgQm9sZHQsIEFuZHJlIEhh cnRtYW5uLCANCkhlaWtvIEdlcnN0dW5nDQoNCldlYnNpdGVzOiBodHRwczovL3d3dy5tZWlu YmVyZy5kZSAgaHR0cHM6Ly93d3cubWVpbmJlcmdnbG9iYWwuY29tDQoNCk1laW5iZXJnIC0g VGhlIFN5bmNocm9uaXphdGlvbiBFeHBlcnRzLg0KDQo=

--------------Mic94HPB0lo00JkdJjD0Whev--

--------------jCuDCeO0MhdiqXrDrS7Kpdzd
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEB4vtcjCE6s9kni+wQXIcDHUJ+cgFAmjCvd0FAwAAAAAACgkQQXIcDHUJ+chi +RAAgEdqaumUcCQjRmf54Z6YrzpA1mY8l2/DQ601GWzZSFg/a2TPhSeywllRTc5av+1kNfft44pM nhx4uzAvsSCuBCowEAcExtZLR/YjqBLwNmnWlx0MwWDHuoD27PGV7zCzb+6Uv2/xpvmkRgq6vXgZ KDyetX3YWSrIw+j43s2OoEQDwo5baMPUSc1gmBzgbHmc8gasGCkg3UKxDaM/4glCvBRRvNc9kaYR bOlvDNNE/NYr8u/J0W33KF55rOBpA3ISO3cVz/xbFpFnesJjjdqa3a9ZWoUjCSGN6xdiPkg67jmP qBN59KIzQR49g+xMWl9asQhhhuK3eyGKa4DeDKGILnTGBk6RmYoKmm2l+35A6F5ZnUE2rqbClEPU C4CDoOWt3/VeiROFu7Myl7+nf0TdEFUbCDChd70vLIWR/K11IeZOY7UbFoRgnwFlK7LlNdmqK5W0 9zeHL57tpXQLKccEM77VnoWder0IhqB4Zg03Ro/tkN6M+kVQgD29zc32QYW/9AVnB8TKIrmiHo/J 9m4npBpHsLWnvRJYc1Cj857hU7IlLqFb80Vf9uBeJC3qIakrz1iZFV6wckdCXfDsF4Ktd/9py3JP CZEGEIFkAY5zXkxxRcOh+ju6olXY8yMQSB+jUKoD3OIKXZ3lfkr5gQaSzXpzGahmIEH7unHlW8k3 guE=
=PKdj
-----END PGP SIGNATURE-----

--------------jCuDCeO0MhdiqXrDrS7Kpdzd--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--0000000000007ec27f063e86fab3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

ntpd is supposed to support SHA256, but there was a bug in version
4.2.8.p18.

See the ticket: https://bugs.ntp.org/show_bug.cgi?id=3D3954

A temporary patch has been created, and the fix is expected to be included
in the next release.

BR,
Samir

Le jeu. 11 sept. 2025 =C3=A0 14:18, Martin Burnicki <[email protected]=

a

=C3=A9crit :

Hi Murugesh,

As far as I know, ntpd from ntp.org doesn't really support SHA256.

Would it be possible to use AES128CMAC instead? That's supported well by ntpd.

Regards,

Martin

murugesh pitchaiah wrote:

Hi James,

Thanks for your reply.

Initially I had 4.2.8.p12 client. It was sending MAC of size 20 bytes
along with keyid 4 bytes. But for that, the p18 server reported error
"MAC length error, received 24 not 36".

Assuming the p18 expects MAC without truncation I tried p18 for client.
Now having p18 client and p18 server.

P18 client sending 32 plus 4. But p18 server reporting "bad EF length".

Thanks,
Murugesh

On Wed, 3 Sept, 2025, 5:32=E2=80=AFam James Browning, <pessimus192@gmai=

l.com

<mailto:[email protected]>> wrote:

On Mon, Sep 1, 2025, 03:21 murugesh pitchaiah
<[email protected] <mailto:[email protected]>=

wrote:

Why is the server rejecting this mac ? should MAC be reduced to
20 bytes ?

The MAC is too long and it should be trucated to 16 or 20 bytes lon=

g.

Why is the same p18 version in client and server not compatible=

?

I do not know, my best guess is that the code missed a truncation.

--
Martin Burnicki

Senior Software Engineer

Email: [email protected]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

MEINBERG Funkuhren GmbH & Co. KG
Lange Wand 9
31812 Bad Pyrmont, Germany

Registry Court: Amtsgericht Hannover 17 HRA 100322
Managing Directors: Natalie Meinberg, Daniel Boldt, Andre Hartmann,
Heiko Gerstung

Websites: https://www.meinberg.de https://www.meinbergglobal.com

Meinberg - The Synchronization Experts.

--=20

*Cordialement,*
*Samir MOUHOUNE*

--0000000000007ec27f063e86fab3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hello,</p>
<p>ntpd is supposed to support SHA256, but there was a bug in version 4.2.8= .p18.</p>
<p>See the ticket: <a rel=3D"noopener" class=3D"gmail-decorated-link" href= =3D"https://bugs.ntp.org/show_bug.cgi?id=3D3954">https://bugs.ntp.org/show_= bug.cgi?id=3D3954<span aria-hidden=3D"true" class=3D"gmail-ms-0.5 gmail-inl= ine-block gmail-align-middle gmail-leading-none"></span></a></p>
<p>A temporary patch has been created, and the fix is expected to be includ=
ed in the next release.<br><br>BR,<br>Samir</p></div><br><div class=3D"gmai= l_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2= =A0jeu. 11 sept. 2025 =C3=A0=C2=A014:18, Martin Burnicki &lt;<a href=3D"mai= lto:[email protected]">[email protected]</a>&gt; a =C3=A9crit= =C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Murug= esh,<br>

As far as I know, ntpd from <a href=3D"http://ntp.org" rel=3D"noreferrer" t= arget=3D"_blank">ntp.org</a> doesn&#39;t really support SHA256.<br>

Would it be possible to use AES128CMAC instead? That&#39;s supported well b=
y <br>
ntpd.<br>


Regards,<br>

Martin<br>


murugesh pitchaiah wrote:<br>
&gt; Hi James,<br>
&gt; <br>
&gt; Thanks for your reply.<br>
&gt; <br>
&gt; Initially I had 4.2.8.p12 client. It was sending MAC of size 20 bytes =

&gt; along with keyid 4 bytes.=C2=A0 But for that, the p18 server reported = error <br>
&gt; &quot;MAC length error, received 24 not 36&quot;.<br>
&gt; <br>
&gt; Assuming the p18 expects MAC without truncation I tried p18 for client=
. <br>
&gt; Now having p18 client and p18 server.<br>
&gt; <br>
&gt; P18 client sending 32 plus 4. But p18 server reporting &quot;bad EF le= ngth&quot;.<br>
&gt; <br>
&gt; Thanks,<br>
&gt; Murugesh<br>
&gt; <br>
&gt; On Wed, 3 Sept, 2025, 5:32=E2=80=AFam James Browning, &lt;<a href=3D"m= ailto:[email protected]" target=3D"_blank">[email protected]</a> <b=

&gt; &lt;mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a>&gt;&gt; wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0On Mon, Sep 1, 2025, 03:21 murugesh pitchaiah<br> &gt;=C2=A0 =C2=A0 =C2=A0&lt;<a href=3D"mailto:[email protected]"=
target=3D"_blank">[email protected]</a> &lt;mailto:<a href=3D"m= ailto:[email protected]" target=3D"_blank">murugesh.pitchaiah@gm= ail.com</a>&gt;&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Why is the server rejecting this mac =
? should MAC be reduced to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A020 bytes ?<br>
&gt; <br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0The MAC is too long and it should be trucated to 16=
or 20 bytes long.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Why is the same p18 version in client=
and server not compatible ?<br>
&gt; <br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0I do not know, my best guess is that the code misse=
d a truncation.<br>
&gt; <br>

-- <br>
Martin Burnicki<br>

Senior Software Engineer<br>

Email: <a href=3D"mailto:[email protected]" target=3D"_blank">mar= [email protected]</a><br>
Phone: +49 5281 9309-414<br>
Linkedin: <a href=3D"https://www.linkedin.com/in/martinburnicki/" rel=3D"no= referrer" target=3D"_blank">https://www.linkedin.com/in/martinburnicki/</a>=


MEINBERG Funkuhren GmbH &amp; Co. KG<br>
Lange Wand 9<br>
31812 Bad Pyrmont, Germany<br>

Registry Court: Amtsgericht Hannover 17 HRA 100322<br>
Managing Directors: Natalie Meinberg, Daniel Boldt, Andre Hartmann, <br>
Heiko Gerstung<br>

Websites: <a href=3D"https://www.meinberg.de" rel=3D"noreferrer" target=3D"= _blank">https://www.meinberg.de</a>=C2=A0 <a href=3D"https://www.meinberggl= obal.com" rel=3D"noreferrer" target=3D"_blank">https://www.meinbergglobal.c= om</a><br>

Meinberg - The Synchronization Experts.<br>

</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class= =3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s= ignature"><div dir=3D"ltr"><div><b><font size=3D"2"><i><span style=3D"font-= family:&quot;arial black&quot;,sans-serif">Cordialement,<br></span></i></fo= nt></b></div><b><font size=3D"2"><i><span style=3D"font-family:&quot;arial = black&quot;,sans-serif">Samir MOUHOUNE</span></i></font></b><br></div></div=


--0000000000007ec27f063e86fab3--

--- Synchronet 3.21a-Linux NewsLink 1.2