|
Jukka Rissanen
Hi Giri, can you create an issue in github for this. Trying to resolve your issue in mailing list is not very effective. Cheers, Jukka
On Thu, 2019-09-26 at 02:19 -0700, giriprasad@... wrote: But, without those changes, if I am trying to ping the board on which Zephyr is running, it is not responding to ping requests and wireshark capture in this scenario can be found in the attached file. I am unable to figure out where the mistake is happening. I have been trying in different ways but in vain. Is there any suggestions or check points to resolve this issue. Please help...
|
|
|
|
giriprasad@...
But, without those changes, if I am trying to ping the board on which Zephyr is running, it is not responding to ping requests and wireshark capture in this scenario can be found in the attached file. I am unable to figure out where the mistake is happening. I have been trying in different ways but in vain. Is there any suggestions or check points to resolve this issue. Please help...
Thanks & Regards, Giri Prasad N.
|
|
|
|
Marc Herbert
On 24 Sep 2019, at 02:20, giriprasad@semiconsoul.com wrote:It should but might not be enough because ufw is just a user interface. Use "ip[6]tables -L" to verify the actual state.
|
|
|
|
Jukka Rissanen
The changes that you do there basically turn off ARP, the end result is that the IPv4 connectivity cannot work properly after this. Cheers, Jukka
On Wed, 2019-09-25 at 04:15 -0700, giriprasad@... wrote: Hi Jukka,
|
|
|
|
giriprasad@...
Hi Jukka,
"net iface" is returning a valid mac address. But for my Ethernet to work, I have tweaked Zephyr code. I have posted about it in another topic of this mailing list. Please follow this link https://lists.zephyrproject.org/g/devel/message/6325 Please let me understand the problem I am facing, as mentioned in the above link. I am suspecting that, this is causing the issue. Please help me in this regards. Thanks & regards, Giri.
|
|
|
|
Jukka Rissanen
Hi Giri, yes, that is definitely a problem. The destination MAC address should be a valid unicast address. Does you ethernet board have a proper MAC address set to it? You can see the MAC address using "net iface" command in net-shell. Cheers, Jukka
On Tue, 2019-09-24 at 05:52 -0700, giriprasad@... wrote: Hi Jukka,
|
|
|
|
clarification Zephyr kernel type
Khalid Talash <khalid.talash@...>
Hello,
I am currently writing a paper comparing different RTOSs. I want to compare the kernel architecture types of the different RTOSs but Zephyrs kernel confuses me a little bit. I get from literature and wikipedia that basically kernel types are monolithic or microkernel. From your visualization of system architecture on your security overview page I would guess Zephyr uses microkernel type because functionalities like file systems and IPC are seperate from Kernel. But your documentation also says Zephyr uses unified kernel which on the other hand sounds like monolithic to me. Could you please which classification of kernel type (monolithic or microkernel) fits Zephyr? This would help me so much. Thanks in advance. Sincerely Khalid Talash
|
|
|
|
Upcoming Event: Zephyr Project: APIs - Tue, 09/24/2019 9:00am-10:00am, Please RSVP
#cal-reminder
devel@lists.zephyrproject.org Calendar <devel@...>
Reminder: Zephyr Project: APIs When: Tuesday, 24 September 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles Where:https://zoom.us/j/177647878 An RSVP is requested. Click here to RSVP Organizer: devel@... Description: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878 Live meeting minutes: https://docs.google.com/
|
|
|
|
giriprasad@...
Hi Jukka,
I have verified the MAC address. Zephyr is sending the [SYN/ACK] packet with destination MAC address as "ff:ff:ff:ff:ff:ff", which is a broadcast address. Does this causing my ubuntu to not receive the packets? Thanks & Regards, Giri
|
|
|
|
Interfacing ENC28J60(ethernet) with PCA10056.
#nrf52840
Hi Team,
I have interfaced ENC28j60 module to PCA10056 and flashed the example "zephyr/samples/net/sockets/echo" . After this, I am unable to ping PCA10056. I am getting the wireshark log as shown in attached file "wireshark_log_arp_enabled.png". Here, mac_address of ENC28J60 is " 00:04:a3:ae:89:92", IP Address is "192.168.31.37". IP Address of the PC I am pinging from is "192.168.31.74". After this,I have commented out few lines of code in the file "zephyr//subsys/net/l2/ethernet/ethernet.c". Now, I am able to ping "PCA10056". Please find the wireshark log of this in the attached file "wireshark_log_arp_disabled.png". Also attached screenshot of the changes I have made to the file "zephyr//subsys/net/l2/ethernet/ethernet.c" with name "ethernet_file_changes.png". Please help me in understanding why I am unable to ping without changes to the file "zephyr//subsys/net/l2/ethernet/ethernet.c". Please let me know, if more information is needed. Thanks & Regards, Giri
|
|
|
|
Jukka Rissanen
Hi Giri,
toggle quoted messageShow quoted text
You could also verify from wireshark that the MAC addresses are correctly set in the packets. If zephyr sends a packet using wrong destination MAC address, then your ubuntu would not receive it. Cheers, Jukka
On Tue, 2019-09-24 at 02:20 -0700, giriprasad@semiconsoul.com wrote:
Hi,
|
|
|
|
giriprasad@...
Hi,
Thanks for the reply. I have verified the ufw status and it is inactive. Is it enough to say that firewall is disabled. Regards, Giri
|
|
|
|
Jukka Rissanen
Hi,
toggle quoted messageShow quoted text
The text logs do not reveal anything useful (other than the zephyr version used and that you are using ethernet + dhcp). From the wireshark image, we can see that ubuntu does not receive the SYN,ACK that zephyr sends as ubuntu tries to send SYN multiple times. Perhaps there is a firewall that blocks the connection? Cheers, Jukka
On Mon, 2019-09-23 at 23:59 -0700, giriprasad@semiconsoul.com wrote:
Hi Team,
|
|
|
|
giriprasad@...
Hi Team,
I am running tcp socket client program in Ubuntu bash of Windows subsystem for Linux and server program on PCA10056 board, on which zephyr is running. I am able to establish connection and transfer data between server and client. Please observe the zephyr debug log of this, in the file attached with name "socket_connection_log_zephyr_server_wsl_client.txt". Also observe the log of wireshark running on Windows PC. File name is "ws_log_sock_conn_zephyr_server_wsl_client.png" After this, I have tried running the client code in the PC which is running on Ubuntu OS. But, this time I am unable to establish connection between my PC and PCA10056. Please observe the zephyr debug log of this, in the file attached with name "socket_connection_log_zephyr_server_ubuntu_client.txt". Also observe the log of wireshark running on Ubuntu PC. File name is "ws_log_sock_conn_zephyr_server_ubuntu_client.png". I am unsure of this behavior. Please help me to establish connection between Ubuntu PC and PCA10056. Please let me know, if more information is needed. Thanks & Regards, Giri Prasad N.
|
|
|
|
Re: LWM2M batch uploading data
Benjamin Lindqvist
Thanks for the info Mike. Queueing mode seems like it would resolve some worries, but would you mind clarifying one thing? From the issue:
Seems like this can be interpreted as "an observation always implies an uplink", i.e. buffering and batching many observations in a single uplink is not really possible. Is this correct?
On Tue, Sep 24, 2019 at 12:02 AM Michael Scott <mike@...> wrote:
|
|
|
|
Re: LWM2M batch uploading data
Hello Benjamin, On Mon, Sep 23, 2019, 9:11 AM Benjamin Lindqvist <benjamin.lindqvist@...> wrote:
You are correct. The missing piece is LwM2M queue mode support. This mode is registered during the initial client / server connection. It means there is a mutual agreement that the client will (in general) not be available for instantaneous queries, but prior to the agreed upon connection "lifetime", the client will re-establish communication with the server and answer requests. There is a set period of time where the client will remain connected afterward and then it can go back offline. Over the last few months, queue mode in Zephyr has gotten more attention (mainly due to expanding modem support). Unfortunately, due to my current work load, I haven't had the time to implement and test it. Here is the Zephyr issue which tracks the addition of LwM2M queue mode support: Michael Scott Embedded Software Engineer Foundries.io
|
|
|
|
API Meeting Agenda: 2019-09-24
Peter A. Bigot
Carles has asked me to lead the API telecon Tuesday 2019-09-24 as he will not be available. Topics to discuss include:
* Status and concerns related to PR #17155 to change how timeout delays are represented in functions like `k_poll()`: https://github.com/zephyrproject-rtos/zephyr/pull/17155 * Status of the ongoing effort to update the GPIO API: https://github.com/zephyrproject-rtos/zephyr/issues/18530 Additional items in the "Triage" column in the GitHub project may be discussed if time permits. If you want an item included in the meeting, please add it to the GitHub project. Peter https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion https://github.com/zephyrproject-rtos/zephyr/projects/18 https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit
|
|
|
|
Request for reviews: change to timeout representation in kernel functions
Peter A. Bigot
PR 17155 (https://github.com/zephyrproject-rtos/zephyr/pull/17155) is an API cleanup that changes the type used to store timeout delays from a signed integer representing milliseconds to an opaque type that will be able to represent both absolute and relative times, higher resolution timeouts, and potentially timeouts on different clocks. See https://github.com/zephyrproject-rtos/zephyr/issues/19282 for an overview of the current vision and a link to a presentation recently made to TSC that has even more background.
This PR provides the foundation technology that supports better timeouts. In last weeks dev review telecon we discussed merging it quickly to avoid excess pain in rebasing it, and to get it visible early in the development cycle so a late merge doesn't require a rush to rebase a lot of other work. Though it's huge, it's also fairly straightforward. We're still working on a few patches to get it to pass shippable's tests. Code size is unchanged by the rework, but applications that choose to use 64-bit timers (which are new in this PR) will need more RAM. There are some behavioral anomalies with large numbers of timers with short periods but these have been recognized before (and may be eliminated by further refactoring and cleanup). However, we need more reviewers. Please take a look at this, and the related issues, and provide feedback and any concerns you may have. This will be a topic of discussion in the API telecon tomorrow. Peter
|
|
|
|
Re: LWM2M batch uploading data
Benjamin Lindqvist
To be honest, it sort of seems as if the implementation assumes it has a perpetually open socket connection to cloud at all times. Perhaps this is an exaggeration, but I'd kind of like to know how (if?) the implementation handles downed interfaces and broken pipes...
On Mon, Sep 23, 2019 at 5:34 PM Benjamin Lindqvist via Lists.Zephyrproject.Org <benjamin.lindqvist=endian.se@...> wrote:
|
|
|
|
LWM2M batch uploading data
Benjamin Lindqvist
Hi, We have a use-case which I deem to be pretty normal: uplinks are really expensive and should be kept to a minimum (in fact, we want the radio completely powered off 99.99% of the time). But we have N sensors which we want to observe from the cloud, at different intervals. Looking briefly through the specification, one gets the impression that OBSERVE at some interval implies that the device uploads data at this observation interval. What we'd like to do is to sample the data at the observation interval and batch upload it at some different, longer, interval. It's not clear to me if the specification allows this - and if it does, does the Zephyr implementation allow it? Grateful for clarifications.
|
|
|