Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Hack: Matter wifi ap with serialnumber #2

Merged
merged 1 commit into from
Jun 22, 2023
Merged

Hack: Matter wifi ap with serialnumber #2

merged 1 commit into from
Jun 22, 2023

Conversation

dbahrdt
Copy link
Collaborator

@dbahrdt dbahrdt commented Jun 19, 2023 •
edited
Loading

This PR changes the default SSID of the wifi AP to PREFIX-.
Enable SOFT_AP in Matter configuration to use this.

Depends on:

@dbahrdt
Hack: Use serial number to generate wifi api
39fe904 
This commit changes the SSID of the Wifi AP to PREFIX-<SERIALNUMBER> in
accordance with Eltako wifi ap. This change is likely not compatible
with Matter. However we do not support commissioning using Wifi anyway.
Yet we need wifi to be available to configure the device by other means.
In the future we need to find a way to either enable the ap without
using Matter functions or provide proper commissioning over wifi.
The latter is likely the better way.
@dbahrdt dbahrdt force-pushed the feature/matter-wifiap-with-serialnumber branch from e7e5d46 to 39fe904 Compare June 21, 2023 08:23
@dbahrdt dbahrdt requested review from ItRainsSmiles and PatrickHof84 and removed request for Caldwell1988 June 21, 2023 11:54
@dbahrdt dbahrdt merged commit 2d2746f into eltako/release/1.0 Jun 22, 2023
@dbahrdt dbahrdt deleted the feature/matter-wifiap-with-serialnumber branch June 22, 2023 09:47
dbahrdt pushed a commit that referenced this pull request Sep 27, 2023
@bzbarsky-apple
Fix ThreadSanitizer failure in controller factory. (project-chip#26824)
9f1a470 
* Fix ThreadSanitizer failure in controller factory.

The failure looks like this:

  WARNING: ThreadSanitizer: race on NSMutableArray (pid=11619)
    Read-only access of NSMutableArray at 0x7b0c0005f5b0 by thread T3:
      #0 -[__NSArrayM countByEnumeratingWithState:objects:count:] <null>:2 (CoreFoundation:x86_64+0x4a338)
      #1 -[MTRDeviceControllerFactory(InternalMethods) operationalInstanceAdded:] MTRDeviceControllerFactory.mm:855 (Matter:x86_64+0x1fd2a)
      #2 MTROperationalBrowser::OnBrowse(_DNSServiceRef_t*, unsigned int, unsigned int, int, char const*, char const*, char const*, void*) MTROperationalBrowser.mm:100 (Matter:x86_64+0x20ee63c)
      #3 handle_browse_response <null>:2 (libsystem_dnssd.dylib:x86_64+0x3733)
      #4 _dispatch_client_callout <null>:2 (libdispatch.dylib:x86_64+0x3316)

    Previous modifying access of NSMutableArray at 0x7b0c0005f5b0 by main thread:
      #0 -[__NSArrayM addObject:] <null>:2 (CoreFoundation:x86_64+0x2457a)
      #1 -[MTRDeviceControllerFactory createController] MTRDeviceControllerFactory.mm:719 (Matter:x86_64+0x1cee3)
      #2 -[MTRDeviceControllerFactory createControllerOnExistingFabric:error:] MTRDeviceControllerFactory.mm:534 (Matter:x86_64+0x19792)

The basic problem is that we are in the middle of adding an object to
_controllers on the API consumer thread when on the Matter thread we get our
browse notification.

The changes here don't aim to lock around all access to _controllers, but just
to make sure that our mutations of it can't race with the access on the Matter
thread.  More coarse locking would need to be done very carefully, given the
amount of dispath_sync to the Matter thread we have going on.

* Address review comments.
dbahrdt pushed a commit that referenced this pull request Sep 27, 2023
@bzbarsky-apple
Fix thread race in MTRXPCListenerSampleTests. (project-chip#26862)
07a7ea5 
WARNING: ThreadSanitizer: race on NSMutableDictionary (pid=72050)
      Modifying access of NSMutableDictionary at 0x7b0800149020 by thread T7:
        #0 -[__NSDictionaryM setObject:forKey:] <null>:2 (CoreFoundation:x86_64+0x40d4e)
        #1 -[MTRXPCListenerSample listener:shouldAcceptNewConnection:] MTRXPCListenerSampleTests.m:116 (MatterTests:x86_64+0x48437b)
        #2 service_connection_handler_make_connection <null>:2 (Foundation:x86_64+0xdea93)

      Previous modifying access of NSMutableDictionary at 0x7b0800149020 by thread T4:
        #0 -[__NSDictionaryM removeObjectForKey:] <null>:2 (CoreFoundation:x86_64+0x6cd6d)
        #1 __59-[MTRXPCListenerSample listener:shouldAcceptNewConnection:]_block_invoke MTRXPCListenerSampleTests.m:119 (MatterTests:x86_64+0x484630)
Caldwell1988 pushed a commit that referenced this pull request Nov 6, 2023
@cecille @restyled-commits
Fix constexpr complaints on test vectors (project-chip#29462)
f5f2e51 
* Fix constexpr complaints on test vectors

* Attempt #2 - separate PAAs used in non-test

* Things work better when we add all the files

* Restyled by whitespace

* Restyled by clang-format

* add tokenizer

* add the gni

* add pigweed import

* Change filenames

* Restyled by clang-format

---------

Co-authored-by: Restyled.io <[email protected]>
Caldwell1988 pushed a commit that referenced this pull request Nov 6, 2023
@bzbarsky-apple
Fix intermittent LSan failures running "darwin-framework-tool tests l…
b846dbe 
…ist". (project-chip#29666)

The typical failure there looks like this:

==29620==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 88 byte(s) in 1 object(s) allocated from:
    #0 0x106396e12 in calloc+0xa2 (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x51e12)
    #1 0x7ff800dc9789 in map_images_nolock+0x24b (libobjc.A.dylib:x86_64h+0x1789)
    #2 0x7ff800dc94db in map_images+0x42 (libobjc.A.dylib:x86_64h+0x14db)
    #3 0x113d721fa in invocation function for block in dyld4::RuntimeState::setObjCNotifiers(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*))+0x112 (dyld:x86_64+0xf1fa)
    #4 0x113d6d6c8 in dyld4::RuntimeState::withLoadersReadLock(void () block_pointer)+0x28 (dyld:x86_64+0xa6c8)
    #5 0x113d720e1 in dyld4::RuntimeState::setObjCNotifiers(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*))+0x51 (dyld:x86_64+0xf0e1)
    #6 0x113d85d44 in dyld4::APIs::_dyld_objc_notify_register(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*))+0x4e (dyld:x86_64+0x22d44)
    #7 0x7ff800dc9343 in _objc_init+0x4fe (libobjc.A.dylib:x86_64h+0x1343)
    #8 0x7ff800d83992 in _os_object_init+0xc (libdispatch.dylib:x86_64+0x2992)
    #9 0x7ff800d911b7 in libdispatch_init+0x136 (libdispatch.dylib:x86_64+0x101b7)
    #10 0x7ff80bd34894 in libSystem_initializer+0xed (libSystem.B.dylib:x86_64+0x1894)
    project-chip#11 0x113d77e4e in invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const+0xb5 (dyld:x86_64+0x14e4e)
    project-chip#12 0x113d9eaac in invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const+0xf1 (dyld:x86_64+0x3baac)
    project-chip#13 0x113d95e25 in invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const+0x22c (dyld:x86_64+0x32e25)
    project-chip#14 0x113d64db2 in dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const+0x80 (dyld:x86_64+0x1db2)
    project-chip#15 0x113d95bb6 in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const+0xb2 (dyld:x86_64+0x32bb6)
    project-chip#16 0x113d9e603 in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const+0x1d1 (dyld:x86_64+0x3b603)
    project-chip#17 0x113d77d81 in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const+0x8f (dyld:x86_64+0x14d81)
    project-chip#18 0x113d7e659 in dyld4::PrebuiltLoader::runInitializers(dyld4::RuntimeState&) const+0x1d (dyld:x86_64+0x1b659)
    project-chip#19 0x113d8b76d in dyld4::APIs::runAllInitializersForMain()+0x25 (dyld:x86_64+0x2876d)
    project-chip#20 0x113d6938c in dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*)+0xd72 (dyld:x86_64+0x638c)
    project-chip#21 0x113d684e3 in start+0x183 (dyld:x86_64+0x54e3)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ItRainsSmiles ItRainsSmiles ItRainsSmiles approved these changes

@danielschick danielschick Awaiting requested review from danielschick

@PatrickHof84 PatrickHof84 Awaiting requested review from PatrickHof84

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@dbahrdt @ItRainsSmiles