Hi, This evening I took a look at how we might better integrate dhcpv4 into the platform. In the current tree, in order to use dhcp the application is expected to start the dhcp client explicitly.

Hello Daniel,

Hello Richard, Let me start with saying that I agree that Zephyr networking does have issues. They say that any bug is shallow given enough eyes, and Zephyr networking clearly lacks enough eyes. So,

The alias {} node can indeed be used for this. But unless we define a specific format, parsing this might be interesting. However we have some solutions for that if we want to go that route. A

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/10993 : tests/common: Add tests for sys_dlist_* - https://gerrit.zephyrproject.org/r/11000 : drivers: Convert FOR_EACH macro instances

Sure, can you provide patches? Yes, creating a tickets in jira is a good idea in this case. Cheers, Jukka

Hi Marcus, <marcus.shawcroft@...> wrote: While I agree we should prevent the remote to consume all the buffer and possible starve the TX, this is probably due to echo_server design that deep

Hi, the SLIP-TAP driver seems not to be working in qemu for cortex-m targets,too. I can not get any network traffic between, either between to qemu_cortex_m3 targets nor to the PC. Has anyone tried

Dear all: i am running some test pattern about network on arduino_due board, i found that both the ./zephyr/tests and ./zephyr/ssamples/ are have some test pattren about network, they seems

Maybe should this be patched in the out-of-the-box samples? I hope so, have to fiddle around with this :) What is the workflow for the other issues? Should i create tickets in

Hi Richard, You are running out of buffers, please increase the TX/RX/DATA buf count. Could you provide such a conf file and send a patch? Conf file is probably wrong and has wrong settings. No

Hi Community, i have several problems with the net examples. Maybe there are some bugs involved? 1st Problem =========== Sample: echo_server / echo_client On 'make server' on server side and 'make

<jukka.rissanen@...> wrote: Running out of resources is bad, dead lock, especially undetected deadlock, is worse. Avoiding the dead lock where the RX path starves the rest of the system

Hi Piotr, One option would be to split the DATA pool to two so one pool for sending and receiving. Then again this does not solve much as you might still get to a situation where all the buffers are

Hi Paul,

Hi, There seems to be a conceptual issue in a way networking buffers are currently set up. I was thinking about entering Jira bug report but maybe it's just me missing some information

OK, so it seems that, since you can disable the CONFIG_SEMAPHORE_GROUPS feature, you are _not_ using said feature. In theory, this if statement should always be hit in handle_sem_group(): if

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/10947 : samples/mbedtls_dtls_server: Use k_uptime_get_32() - https://gerrit.zephyrproject.org/r/10946 : samples/mbedtls_dtls_client:

Hi, I have a question regarding the impact of CONFIG_SEMAPHORE_GROUPS flag. In my sample application I experienced weird failures in k_sem_give being called from udp receive callback. After debugging

As Anas mentioned, I still think we need 2 level of "asserts". There might be one level which, as you state, is there only to detect early user errors during development and can be turned off on