iOS 16.1 - Home App - Matter accessories

Hi,
Running node-matter 0.0.10 and iOS 16.1
Matter devices are discoverable on the network.
Cannot get pass the pairing process in Home App.
No log generated in node-matter.
Will try compiling chip-tool to run additionnal tests
node-matter process
MacBook-Pro ~ % matter
2022-9-0 18:2:43.811 INFO Device<EMAIL_ADDRESS>2022-9-0 18:2:43.830 INFO Device Listening
Network discovery
17066BB8F282C5E0._matterc._udp.local.
F018989E8D0E0000.local:5540
<IP_ADDRESS>:5540
CM = 1
D = 3840
DN = Matter test device
DT = 257
PH = 33
PI =
SAI = 300
SII = 5000
T = 1
VP = 65521+32769

Thanks for reporting this issue!
I will try to get my hand on an  iOS 16.1 device to reproduce on my side.
One guess of this bug: node-matter only supports IPv4 but Matter is supposed to be IPv6-only with best-effort IPv4 support.
Maybe iOs 16.1 doesn't like that.
No logs on node-matter since it doesn't even receive the iOs pairing request on IPv6
Any chance you can capture the network packets using wireshark?
That will help to figure out the low level.
Adding IPv6 support for node-matter should be pretty easy.

I did the same here, but there is logs and error in it :
jeedom@JeedomBeta:~/node-matter$ matter
2022-9-1 6:49:22.547 INFO Device<EMAIL_ADDRESS>2022-9-1 6:49:22.587 INFO Device Listening
2022-9-1 6:51:1.846 DEBUG MessageExchange onMessageReceived id:0/43688/113659899 t:0/32 reqAck:true payload:<PHONE_NUMBER>3e975736d8f886a1043e6c451e7c134fdac7933fb1f1256784167a6703496c2502d08f24030028043505250188132502d0071818
2022-9-1 6:51:1.846 DEBUG MessageExchange 43688 no message to ack
2022-9-1 6:51:1.847 INFO PaseServer Pase server: Received pairing request from udp://<IP_ADDRESS>:60453
2022-9-1 6:51:1.850 DEBUG MessageChannel sending id:0/43688/3279086306 t:0/33 acked:113659899 reqAck:true payload:<PHONE_NUMBER>3e975736d8f886a1043e6c451e7c134fdac7933fb1f1256784167a6703496c3002205a7950b3fdd3abce91c4f6a6d7dd5ca782cfb705c03f0a5e95731630b6397fdd25036f8935042501e8033002200fb328eea7db7c49316932e8478ff4bb333895588b3342bc292bce5c865d68c6183505250188132502d0071818
2022-9-1 6:51:2.023 DEBUG MessageExchange onMessageReceived id:0/43688/113659900 t:0/34 acked:3279086306 reqAck:true payload:<PHONE_NUMBER>7908fbd1b62e2f0b4aabc626c0a1c805e3beaa70d64c75daa4f47c2f79f3bed3edc7bef49d1919da1397735a0bb61eff27248e3db814a072957aeea91e186e6018
2022-9-1 6:51:2.023 DEBUG MessageExchange 43688 id:0/43688/3279086306 t:0/33 acked:113659899 reqAck:true payload:<PHONE_NUMBER>3e975736d8f886a1043e6c451e7c134fdac7933fb1f1256784167a6703496c3002205a7950b3fdd3abce91c4f6a6d7dd5ca782cfb705c03f0a5e95731630b6397fdd25036f8935042501e8033002200fb328eea7db7c49316932e8478ff4bb333895588b3342bc292bce5c865d68c6183505250188132502d0071818
2022-9-1 6:51:2.349 DEBUG MessageChannel sending id:0/43688/3279086307 t:0/35 acked:113659900 reqAck:true payload:<PHONE_NUMBER>b2efd1bb2e3fc7ba44bcba482dd1b9bb26f9b0fd346d383ffdb7efffdc2db13d85b03307f214369e9d6eee0ba782fb236583b23fc3a5b8b89005a71c5fde9fdf300220a80d39cb067486561de2573ea344307c2ac4f0eb5fabd2a3f011fa4cf177f95e18
2022-9-1 6:51:2.436 DEBUG MessageExchange onMessageReceived id:0/43688/113659901 t:0/36 acked:3279086307 reqAck:true payload:<PHONE_NUMBER>09f38fde1700f192916a5c51d849e131fefa5d595f373a35bb529ba270412018
2022-9-1 6:51:2.436 DEBUG MessageExchange 43688 id:0/43688/3279086307 t:0/35 acked:113659900 reqAck:true payload:<PHONE_NUMBER>b2efd1bb2e3fc7ba44bcba482dd1b9bb26f9b0fd346d383ffdb7efffdc2db13d85b03307f214369e9d6eee0ba782fb236583b23fc3a5b8b89005a71c5fde9fdf300220a80d39cb067486561de2573ea344307c2ac4f0eb5fabd2a3f011fa4cf177f95e18
2022-9-1 6:51:2.437 DEBUG MessageChannel sending id:0/43688/3279086308 t:0/64 acked:113659901 reqAck:true payload:<PHONE_NUMBER>000000
2022-9-1 6:51:2.438 INFO PaseServer Pase server: session 35183 created with udp://<IP_ADDRESS>:60453
2022-9-1 6:51:2.443 DEBUG MessageExchange onMessageReceived id:0/43688/113659902 t:0/16 acked:3279086308 reqAck:false payload:
2022-9-1 6:51:2.443 DEBUG MessageExchange 43688 id:0/43688/3279086308 t:0/64 acked:113659901 reqAck:true payload:<PHONE_NUMBER>000000
2022-9-1 6:51:2.451 DEBUG MessageExchange onMessageReceived id:35183/43689/222790560 t:1/2 reqAck:true payload:<PHONE_NUMBER>020024031d2404031818290324ff0118
2022-9-1 6:51:2.451 DEBUG MessageExchange 43689 no message to ack
2022-9-1 6:51:2.453 DEBUG InteractionProtocol Received read request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/29/3
2022-9-1 6:51:2.454 DEBUG MessageChannel sending id:35183/43689/3279086309 t:1/5 acked:222790560 reqAck:true payload:<PHONE_NUMBER>01240000370124020024031d24040318360218181818290424ff0118
2022-9-1 6:51:2.476 DEBUG MessageExchange onMessageReceived id:35183/43689/222790561 t:0/16 acked:3279086309 reqAck:false payload:
2022-9-1 6:51:2.476 DEBUG MessageExchange 43689 id:36816/43689/3279086309 t:1/5 acked:222790560 reqAck:true payload:<PHONE_NUMBER>01240000370124020024031d24040318360218181818290424ff0118
2022-9-1 6:51:2.477 DEBUG MessageExchange onMessageReceived id:35183/43690/222790562 t:1/2 reqAck:true payload:<PHONE_NUMBER>020024031d2404011818290324ff0118
2022-9-1 6:51:2.477 DEBUG MessageExchange 43690 no message to ack
2022-9-1 6:51:2.478 DEBUG InteractionProtocol Received read request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/29/1
2022-9-1 6:51:2.479 DEBUG MessageChannel sending id:35183/43690/3279086310 t:1/5 acked:222790562 reqAck:true payload:<PHONE_NUMBER>01240001370124020024031d24040118360204280430043e041d18181818290424ff0118
2022-9-1 6:51:2.486 DEBUG MessageExchange onMessageReceived id:35183/43690/222790563 t:0/16 acked:3279086310 reqAck:false payload:
2022-9-1 6:51:2.487 DEBUG MessageExchange 43690 id:36816/43690/3279086310 t:1/5 acked:222790562 reqAck:true payload:<PHONE_NUMBER>01240001370124020024031d24040118360204280430043e041d18181818290424ff0118
2022-9-1 6:51:2.487 DEBUG MessageExchange onMessageReceived id:35183/43691/222790564 t:1/2 reqAck:true payload:<PHONE_NUMBER>03312504fcff18172402002403302404001817240200240330240401181724020024033024040218172402002403302404031817240200240328240402181724020024032824040418172403312404031818290324ff0118
2022-9-1 6:51:2.487 DEBUG MessageExchange 43691 no message to ack
2022-9-1 6:51:2.496 DEBUG InteractionProtocol Received read request from udp://<IP_ADDRESS>:60453 on session secure/35183: */49/65532, 0/48/0, 0/48/1, 0/48/2, 0/48/3, 0/40/2, 0/40/4, */49/3
2022-9-1 6:51:2.497 DEBUG MessageChannel sending id:35183/43691/3279086311 t:1/5 acked:222790564 reqAck:true payload:<PHONE_NUMBER>012400003701240200240330240400182402001818153501240000370124020024033024040118350224003c25018403181818153501240000370124020024033024040218240200181815350124000037012402002403302404031824020218181535012400003701240200240328240402182502f1ff181815350124000037012402002403282404041825020180181818290424ff0118
2022-9-1 6:51:2.521 DEBUG MessageExchange onMessageReceived id:35183/43692/222790565 t:1/8 reqAck:true payload:<PHONE_NUMBER>360215370024000024013024020018350124003c24010318181824ff0118
2022-9-1 6:51:2.521 DEBUG MessageExchange 43692 no message to ack
2022-9-1 6:51:2.521 DEBUG InteractionProtocol Received invoke request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/48/0
2022-9-1 6:51:2.522 DEBUG MessageChannel sending id:35183/43692/3279086312 t:1/9 acked:222790565 reqAck:true payload:<PHONE_NUMBER>15350037002400002401302402011835012400002c01001818181824ff0118
2022-9-1 6:51:2.523 DEBUG MessageExchange onMessageReceived id:35183/43691/222790566 t:0/16 acked:3279086311 reqAck:false payload:
2022-9-1 6:51:2.523 DEBUG MessageExchange 43691 id:36816/43691/3279086311 t:1/5 acked:222790564 reqAck:true payload:<PHONE_NUMBER>012400003701240200240330240400182402001818153501240000370124020024033024040118350224003c25018403181818153501240000370124020024033024040218240200181815350124000037012402002403302404031824020218181535012400003701240200240328240402182502f1ff181815350124000037012402002403282404041825020180181818290424ff0118
2022-9-1 6:51:2.532 DEBUG MessageExchange onMessageReceived id:35183/43693/222790567 t:1/8 reqAck:true payload:<PHONE_NUMBER>36021537002400002401302402021835012400002c0102585824020418181824ff0118
2022-9-1 6:51:2.533 DEBUG MessageExchange 43693 no message to ack
2022-9-1 6:51:2.533 DEBUG InteractionProtocol Received invoke request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/48/2
2022-9-1 6:51:2.534 DEBUG MessageChannel sending id:35183/43693/3279086313 t:1/9 acked:222790567 reqAck:true payload:<PHONE_NUMBER>15350037002400002401302402031835012400002c01001818181824ff0118
2022-9-1 6:51:2.545 DEBUG MessageExchange onMessageReceived id:35183/43692/222790568 t:0/16 acked:3279086312 reqAck:false payload:
2022-9-1 6:51:2.545 DEBUG MessageExchange 43692 id:36816/43692/3279086312 t:1/9 acked:222790565 reqAck:true payload:<PHONE_NUMBER>15350037002400002401302402011835012400002c01001818181824ff0118
2022-9-1 6:51:2.554 DEBUG MessageExchange onMessageReceived id:35183/43694/222790569 t:1/8 reqAck:true payload:<PHONE_NUMBER>360215370024000024013e24020218350124000218181824ff0118
2022-9-1 6:51:2.554 DEBUG MessageExchange 43694 no message to ack
2022-9-1 6:51:2.555 DEBUG InteractionProtocol Received invoke request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/62/2
2022-9-1 6:51:2.556 DEBUG MessageChannel sending id:35183/43694/3279086314 t:1/9 acked:222790569 reqAck:true payload:<PHONE_NUMBER>153500370024000024013e2402031835013100d801308201d43082017aa00302010202083e6ce6509ad840cd300a06082a8648ce3d04030230303118301606035504030c0f4d617474657220546573742050414131143012060a2b0601040182a27c02010c04464646313020170d3231303632383134323334335a180f39393939313233313233353935395a30463118301606035504030c0f4d617474657220546573742050414931143012060a2b0601040182a27c02010c044646463131143012060a2b0601040182a27c02020c04383030303059301306072a8648ce3d020106082a8648ce3d0301070342000480ddf11b228f3e31f63bcf5798da14623aebbde82ef378eeadbfb18fe1abce31d08ed4b20604b6ccc6d9b5fab64e7de10cb74be017c9ec1516056d70f2cd0b22a366306430120603551d130101ff040830060101ff020100300e0603551d0f0101ff040403020106301d0603551d0e04160414af42b7094debd515ec6ecf33b81115225f325288301f0603551d230418301680146afd22771f511fecbf1641976710dcdc31a1717e300a06082a8648ce3d040302034800304502210096c9c8cf2e01886005d8f5bc72c07b75fd9a57695ac4911131138bea033ce50302202554943be57d53d6c475f7d23ebfcfc2036cd29ba6393ec7efad8714ab7182191818181824ff0118
2022-9-1 6:51:2.558 DEBUG MessageExchange onMessageReceived id:35183/43693/222790570 t:0/16 acked:3279086313 reqAck:false payload:
2022-9-1 6:51:2.558 DEBUG MessageExchange 43693 id:36816/43693/3279086313 t:1/9 acked:222790567 reqAck:true payload:<PHONE_NUMBER>15350037002400002401302402031835012400002c01001818181824ff0118
2022-9-1 6:51:2.567 DEBUG MessageExchange onMessageReceived id:35183/43695/222790571 t:1/8 reqAck:true payload:<PHONE_NUMBER>360215370024000024013e24020218350124000118181824ff0118
2022-9-1 6:51:2.567 DEBUG MessageExchange 43695 no message to ack
2022-9-1 6:51:2.568 DEBUG InteractionProtocol Received invoke request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/62/2
2022-9-1 6:51:2.568 DEBUG MessageChannel sending id:35183/43695/3279086315 t:1/9 acked:222790571 reqAck:true payload:<PHONE_NUMBER>153500370024000024013e2402031835013100ec01308201e83082018fa0030201020208143c9d1689f498f0300a06082a8648ce3d04030230463118301606035504030c0f4d617474657220546573742050414931143012060a2b0601040182a27c02010c044646463131143012060a2b0601040182a27c02020c04383030303020170d3231303632383134323334335a180f39393939313233313233353935395a304b311d301b06035504030c144d6174746572205465737420444143203030303731143012060a2b0601040182a27c02010c044646463131143012060a2b0601040182a27c02020c04383030303059301306072a8648ce3d020106082a8648ce3d0301070342000462e2b6e1baff8d74a6fd8216c4cb67a3363a31e691492792e61aee610261481396725ef95e142686ba98f339b0ff65bc338bec7b9e8be0bdf3b2774982476220a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414ee95ad96983a9ea95bcd2b00dc5e671727690383301f0603551d23041830168014af42b7094debd515ec6ecf33b81115225f325288300a06082a8648ce3d040302034700304402202f51cf53bf7777df7318094b9db595eebf2fa881c8c572847b1e689ece654264022029782708ee6b32c7f08ff63dbe618e9a580bb14c183bc288777adf9e2dcff5e61818181824ff0118
2022-9-1 6:51:2.569 DEBUG MessageExchange onMessageReceived id:35183/43694/222790572 t:0/16 acked:3279086314 reqAck:false payload:
2022-9-1 6:51:2.572 DEBUG MessageExchange 43694 id:36816/43694/3279086314 t:1/9 acked:222790569 reqAck:true payload:<PHONE_NUMBER>153500370024000024013e2402031835013100d801308201d43082017aa00302010202083e6ce6509ad840cd300a06082a8648ce3d04030230303118301606035504030c0f4d617474657220546573742050414131143012060a2b0601040182a27c02010c04464646313020170d3231303632383134323334335a180f39393939313233313233353935395a30463118301606035504030c0f4d617474657220546573742050414931143012060a2b0601040182a27c02010c044646463131143012060a2b0601040182a27c02020c04383030303059301306072a8648ce3d020106082a8648ce3d0301070342000480ddf11b228f3e31f63bcf5798da14623aebbde82ef378eeadbfb18fe1abce31d08ed4b20604b6ccc6d9b5fab64e7de10cb74be017c9ec1516056d70f2cd0b22a366306430120603551d130101ff040830060101ff020100300e0603551d0f0101ff040403020106301d0603551d0e04160414af42b7094debd515ec6ecf33b81115225f325288301f0603551d230418301680146afd22771f511fecbf1641976710dcdc31a1717e300a06082a8648ce3d040302034800304502210096c9c8cf2e01886005d8f5bc72c07b75fd9a57695ac4911131138bea033ce50302202554943be57d53d6c475f7d23ebfcfc2036cd29ba6393ec7efad8714ab7182191818181824ff0118
2022-9-1 6:51:2.577 DEBUG MessageExchange onMessageReceived id:35183/43696/222790573 t:1/8 reqAck:true payload:<PHONE_NUMBER>360215370024000024013e2402001835013000205ca7f197d1ce2f7108a62b2659bd77b42bdf435c593300fde010ee5db9c7594118181824ff0118
2022-9-1 6:51:2.577 DEBUG MessageExchange 43696 no message to ack
2022-9-1 6:51:2.577 DEBUG InteractionProtocol Received invoke request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/62/0
2022-9-1 6:51:2.592 DEBUG MessageChannel sending id:35183/43696/3279086316 t:1/9 acked:222790573 reqAck:true payload:<PHONE_NUMBER>153500370024000024013e240201183501310049021531011d023082021906092a864886f70d010702a082020a30820206020103310d300b06096086480165030402013082017106092a864886f70d010701a08201620482015e152400012501f1ff3602050080050180050280050380050480050580050680050780050880050980050a80050b80050c80050d80050e80050f80051080051180051280051380051480051580051680051780051880051980051a80051b80051c80051d80051e80051f80052080052180052280052380052480052580052680052780052880052980052a80052b80052c80052d80052e80052f80053080053180053280053380053480053580053680053780053880053980053a80053b80053c80053d80053e80053f80054080054180054280054380054480054580054680054780054880054980054a80054b80054c80054d80054e80054f80055080055180055280055380055480055580055680055780055880055980055a80055b80055c80055d80055e80055f80056080056180056280056380182403162c04135a494732303134325a423333303030332d32342405002406002507942624080018317d307b020103801462fa823359acfaa9963e1cfa140addf504f37160300b0609608648016503040201300a06082a8648ce3d04030204473045022024e5d1f47a7d7b0d206a26ef699b7c9757b72d469089de3192e678c745e7f60c022100f8aa2fa711fcb79b97e397ceda667bae464e2bd3ffdfc3cced7aa8ca5f4c1a7c3002205ca7f197d1ce2f7108a62b2659bd77b42bdf435c593300fde010ee5db9c7594124030018300140df7350274c4ed6a308ecb561488165e1dff1c06c435538fabdd17f01b1fde6c65b6769fcff1915d282fe3c96f087f6071057ad72a1c80f26eebd6ac0e0f7ad661818181824ff0118
2022-9-1 6:51:2.593 DEBUG MessageExchange onMessageReceived id:35183/43695/222790574 t:0/16 acked:3279086315 reqAck:false payload:
2022-9-1 6:51:2.593 DEBUG MessageExchange 43695 id:36816/43695/3279086315 t:1/9 acked:222790571 reqAck:true payload:<PHONE_NUMBER>153500370024000024013e2402031835013100ec01308201e83082018fa0030201020208143c9d1689f498f0300a06082a8648ce3d04030230463118301606035504030c0f4d617474657220546573742050414931143012060a2b0601040182a27c02010c044646463131143012060a2b0601040182a27c02020c04383030303020170d3231303632383134323334335a180f39393939313233313233353935395a304b311d301b06035504030c144d6174746572205465737420444143203030303731143012060a2b0601040182a27c02010c044646463131143012060a2b0601040182a27c02020c04383030303059301306072a8648ce3d020106082a8648ce3d0301070342000462e2b6e1baff8d74a6fd8216c4cb67a3363a31e691492792e61aee610261481396725ef95e142686ba98f339b0ff65bc338bec7b9e8be0bdf3b2774982476220a360305e300c0603551d130101ff04023000300e0603551d0f0101ff040403020780301d0603551d0e04160414ee95ad96983a9ea95bcd2b00dc5e671727690383301f0603551d23041830168014af42b7094debd515ec6ecf33b81115225f325288300a06082a8648ce3d040302034700304402202f51cf53bf7777df7318094b9db595eebf2fa881c8c572847b1e689ece654264022029782708ee6b32c7f08ff63dbe618e9a580bb14c183bc288777adf9e2dcff5e61818181824ff0118
2022-9-1 6:51:2.629 DEBUG MessageExchange onMessageReceived id:35183/43697/222790575 t:1/8 reqAck:true payload:<PHONE_NUMBER>360215370024000024013024020018350124003c24010818181824ff0118
2022-9-1 6:51:2.629 DEBUG MessageExchange 43697 no message to ack
2022-9-1 6:51:2.630 DEBUG InteractionProtocol Received invoke request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/48/0
2022-9-1 6:51:2.630 DEBUG MessageChannel sending id:35183/43697/3279086317 t:1/9 acked:222790575 reqAck:true payload:<PHONE_NUMBER>15350037002400002401302402011835012400002c01001818181824ff0118
2022-9-1 6:51:2.630 DEBUG MessageExchange onMessageReceived id:35183/43696/222790576 t:0/16 acked:3279086316 reqAck:false payload:
2022-9-1 6:51:2.631 DEBUG MessageExchange 43696 id:36816/43696/3279086316 t:1/9 acked:222790573 reqAck:true payload:<PHONE_NUMBER>153500370024000024013e240201183501310049021531011d023082021906092a864886f70d010702a082020a30820206020103310d300b06096086480165030402013082017106092a864886f70d010701a08201620482015e152400012501f1ff3602050080050180050280050380050480050580050680050780050880050980050a80050b80050c80050d80050e80050f80051080051180051280051380051480051580051680051780051880051980051a80051b80051c80051d80051e80051f80052080052180052280052380052480052580052680052780052880052980052a80052b80052c80052d80052e80052f80053080053180053280053380053480053580053680053780053880053980053a80053b80053c80053d80053e80053f80054080054180054280054380054480054580054680054780054880054980054a80054b80054c80054d80054e80054f80055080055180055280055380055480055580055680055780055880055980055a80055b80055c80055d80055e80055f80056080056180056280056380182403162c04135a494732303134325a423333303030332d32342405002406002507942624080018317d307b020103801462fa823359acfaa9963e1cfa140addf504f37160300b0609608648016503040201300a06082a8648ce3d04030204473045022024e5d1f47a7d7b0d206a26ef699b7c9757b72d469089de3192e678c745e7f60c022100f8aa2fa711fcb79b97e397ceda667bae464e2bd3ffdfc3cced7aa8ca5f4c1a7c3002205ca7f197d1ce2f7108a62b2659bd77b42bdf435c593300fde010ee5db9c7594124030018300140df7350274c4ed6a308ecb561488165e1dff1c06c435538fabdd17f01b1fde6c65b6769fcff1915d282fe3c96f087f6071057ad72a1c80f26eebd6ac0e0f7ad661818181824ff0118
2022-9-1 6:51:2.638 DEBUG MessageExchange onMessageReceived id:35183/43697/222790577 t:0/16 acked:3279086317 reqAck:false payload:
2022-9-1 6:51:2.638 DEBUG MessageExchange 43697 id:36816/43697/3279086317 t:1/9 acked:222790575 reqAck:true payload:<PHONE_NUMBER>15350037002400002401302402011835012400002c01001818181824ff0118
2022-9-1 6:51:4.281 DEBUG MessageExchange onMessageReceived id:35183/43698/222790578 t:1/8 reqAck:true payload:<PHONE_NUMBER>360215370024000024013e2402041835013000209f2ba4cc3a8a22e5335981815738e588075a27c94d0c29d4ef034e1a1fabaaf318181824ff0118
2022-9-1 6:51:4.281 DEBUG MessageExchange 43698 no message to ack
2022-9-1 6:51:4.281 DEBUG InteractionProtocol Received invoke request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/62/4
2022-9-1 6:51:4.282 DEBUG MessageChannel sending id:35183/43698/3279086318 t:1/9 acked:222790578 reqAck:true payload:<PHONE_NUMBER>153500370024000024013e2402051835013000f3153001cb3081c83070020100300e310c300a060355040a0c034353523059301306072a8648ce3d020106082a8648ce3d03010703420004aa06074290173ae948f131d6813f790292b68b356f78181749b73994d0ca76f9bd414e06bfe8bcaa9e3aaeef2374014d73526ebbb51bca9eedfd316ac970cf34a000300a06082a8648ce3d04030203480030450220675069bfc2dc95bbc42035a1a7071aafbb40c7cbc4bb6674e44013994a2ebdc3022100d8bebf35b713b5e48707041a2432bcd8394283353369c68c5cbc08d45e6348c73002209f2ba4cc3a8a22e5335981815738e588075a27c94d0c29d4ef034e1a1fabaaf318300140529e613fc2c19f66885a321c17c06eaf3347047175f0c425ded3fc45a0391b95fe76f43c751f02ef337c47b522a91e47b1472e1a158eeb2e8e37d5e44346a7b61818181824ff0118
2022-9-1 6:51:4.325 DEBUG MessageExchange onMessageReceived id:35183/43699/222790579 t:1/8 reqAck:true payload:<PHONE_NUMBER>360215370024000024013e24020b1835013000fb153001010024020137032714e7b1cf8d6ec7cbc9241501182604791ef22a2605f951d32c37062714e7b1cf8d6ec7cbc92415011824070124080130094104a1e50fdb8491b895647775fde4828d57f5f21ee9d065dbbe7e342f92e67a9dafa6672c786a83e3a478375618059e85eea9b4130d3b7305d689b34b7daaaa7f42370a35012901182402603004143423200b26152d07e4029725234f8c29c8adb7c23005143423200b26152d07e4029725234f8c29c8adb7c218300b40f00f4aed3331e25184c551c6a3070a5ae7c4f66f2ba3737dcd0dace5f119981a2bf799699827b76ab9052d65099e6b8b5bd854af2c22c0305268f34ce5c49e061818181824ff0118
2022-9-1 6:51:4.325 DEBUG MessageExchange 43699 no message to ack
2022-9-1 6:51:4.326 DEBUG InteractionProtocol Received invoke request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/62/11
2022-9-1 6:51:4.326 DEBUG MessageChannel sending id:35183/43699/3279086319 t:1/9 acked:222790579 reqAck:true payload:<PHONE_NUMBER>153501370024000024013e24020b1835012400001818181824ff0118
2022-9-1 6:51:4.326 DEBUG MessageExchange onMessageReceived id:35183/43698/222790580 t:0/16 acked:3279086318 reqAck:false payload:
2022-9-1 6:51:4.327 DEBUG MessageExchange 43698 id:36816/43698/3279086318 t:1/9 acked:222790578 reqAck:true payload:<PHONE_NUMBER>153500370024000024013e2402051835013000f3153001cb3081c83070020100300e310c300a060355040a0c034353523059301306072a8648ce3d020106082a8648ce3d03010703420004aa06074290173ae948f131d6813f790292b68b356f78181749b73994d0ca76f9bd414e06bfe8bcaa9e3aaeef2374014d73526ebbb51bca9eedfd316ac970cf34a000300a06082a8648ce3d04030203480030450220675069bfc2dc95bbc42035a1a7071aafbb40c7cbc4bb6674e44013994a2ebdc3022100d8bebf35b713b5e48707041a2432bcd8394283353369c68c5cbc08d45e6348c73002209f2ba4cc3a8a22e5335981815738e588075a27c94d0c29d4ef034e1a1fabaaf318300140529e613fc2c19f66885a321c17c06eaf3347047175f0c425ded3fc45a0391b95fe76f43c751f02ef337c47b522a91e47b1472e1a158eeb2e8e37d5e44346a7b61818181824ff0118
2022-9-1 6:51:4.331 DEBUG MessageExchange onMessageReceived id:35183/43700/222790581 t:1/8 reqAck:true payload:<PHONE_NUMBER>360215370024000024013e2402061835013000fe153001010124020137032714e7b1cf8d6ec7cbc9241501182604c81ef22a26054852d32c37062415012611d1ee71261824070124080130094104aa06074290173ae948f131d6813f790292b68b356f78181749b73994d0ca76f9bd414e06bfe8bcaa9e3aaeef2374014d73526ebbb51bca9eedfd316ac970cf34370a350128011824020136030402040118300414fa12cdcbf50286c70159f3b6337574c9d96c5f9d3005143423200b26152d07e4029725234f8c29c8adb7c218300b40dad4d104d7677e6b61033571ea6a83c563f651d7b7a4e6d0f724c185d7b1def349f18cedb1ae272759502d6de4e879f7f449f006e8beccfb8967d40245a2a5a5183001003002105a8d028c9301468b300aafe36ab16414270349363248742ffa3e2504491318181824ff0118
2022-9-1 6:51:4.331 DEBUG MessageExchange 43700 no message to ack
2022-9-1 6:51:4.332 DEBUG InteractionProtocol Received invoke request from udp://<IP_ADDRESS>:60453 on session secure/35183: 0/62/6
2022-9-1 6:51:4.333 DEBUG MessageExchange onMessageReceived id:35183/43699/222790582 t:0/16 acked:3279086319 reqAck:false payload:
2022-9-1 6:51:4.333 DEBUG MessageExchange 43699 id:36816/43699/3279086319 t:1/9 acked:222790579 reqAck:true payload:<PHONE_NUMBER>153501370024000024013e24020b1835012400001818181824ff0118
2022-9-1 6:51:4.335 DEBUG MessageChannel sending id:35183/43700/3279086320 t:1/9 acked:222790581 reqAck:true payload:<PHONE_NUMBER>153500370024000024013e2402081835012400001818181824ff0118
2022-9-1 6:51:4.345 DEBUG MessageExchange onMessageReceived id:35183/43700/222790583 t:0/16 acked:3279086320 reqAck:false payload:
2022-9-1 6:51:4.345 DEBUG MessageExchange 43700 id:36816/43700/3279086320 t:1/9 acked:222790581 reqAck:true payload:<PHONE_NUMBER>153500370024000024013e2402081835012400001818181824ff0118
2022-9-1 6:51:4.629 DEBUG MessageExchange onMessageReceived id:0/43701/113659903 t:0/48 reqAck:true payload: 153001203e0ed07afc3615c5fb0636d508b20e0976a0636c53dcd7d47a8e54502f356b562502d18f3003203998a74309cd554bae6e42f310379101243d7ea2862a3a059273f888ef0813fe300441042238d6f12a415da8b88958c66e44db93cb5941a06d5567e61a7b86d225e1aecd18852298cf8e74a29508be161cecd46bc1b49ba8b71a0c6c35c315efb074ee243505250188132502d0071818
2022-9-1 6:51:4.629 DEBUG MessageExchange 43701 no message to ack
2022-9-1 6:51:4.630 INFO CaseServer Case server: Received pairing request from udp://<IP_ADDRESS>:60453
2022-9-1 6:51:4.633 DEBUG MessageChannel sending id:0/43701/3279086321 t:0/49 acked:113659903 reqAck:true payload: 153001204b4354059398f0ca6e9c31c76dc6d571eae16623f07a1a20181f630191dad5d32502708930034104c85368735356bdf422cd1849a71334b1a32f22022e45badee4d22639e55b949158a274eb4b53beaf5e3f2af87564a9f259a682b9fae74b6eaaf8f0793b64bede31046901cf986dc7695be451e0de21a0f841683781b63e73c18bc3e0366f5b789587550bf9bf2edf635c47a832e57b8cb374bc5505ed047263875e42f457b083eeb5f327e90e207f8c2ca57372dc79856229be8bda17057b5363c61acefc2c9089956ca723c0d57cdc75267fb5713d871470de22793cbc657ff42977e163a62dc87517ca7d3a49b2938503434d1e3b8a47bf69097b53eb598595c5f6c05678f2783190b444513f845d4a097fead57a1ef05c6cb1303c6be842082d8e12b74ee023d73463b89f9e9ef6b134239d38efcacc3bb49e1dcf09f9a64fd8c2bd305cd3581772b70dac6657782500c59d89a4f7e19825f271cbb6bf0f9d47e5b0613f666d86f84b272c5534319e8416d7063cecef79ed21adcfc665e734ddb4766e1513f792292283cc521ffa415419a33c5152d3d4865d55ab1fd621977c9e683400accd6fe84623cfcdb359cdee541278a4f2d05b07c11cfb485b9cc64445444cc4786f1fbab74b9240089c23cd51bc3505250188132502d0071818
2022-9-1 6:51:4.673 DEBUG MessageExchange onMessageReceived id:0/43701/113659904 t:0/50 acked:3279086321 reqAck:true payload: 1531015b016a3763fa282df3e242975c2b1290d2f7f73adbf3b6498f8ec21e4a1e758e55ef51f9cf28f7f17cddc2a4533c1547c04ced388c537aa8c575c4229fde9c61dc596fe990082c1c437af7c3eda40df045741a06b8b4aa4f18439a721ee1a82db3200b1afe01ce55c5020c23f48cf5dbe24c84c5fccba2ac6d15a387c8b751734fb00205f74ab7655cd1aa120700bd28745fa6307106364eaf7dfbcef6fd87e2e4bac9344a69a41a55300ad6e7772ca6fda6486e628a59459b8e6b186aeaabae70bef4f195c796f779cd12f4a1f0c7e54b56347649fa60c987e5a1e2ac454e27820efe17f1620368c04ab1acb264d3cb7461c5d873f9663d122df72649878eb18c20cf3b826524c48b9556c364dc7c0c87dd0f0de1870364c4e8987b61c088d0a9f7338e81246467448eb035132c5c1926f957b22ab667bb19580be5c4b0c75786ddb5900f85131f867bba09acff0e08163fddbd595be26fea61c4922818
2022-9-1 6:51:4.673 DEBUG MessageExchange 43701 id:0/43701/3279086321 t:0/49 acked:113659903 reqAck:true payload: 153001204b4354059398f0ca6e9c31c76dc6d571eae16623f07a1a20181f630191dad5d32502708930034104c85368735356bdf422cd1849a71334b1a32f22022e45badee4d22639e55b949158a274eb4b53beaf5e3f2af87564a9f259a682b9fae74b6eaaf8f0793b64bede31046901cf986dc7695be451e0de21a0f841683781b63e73c18bc3e0366f5b789587550bf9bf2edf635c47a832e57b8cb374bc5505ed047263875e42f457b083eeb5f327e90e207f8c2ca57372dc79856229be8bda17057b5363c61acefc2c9089956ca723c0d57cdc75267fb5713d871470de22793cbc657ff42977e163a62dc87517ca7d3a49b2938503434d1e3b8a47bf69097b53eb598595c5f6c05678f2783190b444513f845d4a097fead57a1ef05c6cb1303c6be842082d8e12b74ee023d73463b89f9e9ef6b134239d38efcacc3bb49e1dcf09f9a64fd8c2bd305cd3581772b70dac6657782500c59d89a4f7e19825f271cbb6bf0f9d47e5b0613f666d86f84b272c5534319e8416d7063cecef79ed21adcfc665e734ddb4766e1513f792292283cc521ffa415419a33c5152d3d4865d55ab1fd621977c9e683400accd6fe84623cfcdb359cdee541278a4f2d05b07c11cfb485b9cc64445444cc4786f1fbab74b9240089c23cd51bc3505250188132502d0071818
2022-9-1 6:51:4.675 INFO CaseServer Case server: session 35184 created with udp://<IP_ADDRESS>:60453
2022-9-1 6:51:4.675 DEBUG MessageChannel sending id:0/43701/3279086322 t:0/64 acked:113659904 reqAck:true payload:<PHONE_NUMBER>000000
2022-9-1 6:51:4.680 DEBUG MessageExchange onMessageReceived id:35184/43702/265842085 t:1/8 reqAck:true payload:<PHONE_NUMBER>360215370024000024013024020418350118181824ff0118
2022-9-1 6:51:4.680 DEBUG MessageExchange 43702 no message to ack
2022-9-1 6:51:4.681 DEBUG InteractionProtocol Received invoke request from udp://<IP_ADDRESS>:60453 on session secure/35184: 0/48/4
2022-9-1 6:51:4.681 INFO GeneralCommissioningClusterHandler Commissioning completed on fabric #1 as node #645000913.
2022-9-1 6:51:4.682 DEBUG MessageChannel sending id:35184/43702/3279086323 t:1/9 acked:265842085 reqAck:true payload:<PHONE_NUMBER>15350037002400002401302402051835012400002c01001818181824ff0118
2022-9-1 6:51:4.683 DEBUG MessageExchange onMessageReceived id:0/43701/113659905 t:0/16 acked:3279086322 reqAck:false payload:
2022-9-1 6:51:4.683 DEBUG MessageExchange 43701 id:0/43701/3279086322 t:0/64 acked:113659904 reqAck:true payload:<PHONE_NUMBER>000000
2022-9-1 6:51:4.687 DEBUG MessageExchange onMessageReceived id:35184/43702/265842086 t:0/16 acked:3279086323 reqAck:false payload:
2022-9-1 6:51:4.687 DEBUG MessageExchange 43702 id:36817/43702/3279086323 t:1/9 acked:265842085 reqAck:true payload:<PHONE_NUMBER>15350037002400002401302402051835012400002c01001818181824ff0118
2022-9-1 6:51:4.702 DEBUG MessageExchange onMessageReceived id:35184/43703/265842087 t:1/2 reqAck:true payload:<PHONE_NUMBER>020024033e2404011818290324ff0118
2022-9-1 6:51:4.702 DEBUG MessageExchange 43703 no message to ack
2022-9-1 6:51:4.703 DEBUG InteractionProtocol Received read request from udp://<IP_ADDRESS>:60453 on session secure/35184: 0/62/1
2022-9-1 6:51:4.703 DEBUG MessageChannel sending id:35184/43703/3279086324 t:1/5 acked:265842087 reqAck:true payload:<PHONE_NUMBER>01240000370124020024033e24040118360218181818290424ff0118
2022-9-1 6:51:4.709 DEBUG MessageExchange onMessageReceived id:35184/43703/265842088 t:0/16 acked:3279086324 reqAck:false payload:
2022-9-1 6:51:4.710 DEBUG MessageExchange 43703 id:36817/43703/3279086324 t:1/5 acked:265842087 reqAck:true payload:<PHONE_NUMBER>01240000370124020024033e24040118360218181818290424ff0118
2022-9-1 6:51:4.710 DEBUG MessageExchange onMessageReceived id:35184/43704/265842089 t:1/2 reqAck:true payload:<PHONE_NUMBER>020024031d2404031818290324ff0118
2022-9-1 6:51:4.711 DEBUG MessageExchange 43704 no message to ack
2022-9-1 6:51:4.711 DEBUG InteractionProtocol Received read request from udp://<IP_ADDRESS>:60453 on session secure/35184: 0/29/3
2022-9-1 6:51:4.711 DEBUG MessageChannel sending id:35184/43704/3279086325 t:1/5 acked:265842089 reqAck:true payload:<PHONE_NUMBER>01240000370124020024031d24040318360218181818290424ff0118
2022-9-1 6:51:4.716 DEBUG MessageExchange onMessageReceived id:35184/43704/265842090 t:0/16 acked:3279086325 reqAck:false payload:
2022-9-1 6:51:4.716 DEBUG MessageExchange 43704 id:36817/43704/3279086325 t:1/5 acked:265842089 reqAck:true payload:<PHONE_NUMBER>01240000370124020024031d24040318360218181818290424ff0118
2022-9-1 6:51:4.717 DEBUG MessageExchange onMessageReceived id:35184/43705/265842091 t:1/2 reqAck:true payload:<PHONE_NUMBER>020024033e2404011818280324ff0118
2022-9-1 6:51:4.717 DEBUG MessageExchange 43705 no message to ack
2022-9-1 6:51:4.717 DEBUG InteractionProtocol Received read request from udp://<IP_ADDRESS>:60453 on session secure/35184: 0/62/1
2022-9-1 6:51:4.718 DEBUG MessageChannel sending id:35184/43705/3279086326 t:1/5 acked:265842091 reqAck:true payload:<PHONE_NUMBER>01240000370124020024033e24040118360218181818290424ff0118
2022-9-1 6:51:4.722 DEBUG MessageExchange onMessageReceived id:35184/43705/265842092 t:0/16 acked:3279086326 reqAck:false payload:
2022-9-1 6:51:4.723 DEBUG MessageExchange 43705 id:36817/43705/3279086326 t:1/5 acked:265842091 reqAck:true payload:<PHONE_NUMBER>01240000370124020024033e24040118360218181818290424ff0118
2022-9-1 6:51:4.754 DEBUG MessageExchange onMessageReceived id:35184/43706/265842093 t:1/10 reqAck:true payload:<PHONE_NUMBER>24ff0118
2022-9-1 6:51:4.754 DEBUG MessageExchange 43706 no message to ack
2022-9-1 6:51:4.754 ERROR InteractionServerMessenger Error: Unsupported message type 10
2022-9-1 6:51:4.755 DEBUG MessageChannel sending id:35184/43706/3279086327 t:1/1 acked:265842093 reqAck:true payload:<PHONE_NUMBER>ff0118
2022-9-1 6:51:4.766 DEBUG MessageExchange onMessageReceived id:35184/43706/265842094 t:0/16 acked:3279086327 reqAck:false payload:
2022-9-1 6:51:4.766 DEBUG MessageExchange 43706 id:36817/43706/3279086327 t:1/1 acked:265842093 reqAck:true payload:<PHONE_NUMBER>ff0118

Did a Wireshark dump.
Can see some iOS device MDNS chatter looking for .matter devices.
No active connection on node-matter UDP 5540 port though ...
Currently building chip-tool on another computer to further test if chip-tool can connect of ipv4 wifi network.

I was able to install iOs 16.1 on my old iPhone 8 so I will be able to reproduce the issue pretty soon...
node-matter only advertises an A record on MDNS (for IPv4, instead of a AAAA record for IPv6) so maybe iOs doesn't even try to connect.
But the problem can be completely something else, IPv6 issue was just a wild guess. chip-tool works without problem with node-matter on IPv4 only.

I did the same here, but there is logs and error in it :
2022-9-1 6:51:4.766 DEBUG MessageExchange onMessageReceived id:35184/43706/265842094 t:0/16 acked:3279086327 reqAck:false payload:
2022-9-1 6:51:4.766 DEBUG MessageExchange 43706 id:36817/43706/3279086327 t:1/1 acked:265842093 reqAck:true payload:<PHONE_NUMBER>ff0118

Same here on iOS 16.1 Maybe this "false payload" 👆 could give a hint on the pairing mismatch.

I just tried and for me, iOs 16.1 sees the node-matter and tries to pair with it but node-matter crashes in the middle.
I am investigating now...
Steps to reproduce:

launch node-matter
click on Home app on the iPhone
click "add accessory"
click "more options..." at the top
click on the device "Matter Accessory"
type the setup code 20202021 (hardcoded in Device.ts)
something is happening but failing in the middle

@EHylands : The 2nd time I did the same step, the iphone did not see node-matter
I restarted the iPhone and it worked again after that
You might to try the "restart" magic trick :-)

NOTE: the line It says "This accessory is not certified", click "Add anyway" is an amazing news!!!!!
This means that iOs is allowing home-made Matter devices using the normal Home app!

The magic restart trick did work !!!
node-matter crashing after clicking "Add anyway"
ERROR InteractionServerMessenger Error: Unsupported message type 10

You can check out the branch "add-uint8-16-3264T", you should be able to get a little further...
The problem is now in CASE pairing in the message sigma2. iOs replies "bad parameter value" while Android ChipTool is fine with the exact same node-matter build...
It is the crypto stuff, so not easy to debug... It might take me a couple of days.

Airplane on/off works as well instead of a full reset

Hmmm... the official Matter Lighting test device on my Raspberry Pi doesn't work either with iOs 16.1, it crashes at the exact same step, so the problem might not be node-matter but iOS...
Does anyone have succeeded to pair another official Matter device with an iPhone?
I will try to sync the official Lighting test app to HEAD from project-chip: maybe something has been updated on the protocol but I thought I was already at v1.0.
I know that there was a bug around that code that I reported to Matter that makes project-chip not compatible with Matter official specs but it was not on the code path (it was on session resumption).

Getting further after checking out branch add-uint8-16-3264T !
Are official specifications available for Matter protocol  or are you using Matter code repository as documentation ?
2022-10-2 21:10:51.070 INFO Device<EMAIL_ADDRESS>2022-10-2 21:10:51.087 INFO Device Listening
...
2022-10-2 21:11:50.281 ERROR CaseServer An error occured during the commissioning Error: Received error status: 1 0 2
...

I was using Matter code repository before the specs were released but I am using the specs now.
This part were the crash is was written before the specs were release, but by double-checking it seems mostly correct.
I added bunch of logs in the example Lighting app so I can have access to unencrypted message and private keys, which helps a lot for debugging.

If you get a chance, can you try to build one of the example of Matter code repository and see if you can add it on iOs?
For now, it doesn't work for me. If I have a working device where I can add log, it will be easier to fix the issue.

With Matter example, I can get a bit further in the pairing process.
It fails with "Thread Border Router Required"

Which example did you use and at which revision did you checkout?
If I can reproduce on my side, I will be able to figure out the issue with node-matter...

I checked out Matter master branch a few hours ago.
Where can I get revision number ?
MacBook-Pro standalone % ./chip-lighting-app -v
./chip-lighting-app 1.0

You can type git log at the root of the repository
It should give the commit number.

commit 351876075cd34841a5b7d628df5fb9b42003b5f2 (HEAD -> master, origin/master, origin/HEAD)
Author: Boris Zbarsky<EMAIL_ADDRESS>Date:   Wed Nov 2 18:19:46 2022 -0400

It is still the latest commit :-) checking out the codebase now and I should be able to reproduce what you see...

Pairing worked for me at that commit!

I think I know the problem on your side: you compiled / ran it from your MacBook so it used the BLE library and by default might tried to use Thread afterward.
On my side, I compiled / ran from a virtual box so no BT / Wifi support, this forces to only use the connected network.
 Also, CHIP lighting only works once, after I have to restart the computer for it to work again ... yes, fun...

I am confused, now node-matter crashes at another place:
2022-10-3 17:30:1.809 ERROR InteractionServerMessenger Error: Unsupported message type 10
Yeah, I didn't implemented this one yet... But now it is easy to fix.

Unfortunatly, I still get stuck at the tread router step after closing BT on phone and Macbook.
Recompiling Matter and light-app on barebone BSD server tu further check !
Will let you know.

It works well using the exact recommended version on Ubuntu on virtual box: Ubuntu 22.04 LTS
I don't think you want to take the risk of using another version, big mess to get the exact version of every tool in the build chain

And don't forget to use a virtual disk of 50GB or more. I ran out of space on the disk a couple of time and had to start over... big pain...

Iwill also give a shot to build the lighting app soon, so I join the "Pain group" ;-)

Branch https://github.com/mfucci/node-matter/pull/111 , I added a few missing pieces.
Now it doesn't crash anymore, the commissioning seems to be successful but node-matter doesn't appear in the UI so something is still wrong.
I need to add debug log inside the lighting app to understand what is different. This will be for tomorrow...

Might be more difficult on iOS....
https://www.macrumors.com/2022/11/03/amazon-matter-echo-devices/

So maybe ends in waiting for ios 16.2?

Some update, now that I have a half-working configuration where I can add log, I made a lot of progress but still not there yet:

add supported for message type 10, TimedRequest. Not what this is for or how it works, but returning success works...
after a TimedRequest, the next command is sent inside the same message exchange, breaking the previous. Fixed that, was not too hard
after that, iOs was reading the attributes fabrics to check that the fabric had been configured correctly. This seems seemed simple but was tough to get working. The new value is "fabric-scoped" and should be marked as such which was not documented... and "fabric-scoped" is a new concept that was never used before. I hacked something for that... What node-matter returns is still quite different that was CHIP lighting app returns, but it seems to work...
after that, iOs was reading the Descriptor cluster to check was other endpoints were available on the device. There was a bug on the attribute ids that I fixed
after that, iOs is checking the other endpoint #1, the on/off endpoint. The 2nd thing it is checking is the feature flag which was not implemented. Added that
after that, iOs calls the AdministratorCommissionCluster that was not implemented at all. I added a quick and dirty implementation relying Success but that didn't work. Digging more into the specs, calling this cluster will put back the device into commissioning mode in a special Spake pairing mode (no clues why). Hacked with a hammer the logic to do this.
after that, iOs discovers again the device over MDNS. Some hacked code flow to make this work, but was not too hard.
after that, iOs tries to pair again using Spake. The pairing logic is not that same as the initial pairing so the crypto primitives need to be modified. I hacked something but it didn't work in the 20mn I had left

So for now, I am stuck at 8. Debugging this step should not be  too hard now that I can have the lighting app spitting out all its crypto keys and generated bytestreams. I will continue working on this tonight.
After that, I think iOs will provision another fabric which is not supported at all so will require a lot of code change. Hopefully not. It don't see iOs accessing new clusters past that point so maybe not too much extra work will be required.

Wow great progress
for 3. ok with knowing that "fabric scoped" is important I will add it as comment to all my new clusters for attributes (and such) - because there I saw it several times.

Working!!!!!
I can now add node-matter in Home app!!!
Latest fixes are on "support-ios" branch.
I just piled up hacks to get it working, so it will probably take some time to have iOs supported in "main".
node-matter appears in Home but with the label "No Response" so other things are not functional to be able to operate it.
But CHIP lighting app after pairing is not functional as well...
I will work on fixing that next week.

wow great stuff ...

Ok, I now also used an Ubunutu box with "lighting-app" and iOS 16.1 ... my results is this with: https://github.com/project-chip/connectedhomeip/issues/23565 @mfucci maybe log interesting for you?
I thought maybe a good idea to open issue there ... lets see if iOS 16.1 is faulty or something else

Now master branch is fully compatible with iOs!

WWWOOOWWWW ... Cool,I will verify that today with iPhone and Homepod

Upon attempting to add accessory on iPhone 16.1 using node-matter on a Raspberry PI,  popup indicates that I need a HUB to add it.  Required?

which pairing code do you used? try the QA code ... then still?

@Apollon77 I tried again with QrCode and this time it started to 'pair' but then ran into error:

Copied text would be easier because In fact relevant stuff missing from the log but yes iOS is not working again. Mfucci is already working on it

Reopening this issue: Apple has updated Apple Home app and pairing is not working anymore...
I am on it!

PR #193 should at least restore the pairing functionality ... but the device stayed unresponsive for me ( but not in my home network ... so I need to retest ... maybe solved then already).

Ok, update .. in home network the device is working (including bridge :-))))

Tested on my side and I confirm that iOs is working again with the code in master branch.
Closing this issue


Support for non-public entity types

Sometimes it is not convenient to have a public entity type. Maybe this was discussed before and there is a strong reason for not providing that option. Or I simply do not see an existing straightforward way to accomplish this. But I could not find any discussion on this topic.
Of course, this problem can be solved with custom mapping. However, it's quite a bit of unnecessary work to write a full code of (de)serialization for an entity. Especially, given that BsonMapper does not contain public methods for running the standard (de)serialization pipeline for arbitrary values, only for documents.
What I suggest as a more elegant solution is to provide some way to pass a factory function for creating an instance of non-public type on deserialization. That function could be used instead of instantiation via dynamic compilation.
Possible implementation is to add method RegisterTypeFactory(Func factory) to BsonMapper. Or an overload of RegisterType to make clear these are two alternatives - either full (de)serialization, or standard (de)serialization with custom instantiation.

Hi @baSSiLL, LiteDB support Factory for class intances. If you are using .NET 3.5 version of LiteDB you are using EmitReflectionHandler. This Emit I doesnt not support (as I know) internal classes. You can try ExpressionReflectionHandler as factory. I assume that this factory as not fast as Emit, but more flexible.
You must implement a custom ILitePlatform (take a look on https://github.com/mbdavid/LiteDB/blob/master/LiteDB/Platform/LitePlatformFullDotNet.cs)

Thanks, I'll look into this. I suppose I'll make that closer to my suggestion - by registering factory methods for specific types in my custom implementation of IReflectionHandler.


Feature : owner of private party can launch next round with a button

It will allow player to freely talk and have time to type their vote for the next round

Implemented a skip button instead


How to remove/disable hubot-shipit

I can't reopen this ticket: https://github.com/hubotio/hubot/issues/1397 so, here is a new one.
I've removed hubot-shipit from external-scripts.json
I've run npm uninstall hubot-shipit and made sure that hubot-shipit is no longer listed in either the package.json or package-lock.json file. But, when I run Hubot, I get the following error
ERROR Error loading scripts from npm package - Error: Cannot find module 'hubot-shipit'
Any ideas on why Hubot is still looking for hubot-shipit and/or how I can disable this module?
I've searched the code base for "shipit" and nothing is turning up, so I'm not sure why npm is looking for the hubot-shipit module.

You must also remove the module name from the external-scripts.json file in the project root directory otherwise Hubot will try to activate this module when it initializes.

Gone stale.


Fix the problem that an existing ingress does not work properly

fix #293

After the changes, the ingress configuration looks like this
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
  creationTimestamp: "2023-08-15T02:28:16Z"
  generation: 4
  name: demo-localhost
  namespace: default
  resourceVersion: "87589"
  uid: 3563f9a7-9a94-4891-976b-61e855d7c9dc
spec:
  ingressClassName: nginx
  rules:
  - host: demo.localdev.me
    http:
      paths:
      - backend:
          service:
            name: demo
            port:
              number: 80
        path: /
        pathType: Prefix
      - backend:
          service:
            name: cloudshell-local-cluster-sample
            port:
              number: 7681
        path: /apis/v1alpha1/cloudshell/local-cluster-sample
        pathType: Prefix
status:
  loadBalancer: {}

The original service can still be accessed

cloudshell can be accessed successfully

@Fish-pro thanks.


Replace whisper.info with our implementation

Not sure if it's really useful, but we could replace the whisper.info part to be standalone.
https://github.com/heidelbergcement/whisper-pandas/blob/6fe1b7bd7b2d897eb6064cf3fb0e8fe7bd09aae4/whisper_pandas.py#L21-L23

Done in https://github.com/heidelbergcement/whisper-pandas/commit/d35a1feb9da315afe6bf6060ede536f8a32956f3


Multiple features on file search and download

The application works great and we try to incorporate it in Jupyter notebooks however there are some small things that we would like to see added if possible.

The search function when searching for a file we have to add a %collection%/%.txt / so ibridges knows I am searching for a file now right? Is it possible to have a collection / data variable instead of only path?

Skip if exists, currently it throws an error if a file already exists ... (we know please ignore and skip? or a file size check?) ignore error is a bit overkill as this is not really an error?

The folder does not exists where you want to download the file to... can ibridges please create this? (param mkdir=true?)

This is currently my procedure to retrieve the data
for i, d in enumerate(data):
    irods_path = d['COLL_NAME'] + "/" + d['DATA_NAME']
    local_path = "./" + irods_path
    # Create the folder structure
    os.makedirs(os.path.dirname(local_path), exist_ok=True)
    print("Downloading: " + str(i) + " of " + str(len(data)) + " " + local_path, end="\r")
    if not os.path.exists(local_path):
        download(session, irods_path=irods_path, local_path=local_path)

Hi @jjkoehorst
Thanks for the feedback!

We are currently in the process of completely reworking the search #239. The PR is basically finished, so if you want to have a look and see if that provides what you want that would be great.
You can use overwrite==True. If the checksums are the same, the data won't actually be transferred, but checksums do need to be computed (locally). Is that solution good enough for you?
Hmmm, I/we would need to think about that. I can understand it might be a nice convenience. On the other hand it would introduce one more argument to the download/upload/sync function, where it only saves a single line of code. You can always wrap this functionality in your own function perhaps?

I was curious why it keeps overwriting the file so by adding a ton of prints to the download function I noticed

Conflicting checksums for unlock/home/wur.fdp/stu_hiv-composition-gut/obs_o_samd00665758/sam_samd00665758/metagenomic_amplicon_illumina/asy_drr519722/NGTAX_Silva138.1-picrust_100_DRR519722/provenance.ttl.68bb1fbf513a3703bfcdc03e692a79fc sha2:DS9/8OmoTZoqYgNvinWluzwgio06KRB/xmycWV1zqVk=
That I think you calculate the md5? and irods is calculating the sha2?

MD5 will be taken into account: #248
For more verbosity on uploads, downloads and synchronisations you can use the dry-run option:
Here an example for uploads
from ibridges.path import IrodsPath
from pathlib import Path
from ibridges.interactive import interactive_auth
from ibridges import upload

local_path = Path.home().joinpath("Downloads", "my_books")
irods_path = IrodsPath(session, "demo")

ops = upload(session, local_path, irods_path, dry_run=True, overwrite=True)
ops.print_summary()

You can then either execute all operations with ops.execute(session) or you can execute the single parts.
https://ibridges.readthedocs.io/en/stable/api/full_reference.html#module-ibridges.executor

ad 3. I am a bit hesitant to introduce that to our data transfers. It is convenient if you just want to create the direct folder. However, to make it generic we would have to check if someone wants to add a full collection/folder subtree and that should not happen automatically but done consciously by the programmer.

True, @chStaiger makes sense and its just one line of code extra.
Another topic regarding downloads... We often need to download a few thousand files. In a Jupyter notebook you often start all the steps and then it needs to do checksum compute again right? Is it possible to do a size check only?

In the next release we just opted for the warnings:
overwrite==False, ignore_err=False -> FileExistError
overwrite==True, ignore_err=False -> checksum -> copy
overwrite==False, ignore_err=True -> Skip and warn
overwrite==True, ignore_err=True -> checksum -> copy
Mainly because our current main user group are less experienced users and not informing them in any way they might get the wrong impression of the state of the data.
But we have it on our radar and will see what we can do in later releases.

I understand and agree :) My suggestion was not to change it but to add something to be able to silence it.

I will release the next version without that feature and we will discuss internally whether we want to do a quickfix for that in a bug-fix version or directly work on a more thorough solution #255

WIth that, can we close this issue, or did I overlook something that needs to go into another ticket to pick it up in the development?

I understand and agree :) My suggestion was not to change it but to add something to be able to silence it.

You can use suppress it using the warnings library, see for example:
https://stackoverflow.com/questions/14463277/how-to-disable-python-warnings

@qubixes good point! I will remove the issue.

I think the feature requests have been addressed, so I'm closing this issue. If there is a new feature request that is related to the ones in this issue, just open a new issue (one per feature ideally).


Add CLI to get function status of a specific instance

Motivation
Add CLI support to get status of specific function instance.

@srkukarni  updated the change.

What about server side changes?

Function already has server side api.


A few tweaks to the JetStream code for better observability and throu…

…ghput.

Added custom GC config on the serve side, by defult Python does too much GC as we allocate a lot of objects.
Tweaked log level in orchestrator to WARNING so important messages don't hide in server logs.
Added slow TTFT detection and text logging on both server and client side (benchmark_serving as the client).
Fixed timestamp recording on the server side.
Added prefill based throttling on the client side.
Added concurrent active request throttling on the client side.

Thanks Fenghui for the change! LGTM.


The FoldingTabBar is not displayed when using performSegue

When I perform a performSegue with code, for example in a login when redirecting to the login screen the tabs are not shown, only a black bar comes out; what is this about?

yes you should use delegate

`- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
if ([segue.identifier isEqualToString:@"yourSegueNameHere"]) {
    // Get destination view
    LoginViewControllerName *vc2 = segue.destinationViewController;
}

`

I did not quite understand the example, they could help me with full functionality please, I'm using Swift 3.

You need a navigation controller in there to handle what you're trying to do. Here is some reference on view controller handling in Swift http://www.codingexplorer.com/segue-swift-view-controllers/
Hope that helps

I understand, but am I supposed to go to the next VC?
The function I try to do is a login to a start view, if I enter the Home works correctly; But when I pass from login to home is that the bar is left in black....
:S

duplicate of https://github.com/Yalantis/FoldingTabBar.iOS/issues/76


how to ensure the canvas size and the image inside it is of same size

so, if i want to use the annotation data outside your library, the annotation data would be based upon the canvas created rather than the actual image. So as to ensure that the annotation data be used further, the image size needs to be same as the canvas created. How can i do that?

+1

+1

+1


How  you create the anchor?

Hi,writer !I have some problem on your code about how to create anchors.I read your code but I found that the the return of function get_layer_anchors are
tf.expand_dims(y_on_image,** axis=-1), tf.expand_dims(x_on_image, axis=-1),
tf.constant(list_h_on_image, dtype=tf.float32),
tf.constant(list_w_on_image, dtype=tf.float32),
num_anchors_along_depth,
num_anchors_along_spatial
but the shape of  list_h_on_image  in the first feature layer  is ###  4,while the ### shape of the y_on_image is ### 1440(38*38) how they combine with each other? I cannot find the code.

@muomi you should read more about broadcast in numpy or tensorflow


fix: removed unnecessary renders

If you just look at what github shows you it will look like I've actually added calls to render, and while I have, I have also removed two calls found in ExpandedImageForm.Designer.cs that could cause a single image to be rendered literally dozens of times for a single mouse click.


Create a classification model

Now that our dataset is ready, we are able to train a model. For a baseline, nothing too elaborate is needed. Possible ideas:

Vanilla LSTM
CNN

I have created a LinearModel, but I have to test it more thoroughly:

Check the output of intermediate layers
Check given a deterministic input, the output is correct
(...)


[stable/datadog] update docker images version

What this PR does / why we need it:
Update in stable/datadog the default docker image versions:

cluster-agent version is defaulted to: 1.4.0
agent version is defaulted to: 6 (which correspond to the latest agent 6 release)

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md
[ ] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test

/lgtm

/test pull-charts-e2e

/lgtm


onBeforeRouteLeave not being called on route that uses same component

Reproduction
https://codesandbox.io/s/objective-ptolemy-rlbsjj?file=/src/router.js
Steps to reproduce the bug
Using the repro linked:

Click the link "Lorem Posts"
Click the link "Ipsum Posts".
Click the link "Home" or "About". You will see there's an alert "I'm called" popping out.
Repeat step 1 and step 2. You will see no alert popping out.

Expected behavior
When moving from either "Lorem Posts" or "Ipsum Posts" to any other links, the "I'm called" alert should appear.
Actual behavior
No alert appearing when moving between "Lorem Posts" and "Ipsum Posts".
Additional information
I'm trying to show confirmation popup when leaving route with form. However, I share the same component (let's say FormPage) across different route, such as /posts/create, /posts/edit/:id and /posts/view/:id. Edit page can be accessed from view page, and there is a custom back button in all these page that if clicked, should redirect user to previous page.
I'm using onBeforeRouteLeave hook, to achieve this ,on FormPage component, but noticed that while moving to a whole other page trigger this hook just fine, moving from the edit to view page, which both uses FormPage, such as from the back button action, does not trigger the hook.

This is expected because the route doesn't change, only the path. You need to use onBeforeRouteUpdate() for that.


Fix sqlite3.OperationalError: database is locked on delete

Database delete fails locks on delete, how did this not show up on testing?
 yt-fts delete -c 10
Deleting channel Ben Eater: https://www.youtube.com/channel/UCS0N5baNlQWJCUrhCEo8WlA/videos
Are you sure you want to delete this channel and all its data?
y/n: y
Traceback (most recent call last):
  File "/usr/local/bin/yt-fts", line 8, in <module>
    sys.exit(cli())
             ^^^^^
  File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/yt_fts/yt_fts.py", line 144, in delete
    delete_channel(channel_id)
  File "/usr/local/lib/python3.11/site-packages/yt_fts/db_utils.py", line 171, in delete_channel
    if check_ss_enabled(channel_id):
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/yt_fts/utils.py", line 107, in check_ss_enabled
    cur.execute("""
    ^^^^^^^^^^^^^^^
sqlite3.OperationalError: database is locked

fixed with " Db lock error on delete #121 "


Import 2021 season competitions

What

Import data for additional competitions from 2021 season

Emperor's Cup
ACL
Super Cup
J2, J3

Why

Currently only J1 and Levain Cup data is imported
How

CSV import feature ( #21 ) will be added instead of importing specific data directly


validation on network subnet mask

Steps

Create a deployment with a network subnet mask 32 like the following example.

terraform {
  required_providers {
    grid = {
      source = "threefoldtech/grid"
    }
  }
}

provider "grid" {
    mnemonics = ""
    network = "dev" # or test to use testnet
}

resource "grid_network" "net1" {
    nodes = [1, 7]
    ip_range = "<IP_ADDRESS>/32"
    name = "network"
    description = "newer network"
    add_wg_access = true
}
resource "grid_deployment" "d1" {
  node = 7
  network_name = grid_network.net1.name
  ip_range = lookup(grid_network.net1.nodes_ip_range, 7, "")
  vms {
    name = "vm1"
    flist = "https://hub.grid.tf/tf-official-apps/base:latest.flist"
    cpu = 1
    publicip = true
    planetary = true
    memory = 1024
    entrypoint = "/sbin/zinit init"
    env_vars = {
      "SSH_KEY" = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCa5srzZwh3ulajtY2EZ1SiPY1JNelcaP8O/FZqrnJi6OxAPijl0KzoNrzgemqxhAS/eIglBYbgQuw/Po15MtdMgXmfrtNgrZjQQtLxGFz5KmUbzawPGI7iRkN40LEo0y0hcGLV1G+YiNO+3YU7K5I+gos+04OUJe4HYjcp92nAEviqxa40po2f67KgP5xrZxaOpELZA/hIf1wCzCyTsdvu3k+hw1QlSTIso6WTcUw7LLssvxAs7JZ31kgx+L740xQJWsiVv/go3td0GuETfRSbfjBtOD/wIEHG5UtazOrR+8ukotqQ/ERWuyx1abaEKwro3fLunmjhfgDbnJYy7As1 ahmed@ahmed-Inspiron-3576"
    }
  }
}
output "wg_config" {
    value = grid_network.net1.access_wg_config
}
output "node1_container1_ip" {
    value = grid_deployment.d1.vms[0].ip
}
output "public_ip" {
    value = grid_deployment.d1.vms[0].computedip
}
output "ygg_ip" {
    value = grid_deployment.d1.vms[0].ygg_ip
}

Result
the deployment went well, but couldn't reach the VM

https://github.com/threefoldtech/terraform-provider-grid/pull/128

verified


property emits object for its type instead of inlined typed

What package is the bug related to?
typedoc-plugin-markdown
Describe the issue
The generated markdown contains object instead of the inlined type for properties of a type whose type is based on a typedef.
Repro: https://stackblitz.com/edit/vitejs-vite-xwhbv4ro
Steps to reproduce

Open repro
npm run docs:md
View docs-md/interfaces/Foo.md

Actual Result

Markdown

HTML

Additional Information

The issue does not occur when generating html files (npm run docs:html)
I attempted to isolate the issue without using zod, however I was unsuccessful despite several different ways of trying to achieve.  It does not appear to be a zod problem since the html version emits as expected but apologies for not being able to narrow this down any further.
This seems similar to the object problem in #720

TypeDoc configuration
typedoc: 0.27.3
typedoc-plugin-markdown: 4.3.1
typescript: 5.7.2
Expected behavior
The types for Foo.c and Foo.d should be inlined.

Thank you.
Full inoine object is now represented inside type arguments (as per prop C<EMAIL_ADDRESS>Please note that where associated docs are included (as per prop D) then by default the keyword object is set by default as otherwise it can create quite a lot of noise for large inline objects. However expandObjects=true can be set to always display inline object type regardless if associated docs are included or not.
Hope that makes sense? This is perhaps not very obvious, so will review at some point, but hopefully this behaviour is acceptable for time being.

Thanks for the quick fix @tgreyuk, greatly appreciated!
Understood and makes sense on the decision to use object when associated docs are included.  As you mention, expandObjects does provide ability to expand when needed, only drawback is that it's a global config vs. a type specific config.
Something to consider for future possibly is that I do think there is something to be said for having the default generated output as closely align with the default typedoc output (html format) expect for in areas where it does not make any sense for markdown.
All that said, as of v4.3.2 this is working by design now, thank you again!

I will close this as fixed, but as noted will continue work with aligning with html theme when it makes sense to do so.


Issue-1120 Updating the version of OrientDB

Tested the prerequisites (Acceptance Test) mentioned in https://github.com/strongbox/strongbox/issues/1120

Thanks for your help and congratulations on your first pull request!
@strongbox/core-developers : Would you mind trying it out and confirming whether it works as expected?

Have you tried building strongbox-parent -> strongbox-db -> strongbox ...?

Have you tried building strongbox-parent -> strongbox-db -> strongbox ...?

yes. I did that. No failures or issues observed. I will try to upload the console logs by EOD today (IST)

To be considered for #1130, if it works without side-effects.

@prbobba ,
Would you mind re-checking the following acceptance tests:

[ ] Building the code with mvn clean install -Dintegration.tests still works.
[ ] Running mvn spring-boot:run in the strongbox-web-core still starts up the application correctly.
[ ] Building the code and running the strongbox-distribution from a zip or tar.gz still works.
[ ] The tests in the strongbox-web-integration-tests still run properly.

With your changes against the strongbox:master i'm getting the following compilation error after building the strongbox-parent and strongbox-db projects:
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /java/opensource/carlspring/strongbox-clean/strongbox-client/src/test/java/org/carlspring/strongbox/service/impl/ProxyRepositoryConnectionPoolConfigurationServiceImplIntegrationTest.java:[15,40] package org.springframework.test.context does not exist
[ERROR] /java/opensource/carlspring/strongbox-clean/strongbox-client/src/test/java/org/carlspring/strongbox/service/impl/ProxyRepositoryConnectionPoolConfigurationServiceImplIntegrationTest.java:[16,40] package org.springframework.test.context does not exist
[ERROR] /java/opensource/carlspring/strongbox-clean/strongbox-client/src/test/java/org/carlspring/strongbox/service/impl/ProxyRepositoryConnectionPoolConfigurationServiceImplIntegrationTest.java:[24,2] cannot find symbol
  symbol: class ActiveProfiles
[ERROR] /java/opensource/carlspring/strongbox-clean/strongbox-client/src/test/java/org/carlspring/strongbox/service/impl/ProxyRepositoryConnectionPoolConfigurationServiceImplIntegrationTest.java:[25,2] cannot find symbol
  symbol: class ContextConfiguration
[ERROR] /java/opensource/carlspring/strongbox-clean/strongbox-client/src/test/java/org/carlspring/strongbox/client/ArtifactResolverIntegrationTest.java:[16,40] package org.springframework.test.context does not exist
[ERROR] /java/opensource/carlspring/strongbox-clean/strongbox-client/src/test/java/org/carlspring/strongbox/client/ArtifactResolverIntegrationTest.java:[17,40] package org.springframework.test.context does not exist
[ERROR] /java/opensource/carlspring/strongbox-clean/strongbox-client/src/test/java/org/carlspring/strongbox/client/ArtifactResolverIntegrationTest.java:[24,2] cannot find symbol
  symbol: class ActiveProfiles
[ERROR] /java/opensource/carlspring/strongbox-clean/strongbox-client/src/test/java/org/carlspring/strongbox/client/ArtifactResolverIntegrationTest.java:[25,2] cannot find symbol
  symbol: class ContextConfiguration
[INFO] 8 errors

Closing.


Enable safe public access for Badges

Hey, I just made a Pull Request!
Related to these issues :

https://github.com/backstage/backstage/issues/5039.
https://github.com/backstage/backstage/issues/14659

Related to my previous PR : https://github.com/backstage/backstage/pull/16767
And in response to the PR comment : https://github.com/backstage/backstage/pull/16767#discussion_r1130664140
Context
Today, if backend to backend authentication is enabled, even if the /badges route is not protected by the authMiddleware, trying to load a badge while being unauthenticated generate a HTTP 401 because the badges-backend plugin tries to extract the Authorization token from the request header to perform a call to the catalogApi.
This is fixed through this PR switching the header token extraction to requesting a token to the tokenManager
But as aptly identified by @Rugvip, disabling the authMiddleware  to access the badges externally opens door to potential security issues like enumeration.
In that perspective, I've implemented an obfuscation feature within the badges plugins.
How it works

The change is backward compatible as unless you specify to use the obfuscation mechanism, the previous routes stay available

Note that in the below examples, the authMiddleware is always disabled for the badges endpoint. If it is enable, there is no specific value to add obfuscation above the authentication

Use case 1 : not using the obfuscation mechanism.

Use case 2 : Using the obfuscation mechanism

The two other endpoint to get the badges and the available badges-specs have been updated to only use the hash. That's the exposed endpoints when the API is public

A /obfuscated endpoint have been added protected by it's own authMiddleware that checks user Identity. It's meant to be called by the frontend plugin only. It returns an ID for a specific entity

For the reviewers :

The /obfuscated endpoint works like the following :

The way the hash identifies the right entity is done through a database table that holds the computed hash alongside the needed entity metadata.

| The database table is generated if the cache expire (default 60 min) or if the table is empty
The whole path looks like this

:heavy_check_mark: Checklist

[X] A changeset describing the change and affected packages. (more info)
[X] Added or updated documentation
[X] Tests for new functionality and regression tests for bug fixes
[X] All your commits have a Signed-off-by line in the message. (more info)

@Rbillon59, this is awesome, thanks for providing this amazing and detailed PR description!

@jhaals Asked updates have been done. Please be free to review

Nice to see the database coming along! I think this can be simplified even further by completely removing the need for the custom salt and also scheduling by storing a UUID and entity triplet in the database. The code could be simplified so it's generated once the entity is requested unless it already exists in the database to save additional roundtrips and having to fetch all entities on a schedule.

For the UUID, I'am still thinking we should try to stick to an external resource to generate stable ids instead of something directly tied to the running instance. For that purpose the salt prevents enumeration by adding entropy to the generated obfuscated URL.
About the badge generation, I've though about it as well and the issue I faced is : Given the following algo :
If badge exist : send it back
If badge not exist : generate it then send it back
You cannot generate only the requested badge, as the obfuscated URL cannot be used to craft the original content. So it would force to regenerate the whole catalog and store it in the database for each 404. This could be risky and also expose to a quite easy denial of service attack.

Nice to see the database coming along! I think this can be simplified even further by completely removing the need for the custom salt and also scheduling by storing a UUID and entity triplet in the database. The code could be simplified so it's generated once the entity is requested unless it already exists in the database to save additional roundtrips and having to fetch all entities on a schedule.

For the UUID, I'am still thinking we should try to stick to an external resource to generate stable ids instead of something directly tied to the running instance. For that purpose the salt prevents enumeration by adding entropy to the generated obfuscated URL.

But the UUIDs is stored in the database so there is nothing tied to the running instance and generating an UUID would prevent the enumeration issue that this PR tries to solve.

About the badge generation, I've though about it as well and the issue I faced is : Given the following algo : If badge exist : send it back If badge not exist : generate it then send it back
You cannot generate only the requested badge, as the obfuscated URL cannot be used to craft the original content. So it would force to regenerate the whole catalog and store it in the database for each 404. This could be risky and also expose to a quite easy denial of service attack.

I might be missing something here but here is what I'm thinking.
An internal user call /entity/:namespace/:kind/:name/obfuscated in order to get a badge spec back with the generated link which can be used publicly. When that is called we generate an UUID reference for that specific entity in the badges database. This removes the need to fetch all entities in the catalog on a schedule which is something we want to avoid as it get's expensive for big installations.
Later on when someone externally call the public obfuscated endpoint we would only check if that UUID exist in the database and if not return a 404 meaning there would be no heavy compute except for checking that single reference with the database.

For the UUID, I'am still thinking we should try to stick to an external resource to generate stable ids instead of something directly tied to the running instance. For that purpose the salt prevents enumeration by adding entropy to the generated obfuscated URL.

But the UUIDs is stored in the database so there is nothing tied to the running instance and generating an UUID would prevent the enumeration issue that this PR tries to solve.

Thank you for your explanations ! I think I mistakenly take the database data as ephemeral, or at least susceptible of deletions. That's why I prefered sticking with an external source of truth. Like that a DB failure with lost of data would not occur a badge URL refresh among all the repositories. But I got your point.

I might be missing something here but here is what I'm thinking.
An internal user call /entity/:namespace/:kind/:name/obfuscated in order to get a badge spec back with the generated link which can be used publicly. When that is called we generate an UUID reference for that specific entity in the badges database. This removes the need to fetch all entities in the catalog on a schedule which is something we want to avoid as it get's expensive for big installations.
Later on when someone externally call the public obfuscated endpoint we would only check if that UUID exist in the database and if not return a 404 meaning there would be no heavy compute except for checking that single reference with the database.

Sorry, my bad not understanding your first proposal. Again, I think my mistake is to not consider the database data as trustworthy.

@jhaals I've implemented the uuid feature, replacing the hash mechanism.

@jhaals Sorry, I rebased on master, I had so fix some dependencies, but also the husky pre-commit script. There is some issues with builds. There is also issues with the reviewdog, but for completely other subjects. How to deal with those issues now ? Thanks

I think this is ready to go +1 Nice work!

Thanks ! Your reviews were very relevant too, thank you !


Template overhaul

Overhaul
This mixes a gui overhaul of the template page, a refactor of code related to templates and adds some new features for templates.
Changes
Moved most Template stuff from cMain.cpp to a new file called TemplatePage. Refactored most Template functions to follow.
Renamed box sizer in template page-
Changed labels of Template page control buttons-
Added Tooltips to Template page control buttons.
Added Unicode arrows to Import&Export buttons.
Added add step button to template page.
Added Template iterator transformation.
Added Template direction transformation.
Changed amount transformation to allow both types at the same time.
Added button toggles.

I unfortunately won't have time to test the functionality out for at least a week, but if you have tested it and think it works I will approve it. It first need to really work when it is released. :)

I have tested each part in insolation, and they work for the scenarios i can imagine. The scenarios i can't imagine, who knows ;)
But yes i believe it works.
One thing of note. Since the new rotation system assumes Origo as the pivot point, that means it probably can't be combined with the iteration system.

Seems reasonable that the user has to do those separately. 👍


Unable to externalize context/dynamic require

Feature request
There should be an easy way to make require calls external for a node target. For now the behaviour seems to be inconsistent because require('./someModule') is treated completely different than require('./modules/' + name).
What is the expected behavior?
Making module external should be possible to accomplish purely by webpack configuration, without using webpack-specific code like __non_webpack_require__.
What is motivation or use case for adding/changing the behavior?
I have a scenario where my application (target: 'node') automatically loads external middlewares (not built in by webpack) from certain folder. If middlewares paths were predefined, it's not a problem, I can do
const m1 = require('./middlewares/first/index.js');
const m2 = require('./middlewares/second/index.js');

and in my webpack configuration I can specify:
{
  externals: [
    (context, request, callback) => {
       if (/middlewares/.test(request)) {
          return callback(null, 'commonjs ' + request);
       }
       callback();
    },
  ],
}

and the above require statements will be evaluated during runtime of built app. There's no need for them to be present anywhere in project during build.
However, my case is all about dynamic loading. I'd like to load the modules based on folder contents or based on some list known only in runtime:
for (const name of middlewareNames) {
  middlewares[name] = require('./middlewares/' + name + '/index.js');
}

That way, unfortunately, the path from this require statement never reaches the function specified in externals. Since middlewares folder is not present in project during build, it ends up throwing
ERROR in ./src/server.ts
Module not found: Error: Can't resolve './middlewares' in 'C:\...'

I see no way to just mark this dynamic require call as external. The same thing happens if I try using context:
require.context('./middlewares', false, /index\.js/);

One workaround for this problem is using __non_webpack_require__ for my dynamic middlewares loading mechanism. But this is vendor-locking. If I ever decide to change from webpack to something else, I'd need to replace __non_webpack_require__ with something else. Or, if I want to build-in some middlewares and still be able to load other middlewares dynamically during runtime, it will again require code changes while in fact a simple require in a loop and some configuration in webpack should be enough to accomplish the task.
How should this be implemented in your opinion?
Since webpack does a static code analysis anyway, it might be achieved by webpack-specific comments in code. This way, it doesn't break the original code and won't require any changes if one choose to build app in different way or to run it directly.

It should be possible to explicitly mark require as external:

require(/* webpack-require-external */'./middlewares/' + name + '/index.js');
require(/* webpack-require-external */moduleName);

All require calls not marked as external should be passed to the externals resolver and in this case:

require('./middlewares/' + name + '/index.js');

it should still try to find all possible existing files in project that match the expression (like './middlewares/builtInMiddleware/index.js') and these (if the exist) will be passed to externals resolver, but besides that, a special request like this should be passed too: './middlewares/*/index.js'. If user doesn't explicitly do
return callback(null, 'commonjs ' + request);

the resulting app will behave as usual, throwing module not found error in runtime if you try to import something that's not already built-in. But if you do mark it as commonjs module, resulting app will try to perform standard require call (equivalent of __non_webpack_require__) for all require calls to modules that are not already built-in.
3. It might be useful to also do require like this:
require(/* webpack-require-fallback-external */moduleName);

which in runtime will try to use a built-in module and if module like that is not present, it will perform standard require.
Are you willing to work on this yourself?
I think my knowledge on internal webpack mechanisms is too week for now

Have you tried this? https://github.com/liady/webpack-node-externals
It works like a charm. Using externals is the way to go.

@ooflorent I've explained in the issue that dynamic requires do not reach functions passed to externals at all.

@sokra I think it is solved in webpack@5, am I right?

@aczekajski there is __non_webpack_require__  https://webpack.js.org/api/module-variables/#__non_webpack_require__-webpack-specific that is looks like what you are expect. Feel free to feedback.


Homepage: central text block

Styling:

h2 {
    font-family: Work Sans Light;
    color: rgba(255,255,255,0.7);
    font-size: 1.2rem;
    text-transform: uppercase;
    line-height: 1.5rem;
}

Wording:

   "The future is"

   looking 62% more safe

   "than yesterday"

styling and wording like above


App: Topic Explorer

[x] Create a topic explorer that lists topics alphabetically.
[ ] Topics which belongs to a pinned category can be shown at the top as "Featured" (but the featured topics does not need to be hidden in the alphabetical list below).
[x] TBC: The topic names can perhaps be overlayed over the image tiles (will need to add support for that in the still to be created LImage component), with the image blurred so that it is easy to read the text
[ ] Need to determine the image aspect ratio for the topic tiles. (For video we use the video aspect ratio and for audio we will use square. Perhaps a 4:3 aspect ratio could work for topics?)
[ ] Create navigation buttons for the different experiences (separate task?) Can be sticky at bottom of page for mobile view, and perhaps in top bar for PC view. Topic explorer could be named "Explore" in the menu. Video experience could perhaps be "Watch" and future audio experience "Listen".

Idea for layout of Explore page (up for discussion)

[ ] Create a category Featured that is pinned
[ ] Add a french Translation for that Category (En Vedette)
[ ] Tag some posts with Feature

[ ] Create a category Featured that is pinned
[ ] Add a french Translation for that Category (En Vedette)
[ ] Tag some posts with Feature

[ ] Swap image and text
[ ] Not use the card view for
[ ] Heading is too big and bold
[ ] Button to swicth feels too heavy, too dark
[ ]


Add drop/paste resource for css

Follow up on #190206
This allows pasting or dropping uri lists / files into css files to insert url(...) functions. I've removed the logic from #190206 that was handling pasting of text that looks like a uri

Thanks a lot @mjbvz, looks good.

Looking at the other alternatives in the paste menu, I suggest du go uppercase:  Insert url() Function?

Thanks @mjbvz !


Python Getting started grammar fixes, broken link corrections.

Motivation and Context

Description

Python getting_started lesson 03: There was a grammar error saying "The function will take in input the text to summarize." which I changed to "The function will take the text to be summarized as input."
Python getting_started lesson 05: Corrected inconsistent add_plugin structure for better readability. The links in the Plan Object Model and Sequential Planner sections were broken, so I linked them to the correct page.
Python getting_started lesson 06: Minor fix, corrected grammar from "Let's add also memory to it!" to "Let's also add memory to it!"
PROMPT_TEMPLATE_LANGUAGE.md: The link to the docs repo prompt-template-syntax.md was broken, so I rerouted it to the correct page.
Contribution Checklist

[x] The code builds clean without any errors or warnings
[x] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
[x] All unit tests pass, and I have added new tests where possible
[x] I didn't break anyone :smile:

@MattNic2 please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]

Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree

Hi @MattNic2, we appreciate the contribution here. Are you still interested in seeing this through? We've done some re-arranging with our learn site docs. You'd need to pull in latest main to your branch, resolve the conflict, and figure out which link to point to.
Please feel free to re-open this PR if you want to get the changes included. Thanks.


Check Ember.Test.waiters in wait helper

Hypothetically - if I created a PR to add the Ember.Test.waiters check in:
https://github.com/emberjs/ember.js/blob/master/packages/ember-testing/lib/helpers.js#L197
To the wait helper:
https://github.com/switchfly/ember-test-helpers/blob/master/lib/ember-test-helpers/wait.js#L30
Might that be accepted - or is there a reason why it doesn't include that check?

Seems like a good idea. I'm happy to help provide guidance if needed...

Thanks - I'll prepare a PR

Released in v0.5.21 - thanks


ONBS Freezes with songs with two notes in the same tick

Describe the bug
Open Noteblock Studio freezes after trying to load a Song with Two Notes in the same tick.
To Reproduce
Steps to reproduce the behavior:

Open the provided file in the latest release of ONBS.
ONBS Freezes and needs to be closed forcibly.

Expected behavior
Throw Loading Error or Crash.
Additional context
The File was generated using pynbs with the following code:
import pynbs

file = pynbs.new_file()

file.notes.extend([
    pynbs.Note(tick=0, key=33, layer=0, instrument=0),
    pynbs.Note(tick=0, key=34, layer=0, instrument=0),
    pynbs.Note(tick=1, key=35, layer=0, instrument=0)
])

file.save("sample.nbs")

sample.zip

Well, NBS isn't supposed to know how to handle two note blocks in the same spot, so rather, this is a problem with pynbs generating an invalid file.
Though you probably don't want two note blocks in the same spot, so I assume you forgot to change the layer of the second note to 1?

Sincere thanks for the rapid response. That's true my fault, I will close the issue!
Sorry for the trouble.


Please consider adding monerocardgames.com

What's the name of your business?
Monero Card Games
What's the URL of the website?
https://monerocardgames.com
Write a brief description of your business/service (max 50 characters)
Provably fair Monero card games.
Enter the URL where a Monero mention can be found
https://monerocardgames.com
How do you accept Monero? (choose only one option)

[ ] Monero integrations (github.com/monero-integrations)
[ ] Globee
[x] Native wallet
[ ] Other payment gateaway (Coinpayments, Morphtoken, etc. Please specify)

How would you categorize your business? (choose only one option)

[ ] Exchange
[ ] Block Explorer
[ ] Payment Gateway
[ ] Library and Helper
[ ] Tool
[ ] Service
[ ] Goods
[x] Entertainment

Comment

Looks ok.


Refactor: Refactor CHF App and SBI

Description

Bump GO version to 1.21
Adjust CI version
Refactor SBI

server, consumer, processor

I would remove any unused code only ensuring everything is working as expected.

I would remove any unused code only ensuring everything is working as expected.

I tested the functionality with UERANSIM and saw the charging record from webconsole, it works fine for now.


[Bug]  Delayed message delivery receive duplicate messages when unload topic

Search before asking

[X] I searched in the issues and found nothing similar.

Version
2.7.5 / 2.8.4 /master
Minimal reproduce step

Run the code for 20 minutes

public static void main(String[] args) {
        String url = "pulsar://<IP_ADDRESS>:6650";
        String t = "persistent://components/test/test_deliver";
        new Thread(() -> {
            try {
                PulsarClient client = PulsarClient.builder()
                    .serviceUrl(url)
                    .ioThreads(1)
                    .listenerThreads(2)
                    .build();
                Producer<String> producerA = client.newProducer(Schema.STRING)
                    .topic(t)
                    .producerName("test")
                    .create();
                Random random = new Random();
                while (true) {
                    String message = String.valueOf(System.currentTimeMillis());
                    producerA.newMessage(Schema.STRING).value(message).deliverAfter(random.nextInt(30), TimeUnit.MINUTES).send();
                    Thread.sleep(10L);
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
        }).start();
        Set<String> stringSet = new ConcurrentHashSet<>();
        try {
            PulsarClient client = PulsarClient.builder()
                .serviceUrl(url)
                .ioThreads(1)
                .listenerThreads(2)
                .build();
            Consumer consumer = client.newConsumer(Schema.STRING)
                .topic(t)
                .subscriptionName("frozen")
                .subscriptionType(SubscriptionType.Shared)
                .subscribe();
            while (true) {
                Message<String> message = consumer.receive();
                if (stringSet.contains(message.getValue())) {
                    log.info("duplicate messages thread={} message={}", Thread.currentThread().getName(), message.getValue());
                } else {
                    stringSet.add(message.getValue());
                }
                consumer.acknowledge(message);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

After 20 minutes, execute unload cmd:

bin/pulsar-admin topics unload persistent://components/test/test_deliver

See consumer log, duplicate messages

What did you expect to see?
no duplicate messages
What did you see instead?
duplicate messages
Anything else?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

cc @coderzc since you're working on delay message heavily recently, can you help with this issue to see if it's a usage issue?

I maybe understand what caused the issue, try set isAckReceiptEnabled(true) to true when create consumer.
            Consumer consumer = client.newConsumer(Schema.STRING)
                .topic(t)
                .subscriptionName("frozen")
                // enable ack receipt
                .isAckReceiptEnabled(true)
                .subscriptionType(SubscriptionType.Shared)
                .subscribe();

Then, try you test again.

@dao-jun  My client is pulsar-client-go. Is there similar consumer option like isAckReceiptEnabled. Maybe AckWithResponse? Could you explain the reason for the duplicate consume?

@dao-jun I tried but it did not solve the promblem.

func test() {
	clientOps := pulsar.ClientOptions{
		URL: "pulsar://localhost:6650",
	}
	client, err := pulsar.NewClient(clientOps)
	if err != nil {
		return
	}
	defer client.Close()
	consumerOps := pulsar.ConsumerOptions{
		Topic:            "persistent://public/default/my-topic",
		SubscriptionName: "test",
		AckWithResponse:  true,
	}
	consumer, err := client.Subscribe(consumerOps)
	if err != nil {
		return
	}
	defer consumer.Close()
	for {
		msg, err := consumer.Receive(context.Background())
		if err != nil {
			return
		}
		// Do your business here
		consumer.Ack(msg)
	}
}

@SennoYuki

The problem is Pulsar optimized consumer.ack.
When you call consumer.ack, the ack request will not send to the broker immediately, but cached in the client. When the cached ack requests reached the threshold, send them to the broker in batch.
If you unload the topic when the ack requests didn't send to the broker, you will receive duplicated messages.

enable AckWithResponse, the consumer will wait until broker received the ack

@dao-jun I think it's only part reson for small batch duplicated messages. But in my scene the duplicated messages is huge. It's not possible causing the 20M and more message duplicated consume. And in topics stats the non ack messages shows smaller than 1k

Few unacked message also have a chance to cause many duplicated messages, you can take a try @SennoYuki

ok @dao-jun , I will retry tomorrow. Hope a good result.

Mark:
The root cause is the conflicts between cursor.readEntries and cursor.asyncReplayEntries.

@dao-jun I retry serveral times . It dose not work

I guess your topic have non-delayed delivery messages and delay delivery messages, if your topic only have delayed delivery messages, it will be work. As I marked before, it's the conflicts between cursor.readEntries and cursor.asyncReplayEntries, one for delayed messages, another fro non-delayed delivery messages. We don't have a suitable solution yet to solve the problem. @SennoYuki

@dao-jun I confirm it dose not contain non-delayed delivery message. In my program any message has more than 5 minute delay time. Sad, I choose Pulsar because it supports delayed messages. Any plan for this bug?


Add Terry to emeritus

@TerryHowe  Thank you for your dedication and hard work as a maintainer. I am not reluctant to see you stepped down from the ORAS maintainer seats because you plays a critical role in the ORAS community in the past year. Your efforts have been invaluable to the project.


Tracking issue: Performance benchmarks and profiling

We would definitely benefit from some benchmarking and profiling of the current code, to find bottlenecks and choke points. This issue will keep track of them.
Here are some suggestions of things that could give us a good insight:

Flame graphs: A simple, yet powerful profiling that can help us find places that are bottlenecking our code.
Code benchmarks: The first step was made in #259, including more benchmarks would be very useful
Memory profiling: Look for how we use memory and CPU cache. I would divide this into two categories:

heap allocation
cache friendless

Figure out how well our current I/O code behaves, and if we can reduce how much we syscall/wait for data
(anything else??)

I've captured two flamegraphs on 6a286a6. Both are captured during block download, but one is while downloading mainly empty blocks, and the other after 350k, where it gets more full.
Both flamegraphs are with the default assumevalid, and I'm using --connect with another node running on my own home network.
It's funny how in the first one, our logger is a big resource taker. I guess we should go back to only logging every 10k blocks or something.