* add a few rimestats to keep track of sent and received acks
* made a number of configuration options possible to override (ack timing)
* added the logic for sending 802.15.4 link layer ack packets, despite not being able to guarentee the 802.15.4 MAC timing
* increased the number of sequence numbers to keep track of for duplicate filtering
Combined recent changes from darconeous...
- Refactor to decrease minimum code footprint.
- Added `RESOLV_CONF_SUPPORTS_RECORD_EXPIRATION`.
...with a few additional changes to reduce code size.
"Bridge mode" allows devices to more easily send 802.15.4 packets as if
they were a different device. It also turns off any packet filtering
that may be implemented at layer 2. It works by allowing
`PACKETBUF_ADDR_SENDER` to be set earlier in the stack.
This is useful for implementing 6LoWPAN-ethernet bridges.
Enabled via setting `NETSTACK_CONF_BRIDGE_MODE` to 1. Disabled by
default.
This patch updates the DNS resolver to support IPv6 and introduces an
improved API for looking up DNS entries. This patch also adds optional
support for mDNS lookups and responses to the DNS resolver.
Here is a quick summary of the changes:
* Added support for IPv6 lookups.
* DNS queries now honor record expiration.
* Added support for mDNS, compatible with "Bonjour".
* Implemented a new lookup api, `resolv_lookup2()`, which provides
more information about the state of the record(error, expired,
looking-up, etc.).
About mDNS/Bonjour Support
--------------------------
This patch adds basic support for mDNS/Bonjour, which allows you to
refer to the name of a device instead of its IP address. This is
incredibly convenient for IPv6 addresses because they tend to be very
long and difficult to remember. It is especially important for
link-local IPv6 addresses, since not all programs support the '%'
notation for indicating a network interface (required on systems with
more than one network interface to disambiguate).
In other words, instead of typing in this:
* `http://[fe80::58dc:d7ed:a644:628f%en1]/`
You can type this instead:
* `http://contiki.local/`
Huge improvement, no?
The convenience extends beyond that: this mechanism can be used for
nodes to talk to each other based on their human-readable names instead
of their IPv6 addresses. So instead of a switch on
`aaaa::58dc:d7ed:a644:628f` triggering an actuator on
`aaaa::ed26:19c1:4bd2:f95b`, `light-switch.local` can trigger the
actuator on `living-room-lights.local`.
What you need to do to be able to look up `.local` names on your
workstation depends on a few factors:
* Your machine needs to be able to send and receive multicast packets
to and from the LoWPAN. You can do this easily with the Jackdaw
firmware on an RZUSBStick. If you have a border router, you will need
it to bridge the mDNS multicast packets across the border.
* If you are using a Mac, you win. All Apple devices support mDNS
lookups.
* If you are using Windows, you can install Apple's Bonjour for Windows
package. (This may be already installed on your machine if you have
installed iTunes) After you install this you can easily do `.local`
lookups.
* If you are using a Unix machine, you can install Avahi.
The default hostname is set to `contiki.local.`. You can change the
hostname programmatically by calling `resolv_set_hostname()`. You can
change the default hostname by changing `CONTIKI_CONF_DEFAULT_HOSTNAME`.
You may disable mDNS support by setting `RESOLV_CONF_SUPPORTS_MDNS` to
`0`.
---------------------------------
core/net/resolv: `resolv_lookup2()` -> `resolv_lookup()`
Note that this patch should fix several `resolv_lookup()` bugs
that already existed. There were many cases where `resolv_lookup()`
was being called and the IP address ignored, but later code
assumed that the IP address had been fetched... ANYWAY, those
should be fixed now.
---------------------------------
examples/udp-ipv6: Updated client to use MDNS to lookup the server.
Also updated the Cooja regression test simulation.
Modern compilers (especially GCC) ignore the register keyword anyway and the latest cc65 snapshot generates actually larger code with the register keyword at the locations in question.
Either I found and fixed a severe bug in PSOCK_READTO() or I misunderstood something completely. To me PSOCK_READTO() is supposed to return if either the supplied character was read or if the user supplied buffer is exhausted - sor far so good.
However if the latter occurs up to now PSOCK_READTO() was continuing to process characters already read from the network (aka present in the uIP buffer) in order to check if the supplied character was found there and adjust the return value accordingly. But this means that the character processed this way were lost forever for the caller as the next call to PSOCK_READTO() would continue to read past the characters processed this way.
Therefore I removed that character processing altogether. So now if the user supplied buffer is exhausted before the supplied character is found the next call to PSOCK_READTO() starts exactly where previous call left off.
While it may very well be beneficial to have explict uiplib_ip4addrconv() and uiplib_ip6addrconv() available for IPv6 builds I'm having a hard time to see the point in uiplib_ip6addrconv() for IPv4 builds.
Unrelated to the above the dispatching of uiplib_ipaddrconv() to either uiplib_ip4addrconv() or uiplib_ip6addrconv() can be accomplished by the C preprocessor only thus avoiding the size/speed overhead of an additional callframe.
