Question: [HELP] [BUG] Can't discover BACnet devices - Version 3.4.4?

Hi @ttrading,

This issue was closed, if you discover some issue - please open the new one. Also, please provide your BACnet connector configuration.

Due to typical issues with BACnet - please check that you set host for application - your IP in the same network, as device and port - 47808, mask usually - 24.

For device - please try to set * instead of host and * instead of port, this will enable global broadcast for device search. Aslo I should mention that you need to run the gateway and emulator on different devices, because emulator may reserver port 47808 and the gateway won't be able to use it for application.

[HELP] [BUG] Can't discover BACnet devices - Version 3.4.4
**Describe the issue**
Create description about your issue, and your actions to solve it.

 Have set up the BACnet connector from my ThingsBoard cloud instance, but it's not discovering the devices on the network. The devices are both at 192.168.11.35:47808, with first device being the gateway that connects to the plug via wireless mesh, with both devices being discoverable on YABE from the desktop machine. The command I used to set up the container is below, minus the host and accessToken

 `docker run -d -it --network=host --expose 8082 -e host= -e port=1883 -e accessToken= -p 60000-61000:60000-61000 -v "C:\Users\Office Demos\Documents\tb-gateway\config:/thingsboard_gateway/config" -v "C:\Users\Office Demos\Documents\tb-gateway\extensions:/thingsboard_gateway/extensions" -v "C:\Users\Office Demos\Documents\tb-gateway\logs:/thingsboard_gateway/logs" --name tb-gateway --restart always thingsboard/tb-gateway`

image

**Configuration** (Attach your configuration file)
**Notate: Remove Access token from file if you want to attach a tb_gateway.yaml**

{
 "thingsboard": {
 "host": "thingsboard.cloud",
 "port": 1883,
 "remoteShell": false,
 "remoteConfiguration": true,
 "statistics": {
 "enable": true,
 "statsSendPeriodInSeconds": 3600,
 "configuration": null,
 "commands": []
 },
 "deviceFiltering": {
 "enable": false,
 "filterFile": "list.json"
 },
 "maxPayloadSizeBytes": 1024,
 "minPackSendDelayMS": 200,
 "minPackSizeToSend": 500,
 "checkConnectorsConfigurationInSeconds": 60,
 "handleDeviceRenaming": true,
 "security": {
 "accessToken": ""
 },
 "qos": 1,
 "checkingDeviceActivity": {
 "checkDeviceInactivity": false,
 "inactivityTimeoutSeconds": 200,
 "inactivityCheckPeriodSeconds": 500
 }
 },
 "storage": {
 "type": "memory",
 "read_records_count": 100,
 "max_records_count": 100000,
 "data_folder_path": "./data/",
 "max_file_count": 10,
 "max_read_records_count": 10,
 "max_records_per_file": 10000,
 "data_file_path": "./data/data.db",
 "messages_ttl_check_in_hours": 1,
 "messages_ttl_in_days": 7
 },
 "grpc": {
 "enabled": false,
 "serverPort": 9595,
 "keepaliveTimeMs": 10000,
 "keepaliveTimeoutMs": 5000,
 "keepalivePermitWithoutCalls": true,
 "maxPingsWithoutData": 0,
 "minTimeBetweenPingsMs": 10000,
 "minPingIntervalWithoutDataMs": 5000,
 "keepAliveTimeMs": 10000,
 "keepAliveTimeoutMs": 5000
 },
 "connectors": [
 {
 "type": "bacnet",
 "name": "BACnet",
 "configuration": "bacnet.json"
 }
 ]
}

**Connector name (If you need help with some connector/converter):**
BACnet Connector

{
 "name": "BACnet",
 "logLevel": "DEBUG",
 "general": {
 "objectName": "TB_gateway",
 "address": "0.0.0.0:47808",
 "objectIdentifier": 599,
 "maxApduLengthAccepted": 1476,
 "segmentationSupported": "segmentedBoth",
 "vendorIdentifier": 15
 },
 "devices": [
 {
 "deviceName": "S_1AC0_DemoPlug",
 "deviceType": "default",
 "address": "192.168.11.35:47808",
 "pollPeriod": 10000,
 "timeseries": [
 {
 "key": "InsRealPower1",
 "type": "int",
 "objectId": "analogInput:2",
 "propertyId": "InsRealPower1"
 }
 ]
 },
 {
 "deviceName": "HoneywellGateway_MainOffice",
 "deviceType": "default",
 "address": "192.168.11.35:47808",
 "pollPeriod": 10000
 }
 ]
}

**Error traceback (If it was raised):**

**Versions (please complete the following information):**
 - OS: Windows 10 - Docker Desktop v 24.0.7
 - Thingsboard IoT Gateway version 3.4.4
 - Python version - 3.11.7

Hi @TomAllen95 @kamisettychandan,

Thank you for interest in ThingsBoard IoT gateway. At the moment we are investigating the connection ability to YABE simulator, unfortunately for now, with no luck, but we will write you after finding the reason why it cannot connect.

@imbeacon

Please find my docker logs, then you can understand the problem.

Day.4.Docker_Logs.txt

Please find Config files,
bacnet.json.txt
tb-gateway.txt

Kindly check and update

Hello,

any news on this topic?
I have the same issue.
TB-Gateway is sending "Unconfirmed-REQ who-Is"-Messages to 'Room Control Simulator'.
But nothing more happens.
grafik
I opended another case a few weeks ago, because I can`t access data from other bacnet-devices as well.
( URL
I can access all the data witch Yabe (of room simulator and bacnet end-device).

Is anyone here using bacnet-connector of tb-gateway successfully?

Kind regards.

Hi all,

Please try to use the latest version of the gateway( URL we have completely remastered BACnet connector, migrate to bacpypes3 as a base for it, instead of bacpypes. Also, we have tested the connector with YABE, it was able to read and write data.
I close this issue, because it relates to previous implementation of the connector, but please feel free to open new issues in case of noticing some misbehaving.

[HELP] Can't access data with Bacnet
Hello,

I cant`t access data of a heating system with bacnet using thingsboard-gateway.
When I use Yabe, I can accesss all the things I want to know.
But when requesting data with thingsboard-gateway, I don`t get any answer of the heating system to my request.
grafik

e.g. the request for this value shold look like this I think:
{
 "general": {
 "objectName": "tb-gateway",
 "address": "0.0.0.0:47808",
 "objectIdentifier": 599,
 "maxApduLengthAccepted": 1476,
 "segmentationSupported": "segmentedBoth",
 "vendorIdentifier": 15
 },
 "devices": [
 {
 "deviceName": "BACnet Device ${objectName}",
 "deviceType": "default",
 "address": "IPADDR:47808",
 "pollPeriod": 10000,
 "attributes": [
 {
 "key": "Außentemperatur Kessel 1",
 "type": "double",
 "objectId": "analogInput:239",
 "propertyId": "presentValue"
 }
 ]
 }
 ],
 "logLevel": "DEBUG",
 "name": "Bacnet",
 "enableRemoteLogging": true,
 "id": "ac5e542d-623b-432a-9a96-04fe82655e34"
}

Debug-Logs of thingsboard-gateway:

b-gateway | 2024-09-04 11:50:37 - |INFO| - [tb_gateway_remote_configurator.py] - tb_gateway_remote_configurator - _process_config_request - 204 - Configuration update request received.
tb-gateway | 2024-09-04 11:50:37 - |DEBUG| - [tb_gateway_remote_configurator.py] - tb_gateway_remote_configurator - _process_config_request - 205 - Got config update request: {'active_connectors': ['Bacnet']}
tb-gateway | 2024-09-04 11:50:37 - |DEBUG| - [tb_gateway_remote_configurator.py] - tb_gateway_remote_configurator - _handle_active_connectors_update - 404 - Processing active connectors configuration update...
tb-gateway | 2024-09-04 11:50:37 - |INFO| - [tb_gateway_remote_configurator.py] - tb_gateway_remote_configurator - _process_config_request - 204 - Configuration update request received.
tb-gateway | 2024-09-04 11:50:37 - |DEBUG| - [tb_gateway_remote_configurator.py] - tb_gateway_remote_configurator - _process_config_request - 205 - Got config update request: {'Bacnet': {'mode': 'basic', 'name': 'Bacnet', 'type': 'bacnet', 'enableRemoteLogging': True, 'logLevel': 'DEBUG', 'sendDataOnlyOnChange': False, 'configuration': 'bacnet.json', 'configurationJson': {'general': {'objectName': 'tb-gateway', 'address': '0.0.0.0:47808', 'objectIdentifier': 599, 'maxApduLengthAccepted': 1476, 'segmentationSupported': 'segmentedBoth', 'vendorIdentifier': 15}, 'devices': [{'deviceName': 'BACnet Device ${objectName}', 'deviceType': 'default', 'address': 'IP-ADDR:47808', 'pollPeriod': 10000, 'attributes': [{'key': 'Außentemperatur Kessel 1', 'type': 'double', 'objectId': 'analogInput:239', 'propertyId': 'presentValue'}]}], 'logLevel': 'DEBUG', 'name': 'Bacnet', 'enableRemoteLogging': True, 'id': 'ac5e542d-623b-432a-9a96-04fe82655e34'}, 'ts': 1725450637146, 'key': 'auto', 'basicConfig': {'general': {'objectName': 'tb-gateway', 'address': '0.0.0.0:47808', 'objectIdentifier': 599, 'maxApduLengthAccepted': 1476, 'segmentationSupported': 'segmentedBoth', 'vendorIdentifier': 15}, 'devices': [{'deviceName': 'BACnet Device ${objectName}', 'deviceType': 'default', 'address': 'IP-ADDR:47808', 'pollPeriod': 10000, 'attributes': [{'key': 'Außentemperatur Kessel 1', 'type': 'double', 'objectId': 'analogInput:239', 'propertyId': 'presentValue'}]}], 'logLevel': 'DEBUG', 'name': 'Bacnet', 'enableRemoteLogging': True, 'id': 'ac5e542d-623b-432a-9a96-04fe82655e34'}}}
tb-gateway | 2024-09-04 11:50:37 - |DEBUG| - [tb_gateway_remote_configurator.py] - tb_gateway_remote_configurator - _handle_connector_configuration_update - 449 - Processing connectors configuration update...
tb-gateway | 2024-09-04 11:50:37 - |DEBUG| - [tb_gateway_remote_configurator.py] - tb_gateway_remote_configurator - create_configuration_file_backup - 757 - Backup file created for configuration file bacnet.json in /thingsboard_gateway/config/backup/bacnet.backup.1725450637.json
tb-gateway | 2024-09-04 11:50:37 - |DEBUG| - [bacnet_connector.py] - bacnet_connector - scan_network - 226 - WhoIsRequest has been sent.
tb-gateway | 2024-09-04 11:50:37 - |DEBUG| - [bacnet_connector.py] - bacnet_connector - run - 80 - WhoIsRequest has been sent.
tb-gateway | 2024-09-04 11:50:37 - |DEBUG| - [bacnet_connector.py] - bacnet_connector - scan_network - 226 - WhoIsRequest has been sent.
tb-gateway | 2024-09-04 11:50:37 - |INFO| - [tb_gateway_remote_configurator.py] - tb_gateway_remote_configurator - _process_config_request - 204 - Configuration update request received.
tb-gateway | 2024-09-04 11:50:37 - |DEBUG| - [tb_gateway_remote_configurator.py] - tb_gateway_remote_configurator - _process_config_request - 205 - Got config update request: {'Bacnet': {'mode': 'basic', 'name': 'Bacnet', 'type': 'bacnet', 'enableRemoteLogging': True, 'logLevel': 'DEBUG', 'sendDataOnlyOnChange': False, 'configuration': 'bacnet.json', 'configurationJson': {'general': {'objectName': 'tb-gateway', 'address': '0.0.0.0:47808', 'objectIdentifier': 599, 'maxApduLengthAccepted': 1476, 'segmentationSupported': 'segmentedBoth', 'vendorIdentifier': 15}, 'devices': [{'deviceName': 'BACnet Device ${objectName}', 'deviceType': 'default', 'address': 'IP-ADDR:47808', 'pollPeriod': 10000, 'attributes': [{'key': 'Außentemperatur Kessel 1', 'type': 'double', 'objectId': 'analogInput:239', 'propertyId': 'presentValue'}]}], 'logLevel': 'DEBUG', 'name': 'Bacnet', 'enableRemoteLogging': True, 'id': 'ac5e542d-623b-432a-9a96-04fe82655e34'}, 'ts': 1725450637146, 'key': 'auto', 'basicConfig': {'general': {'objectName': 'tb-gateway', 'address': '0.0.0.0:47808', 'objectIdentifier': 599, 'maxApduLengthAccepted': 1476, 'segmentationSupported': 'segmentedBoth', 'vendorIdentifier': 15}, 'devices': [{'deviceName': 'BACnet Device ${objectName}', 'deviceType': 'default', 'address': 'IP-ADDR:47808', 'pollPeriod': 10000, 'attributes': [{'key': 'Außentemperatur Kessel 1', 'type': 'double', 'objectId': 'analogInput:239', 'propertyId': 'presentValue'}]}], 'logLevel': 'DEBUG', 'name': 'Bacnet', 'enableRemoteLogging': True, 'id': 'ac5e542d-623b-432a-9a96-04fe82655e34'}}}

tcpdump:

13:57:32.811805 IP iotgw.bacnet > IPADDR.bacnet: UDP, length 8
13:57:32.814702 IP iotgw.bacnet > IPADDR.bacnet: UDP, length 8

Can someone please help me to solve this problem.?
Sorry, I´m not really a bacnet-specialist.

**Versions (please complete the following information):**
 - OS: Rocky Linux 9.4
 - Thingsboard IoT Gateway version 3.5.1 (Docker)
 - Python version 3.9

Try changing this IP address

{
"general": {
"objectName": "tb-gateway",
"address": "**0.0.0.0**:47808",

To be the IP address of the network interface of your TBGW.

Harv

Hello,

thank you for your message.
Still there is no answer of the Bacnet-Device.
Looks like something is wrong with the request itself. In Wireshark I can see the request sent to bacnet-device, but nothing is sent back:
grafik
Some flags look differnet in yabe-request:
grafik

You could try URL to find all the objects. If you don't get your device, your problem might be related to URL

Ok thank you. I just installed bacpypes on my machine and downloaded ReadObjectList.py.
Now the following arguments are required: device_id, device_addr
How, or where can i set this arguments?
device_addr should look like "192.0.0.1:47808" for example?
and what's the device_id?

Thank you jurkov.
With bacpypes I can access all the data. And sorry for my stupid questions, but I`m not a bacnet-specialist :)
But my Bacnet-Device is only responding to "Confirmed-REQ"-messages:
python samples/ReadObjectList.py --ini BACpypes.ini 2XXXXX5 10.XXX.XXXX.1
grafik

When I send "Unconfirmed-REQ who-Is" (as thingsboard-gateway does), I get no answer:
grafik

So I need to make thingsboard to send Confirmed-REQ-messages to the bacnet-device?
How can I do this?
How to specify the device-ID for bacnet-device in thingsboard?

You may have to create a feature request or create the feature by yourself. It is possible to create a custom uplink and downlink converter. See URL

I added my BacNET devices based on URL line 12 and line 14.

Hi @mgruenberger21 and everyone!
We are pleased to inform you that we added a new Async BACnet connector that used bacpypes3 (via PR #1607).
The old BACnet connector is now deprecated and can only be enabled manually.
Please, run the latest version of the gateway via the master branch and let us know about the results.

Hi all,

New implementation of connector was tested with YABE, please try it, for now I close this issue, feel free to open a new one if you discover some misbehaviour with new connector implementation (In gateway 3.6.2+).


Question: Scheduler - Scheme Mode - Thermostat Auto?

When setting a climate entity to hvac mode auto, there shouldn't be a temperature applied.
See here for the definition in HA:

In contrast to:

I follow the definitions from HA, so I'd say that your problem is caused by the homematic integration.

If you want to do so anyway, see here for instructions for a workaround.

Scheduler - Scheme Mode - Thermostat Auto
### Card Version

Latest release

### Bug description

I just discovered the "Make Scheme" button, which is absolutely fantastic for thermostat scheduling.

First of all, THANKS for making this feature. Its amazing. I sent you a "few cups of coffee"

Second of all-

You cannot set a temp when using auto mode.

You can only set temp when using heat or cool. However, many mini splits have auto mode.

This functionality does exist within home assistant (and works via the climate card), however, the make scheme card cannot seem to handle this.

Also, this may or may not be a duplicate of URL

Thanks a lot for the coffees! It's a good motivation to keep improving things 👍

As for your issue, it has been addressed multiple times. See URL for my response.

Hey, You deserve far more for the work you have done on home assistant.

Between this, and alarmo, those are two extremely solid integrations.

Thanks for a response/solution!

Set temperature in "Auto Mode" not possible
### Checklist

- [X] I checked for similar existing requests (both open and closed) before posting.
- [X] My request is generic, other users may benefit from it too.
- [X] I will participate in further discussion about this feature and can test it (if requested) once it's done.

### Proposal

The Homematic IP app allows to set temperature in Auto Mode to a desired level. In scheduler this option is not exposed (see screenshot).
image

One must use Heating Mode to set a desired temperature which results in constant heating even if environment temp is already high enough. I'm not sure if this option is exposed via API but it would make settings more easy for me.

### Additional info

Maybe it's possible to make that temp slider available in automatic mode like here in Heating Mode:
image

I'm unsure if the Rest API docs on URL expose anything useful. At least I wasn't able to find anything suitable.


Question: ` ` eagerly makes selections?

URL says a few things about up and down:

I don't understand what it means by "if the popup is available" though. Does that mean if the popup listbox is showing? Does it have something to do with the combobox being editable? Is it about the autocomplete suggestion rather than the actual listbox? I'm going to assume it means what the example does:

The example opens the listbox popup when pressing up or down, and it doesn't change the option at all. I'm a little hesitant to do this since it doesn't seem to be the same as what ` ` does on most platforms, but if that's whats best for users then I guess we ought to go for it. Based on the resolution here, it sounds like we already have consensus to just follow these aria authoring practices.

I also just noticed that there is no recommendation for right or left arrow keys in the aria authoring practices... maybe those should cycle the selected option without opening the listbox like Scott mentioned in his last comment?

` ` eagerly makes selections
I believe the selection should be made when the option is chosen, not while it's just being perused:
1. would prevent the width jank as shown in the video
2. would prevent the `oninput` event from firing for each keyboard navigation
3. would align it's behavior to that of a mouse

 see video

Kapture 2023-05-02 at 12 21 28

codepen for the above video

@scottaohara do you know what the arrow key behavior should be while the listbox is open? I think that we discussed arrow key behavior while the listbox is closed but not while its open here: URL

iirc, windows works as the prototype shows but no other OS does? I've written JS to disable it so all browsers work the same when perusing select menu options from keyboard. Like on this site, if `change` fired while just navigating the options, it'd change the url and the user would lose their place and be surprised about the change. a screenreader doesnt have the issue, they've got the virtual cursor iirc.

if someone invokes the combobox's listbox popup, then the change event should only fire when a purposeful selection/closure of the listbox has been made. Windows does change the current option shown in the combobox trigger when cycling through focused options, but the change doesn't occur until the user purposefully makes the change. On macOS, chosen option in the trigger doesn't change until the purposeful selectin has been made. IMO this is the better option.

Some points of clarity though, regardless of what choice is made, some 'jankiness' would still occur if the triggering element adjusted in size based on the current value. IMO that looks broken and maybe selectmenu should behave more like the select element here, and have its min-width based on the length of its longest option - allowing people to overwrite this if they see fit, but avoiding some of this awkward resizing behavior by default.

Re: the commentary of how a screen reader would not have the 'change' issue - that's not really true, as this component would generally pop someone into forms mode - which is the expected way to interact with such a control. using virtual pc cursor would not be how someone would normally interact with the contents of the listbox popup, and is actually not even possible to be interacted with in this way with the native select element.

Final FYI, the UX of the select element on this site's is rather broken on Windows, as I can hear this is an unnamed combobox, and i can use up/down arrow keys to change the selection without opening the popup - but because the activation behavior has been suppressed, while i can hear myself changing the selected option, nothing happens. i have to then hit enter to attempt to select, but this then opens the popup instead, and now i have to re-activate the item i was already attempting to activate. a popup of a list of links would have been more expected here is all.

Arrow key up/down on closed
Another ` ` behavior to discuss: what should happen when the control's listbox is closed, and a user arrow keys up/down on the control's button?

Per my testing of ` ` in Chromium and Gecko on Windows, up/down arrow keys advance backwards/forwards through the list of options without opening the listbox.

However looking at the example at URL up/down arrow open the listbox in addition to moving to the next previous option.

The guidance in URL doesn't state that up/down arrow should open the listbox.

So I'm not clear on whether the best practice is to open the listbox or not when up/down arrow is pressed. Thoughts?

(Thanks @mfreed7 for pointing this out).

I'm glad you opened this @dandclark, as I was reading through #386 and noticed this hadn't been mentioned yet.

The APG isn't going to be what can be looked at here for the definitive behavior since the `select` behaves differently depending on the platform, and the APG pattern takes a bit of both, though leaning a bit more towards macOS behavior. On macOS, the listbox always popsup when using the up or down arrow keys. Firefox on macOS allows for left and right arrows to cycle through the select's options when in the collapsed state. Safari and Chromium don't seem to behave that way, though.

On Windows, the expectation is that up , down , left and right will cycle through the select element's options without opening the listbox (firefox, chrome, edge). To open the listbox with arrow keys, someone would also need to use the alt key, along with up or down to get the listbox to popup.

Per the discussion the other day about #429, these differences in the listbox popping up or not matter a bit less since the `change` event will fire the same either way.

I'd imagine that preference for behavior may be contingent on people's familiarity with their primary OS.

I tested out the behavior on various platforms and browsers:

- Up and Left choose the previous option, Down and Right choose the next option. The listbox is not opened.
 - Windows Chrome
 - Windows Firefox
 - Linux Chrome
 - Linux Firefox
- The listbox is opened. The selected option is focused but not moved forwards/backwards. Left and Right do nothing.
 - MacOS Chrome
 - MacOS Safari
 - MacOS Firefox

As scott mentioned, the behavior is platform specific and not browser specific, and users may expect it to act the way the existing select element does on their OS.

As I mentioned in my last comment, the ARIA practices seem to suggest doing the MacOS behavior but with an added funny behavior where pressing down opens the listbox and selects the last option.

My proposed resolution is to do the same thing that the existing select element does and change the behavior based on the OS because that is most likely to be what the user expects, but I am open to suggestions.

We resolved to make up, down, left, and right open the listbox without changing the selected option.

This issue got mirrored to I18N's repo due to the `i18n-tracker` label and I dug around to find the reason for the tag in the IRC log above:

Just to confirm, arrow keys can signal either logical or physical movement, depending on context. Physical movement means "left is left and right is right (etc.)" regardless of text directionality or writing mode. Logical movement means that "left is towards the start (in an LTR context) vs. right is towards the start (in an RTL context)". Physical vs. logical movement depends on the operation in question.

List navigation should generally be logical rather than physical, with up being towards the start and down being towards the end. Left is "towards start" for LTR (`dir=ltr`) and `vertical-lr` modes and "towards end" for RTL (`dir=rtl`) and `vertical-rl` modes (with right mirroring the behavior).

Since you resolved to open the select (and not navigate), is there an equivalent issue somewhere about navigation? I don't see a reason here to reopen this issue.

since i could make the call, just commenting to clarify that while I had mentioned that people may have preferences, that for this topic that wasn't meant to indicate that I wouldn't also agree that cross-browser/platform consistency.

i actually think this is a good change.

however, because I"m me, i also wanted to respond to:

looking to design systems to mimic how they've implemented custom components like this would often mean a bunch of behaviors from the native equivalent were dropped. e.g., was left/right selection not implemented because of a purposeful choice, or because it wasn't ever thought about since the requirements were written by someone unfamiliar with the variations. Or, was it deemed too complex to implement? That often happens with custom select-only comboboxes in regards to the type ahead functionality. Most instances i come across don't allow for the quick jump to an option by pressing the first few characters of that option's label. For instance, neither Fluent UI or Salesforce comboboxes allow for this if using the select-only combobox. They also don't allow someone to click on their custom labels to move focus to the associated combobox element. That's not a dig on these, or anyone who worked on them. it's not "required" that they do these things. But they are missing features from what the current select element provide (or from what other custom made components may or may not provide).

So, very long way of saying "yes, let's look at what other design systems are doing. BUT ALSO, let's look at what they didn't do compared to what they were trying to recreate. What did they leave out, and if something hit the cutting room floor, why?"

Totally agree! I just wanted to make sure we weren't limiting our research to native select menus. Really, I think everyone in this week's meeting seemed to agree that the right way to pick the "right" behavior was to consider what's best for users, and do that. As I said at the end of the meeting, I'm quite sure this issue isn't closed, it's just "closed for now". Please add your thoughts on what's best and we'll keep discussing.


Question: vL3 DNS doesn't work in an interdomain context?

@glazychev-art I feel we might need to verify it.

@NikitaSkrynnik Could you please compare behaviour with NSM v1.5.0 (with coredns) and current main version?

vL3 DNS doesn't work in an interdomain context
## Expected Behavior

After deploying the interdomain vL3 example, the vL3 DNS feature should work as described in its associated example.

Specifically, after modifying the `NSM_DNS_TEMPLATES` to avoid using the `{{ .NetworkService }}` property (which contains the illegal character `@` in the case of an interdomain vL3 service), the vL3 NSE should respond to DNS queries with the vL3 IP of the pod about which the query is.

For instance, in the context of the interdomain vL3 example example and after modifying the `NSM_DNS_TEMPLATES` to `{{ index .Labels \"podName\" }}.my-interdomain-vl3-network` for both vL3 NSEs, the NSEs should respond to DNS queries about the `alpine.my-interdomain-vl3-network` with the IP address of the `alpine` pod connected to the `my-interdomain-vl3-network` vL3 network. Since two `alpine` pods are deployed in this example (one in each cluster), whether the NSE should return the vL3 IP of the local alpine pod, the remote one, or both, remains to be defined.

## Current Behavior

In the context described above, neither the alpine pods nor NSE pods are able to resolve the `alpine.my-interdomain-vl3-network` domain name.

## Failure Information (for bugs)

Running `nslookup alpine.my-interdomain-vl3-network.` in either one alpine pod or one vL3 NSE pod results in the `SERVFAIL` error.

## Steps to Reproduce

1. Deploy the interdomain vL3 example while modifying the NSE deployment to use the `{{ index .Labels \"podName\" }}.my-interdomain-vl3-network` value for the `NSM_DNS_TEMPLATES` environment variable
2. Run `apt update && apt install dnsutils && nslookup alpine.my-interdomain-vl3-network. 127.0.0.1` in the NSE pod
3. Observe that the DNS query is failing
4. Check the pod's logs for errors

## Context

The interdomain vL3 example example was deployed on 3 VMs, each running a local `kind` cluster. The nodes of each kind cluster have InternalIPs in different ranges, and multicluster communication between nodes is possible using their InternalIPs. The nodes however do not have ExternalIPs.

MetalLB is also deployed in each cluster to provide ExternalIPs to k8s services. These IPs are routable between the three VMs.

I used Kind 0.17.0.

## Failure Logs

When a DNS query about the `alpine` pod is sent to the vL3 NSE, the following error appears in the pod's logs:

Jan 26 12:10:22.802 [TRAC] [id:55094] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Jan 26 12:10:22.803 [TRAC] [id:55094] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Jan 26 12:10:22.803 [TRAC] [id:55094] [type:dnsServer] (3) ⎆ sdk/pkg/tools/dnsutils/norecursion/norecursionDNSHandler.ServeDNS()
Jan 26 12:10:22.803 [TRAC] [id:55094] [type:dnsServer] (4) ⎆ sdk/pkg/tools/dnsutils/memory/memoryHandler.ServeDNS()
Jan 26 12:10:22.803 [TRAC] [id:55094] [type:dnsServer] (5) ⎆ sdk/pkg/tools/dnsutils/fanout/fanoutHandler.ServeDNS()
Jan 26 12:10:22.859 [TRAC] [id:55094] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Jan 26 12:10:22.859 [TRAC] [id:55094] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Jan 26 12:10:22.859 [ERRO] [id:55094] [noloopDNSHandler:ServeDNS] [type:dnsServer] (2.1) loop is not allowed: query: ;; opcode: QUERY, status: NOERROR, id: 55094; ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0; ; ;; QUESTION SECTION:; ;alpine.my-interdomain-vl3-network. IN A; ;

The complete logs of the vL3 NSE pod are available here.

Hi @fr-Pursuit ,

Could you please recheck your problem with `{{ index .Labels \"podName\" }}.my-interdomain-vl3-network.`(added dot at the end)?

Hi,

With the added dot at the end of the template, the DNS resolution partially works.
if I have a pod named `yelb-ui` connected to the vL3 network `nslookup yelb-ui.my-interdomain-vl3-network` fails after initially returning the expected IP:

# nslookup yelb-ui.my-interdomain-vl3-network. && echo success
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: yelb-ui.my-interdomain-vl3-network
Address: 172.16.0.3
** server can't find yelb-ui.my-interdomain-vl3-network: SERVFAIL

The same error also appears in the logs of the vL3 NSE that is in the same cluster as the `yelb-ui` pod:

Feb 6 23:18:25.908 [TRAC] [id:29292] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Feb 6 23:18:25.908 [TRAC] [id:29292] [type:dnsServer] (1.1) message-request={"Id":29292,"Response":false,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":true,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"yelb-ui.my-interdomain-vl3-network.my-interdomain-vl3-network.","Qtype":28,"Qclass":1}],"Answer":null,"Ns":null,"Extra":null}
Feb 6 23:18:25.908 [DEBU] [id:29292] [type:dnsServer] (1.2) passed clientURLs: [{udp 172.16.1.1 false }]
Feb 6 23:18:25.908 [DEBU] [id:29292] [type:dnsServer] (1.3) passed SearchDomains: []
Feb 6 23:18:25.908 [TRAC] [id:29292] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Feb 6 23:18:25.908 [TRAC] [id:29292] [type:dnsServer] (3) ⎆ sdk/pkg/tools/dnsutils/norecursion/norecursionDNSHandler.ServeDNS()
Feb 6 23:18:25.908 [TRAC] [id:29292] [type:dnsServer] (3.1) message-request-diff=[{"type":"update","path":["MsgHdr","RecursionDesired"],"from":true,"to":false}]
Feb 6 23:18:25.908 [TRAC] [id:29292] [type:dnsServer] (4) ⎆ sdk/pkg/tools/dnsutils/memory/memoryHandler.ServeDNS()
Feb 6 23:18:25.908 [TRAC] [id:29292] [type:dnsServer] (5) ⎆ sdk/pkg/tools/dnsutils/fanout/fanoutHandler.ServeDNS()
Feb 6 23:18:25.911 [TRAC] [id:29292] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Feb 6 23:18:25.911 [TRAC] [id:29292] [type:dnsServer] (1.1) message-request={"Id":29292,"Response":false,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"yelb-ui.my-interdomain-vl3-network.my-interdomain-vl3-network.","Qtype":28,"Qclass":1}],"Answer":null,"Ns":null,"Extra":null}
Feb 6 23:18:25.911 [DEBU] [id:29292] [type:dnsServer] (1.2) passed clientURLs: [{udp 172.16.1.1 false }]
Feb 6 23:18:25.911 [DEBU] [id:29292] [type:dnsServer] (1.3) passed SearchDomains: []
Feb 6 23:18:25.911 [TRAC] [id:29292] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Feb 6 23:18:25.911 [ERRO] [id:29292] [noloopDNSHandler:ServeDNS] [type:dnsServer] (2.1) loop is not allowed: query: ;; opcode: QUERY, status: NOERROR, id: 29292; ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0; ; ;; QUESTION SECTION:; ;yelb-ui.my-interdomain-vl3-network.my-interdomain-vl3-network. IN AAAA; ;
Feb 6 23:18:25.911 [TRAC] [id:29292] [type:dnsServer] (2.2) message-response={"Id":29292,"Response":true,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":2,"Question":[{"Name":"yelb-ui.my-interdomain-vl3-network.my-interdomain-vl3-network.","Qtype":28,"Qclass":1}],"Answer":[],"Ns":[],"Extra":[]}
Feb 6 23:18:25.913 [TRAC] [id:29292] [type:dnsServer] (5.1) message-response={"Id":29292,"Response":true,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":2,"Question":[{"Name":"yelb-ui.my-interdomain-vl3-network.my-interdomain-vl3-network.","Qtype":28,"Qclass":1}],"Answer":[],"Ns":[],"Extra":[]}

In practice, this error seems to considerably increase the time it takes for a program to perform a DNS resolution in the `my-interdomain-vl3-network` zone. For example, every time I use the `ping yelb-ui.my-interdomain-vl3-network` command, I have to wait a significant while before the actual pings get exchanged (whereas if I use the IP, the pings are exchanged almost immediately).

PS: I changed the template to use a custom `domain` label instead of the default `podName` label to generate the domain name

Actually, the slow `ping` initialization seems to be caused by slow, failing reverse DNS queries: the command temporarily freezes _after_ the IP associated with the domain is shown, but _before_ the first response appears.

In the meantime, the following appears in the remote NSE's logs:

Feb 7 12:06:14.957 [TRAC] [id:26676] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Feb 7 12:06:14.957 [TRAC] [id:26676] [type:dnsServer] (1.1) message-request={"Id":26676,"Response":false,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"3.0.16.172.in-addr.arpa.","Qtype":12,"Qclass":1}],"Answer":null,"Ns":null,"Extra":null}
Feb 7 12:06:14.958 [DEBU] [id:26676] [type:dnsServer] (1.2) passed clientURLs: [{udp 172.16.0.1 false }]
Feb 7 12:06:14.958 [DEBU] [id:26676] [type:dnsServer] (1.3) passed SearchDomains: []
Feb 7 12:06:14.958 [TRAC] [id:26676] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Feb 7 12:06:14.958 [ERRO] [id:26676] [noloopDNSHandler:ServeDNS] [type:dnsServer] (2.1) loop is not allowed: query: ;; opcode: QUERY, status: NOERROR, id: 26676; ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0; ; ;; QUESTION SECTION:; ;3.0.16.172.in-addr.arpa. IN PTR; ;
Feb 7 12:06:14.958 [TRAC] [id:26676] [type:dnsServer] (2.2) message-response={"Id":26676,"Response":true,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":2,"Question":[{"Name":"3.0.16.172.in-addr.arpa.","Qtype":12,"Qclass":1}],"Answer":[],"Ns":[],"Extra":[]}
Feb 7 12:06:15.011 [TRAC] [id:26676] [type:dnsServer] (5.1) message-response={"Id":26676,"Response":true,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":2,"Question":[{"Name":"3.0.16.172.in-addr.arpa.","Qtype":12,"Qclass":1}],"Answer":[],"Ns":[],"Extra":[]}

The same error appears several times in the logs, as the server seems to handle one PTR request per entry in the pod's DNS search path.

I've also noticed major slowdowns in the yelb app, but these don't seem to be caused by NSM: in order for the app to work regardless of how it is deployed, I added the `my-interdomain-vl3-network` domain in the pod's DNS search path. But since it was added at the end of the search path, the pod has to wait for several failing DNS queries to finish before sending the right query.

@fr-Pursuit
`nslookup` makes both ipv4 and ipv6 requests by default.

So, we can check:
`nslookup -debug yelb-ui.my-interdomain-vl3-network.`
or
`nslookup -type=a -debug yelb-ui.my-interdomain-vl3-network.`

For ping, force ipv4:
`ping yelb-ui.my-interdomain-vl3-network. -4`

@glazychev-art Indeed! The `nslookup` failure came from an AAAA request. Here's the output of the command you sent:

# nslookup -debug yelb-ui.my-interdomain-vl3-network.
Server: 127.0.0.1
Address: 127.0.0.1#53

------------
 QUESTIONS:
 yelb-ui.my-interdomain-vl3-network, type = A, class = IN
 ANSWERS:
 -> yelb-ui.my-interdomain-vl3-network
 internet address = 172.16.0.3
 ttl = 283
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
Name: yelb-ui.my-interdomain-vl3-network
Address: 172.16.0.3
------------
 QUESTIONS:
 yelb-ui.my-interdomain-vl3-network, type = AAAA, class = IN
 ANSWERS:
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
** server can't find yelb-ui.my-interdomain-vl3-network: SERVFAIL

I already tried to force IPv4 on ping though, which didn't change anything. I don't find this surprising though, since from what I saw the freeze came from reverse DNS queries.

I didn't see how `nslookup` could directly tell how long each request took, but using the `time` command, I got this:

root@yelb-appserver-55688766-pm8rf:/# time nslookup -debug yelb-ui.my-interdomain-vl3-network.
Server: 127.0.0.1
Address: 127.0.0.1#53

------------
 QUESTIONS:
 yelb-ui.my-interdomain-vl3-network, type = A, class = IN
 ANSWERS:
 -> yelb-ui.my-interdomain-vl3-network
 internet address = 172.16.0.3
 ttl = 3511
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
Name: yelb-ui.my-interdomain-vl3-network
Address: 172.16.0.3
------------
 QUESTIONS:
 yelb-ui.my-interdomain-vl3-network, type = AAAA, class = IN
 ANSWERS:
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
** server can't find yelb-ui.my-interdomain-vl3-network: SERVFAIL

real 0m0.905s
user 0m0.014s
sys 0m0.000s

Each request took more or less the same time, so I'd say around 400/500ms per request.

As for the `PTR` requests, they come from the `ping` problem itself. From what I can see, `ping` performs a reverse DNS query when you use it with a domain name instead of an IP:

% ping -4 google.com -c 4
PING (216.58.213.78) 56(84) bytes of data.
64 bytes from lhr25s01-in-f14.1e100.net (216.58.213.78): icmp_seq=1 ttl=110 time=4.92 ms
64 bytes from lhr25s01-in-f14.1e100.net (216.58.213.78): icmp_seq=2 ttl=110 time=4.91 ms
64 bytes from par21s18-in-f14.1e100.net (216.58.213.78): icmp_seq=3 ttl=110 time=4.98 ms
64 bytes from lhr25s01-in-f78.1e100.net (216.58.213.78): icmp_seq=4 ttl=110 time=5.00 ms

--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.909/4.950/5.000/0.038 ms

% ping -4 216.58.213.78 -c 4
PING 216.58.213.78 (216.58.213.78) 56(84) bytes of data.
64 bytes from 216.58.213.78: icmp_seq=1 ttl=110 time=4.86 ms
64 bytes from 216.58.213.78: icmp_seq=2 ttl=110 time=4.87 ms
64 bytes from 216.58.213.78: icmp_seq=3 ttl=110 time=4.96 ms
64 bytes from 216.58.213.78: icmp_seq=4 ttl=110 time=4.92 ms

--- 216.58.213.78 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.857/4.902/4.963/0.041 ms

Could you check please `time nslookup -debug -type=a yelb-ui.my-interdomain-vl3-network.` ?

Got it, thanks. Apparently we also need to process PTR requests.

Here's what I get when I only query `A` records:

# time nslookup -debug -type=a yelb-ui.my-interdomain-vl3-network.
Server: 127.0.0.1
Address: 127.0.0.1#53

------------
 QUESTIONS:
 yelb-ui.my-interdomain-vl3-network, type = A, class = IN
 ANSWERS:
 -> yelb-ui.my-interdomain-vl3-network
 internet address = 172.16.0.3
 ttl = 2402
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
Name: yelb-ui.my-interdomain-vl3-network
Address: 172.16.0.3

real 0m0.380s
user 0m0.008s
sys 0m0.008s

@fr-Pursuit
In fact, the cache should work. Here are the logs, where we see that the response from the first request was cached, and the second one simply takes the result from this cache (dnsCacheHandler):

Feb 8 05:54:55.385 [TRAC] [id:40104] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/checkmsg/checkMsgHandler.ServeDNS()
Feb 8 05:54:55.385 [TRAC] [id:40104] [type:dnsServer] (1.1) message-request={"Id":40104,"Response":false,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":true,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":true,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"alpine.my-interdomain-vl3-network.my.cluster3.","Qtype":1,"Qclass":1}],"Answer":null,"Ns":null,"Extra":null}
Feb 8 05:54:55.385 [TRAC] [id:40104] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Feb 8 05:54:55.385 [DEBU] [id:40104] [type:dnsServer] (2.1) passed clientURLs: [{udp 172.16.1.1 false } {udp 10.96.0.10 false }]
Feb 8 05:54:55.385 [DEBU] [id:40104] [type:dnsServer] (2.2) passed SearchDomains: [ns-floating-vl3-basic.svc.cluster.local svc.cluster.local cluster.local]
Feb 8 05:54:55.385 [TRAC] [id:40104] [type:dnsServer] (3) ⎆ sdk/pkg/tools/dnsutils/searches/searchDomainsHandler.ServeDNS()
Feb 8 05:54:55.385 [TRAC] [id:40104] [type:dnsServer] (4) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Feb 8 05:54:55.385 [TRAC] [id:40104] [type:dnsServer] (5) ⎆ sdk/pkg/tools/dnsutils/cache/dnsCacheHandler.ServeDNS()
Feb 8 05:54:55.385 [TRAC] [id:40104] [type:dnsServer] (6) ⎆ sdk/pkg/tools/dnsutils/fanout/fanoutHandler.ServeDNS()
Feb 8 05:54:55.386 [TRAC] [id:40104] [type:dnsServer] (6.1) message-response={"Id":40104,"Response":true,"Opcode":0,"Authoritative":true,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"alpine.my-interdomain-vl3-network.my.cluster3.","Qtype":1,"Qclass":1}],"Answer":[{"Hdr":{"Name":"alpine.my-interdomain-vl3-network.my.cluster3.","Rrtype":1,"Class":1,"Ttl":3600,"Rdlength":4},"A":"172.16.1.2"}],"Ns":[],"Extra":[]}

Feb 8 05:54:59.368 [TRAC] [id:23717] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/checkmsg/checkMsgHandler.ServeDNS()
Feb 8 05:54:59.368 [TRAC] [id:23717] [type:dnsServer] (1.1) message-request={"Id":23717,"Response":false,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":true,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":true,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"alpine.my-interdomain-vl3-network.my.cluster3.","Qtype":1,"Qclass":1}],"Answer":null,"Ns":null,"Extra":null}
Feb 8 05:54:59.368 [TRAC] [id:23717] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Feb 8 05:54:59.368 [DEBU] [id:23717] [type:dnsServer] (2.1) passed clientURLs: [{udp 172.16.1.1 false } {udp 10.96.0.10 false }]
Feb 8 05:54:59.368 [DEBU] [id:23717] [type:dnsServer] (2.2) passed SearchDomains: [ns-floating-vl3-basic.svc.cluster.local svc.cluster.local cluster.local]
Feb 8 05:54:59.369 [TRAC] [id:23717] [type:dnsServer] (3) ⎆ sdk/pkg/tools/dnsutils/searches/searchDomainsHandler.ServeDNS()
Feb 8 05:54:59.369 [TRAC] [id:23717] [type:dnsServer] (4) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Feb 8 05:54:59.369 [TRAC] [id:23717] [type:dnsServer] (5) ⎆ sdk/pkg/tools/dnsutils/cache/dnsCacheHandler.ServeDNS()
Feb 8 05:54:59.369 [TRAC] [id:23717] [type:dnsServer] (5.1) message-response={"Id":23717,"Response":true,"Opcode":0,"Authoritative":true,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"alpine.my-interdomain-vl3-network.my.cluster3.","Qtype":1,"Qclass":1}],"Answer":[{"Hdr":{"Name":"alpine.my-interdomain-vl3-network.my.cluster3.","Rrtype":1,"Class":1,"Ttl":3597,"Rdlength":4},"A":"172.16.1.2"}],"Ns":[],"Extra":[]}

Could you also check the latest main branch of deployments-k8s? We slightly increased the query speed, at least `nslookup type=a` should work faster.

Weirdly, I get similar logs in the `cmd-nsc` container, but logs from the NSE indicate it stills handles the requests, even though they should be cache in the local `cmd-nsc` container.

I ran `dig yelb-appserver.my-interdomain-vl3-network` on the `yelb-appserver` container (so only the local NSE should get involved).

I'll retry with the latest main branch (I'm currently using v1.7.0), and I'll get back to you.

Great! With the latest branch, the DNS resolutions are quite faster:

# time nslookup -debug -type=a yelb-ui.my-interdomain-vl3-network.
Server: 127.0.0.1
Address: 127.0.0.1#53

------------
 QUESTIONS:
 yelb-ui.my-interdomain-vl3-network, type = A, class = IN
 ANSWERS:
 -> yelb-ui.my-interdomain-vl3-network
 internet address = 172.16.1.4
 ttl = 3408
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
Name: yelb-ui.my-interdomain-vl3-network
Address: 172.16.1.4

real 0m0.021s
user 0m0.009s
sys 0m0.009s

However, I have another issue... I deployed `yelb` using the same manifest as before, and for some reason `yelb-db.my-interdomain-vl3-network` cannot be resolved. The `yelb-db` pod was successfully connected to the vL3 network (with the address `172.16.0.2`), but the NSE fails when I try to resolve its associated name:

# nslookup -debug -type=a yelb-db.my-interdomain-vl3-network.
Server: 127.0.0.1
Address: 127.0.0.1#53

------------
 QUESTIONS:
 yelb-db.my-interdomain-vl3-network, type = A, class = IN
 ANSWERS:
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
** server can't find yelb-db.my-interdomain-vl3-network: SERVFAIL

The following error appears in the NSE's logs:

Feb 8 12:03:31.680 [TRAC] [id:40970] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Feb 8 12:03:31.681 [TRAC] [id:40970] [type:dnsServer] (1.1) message-request={"Id":40970,"Response":false,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":true,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"yelb-db.my-interdomain-vl3-network.","Qtype":1,"Qclass":1}],"Answer":null,"Ns":null,"Extra":null}
Feb 8 12:03:31.681 [DEBU] [id:40970] [type:dnsServer] (1.2) passed clientURLs: []
Feb 8 12:03:31.681 [DEBU] [id:40970] [type:dnsServer] (1.3) passed SearchDomains: []
Feb 8 12:03:31.681 [TRAC] [id:40970] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Feb 8 12:03:31.681 [TRAC] [id:40970] [type:dnsServer] (3) ⎆ sdk/pkg/tools/dnsutils/norecursion/norecursionDNSHandler.ServeDNS()
Feb 8 12:03:31.682 [TRAC] [id:40970] [type:dnsServer] (3.1) message-request-diff=[{"type":"update","path":["MsgHdr","RecursionDesired"],"from":true,"to":false}]
Feb 8 12:03:31.682 [TRAC] [id:40970] [type:dnsServer] (4) ⎆ sdk/pkg/tools/dnsutils/memory/memoryHandler.ServeDNS()
Feb 8 12:03:31.682 [TRAC] [id:40970] [type:dnsServer] (5) ⎆ sdk/pkg/tools/dnsutils/fanout/fanoutHandler.ServeDNS()
Feb 8 12:03:31.682 [ERRO] [id:40970] [fanoutHandler:ServeDNS] [type:dnsServer] (5.1) no urls to fanout
Feb 8 12:03:31.682 [TRAC] [id:40970] [type:dnsServer] (5.2) message-response={"Id":40970,"Response":true,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":2,"Question":[{"Name":"yelb-db.my-interdomain-vl3-network.","Qtype":1,"Qclass":1}],"Answer":[],"Ns":[],"Extra":[]}

All the other names can be resolved fine: only `yelb-db` has a problem.

Any idea would could have gone wrong?

Is `yelb-db` another client as `yelb-ui` ?

Could you upload the full NSE log to which it is connected?

`yelb-db` is indeed another client. The logs of the `nsc-cmd-init` container contained errors about a timeout being exceeded.

I'm currently redeploying my clusters. It's probably better to restart with a clean setup, just to be sure my previous tinkering didn't affect anything.

It appears something was wrong with my setup. After a clean reinstall, everything works fine.

However, the resolution speedup only applies when I used the absolute DNS name:

#time nslookup -debug -type=a yelb-db.my-interdomain-vl3-network.
Server: 127.0.0.1
Address: 127.0.0.1#53

------------
 QUESTIONS:
 yelb-db.my-interdomain-vl3-network, type = A, class = IN
 ANSWERS:
 -> yelb-db.my-interdomain-vl3-network
 internet address = 172.16.1.3
 ttl = 3406
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
Name: yelb-db.my-interdomain-vl3-network
Address: 172.16.1.3

real 0m0.017s
user 0m0.005s
sys 0m0.009s

If I use the relative name (`my-interdomain-vl3-network` being in the DNS search path), it still takes around 400ms:

# time nslookup -debug -type=a yelb-db
Server: 127.0.0.1
Address: 127.0.0.1#53

------------
 QUESTIONS:
 yelb-db, type = A, class = IN
 ANSWERS:
 -> yelb-db.my-interdomain-vl3-network
 internet address = 172.16.1.3
 ttl = 3311
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
Name: yelb-db.my-interdomain-vl3-network
Address: 172.16.1.3

real 0m0.305s
user 0m0.006s
sys 0m0.012s

@fr-Pursuit
Thank you for your results and comments! We really appreciate it.

I think it's not quite right to solve all dns problems in one issue. Could you create a separate ones for other problems? For example, about PTR requests.

Seems like root cause of the problem is fixed.

Next problem will be considered separatly URL

The vL3 DNS doesn't support PTR requests
## Expected Behavior

The vL3 DNS service should support PTR (ie: reverse DNS) requests, potentially by returning an empty response.

## Current Behavior

An error occurs when the vL3 NSE receives PTR requests. When using the `ping` command with a vL3 domain name, this translates in a small freeze just before the first ping is sent (while the program waits for the timeout associated with the reverse DNS request).

## Failure Information (for bugs)

When the NSE receives a PTR request, this error appears in the logs:

Feb 7 12:06:14.957 [TRAC] [id:26676] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Feb 7 12:06:14.957 [TRAC] [id:26676] [type:dnsServer] (1.1) message-request={"Id":26676,"Response":false,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"3.0.16.172.in-addr.arpa.","Qtype":12,"Qclass":1}],"Answer":null,"Ns":null,"Extra":null}
Feb 7 12:06:14.958 [DEBU] [id:26676] [type:dnsServer] (1.2) passed clientURLs: [{udp 172.16.0.1 false }]
Feb 7 12:06:14.958 [DEBU] [id:26676] [type:dnsServer] (1.3) passed SearchDomains: []
Feb 7 12:06:14.958 [TRAC] [id:26676] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Feb 7 12:06:14.958 [ERRO] [id:26676] [noloopDNSHandler:ServeDNS] [type:dnsServer] (2.1) loop is not allowed: query: ;; opcode: QUERY, status: NOERROR, id: 26676; ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0; ; ;; QUESTION SECTION:; ;3.0.16.172.in-addr.arpa. IN PTR; ;
Feb 7 12:06:14.958 [TRAC] [id:26676] [type:dnsServer] (2.2) message-response={"Id":26676,"Response":true,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":2,"Question":[{"Name":"3.0.16.172.in-addr.arpa.","Qtype":12,"Qclass":1}],"Answer":[],"Ns":[],"Extra":[]}
Feb 7 12:06:15.011 [TRAC] [id:26676] [type:dnsServer] (5.1) message-response={"Id":26676,"Response":true,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":2,"Question":[{"Name":"3.0.16.172.in-addr.arpa.","Qtype":12,"Qclass":1}],"Answer":[],"Ns":[],"Extra":[]}

## Steps to Reproduce

1. Deploy the interdomain vL3 example (while renaming one alpine pod to `alpine2` to avoid confusion and setting the `NSM_DNS_TEMPLATES` environment variable to `{{ index .Labels \"podName\" }}.my-interdomain-vl3-network.` for the DNS service to work)
2. Open a shell in the `alpine` pod
3. Run `ping alpine2.my-interdomain-vl3-network`

## Context

`ping` is a great way to see how PTR requests are handled since when using ping with a domain name, the program performs a reverse DNS query on the source address of the response:

I didn't see how nslookup could directly tell how long each request took, but using the time command, I got this:

root@yelb-appserver-55688766-pm8rf:/# time nslookup -debug yelb-ui.my-interdomain-vl3-network.
Server: 127.0.0.1
Address: 127.0.0.1#53

------------
 QUESTIONS:
 yelb-ui.my-interdomain-vl3-network, type = A, class = IN
 ANSWERS:
 -> yelb-ui.my-interdomain-vl3-network
 internet address = 172.16.0.3
 ttl = 3511
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
Name: yelb-ui.my-interdomain-vl3-network
Address: 172.16.0.3
------------
 QUESTIONS:
 yelb-ui.my-interdomain-vl3-network, type = AAAA, class = IN
 ANSWERS:
 AUTHORITY RECORDS:
 ADDITIONAL RECORDS:
------------
** server can't find yelb-ui.my-interdomain-vl3-network: SERVFAIL

real 0m0.905s
user 0m0.014s
sys 0m0.000s
Each request took more or less the same time, so I'd say around 400/500ms per request.

As for the PTR requests, they come from the ping problem itself. From what I can see, ping performs a reverse DNS query when you use it with a domain name instead of an IP:

% ping -4 google.com -c 4
PING (216.58.213.78) 56(84) bytes of data.
64 bytes from lhr25s01-in-f14.1e100.net (216.58.213.78): icmp_seq=1 ttl=110 time=4.92 ms
64 bytes from lhr25s01-in-f14.1e100.net (216.58.213.78): icmp_seq=2 ttl=110 time=4.91 ms
64 bytes from par21s18-in-f14.1e100.net (216.58.213.78): icmp_seq=3 ttl=110 time=4.98 ms
64 bytes from lhr25s01-in-f78.1e100.net (216.58.213.78): icmp_seq=4 ttl=110 time=5.00 ms

--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.909/4.950/5.000/0.038 ms

% ping -4 216.58.213.78 -c 4
PING 216.58.213.78 (216.58.213.78) 56(84) bytes of data.
64 bytes from 216.58.213.78: icmp_seq=1 ttl=110 time=4.86 ms
64 bytes from 216.58.213.78: icmp_seq=2 ttl=110 time=4.87 ms
64 bytes from 216.58.213.78: icmp_seq=3 ttl=110 time=4.96 ms
64 bytes from 216.58.213.78: icmp_seq=4 ttl=110 time=4.92 ms

--- 216.58.213.78 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.857/4.902/4.963/0.041 ms

This problem was diagnosed as part of #1414

The example was deployed on three kind clusters using kind `0.17.0` and the kindest `v1.25.3` image

@glazychev-art Could you please add a test into deployments-k8s?

@fr-Pursuit
Could you check PTR requests on the latest main branch if you get a chance?

@glazychev-art Hi! PTR requests seem to be handled correctly now. `ping` doesn't freeze at all :)

However, I now need to explicitly use IPv4 in order for the ping to work...

/ # ping -c 4 alpine2.my-interdomain-vl3-network
ping: bad address 'alpine2.my-interdomain-vl3-network'

/ # ping -c 4 alpine2.my-interdomain-vl3-network -4
PING alpine2.my-interdomain-vl3-network (172.16.0.2): 56 data bytes
64 bytes from 172.16.0.2: seq=0 ttl=59 time=65.076 ms
64 bytes from 172.16.0.2: seq=1 ttl=59 time=2.696 ms
64 bytes from 172.16.0.2: seq=2 ttl=59 time=12.237 ms
64 bytes from 172.16.0.2: seq=3 ttl=59 time=60.345 ms

When the ping fails, this error appears in the NSE's logs:

Mar 26 21:04:34.885 [TRAC] [id:22041] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Mar 26 21:04:34.885 [TRAC] [id:22041] [type:dnsServer] (1.1) message-request={"Id":22041,"Response":false,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"alpine2.my-interdomain-vl3-network.","Qtype":28,"Qclass":1}],"Answer":null,"Ns":null,"Extra":null}
Mar 26 21:04:34.885 [DEBU] [id:22041] [type:dnsServer] (1.2) passed clientURLs: [{udp 172.16.0.1 false } {udp 172.16.0.1 false }]
Mar 26 21:04:34.885 [DEBU] [id:22041] [type:dnsServer] (1.3) passed SearchDomains: []
Mar 26 21:04:34.885 [TRAC] [id:22041] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Mar 26 21:04:34.886 [TRAC] [id:22041] [type:dnsServer] (3) ⎆ sdk/pkg/tools/dnsutils/norecursion/norecursionDNSHandler.ServeDNS()
Mar 26 21:04:34.886 [TRAC] [id:22041] [type:dnsServer] (1) ⎆ sdk/pkg/tools/dnsutils/dnsconfigs/dnsConfigsHandler.ServeDNS()
Mar 26 21:04:34.887 [TRAC] [id:22041] [type:dnsServer] (4) ⎆ sdk/pkg/tools/dnsutils/memory/memoryHandler.ServeDNS()
Mar 26 21:04:34.887 [TRAC] [id:22041] [type:dnsServer] (1.1) message-request={"Id":22041,"Response":false,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":0,"Question":[{"Name":"alpine2.my-interdomain-vl3-network.","Qtype":28,"Qclass":1}],"Answer":null,"Ns":null,"Extra":null}
Mar 26 21:04:34.887 [DEBU] [id:22041] [type:dnsServer] (1.2) passed clientURLs: [{udp 172.16.0.1 false } {udp 172.16.0.1 false }]
Mar 26 21:04:34.887 [DEBU] [id:22041] [type:dnsServer] (1.3) passed SearchDomains: []
Mar 26 21:04:34.887 [TRAC] [id:22041] [type:dnsServer] (2) ⎆ sdk/pkg/tools/dnsutils/noloop/noloopDNSHandler.ServeDNS()
Mar 26 21:04:34.887 [ERRO] [id:22041] [noloopDNSHandler:ServeDNS] [type:dnsServer] (2.1) loop is not allowed: query: ;; opcode: QUERY, status: NOERROR, id: 22041; ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0; ; ;; QUESTION SECTION:; ;alpine2.my-interdomain-vl3-network. IN AAAA; ;
Mar 26 21:04:34.887 [TRAC] [id:22041] [type:dnsServer] (2.2) message-response={"Id":22041,"Response":true,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":2,"Question":[{"Name":"alpine2.my-interdomain-vl3-network.","Qtype":28,"Qclass":1}],"Answer":[],"Ns":[],"Extra":[]}
Mar 26 21:04:34.888 [TRAC] [id:22041] [type:dnsServer] (5) ⎆ sdk/pkg/tools/dnsutils/fanout/fanoutHandler.ServeDNS()
Mar 26 21:04:34.915 [TRAC] [id:22041] [type:dnsServer] (5.1) message-response={"Id":22041,"Response":true,"Opcode":0,"Authoritative":false,"Truncated":false,"RecursionDesired":false,"RecursionAvailable":false,"Zero":false,"AuthenticatedData":false,"CheckingDisabled":false,"Rcode":2,"Question":[{"Name":"alpine2.my-interdomain-vl3-network.","Qtype":28,"Qclass":1}],"Answer":[],"Ns":[],"Extra":[]}

It seems the `AAAA` request fails in a way that makes `ping` fails before it even attempts to make a `A` request. I don't remember seeing that before. Is it be caused by a change in NSM or somewhere else?

@fr-Pursuit
No, there were no changes in NSM in this direction. And this behavior was before, you can check versions v1.8.0 or v1.7.1 :)
`ping` utility is the reason for this. Depending on the system settings, it prefers IPv6 over IPv4.

As far as I can see, in some linux versions this is solved by changing `/etc/gai.conf`. But not for alpine. Perhaps this will help you.

@fr-Pursuit Hello, I've fixed the problem with `ping` and explicit `IPv4`. Could you please check it?

@NikitaSkrynnik Hi! Sorry for the late reply.

It's all fixed, thanks!

/ # ping -c 4 alpine2.my-interdomain-vl3-network
PING alpine2.my-interdomain-vl3-network (172.16.1.2): 56 data bytes
64 bytes from 172.16.1.2: seq=0 ttl=56 time=1.426 ms
64 bytes from 172.16.1.2: seq=1 ttl=56 time=1.503 ms
64 bytes from 172.16.1.2: seq=2 ttl=56 time=1.652 ms
64 bytes from 172.16.1.2: seq=3 ttl=56 time=4.073 ms

--- alpine2.my-interdomain-vl3-network ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.426/2.163/4.073 ms


Question: [Bug]: Failed to launch the browser process!

@davicente I haven't seen this error before. Have you tried clearing the heroku build cache by chance?
 URL

If that doesn't work, try starting a new heroku app with the same repo, just to be sure we can rule heroku out of the equation.

[Bug]: Failed to launch the browser process!
### Bug description

An error is thrown when I use the following code！

 const browser = await puppeteer.launch({
 headless: true
 });

error message:

Failed to launch the browser process!\n/opt/video-url-analysis/node_modules/_puppeteer@13.1.0@puppeteer/.local-chromium/linux-950341/chrome-linux/chrome: error while loading shared libraries: libatk-1.0.so.0: cannot open shared object file: No such file or directory\n\n\nTROUBLESHOOTING: URL

I saw the tips about node 14.0.0 Chrome is downloaded but fails to launch on Node.js 14 , but I use the node version is v14.18.1!
What do I need to do to run it!

### Puppeteer version

13.1.0

### Node.js version

v14.18.1

### npm version

6.14.15

### What operating system are you seeing the problem on?

Linux

### Relevant log output

shell
Failed to launch the browser process!\n/opt/video-url-analysis/node_modules/_puppeteer@13.1.0@puppeteer/.local-chromium/linux-950341/chrome-linux/chrome: error while loading shared libraries: libatk-1.0.so.0: cannot open shared object file: No such file or directory\n\n\nTROUBLESHOOTING: URL

I'm having this same issue after deploying in Heroku. In local is working perfectly, but in Heroku it fails. I've followed the
guidelines adding the buildpack and so, but same error.

This is how I initialize the browser:

` browser = await puppeteer.launch({
 headless: true,
 args: ['--no-sandbox', '--disable-setuid-sandbox'],
 });`

The error I get:
`Error: Failed to launch the browser process! `

Here the buildpacks added in Heroku
image

Now I've solved it！install libXScrnSaver in the server and can run it!

sudo yum -y install libXScrnSaver-1.2.2-6.1.el7.x86_64

I think that's not valid for me in Heroku. Thanks anyway for your answer. I'll keep searching

Just in case anyone comes here with same problem for Heroku, I created an issue in the libpack library for Heroku. Hopefully it will be discuss there:
 URL

@davicente What does the command do?

I am getting `bash: yum: command not found` as error.

@zhaosheng808 What does the command do?

I am getting `bash: yum: command not found` as error.

I don't know the specific principle of this, but I have performed the following operations and the problem has been solved

sudo yum -y install libXScrnSaver-1.2.2-6.1.el7.x86_64

and

sudo yum install -y chromium

you can see this issues URL

You may install the buildpack on the server using github repo: URL

In Ubuntu you have to:

 apt install chromium-browser
 apt install libxkbcommon0
 apt install libxshmfence1
 apt install 1622 apt-get install ca-certificates
 apt install fonts-liberation
 apt install libasound2
 apt install libatk-bridge2.0-0
 apt install libatk1.0-0
 apt install libc6
 apt install libcairo2
 apt install libcups2
 apt install libdbus-1-3
 apt install libexpat1
 apt install libfontconfig1
 apt install libgbm1
 apt install libgcc1
 apt install libglib2.0-0
 apt install libgtk-3-0
 apt install libnspr4
 apt install libnss3
 apt install libpango-1.0-0
 apt install libpangocairo-1.0-0
 apt install libstdc++6
 apt install libx11-6
 apt install libx11-xcb1
 apt install libxcb1
 apt install libxcomposite1
 apt install libxcursor1
 apt install libxdamage1
 apt install libxext6
 apt install libxfixes3
 apt install libxi6
 apt install libxrandr2
 apt install libxrender1
 apt install libxss1
 apt install libxtst6
 apt install lsb-release wget
 apt install xdg-utils
 apt install

Getting the error `Failed to launch both playwright and puppeteer`

I have same issue
in locally it work perfectly but when i copy it into docker i have got an error

cmd
Error: Unable to launch browser, error message: Failed to launch the browser process!
 /usr/src/node_modules/puppeteer/.local-chromium/linux-1022525/chrome-linux/chrome: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory

we were using azure web apps
after some restart we need to execute above
in order make puppter working

In Ubuntu you can try;

`sudo apt install libxkbcommon0 libxshmfence1 ca-certificates fonts-liberation libasound2 libatk-bridge2.0-0 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgbm1 libgcc1 libglib2.0-0 libgtk-3-0 libnspr4 libnss3 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 lsb-release wget xdg-utils` to install all the packages togather

thanks, man. can you explain why it's working after installing all the packages?

'Error: Failed to launch the browser process!' after trying all suggestions
I'm having this issue that I know have appeared many times. But after checking all possible solutions, noone is working for me. Everything is working fine for me in local, but after deploying in Heroku, I recieve that error:

The error I get:
'Error: Failed to launch the browser process!'

This is how I initialize the browser:
browser = await puppeteer.launch({ headless: true, args: ['--no-sandbox', '--disable-setuid-sandbox'], });

Here the buildpacks added in Heroku
image

I'm a little lost and desperate
I hope you can help me :)

Thanks @davicente lets see what we can do.

First can you post the rest of the error too please?

Hi @jontewks,
first of all, thanks for your fast reply.

This is the stack:

Error: Failed to launch the browser process!
ERROR:platform_thread_posix.cc(148)] pthread_create: Resource temporarily unavailable (11)
FATAL:browser_task_executor.cc(405)] Failed to start BrowserThread:IO
host app worker.1 - #0 0x56251b45c029 base::debug::CollectStackTrace()
host app worker.1 - #1 0x56251b3c3623 base::debug::StackTrace::StackTrace()
host app worker.1 - #2 0x56251b3d68f0 logging::LogMessage::~LogMessage()
host app worker.1 - #3 0x56251938bba6 content::BrowserTaskExecutor::CreateIOThread()
host app worker.1 - #4 0x56251af5e408 content::ContentMainRunnerImpl::RunBrowser()
host app worker.1 - #5 0x56251af5e117 content::ContentMainRunnerImpl::Run()
host app worker.1 - #6 0x56251af5b985 content::RunContentProcess()
host app worker.1 - #7 0x56251af5c45e content::ContentMain()
host app worker.1 - #8 0x56251afba7ce headless::HeadlessBrowserMain()
host app worker.1 - #9 0x56251afba4fd headless::HeadlessShellMain()
host app worker.1 - #10 0x562517d01133 ChromeMain
host app worker.1 - #11 0x7fb491ed50b3 __libc_start_main
host app worker.1 - #12 0x562517d00f6a _start
host app worker.1 -
host app worker.1 - Received signal 6
host app worker.1 - #0 0x56251b45c029 base::debug::CollectStackTrace()
host app worker.1 - #1 0x56251b3c3623 base::debug::StackTrace::StackTrace()
host app worker.1 - #2 0x56251b45bb01 base::debug::(anonymous namespace)::StackDumpSignalHandler()
host app worker.1 - #3 0x7fb492da63c0 (/usr/lib/x86_64-linux-gnu/libpthread-2.31.so+0x153bf)
host app worker.1 - #4 0x7fb491ef418b gsignal
host app worker.1 - #5 0x7fb491ed3859 abort
host app worker.1 - #6 0x56251b45ad95 base::debug::BreakDebuggerAsyncSafe()
host app worker.1 - #7 0x56251b3d6d1f logging::LogMessage::~LogMessage()
host app worker.1 - #8 0x56251938bba6 content::BrowserTaskExecutor::CreateIOThread()
host app worker.1 - #9 0x56251af5e408 content::ContentMainRunnerImpl::RunBrowser()
host app worker.1 - #10 0x56251af5e117 content::ContentMainRunnerImpl::Run()
host app worker.1 - #11 0x56251af5b985 content::RunContentProcess()
host app worker.1 - #12 0x56251af5c45e content::ContentMain()
host app worker.1 - #13 0x56251afba7ce headless::HeadlessBrowserMain()
host app worker.1 - #14 0x56251afba4fd headless::HeadlessShellMain()
host app worker.1 - #15 0x562517d01133 ChromeMain
host app worker.1 - #16 0x7fb491ed50b3 __libc_start_main
host app worker.1 - #17 0x562517d00f6a _start
[...]

Let me know if you have any idea about the problem.
Regards

@davicente I was going to say I haven't seen that error before but I see you closed it. Mind mentioning what your fix was here just in case anyone else comes across this in the future?

It looks like it was related with a problem with memory limitation in the pod (in case it happens to anyone again).
Thanks for your support :).

hey @jontewks , this did not work for me.. i deleted cache a couple of times and I get this error everytime..

js
2022-03-15T20:03:34.549420+00:00 app[web.1]: Chrome Initialize failed: Error: Failed to launch the browser process!
2022-03-15T20:03:34.549432+00:00 app[web.1]: [133:133:0315/200334.538525:ERROR:ozone_platform_x11.cc(247)] Missing X server or $DISPLAY
2022-03-15T20:03:34.549445+00:00 app[web.1]: [133:133:0315/200334.538571:ERROR:env.cc(225)] The platform failed to initialize. Exiting.
2022-03-15T20:03:34.549472+00:00 app[web.1]: TROUBLESHOOTING: URL
2022-03-15T20:03:34.549484+00:00 app[web.1]: at onClose (/app/node_modules/puppeteer/lib/cjs/puppeteer/node/BrowserRunner.js:237:20)
2022-03-15T20:03:34.549499+00:00 app[web.1]: at ChildProcess. (/app/node_modules/puppeteer/lib/cjs/puppeteer/node/BrowserRunner.js:228:79)
2022-03-15T20:03:34.549521+00:00 app[web.1]: at ChildProcess.emit (events.js:412:35)
2022-03-15T20:03:34.549530+00:00 app[web.1]: at Process.ChildProcess._handle.onexit (internal/child_process.js:282:12)

any idea why this can be happening?

I see.. that is issue then, I am trying to run it as `headless: false`. Was not aware that heroku did not supported this feature. So for what you are saying there is absolutely no workaround for launching a puppeteer client with `headless: false` on heroku correct?


Question: RN 0.69.3, ReactNativeConfig.h file not found?

Hey, Reanimated works with Fabric. If it doesn't work for you in your app, this is probably an issue with your configuration or setup.

@shahmeer-ali Have you tried any steps that worked for other people?
- URL
- URL

RN 0.69.3, ReactNativeConfig.h file not found
## Description

After updating project to new version RN 0.69.3 and run project on Xcode, error comings out

<img width="1512" alt="Schermata 2022-08-01 alle 16 46 30" src=" URL

## Package versions

| name | version |
| ------------------------------------ | ------- |
| react-native |0.69.3|
| react-native-reanimated | ^2.4.1|
| NodeJS |18.7.0|
| Xcode |13.4.1|
| Java |openjdk version "11.0.16"|
| Gradle |7.3.3|
| expo ||

## Affected platforms

- [ ] Android
- [x] iOS
- [ ] Web

Hello @alzhab! Thanks for submitting the issue. Here are some more questions:

1. Do you use Expo?
2. Did you remember to run `RCT_NEW_ARCH_ENABLED=1 pod install` in `ios` directory of your app?

I've just created a fresh RN 0.69.3 app, added react-native-reanimated, build the app for iOS and it works fine.

Please make sure that you enable Fabric via environmental variable `RCT_NEW_ARCH_ENABLED` and not directly in Podfile.

Related issues:
* URL
* URL

Hello
1 No, i don't use Expo
2 Yes Fabric enabled and run command with flag RCT_NEW_ARCH_ENABLED=1

Not working with Fabric on iOS
## Description

Using latest Reanimated (2.4.1) together with the current 0.68 release candidate is not working with the new architecture/fabric enabled on iOS.

### Expected behavior

The app compiles with the `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1` flags.

### Actual behavior & steps to reproduce

The app fails to compile with the error:

'react/config/ReactNativeConfig.h' file not found

## Snack or minimal code example

bash
npx react-native init ReanimatedFabric --version 0.68.0-rc.1
cd ReanimatedFabric
yarn add react-native-reanimated@2.4.1
cd ios
USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 bundle exec pod install
yarn ios

## Package versions

| name | version |
| ------------------------------------ | ------- |
| react-native | 0.68.0-rc.0, 0.68.0-rc.1 |
| react-native-reanimated | 2.2.4, 2.4.1 |
| NodeJS | 16.14.0 |
| Xcode | 13.2.1 |

## Affected platforms

- [ ] Android
- [x] iOS
- [ ] Web

Hello! We're actively working on porting Reanimated to Fabric but it's not completely ready yet. In fact, Reanimated integrates quite closely with the renderer system so we need to rewrite some parts specifically for Fabric and that's exactly what we have been doing for the past few months.

The good news is that in parallel we're porting react-native-gesture-handler and react-native-screens to Fabric as well so hopefully the developers will be able to enable Fabric in their apps as soon as possible.

URL

I also opened discussion for nightly release support but now new architecture has shipped

Same issue.
I upgrade `react-native-reanimated` to `v2.6.0` still has issue.

@alantoa @Tjerk-Haaye-Henricus they are actively working on it you can check the Fabric branch URL

Amazing :) Thanks a thousand times for that information 🙏
btw: i really really in love with your work and i'm using all of your rn repos inside of several projects 🤓

FYI this does still seem be happening with react-native 0.68.1 and react-native-reanimated 2.8.0. I really appreciate all the hard work you guys are doing!

@ahmadzraiq They announced that version 3 should resolve this: URL

@mikeislearning "If you’d like to try running Reanimated on the new Fabric architecture, make sure that you are using at least version 0.69 of React Native"

so it's not working for expo SDK 45, right? (Expo SDK 45 uses v0.68.2)

Version 3 is coming 😏 and hopefully solving this issue.

 URL

I'm still getting `'react/config/ReactNativeConfig.h' file not found` when building react-native v0.68.2 with v3.0.0-rc.0 and Fabric enabled.

Could you anyone confirm that v3.0.0-rc.0 is supposed to work with Fabric enabled?

@maxperry Yes, but only with using RN 0.69, where you have the new arch enabled.

we got RN 0.69 released but the error 'react/config/ReactNativeConfig.h' file not found is still here

If you want to use Fabric in your app you need to install Reanimated 3, but if you just want to use react-native@0.69 you should use Reanimated 2.9.1

What if 0.68.2 (expo 45) is a hard requirement and the app depends on reanimated?

Hey all, just wanted to sum up the discussion and close the issue since it was resolved with the release of 3.0.0-rc.0, which is the very first version that supports the new React Native renderer, Fabric. 🎉

If you’d like to try running **Reanimated on the new Fabric architecture**, you need to upgrade to React Native 0.69 (or newer) and install Reanimated 3.0.0-rc.0 (or newer). Note that it will not work with Reanimated 2.x or React Native 0.68.x. For more details, check out this blog post.

If you want to use **Reanimated on the old Paper architecture**, you can still use version 2.x and React Native 0.64+. However, if you don't use old Reanimated 1 API, we encourage you to upgrade to Reanimated 3 (which is fully-compatible with Reanimated 2 API and built from sources on both platforms).

Currently (as of July 2022), Expo SDK does not support Fabric yet. Expo SDK 45 includes react-native 0.68.2 and react-native-reanimated 2.x which does not support Fabric.

I am getting this error on RN v0.70.1 with new architecture and fabric enabled. I have installed `3.0.0-rc.2` version of reanimated. Tried re-install node_modules, and pods. Also tried deleting pod lock file and cleaning build from XCode, but didn't help. @tomekzaw

@fawad-khalil Can you try removing `ios/build` folder of your app?

So any solution so far making Reanimated to work with Fabric?

screenshot

@tomekzaw
 Invalid `RNReanimated.podspec` file: [react-native-reanimated] Reanimated 3.2.0 supports the New Architecture only on the latest minor release of React Native. Please upgrade to React Native 0.72.0+ or downgrade to an older version of Reanimated v3.

I am getting this message . only thing i did was new react native init , and pod install with fabric, and then installed reanimated all . by default react native is coming with .71 version. and reanimated asks for .72, i think its not stable yet so is there any solution to this.

@Commaando Yeah, Reanimated 3.1.0 and 3.2.0 support Fabric only with React Native 0.72 which is not stable yet (currently latest pre-release is 0.72.0-rc.5). Sorry for this, we were just too fast. If you really need to use Reanimated with React Native 0.71, please use `react-native-reanimated@3.0.2`.