[Contiki-developers] udp-ipv6
Petar Simeonov
I continue with my ipv6 experiments. This time I decided to test
udp-ipv6 examples with sky platform (server and client).
I did a simulation with cooja and everything worked fine but when I
tried with real nodes had no success. Then I decided to enable DEBUG
option in the file ipv6.c and got the following results:
Server:
----------------
Contiki 2.4 started. Node id is set to 256.
Rime started with address 0.18.116.0.46.207.92.101
MAC 00:12:74:00:2e:cf:5c:65 CSMA CX-MAC, channel check rate 8 Hz, radio
channel 26
Tentative link-local IPv6 address fe80:0000:0000:0000:0212:7400:2ecf:5c65
Starting 'UDP server process'
UDP server started
Server IPv6 addresses: fe80:0000:0000:0000:0212:7400:2ecf:5c65
Created a server connection with remote address
0000:0000:0000:0000:0000:0000:0000:0000 local/remote port 3000/3001
IPv6 packet received from fe80:0000:0000:0000:0212:7400:5c65:3aeb to
ff02:0000:0000:0000:0000:0001:ffcf:5c65
icmp6_input: length 80
Sending packet with length 80 (40)
IPv6 packet received from fe80:0000:0000:0000:0212:7400:5c65:3aeb to
ff02:0000:0000:0000:0000:0001:ffcf:5c65
icmp6_input: length 80
Sending packet with length 80 (40)
client:
------------------
Contiki 2.4 started. Node id is set to 1024.
Rime started with address 0.18.116.0.92.101.58.235
MAC 00:12:74:00:5c:65:3a:eb CSMA CX-MAC, channel check rate 8 Hz, radio
channel 26
Tentative link-local IPv6 address fe80:0000:0000:0000:0212:7400:5c65:3aeb
Starting 'UDP client process'
UDP client process started
Client IPv6 addresses: fe80:0000:0000:0000:0212:7400:5c65:3aeb
Created a connection with the server
fe80:0000:0000:0000:0212:7400:2ecf:5c65 local/remote port 3001/3000
Client sending to: fe80:0000:0000:0000:0212:7400:2ecf:5c65 (msg: Hello
1 from the client)
In udp_send
Sending packet with length 71 (31)
Client sending to: fe80:0000:0000:0000:0212:7400:2ecf:5c65 (msg: Hello
2 from the client)
In udp_send
Sending packet with length 71 (31)
IPv6 packet received from 0000:0000:0000:0000:0000:0000:0000:0000 to
ff02:0000:0000:0000:0000:0001:ffcf:5c65
Dropping packet, not for me
IPv6 packet received from fe80:0000:0000:0000:0212:7400:2ecf:5c65 to
ff02:0000:0000:0000:0000:0000:0000:0002
Dropping packet, not for me
IPv6 packet received from fe80:0000:0000:0000:0212:7400:2ecf:5c65 to
ff02:0000:0000:0000:0000:0000:0000:0002
Dropping packet, not for me
Client sending to: fe80:0000:0000:0000:0212:7400:2ecf:5c65 (msg: Hello
3 from the client)
In udp_send
Sending packet with length 71 (31)
According to cooja simulation in the server after this messages, I
expect to see as shown below but it never happens.
IPv6 packet received from fe80:0000:0000:0000:0212:7400:5c65:3aeb to
fe80:0000:0000:0000:0212:7400:2ecf:5c65
Receiving UDP packet
In udp_send
Server received: 'Hello 1 from the client' from
fe80:0000:0000:0000:0212:7400:5c65:3aeb
Responding with message: Hello from the server! (1)
In udp_send
Sending packet with length 74 (34)
In udp_send
Can someone help me to find where is my problem? How to debug it?
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Contiki-developers mailing list
Contiki-d...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/contiki-developers
Joakim Eriksson
I did an update of the 6lowpan (sicslowpan.h/c) implementation today.
It is now supporting the latest version of the header compression and
I also did fix a bug that caused the IP buffer to be misaligned. This
cause it to fail on real nodes (especially UDP compression) but likely
work (possibly with warnings) in COOJA. Try checking out the latest
files and see if that helps.
(I got completely wrong ports when I tested, and sometimes wrong UDP
packet length).
Best regards,
-- Joakim Eriksson, SICS
Anthony Asterisk
I noticed a problem with the calls to memcpy/memset where the buffer was cast with (void *). I was undecided whether it was an sdcc bug or an code-bug. I resolved the problem by changing the cast to (u8_t *) in my local copy. Do you think this is related to what you found or something different?
a*
Adam Dunkels
Anthony Asterisk wrote:
> I noticed a problem with the calls to memcpy/memset where the buffer was
> cast with (void *). I was undecided whether it was an sdcc bug or an
> code-bug. I resolved the problem by changing the cast to (u8_t *) in my
> local copy. Do you think this is related to what you found or something
> different?
Where were these memcpys?
Thanks,
/adam
--
Adam Dunkels <ad...@sics.se> | +46 70 7731614 | http://www.sics.se/~adam/
Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org
Joakim Eriksson
The problem I had with this was that one of the buffers (uint8_t array)
ended up being allocated at an odd address causing all 16-bits accesses
of the structs (uip structs) to be unaligned which caused the node to
reboot. So it might not have been the same problem?!
Did you notice any difference after my last commit (the hc-06)?
Best regards
-- Joakim
Adam Dunkels skrev 2010-02-26 22:55:
> Hi Anthony,
>
> Anthony Asterisk wrote:
>> I noticed a problem with the calls to memcpy/memset where the buffer was
>> cast with (void *). I was undecided whether it was an sdcc bug or an
>> code-bug. I resolved the problem by changing the cast to (u8_t *) in my
>> local copy. Do you think this is related to what you found or something
>> different?
>
> Where were these memcpys?
>
> Thanks,
>
> /adam
Petar Simeonov
After I updated my nodes with the last contiki the UDP client-server
examples work very well.
Petar
