Hi Marko,
I rechecked this morning and OC_TRANSPORT_IPV4 was not set.. ipv4 was..
so I did that and activated log level 0 as you told me.
this is the console output wehen i run
newtmgr.exe taskstat -c udp
with the connection udp:
udp: type=oic_udp, connstring='[192.168.2.126]:5683'
the code i use is the original slinky_oic app, just changed sysval IPV4
any idea whats causing the problem?
017673 1: st1 7(up|mcast|link)
017675 192.168.2.126/24
017678 fe80:0:0:0:201:1ff:fe02:203/64
017681 2003:72:8e38:4051:201:1ff:fe02:203/64
017685 compat> oc_buffer_rx: <unkwn>
023635 [ts=23635000ssb, mod=7 level=1] CoAP: received datalen=23
023641 [ts=23641000ssb, mod=7 level=0] Token (len 0) []
023646 [ts=23646000ssb, mod=7 level=0] OPTION 11 (delta 11, len 4): Uri-Path
[omgr]
023653 [ts=23653000ssb, mod=7 level=0] Parsed: CoAP version: 1, token:
0x0000, mid: 0
023661 [ts=23661000ssb, mod=7 level=0] type: CON
023666 [ts=23666000ssb, mod=7 level=0] method: PUT
023670 [ts=23670000ssb, mod=7 level=0] Payload: 13 bytes
023677 [ts=23677000ssb, mod=7 level=0] coap_notify_observers: no observers left
023683 [ts=23683000ssb, mod=7 level=0] coap_tx: 0x200117b4
023688 [ts=23688000ssb, mod=7 level=0] Content-Format [60]
023693 [ts=23693000ssb, mod=7 level=0] OPTION 12 (delta 12, len 1)
023699 [ts=23699000ssb, mod=7 level=0] coap_tx: serialized 414 B (header len 7,
payload len 407)
023708 [ts=23708000ssb, mod=7 level=0] Sending transaction 0
023713 [ts=23713000ssb, mod=7 level=1] coap_send_message(): (414)
023719 [ts=23719000ssb, mod=7 level=0] oc_buffer_tx: <unkwn>
Am 21.06.2018 um 23:24 schrieb marko kiiskila:
Indeed, the address is the address of the board. I assumed you were
using simulator, as your newtmgr target specified 127.0.0.1as the address?
To get more output on the firmware console, you can turn on OC_DEBUG,
OC_LOGGING,
and set LOG_LEVEL to 0. Also do the log_register() with oic_log, similar to
what slinky_oic does.
This should make the OIC logs appear in the console; you can verify this with
serial.
On Jun 21, 2018, at 2:07 PM, Jan Clement <[email protected]> wrote:
Hello Marko,
OC_TRANSPORT_IP and OC_TRANSPORT_IPV4 are both set.
The ip-adress should be the one from the board, right? I always get a timeout.
Is there a way to activate some kind of verbose output?
I start the service by calling
oc_main_init((oc_handler_t *)&omgr_oc_handler);
as in the slinky_oic app, which also does not connect.
any ideas?
Regards,
jan
Am 21.06.2018 um 22:14 schrieb marko kiiskila:
On Jun 21, 2018, at 10:59 AM, marko kiiskila <[email protected]> wrote:
On Jun 21, 2018, at 2:19 AM, Jan Clement <[email protected]> wrote:
Hello you All,
at the moment I am stuck at connecting to the oic server via newtmgr over udp.
the connection works fine with serial but ip is not.
I added a connection with
newtmgr conn add myudp5683 type=oic_udp connstring=[127.0.0.1]:5683
the port number is from the documentation, is it the correct one? And where
could i change it?
Make sure that you have syscfg knobs OC_TRANSPORT_IP and OC_TRANSPORT_IPV4
turned on.
5683 is the right port. There’s a define in
net/oic/src/port/mynewt/ip4_adaptor.c, if you need to change it.
Making it adjustable with syscfg is ok, if you want to create a PR.
BTW, here are profiles I’m using for communicating with the server over
loopback interface.
[marko@IsMyLaptop:~]$ newtmgr conn show v4_lo
Connection profiles:
v4_lo: type=oic_udp, connstring='[127.0.0.1]:5683'
[marko@IsMyLaptop:~]$ newtmgr conn show v6_lo
Connection profiles:
v6_lo: type=oic_udp, connstring='[::1]:5683'
