Re: [riot-devel] Compile-time peripheral configuration in board definitions
Hi Joakim,
many thanks for your comprehensive answer.
> First, let's clear up one thing regarding the current
> implementation: The static const structs defined in periph_conf.h are
> garbage collected in all modules where they are not directly used, so
> usually, this means that it will only use ROM once (in the .rodata
> section of the appropriate periph driver object). You can see this in
> the .map file in the bin dir after building, there should only be one
> reference to each configuration struct.
Yes, that's what I meant when I said "Each object file would have an
own copy of this static variable if it is used." I should have added
"and only if it is used" to clarify that.
> I don't know if using the _NUMOF macro constitutes as usage with
> regards to linker GC, if the compiler is smart then the struct itself
> should not be allocated when you only use sizeof(pwm_conf) but never
> reference pwm_conf itself.
I would guess that the `sizeof(array/array[0])` can be determined during
compile time and the structure is not allocated.
> Putting the configuration struct in the periph driver implementation
> file is equivalent to putting it in the header from the compiler
> point of view when building the periph driver, so it should be
> possible to perform the same optimizations as when the configuration
> is in periph_conf.h, which is good.
Provided that it is used in periph module only.
> Putting the configuration in the periph driver implementation will
> place the configuration inside the CPU, which is bad for flexibility
> and configurability.
>
> Unless you also define an initializer macro somewhere in the board
> config, e.g. periph_conf.h, which is a bit more inconvenient than the
> current approach due to multi line macros needing to escape newlines
> etc.
You are right, but there should be only configurable parts exposed in
header file. For example, for the ESP32 PWM, configuration details such
as the periphery module used, the register set used, the signal group
used, or the interrupt source used must not be changed by board
definition and should not be exposed to the header file. In case of
ESP32 PWM, only the pins used as PWM channels are configurable which is
exposed as a simple list of GPIO pins.
My impression is, if I'm not wrong, that some MCUs expose not only
configuration details but also implementation details in their `*_conf`
structs.
> One possible alternative solution is to create a periph_conf.c file
> in the board directory, and use extern declarations in periph_conf.h
> just like you proposed in order to let the drivers access the
It was not a proposal but just a description how it is realized for
ESP32 boards at the moment. I'm just looking for some advise on whether
to change to the usual approach used in RIOT for other boards.
> structs. The drawback here is that the compiler will not be able to
> optimize away execution paths which are not reachable using the
> current configuration. On some implementations this will make no
> difference but on others this will make the code a lot larger due to
> multiple large branches which would normally be optimized away due
> to dead code elimination in the compiler.
In the case of ESP32, if I place the static arrays of PWM pins in the
header file instead of defining them as macros, the code gets a bit larger.
> XFA would also have the same drawback as the periph_conf.c solution,
> because the whole array is not visible to the compiler during
> compilation of periph/abcd.c, so it can't fully perform DCE and other
> optimizations.
Ah ok, I understand.
To summarize your e-mail, you would advise to change the definitions of
ESP32 boards to expose configuration structures in header files
according to the RIOT approach for board definitions.
Regards
Gunar
> Best regards, Joakim
>
> On Mon, Dec 17, 2018 at 4:14 PM Gunar Schorcht
> wrote:
>>
>> Hi,
>>
>> I'm thinking about to revise the ESP32 board definitions and would
>> need an advice from experienced core developers.
>>
>> Most (if not all) boards define their peripheral configuration of
>> ADCs, DACs and PWMs in `periph_conf.h` in a kind of static const
>> arrays and define macros based on the size of these arrays as
>> follows:
>>
>> ``` static const pwm_conf_t pwm_conf[] = { { .dev = MINI_TIMER0,
>> .pin_ch = PWM_PINS_CH0, .div = MINI_TIMER0_DIV, }, { .dev =
>> MINI_TIMER2, .pin_ch = PWM_PINS_CH1, .div = MINI_TIMER2_DIV, } };
>> #define PWM_NUMOF (sizeof(pwm_conf) / sizeof(pwm_conf[0])) ```
>>
>> Even though these static const arrays are allocated in the .rodata
>> segment, they are allocated in each module that includes `board.h`.
>> XFAs addresses this problem.
>>
>> For ESP32-Boards I tried another approach. In `periph_conf.h` there
>> is only a declaration of an external const variable `pwm_dev_num`
>> which contains the number of PWM devices and the macro `PWM_NUMOF`
>> is then defined as follows:
>>
>> ``` extern const unsigned
Re: [riot-devel] Compile-time peripheral configuration in board definitions
Hi Gunar,
I have experimented with something similar, moving the configurations
to a .c file instead of periph_conf.h, but I came to the conclusion
that there are a number of drawbacks to the various alternatives.
First, let's clear up one thing regarding the current implementation:
The static const structs defined in periph_conf.h are garbage
collected in all modules where they are not directly used, so usually,
this means that it will only use ROM once (in the .rodata section of
the appropriate periph driver object). You can see this in the .map
file in the bin dir after building, there should only be one reference
to each configuration struct.
I don't know if using the _NUMOF macro constitutes as usage with
regards to linker GC, if the compiler is smart then the struct itself
should not be allocated when you only use sizeof(pwm_conf) but never
reference pwm_conf itself.
Putting the configuration struct in the periph driver implementation
file is equivalent to putting it in the header from the compiler point
of view when building the periph driver, so it should be possible to
perform the same optimizations as when the configuration is in
periph_conf.h, which is good.
Putting the configuration in the periph driver implementation will
place the configuration inside the CPU, which is bad for flexibility
and configurability. Unless you also define an initializer macro
somewhere in the board config, e.g. periph_conf.h, which is a bit more
inconvenient than the current approach due to multi line macros
needing to escape newlines etc.
One possible alternative solution is to create a periph_conf.c file in
the board directory, and use extern declarations in periph_conf.h just
like you proposed in order to let the drivers access the structs. The
drawback here is that the compiler will not be able to optimize away
execution paths which are not reachable using the current
configuration. On some implementations this will make no difference
but on others this will make the code a lot larger due to multiple
large branches which would normally be optimized away due to dead code
elimination in the compiler.
XFA would also have the same drawback as the periph_conf.c solution,
because the whole array is not visible to the compiler during
compilation of periph/abcd.c, so it can't fully perform DCE and other
optimizations.
Best regards,
Joakim
On Mon, Dec 17, 2018 at 4:14 PM Gunar Schorcht wrote:
>
> Hi,
>
> I'm thinking about to revise the ESP32 board definitions and would need
> an advice from experienced core developers.
>
> Most (if not all) boards define their peripheral configuration of ADCs,
> DACs and PWMs in `periph_conf.h` in a kind of static const arrays and
> define macros based on the size of these arrays as follows:
>
> ```
> static const pwm_conf_t pwm_conf[] = {
> {
> .dev = MINI_TIMER0,
> .pin_ch = PWM_PINS_CH0,
> .div = MINI_TIMER0_DIV,
> },
> {
> .dev = MINI_TIMER2,
> .pin_ch = PWM_PINS_CH1,
> .div = MINI_TIMER2_DIV,
> }
> };
> #define PWM_NUMOF (sizeof(pwm_conf) / sizeof(pwm_conf[0]))
> ```
>
> Even though these static const arrays are allocated in the .rodata
> segment, they are allocated in each module that includes `board.h`. XFAs
> addresses this problem.
>
> For ESP32-Boards I tried another approach. In `periph_conf.h` there is
> only a declaration of an external const variable `pwm_dev_num` which
> contains the number of PWM devices and the macro `PWM_NUMOF` is then
> defined as follows:
>
> ```
> extern const unsigned pwm_dev_num;
> #define PWM_NUMOF (pwm_dev_num)
> ```
>
> That's it. The complex configuration array of PWM is defined as static
> const array in the according .c file. The `prm_dev_num` variable is also
> defined there as usual:
> ```
> const unsigned pwm_dev_num = sizeof(_pwm_hw) / sizeof(_pwm_hw[0]);
> ```
>
> With this apporach, the pretty complex static configuration array
> `_pwm_hw[]` exists only once, the complexity of the configuration is
> hidden and the variable `pwm_dev_num` is also determin at compile time.
>
> The question I have is: should I change the board definitions according
> to the approach used by all other board definitions to be compatible
> with these board definitions, or can I leave them as they are?
>
> What would be your advice?
>
> Regards
> Gunar
>
> --
> Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
> kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Compile-time peripheral configuration in board definitions
Hi Juan, thanks for your answer. > So you are saying that the data gets duploicated in ROM several > times? I did not know that. If that is the case, then it's > definitely a bad thing! Yes, at least for object files where they are used and cannot be optimized. The static storage type limits the scope of a variable to a particular file. If you define such a static variable wihtin a header file, it becomes a static variable definition with limited scope in each .c file that includes this header file. Each object file would have an own copy if this variable if it is used. Regards Gunar -- Dr. Gunar Schorcht Mission Level Design GmbH Langewiesener Strasse 22 98693 Ilmenau schor...@mldesigner.de Sitz der Gesellschaft: Lohmühlenweg 2 99310 Arnstadt Amtsgericht Jena: HRB 111384 Geschäftsführung: Dipl.-Inf. Tino Jungebloud -- Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben kennenlernen willst, dann lauf Marathon. (Emil Zatopek) signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Compile-time peripheral configuration in board definitions
Hi Gunar, Even though these static const arrays are allocated in the .rodata segment, they are allocated in each module that includes `board.h`. XFAs addresses this problem. So you are saying that the data gets duploicated in ROM several times? I did not know that. If that is the case, then it's definitely a bad thing! For ESP32-Boards I tried another approach. In `periph_conf.h` there is only a declaration of an external const variable `pwm_dev_num` which contains the number of PWM devices and the macro `PWM_NUMOF` is then defined as follows: ``` extern const unsigned pwm_dev_num; #define PWM_NUMOF (pwm_dev_num) ``` Regardless of ROM duplication or not, I think you approach is much better and cleaner. Also, you don't bloat the header, and don't have the compiler parse the same definitions several times. I see no reasons to define the array in the header file. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Compile-time peripheral configuration in board definitions
Hi,
I'm thinking about to revise the ESP32 board definitions and would need
an advice from experienced core developers.
Most (if not all) boards define their peripheral configuration of ADCs,
DACs and PWMs in `periph_conf.h` in a kind of static const arrays and
define macros based on the size of these arrays as follows:
```
static const pwm_conf_t pwm_conf[] = {
{
.dev = MINI_TIMER0,
.pin_ch = PWM_PINS_CH0,
.div = MINI_TIMER0_DIV,
},
{
.dev = MINI_TIMER2,
.pin_ch = PWM_PINS_CH1,
.div = MINI_TIMER2_DIV,
}
};
#define PWM_NUMOF (sizeof(pwm_conf) / sizeof(pwm_conf[0]))
```
Even though these static const arrays are allocated in the .rodata
segment, they are allocated in each module that includes `board.h`. XFAs
addresses this problem.
For ESP32-Boards I tried another approach. In `periph_conf.h` there is
only a declaration of an external const variable `pwm_dev_num` which
contains the number of PWM devices and the macro `PWM_NUMOF` is then
defined as follows:
```
extern const unsigned pwm_dev_num;
#define PWM_NUMOF (pwm_dev_num)
```
That's it. The complex configuration array of PWM is defined as static
const array in the according .c file. The `prm_dev_num` variable is also
defined there as usual:
```
const unsigned pwm_dev_num = sizeof(_pwm_hw) / sizeof(_pwm_hw[0]);
```
With this apporach, the pretty complex static configuration array
`_pwm_hw[]` exists only once, the complexity of the configuration is
hidden and the variable `pwm_dev_num` is also determin at compile time.
The question I have is: should I change the board definitions according
to the approach used by all other board definitions to be compatible
with these board definitions, or can I leave them as they are?
What would be your advice?
Regards
Gunar
--
Wenn du laufen willst, lauf eine Meile. Wenn du ein neues Leben
kennenlernen willst, dann lauf Marathon. (Emil Zatopek)
signature.asc
Description: OpenPGP digital signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
Hi Thomas, Am Mo., 17. Dez. 2018 um 11:57 Uhr schrieb Thomas C. Schmidt < t.schm...@haw-hamburg.de>: > Hi Martine, > > On 17/12/2018 11:17, Martine Lenders wrote: > > > at first glance this seems to be indeed a bug. If the prefix > > `2001:db8::/64` is configured for one interface, this should be hint > > enough for the NDP to use that interface to multicast the NS there. I'll > > investigate that. > > > > However, I have to add that RFC 6775 (which applies for the border > > router) makes the neighbor discovery very destination-oriented (so > > typically NS are only send upstream performing address registration with > > the upstream router). So that might also be a legitimate behavior, as > > downstream nodes should usually be registered via Address registration > > with the border router or at least a route should be configured to the > > downstream node with a routing protocol of your choosing ;-). > > > > Yes, but forwarding to the default upstream should be a failure in this > case: The packet would then come back from upstream in a loop. > Yes indeed. Forwarding to the default route is definitely an error. > > Cheers, > Thomas > > > Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt > > mailto:t.schm...@haw-hamburg.de>>: > > > > Hi Joakim, > > > > On 17/12/2018 09:37, Joakim Nohlgård wrote: > > > > > Thank you for your answer. OK I think I understand what you mean, > but > > > is this really the correct behavior? > > > It was certainly unexpected to me to have the packets go out the > > > default route instead of on the interface with the configured > prefix. > > > > > > I will try to elaborate: > > > I have a prefix 2001:db8::/64 configured for the wireless > interface. > > > When I run ping6 2001:db8::1234 from the shell on the RIOT node, I > > > expect the system to first attempt to find 2001:db8::1234 on the > > > interface which has been configured for that prefix, instead of > > > immediately falling back and taking the default route when the > > > destination does not already exist in the NIB neighbor table. > > > > > > > I would expect so, too: This should be the correct routing decision > and > > default routing is wrong. Sorry, I didn't see that in your previous > > mail. > > I'm not sure such fallback makes sense at all, if a specific, > globally > > routable prefix is configured. If 2001:db8::1234 is not reachable via > > 2001:db8::/64, a 'destination unreachable' should be triggered. > > > > Cheers, > >thomas > > > > > On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt > > > mailto:t.schm...@haw-hamburg.de>> > wrote: > > >> > > >> Hi Joakim, > > >> > > >> it appears that you are experimenting with a special case. > > >> > > >> Normally, a sending node decides on the outgoing interface based > > on the > > >> destination IP prefix. If you don't have a more specific routing > > entry, > > >> the default IF is correctly chosen in your case. > > >> > > >> After the interface is selected, the source needs to decide on > the > > >> Layer2 framing. Most link-layer technologies use an addressing > > >> (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In > your > > >> case, you mention SLIP. A serial line interface does not use L2 > > >> addresses and does not need ND. > > >> > > >> Best, > > >>Thomas > > >> > > >> On 17/12/2018 08:59, Joakim Nohlgård wrote: > > >>> Hi developers, > > >>> When using the shell on the gnrc_border_router application > > trying to > > >>> send to an unknown address with its designated prefix, the > > application > > >>> does not send any neighbor solicitations on the wireless > network. > > >>> When I type ping6 2001:db8::1234 I expected that a neighbor > > >>> solicitation query to go out on the interface that has been > > configured > > >>> with the routing destination for 2001:db8::/64, but wireshark > shows > > >>> that nothing is sent on the wireless, but instead the ICMPv6 > > packet is > > >>> sent immediately over the slip/ethos interface, which is > > configured as > > >>> the default route. > > >>> > > >>> Is this behavior correct or is this a routing bug? > > >>> > > >>> Configurations: > > ifconfig > > >>> Iface 6 HWaddr: 02:DA:F1:03:BC:48 > > >>> MTU:1500 HL:64 RTR > > >>> RTR_ADV Source address length: 6 > > >>> Link type: wired > > >>> inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local > > TNT[1] > > >>> inet6 addr: fe80::2 scope: local VAL > > >>> inet6 group: ff02::2 > > >>> inet6 group: ff02::1 > > >>> inet6 group: ff02::1:ff03:bc48 > > >>>
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
Hi Martine, On 17/12/2018 11:17, Martine Lenders wrote: at first glance this seems to be indeed a bug. If the prefix `2001:db8::/64` is configured for one interface, this should be hint enough for the NDP to use that interface to multicast the NS there. I'll investigate that. However, I have to add that RFC 6775 (which applies for the border router) makes the neighbor discovery very destination-oriented (so typically NS are only send upstream performing address registration with the upstream router). So that might also be a legitimate behavior, as downstream nodes should usually be registered via Address registration with the border router or at least a route should be configured to the downstream node with a routing protocol of your choosing ;-). Yes, but forwarding to the default upstream should be a failure in this case: The packet would then come back from upstream in a loop. Cheers, Thomas Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt mailto:t.schm...@haw-hamburg.de>>: Hi Joakim, On 17/12/2018 09:37, Joakim Nohlgård wrote: > Thank you for your answer. OK I think I understand what you mean, but > is this really the correct behavior? > It was certainly unexpected to me to have the packets go out the > default route instead of on the interface with the configured prefix. > > I will try to elaborate: > I have a prefix 2001:db8::/64 configured for the wireless interface. > When I run ping6 2001:db8::1234 from the shell on the RIOT node, I > expect the system to first attempt to find 2001:db8::1234 on the > interface which has been configured for that prefix, instead of > immediately falling back and taking the default route when the > destination does not already exist in the NIB neighbor table. > I would expect so, too: This should be the correct routing decision and default routing is wrong. Sorry, I didn't see that in your previous mail. I'm not sure such fallback makes sense at all, if a specific, globally routable prefix is configured. If 2001:db8::1234 is not reachable via 2001:db8::/64, a 'destination unreachable' should be triggered. Cheers, thomas > On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt > mailto:t.schm...@haw-hamburg.de>> wrote: >> >> Hi Joakim, >> >> it appears that you are experimenting with a special case. >> >> Normally, a sending node decides on the outgoing interface based on the >> destination IP prefix. If you don't have a more specific routing entry, >> the default IF is correctly chosen in your case. >> >> After the interface is selected, the source needs to decide on the >> Layer2 framing. Most link-layer technologies use an addressing >> (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your >> case, you mention SLIP. A serial line interface does not use L2 >> addresses and does not need ND. >> >> Best, >> Thomas >> >> On 17/12/2018 08:59, Joakim Nohlgård wrote: >>> Hi developers, >>> When using the shell on the gnrc_border_router application trying to >>> send to an unknown address with its designated prefix, the application >>> does not send any neighbor solicitations on the wireless network. >>> When I type ping6 2001:db8::1234 I expected that a neighbor >>> solicitation query to go out on the interface that has been configured >>> with the routing destination for 2001:db8::/64, but wireshark shows >>> that nothing is sent on the wireless, but instead the ICMPv6 packet is >>> sent immediately over the slip/ethos interface, which is configured as >>> the default route. >>> >>> Is this behavior correct or is this a routing bug? >>> >>> Configurations: ifconfig >>> Iface 6 HWaddr: 02:DA:F1:03:BC:48 >>> MTU:1500 HL:64 RTR >>> RTR_ADV Source address length: 6 >>> Link type: wired >>> inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local TNT[1] >>> inet6 addr: fe80::2 scope: local VAL >>> inet6 group: ff02::2 >>> inet6 group: ff02::1 >>> inet6 group: ff02::1:ff03:bc48 >>> inet6 group: ff02::1:ff00:2 >>> >>> Iface 7 Channel: 26 Page: 0 NID: 0x23 >>> Long HWaddr: 23:31:53:29:36:B7:6E:5A >>> TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4 >>> ACK_REQ CSMA MTU:1280 HL:64 RTR >>> RTR_ADV IPHC >>> Source address length: 8 >>> Link type: wireless >>> inet6 addr: fe80::2131:5329:36b7:6e5a scope: local VAL >>> inet6 addr: 2001:db8::2131:5329:36b7:6e5a scope:
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
Hi, at first glance this seems to be indeed a bug. If the prefix `2001:db8::/64` is configured for one interface, this should be hint enough for the NDP to use that interface to multicast the NS there. I'll investigate that. However, I have to add that RFC 6775 (which applies for the border router) makes the neighbor discovery very destination-oriented (so typically NS are only send upstream performing address registration with the upstream router). So that might also be a legitimate behavior, as downstream nodes should usually be registered via Address registration with the border router or at least a route should be configured to the downstream node with a routing protocol of your choosing ;-). Best regards, Martine Am Mo., 17. Dez. 2018 um 10:13 Uhr schrieb Thomas C. Schmidt < t.schm...@haw-hamburg.de>: > Hi Joakim, > > On 17/12/2018 09:37, Joakim Nohlgård wrote: > > > Thank you for your answer. OK I think I understand what you mean, but > > is this really the correct behavior? > > It was certainly unexpected to me to have the packets go out the > > default route instead of on the interface with the configured prefix. > > > > I will try to elaborate: > > I have a prefix 2001:db8::/64 configured for the wireless interface. > > When I run ping6 2001:db8::1234 from the shell on the RIOT node, I > > expect the system to first attempt to find 2001:db8::1234 on the > > interface which has been configured for that prefix, instead of > > immediately falling back and taking the default route when the > > destination does not already exist in the NIB neighbor table. > > > > I would expect so, too: This should be the correct routing decision and > default routing is wrong. Sorry, I didn't see that in your previous mail. > I'm not sure such fallback makes sense at all, if a specific, globally > routable prefix is configured. If 2001:db8::1234 is not reachable via > 2001:db8::/64, a 'destination unreachable' should be triggered. > > Cheers, > thomas > > > On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt > > wrote: > >> > >> Hi Joakim, > >> > >> it appears that you are experimenting with a special case. > >> > >> Normally, a sending node decides on the outgoing interface based on the > >> destination IP prefix. If you don't have a more specific routing entry, > >> the default IF is correctly chosen in your case. > >> > >> After the interface is selected, the source needs to decide on the > >> Layer2 framing. Most link-layer technologies use an addressing > >> (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your > >> case, you mention SLIP. A serial line interface does not use L2 > >> addresses and does not need ND. > >> > >> Best, > >>Thomas > >> > >> On 17/12/2018 08:59, Joakim Nohlgård wrote: > >>> Hi developers, > >>> When using the shell on the gnrc_border_router application trying to > >>> send to an unknown address with its designated prefix, the application > >>> does not send any neighbor solicitations on the wireless network. > >>> When I type ping6 2001:db8::1234 I expected that a neighbor > >>> solicitation query to go out on the interface that has been configured > >>> with the routing destination for 2001:db8::/64, but wireshark shows > >>> that nothing is sent on the wireless, but instead the ICMPv6 packet is > >>> sent immediately over the slip/ethos interface, which is configured as > >>> the default route. > >>> > >>> Is this behavior correct or is this a routing bug? > >>> > >>> Configurations: > ifconfig > >>> Iface 6 HWaddr: 02:DA:F1:03:BC:48 > >>> MTU:1500 HL:64 RTR > >>> RTR_ADV Source address length: 6 > >>> Link type: wired > >>> inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local TNT[1] > >>> inet6 addr: fe80::2 scope: local VAL > >>> inet6 group: ff02::2 > >>> inet6 group: ff02::1 > >>> inet6 group: ff02::1:ff03:bc48 > >>> inet6 group: ff02::1:ff00:2 > >>> > >>> Iface 7 Channel: 26 Page: 0 NID: 0x23 > >>> Long HWaddr: 23:31:53:29:36:B7:6E:5A > >>> TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA > Retries: 4 > >>> ACK_REQ CSMA MTU:1280 HL:64 RTR > >>> RTR_ADV IPHC > >>> Source address length: 8 > >>> Link type: wireless > >>> inet6 addr: fe80::2131:5329:36b7:6e5a scope: local VAL > >>> inet6 addr: 2001:db8::2131:5329:36b7:6e5a scope: global > VAL > >>> inet6 group: ff02::2 > >>> inet6 group: ff02::1 > >>> inet6 group: ff02::1:ffb7:6e5a > >>> routing: > nib route > >>> 2001:db8::/64 dev #7 > >>> default* via fe80::1 dev #6 > >>> > >>> Best regards, > >>> Joakim > >>> ___ > >>> devel mailing list > >>> devel@riot-os.org > >>> https://lists.riot-os.org/mailman/listinfo/devel > >>> > >> > >> -- > >> > >> Prof. Dr. Thomas C. Schmidt > >> ° Hamburg
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
Hi Joakim, On 17/12/2018 09:37, Joakim Nohlgård wrote: Thank you for your answer. OK I think I understand what you mean, but is this really the correct behavior? It was certainly unexpected to me to have the packets go out the default route instead of on the interface with the configured prefix. I will try to elaborate: I have a prefix 2001:db8::/64 configured for the wireless interface. When I run ping6 2001:db8::1234 from the shell on the RIOT node, I expect the system to first attempt to find 2001:db8::1234 on the interface which has been configured for that prefix, instead of immediately falling back and taking the default route when the destination does not already exist in the NIB neighbor table. I would expect so, too: This should be the correct routing decision and default routing is wrong. Sorry, I didn't see that in your previous mail. I'm not sure such fallback makes sense at all, if a specific, globally routable prefix is configured. If 2001:db8::1234 is not reachable via 2001:db8::/64, a 'destination unreachable' should be triggered. Cheers, thomas On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt wrote: Hi Joakim, it appears that you are experimenting with a special case. Normally, a sending node decides on the outgoing interface based on the destination IP prefix. If you don't have a more specific routing entry, the default IF is correctly chosen in your case. After the interface is selected, the source needs to decide on the Layer2 framing. Most link-layer technologies use an addressing (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your case, you mention SLIP. A serial line interface does not use L2 addresses and does not need ND. Best, Thomas On 17/12/2018 08:59, Joakim Nohlgård wrote: Hi developers, When using the shell on the gnrc_border_router application trying to send to an unknown address with its designated prefix, the application does not send any neighbor solicitations on the wireless network. When I type ping6 2001:db8::1234 I expected that a neighbor solicitation query to go out on the interface that has been configured with the routing destination for 2001:db8::/64, but wireshark shows that nothing is sent on the wireless, but instead the ICMPv6 packet is sent immediately over the slip/ethos interface, which is configured as the default route. Is this behavior correct or is this a routing bug? Configurations: ifconfig Iface 6 HWaddr: 02:DA:F1:03:BC:48 MTU:1500 HL:64 RTR RTR_ADV Source address length: 6 Link type: wired inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local TNT[1] inet6 addr: fe80::2 scope: local VAL inet6 group: ff02::2 inet6 group: ff02::1 inet6 group: ff02::1:ff03:bc48 inet6 group: ff02::1:ff00:2 Iface 7 Channel: 26 Page: 0 NID: 0x23 Long HWaddr: 23:31:53:29:36:B7:6E:5A TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4 ACK_REQ CSMA MTU:1280 HL:64 RTR RTR_ADV IPHC Source address length: 8 Link type: wireless inet6 addr: fe80::2131:5329:36b7:6e5a scope: local VAL inet6 addr: 2001:db8::2131:5329:36b7:6e5a scope: global VAL inet6 group: ff02::2 inet6 group: ff02::1 inet6 group: ff02::1:ffb7:6e5a routing: nib route 2001:db8::/64 dev #7 default* via fe80::1 dev #6 Best regards, Joakim ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
Hi Thomas, Thank you for your answer. OK I think I understand what you mean, but is this really the correct behavior? It was certainly unexpected to me to have the packets go out the default route instead of on the interface with the configured prefix. I will try to elaborate: I have a prefix 2001:db8::/64 configured for the wireless interface. When I run ping6 2001:db8::1234 from the shell on the RIOT node, I expect the system to first attempt to find 2001:db8::1234 on the interface which has been configured for that prefix, instead of immediately falling back and taking the default route when the destination does not already exist in the NIB neighbor table. /Joakim On Mon, Dec 17, 2018 at 9:11 AM Thomas C. Schmidt wrote: > > Hi Joakim, > > it appears that you are experimenting with a special case. > > Normally, a sending node decides on the outgoing interface based on the > destination IP prefix. If you don't have a more specific routing entry, > the default IF is correctly chosen in your case. > > After the interface is selected, the source needs to decide on the > Layer2 framing. Most link-layer technologies use an addressing > (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your > case, you mention SLIP. A serial line interface does not use L2 > addresses and does not need ND. > > Best, > Thomas > > On 17/12/2018 08:59, Joakim Nohlgård wrote: > > Hi developers, > > When using the shell on the gnrc_border_router application trying to > > send to an unknown address with its designated prefix, the application > > does not send any neighbor solicitations on the wireless network. > > When I type ping6 2001:db8::1234 I expected that a neighbor > > solicitation query to go out on the interface that has been configured > > with the routing destination for 2001:db8::/64, but wireshark shows > > that nothing is sent on the wireless, but instead the ICMPv6 packet is > > sent immediately over the slip/ethos interface, which is configured as > > the default route. > > > > Is this behavior correct or is this a routing bug? > > > > Configurations: > >> ifconfig > > Iface 6 HWaddr: 02:DA:F1:03:BC:48 > >MTU:1500 HL:64 RTR > >RTR_ADV Source address length: 6 > >Link type: wired > >inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local TNT[1] > >inet6 addr: fe80::2 scope: local VAL > >inet6 group: ff02::2 > >inet6 group: ff02::1 > >inet6 group: ff02::1:ff03:bc48 > >inet6 group: ff02::1:ff00:2 > > > > Iface 7 Channel: 26 Page: 0 NID: 0x23 > >Long HWaddr: 23:31:53:29:36:B7:6E:5A > > TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4 > >ACK_REQ CSMA MTU:1280 HL:64 RTR > >RTR_ADV IPHC > >Source address length: 8 > >Link type: wireless > >inet6 addr: fe80::2131:5329:36b7:6e5a scope: local VAL > >inet6 addr: 2001:db8::2131:5329:36b7:6e5a scope: global VAL > >inet6 group: ff02::2 > >inet6 group: ff02::1 > >inet6 group: ff02::1:ffb7:6e5a > > routing: > >> nib route > > 2001:db8::/64 dev #7 > > default* via fe80::1 dev #6 > > > > Best regards, > > Joakim > > ___ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel > > > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° > ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
Hi Joakim, it appears that you are experimenting with a special case. Normally, a sending node decides on the outgoing interface based on the destination IP prefix. If you don't have a more specific routing entry, the default IF is correctly chosen in your case. After the interface is selected, the source needs to decide on the Layer2 framing. Most link-layer technologies use an addressing (802.3/11, 15.4 ...) and the MAC address is acquired via ND. In your case, you mention SLIP. A serial line interface does not use L2 addresses and does not need ND. Best, Thomas On 17/12/2018 08:59, Joakim Nohlgård wrote: Hi developers, When using the shell on the gnrc_border_router application trying to send to an unknown address with its designated prefix, the application does not send any neighbor solicitations on the wireless network. When I type ping6 2001:db8::1234 I expected that a neighbor solicitation query to go out on the interface that has been configured with the routing destination for 2001:db8::/64, but wireshark shows that nothing is sent on the wireless, but instead the ICMPv6 packet is sent immediately over the slip/ethos interface, which is configured as the default route. Is this behavior correct or is this a routing bug? Configurations: ifconfig Iface 6 HWaddr: 02:DA:F1:03:BC:48 MTU:1500 HL:64 RTR RTR_ADV Source address length: 6 Link type: wired inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local TNT[1] inet6 addr: fe80::2 scope: local VAL inet6 group: ff02::2 inet6 group: ff02::1 inet6 group: ff02::1:ff03:bc48 inet6 group: ff02::1:ff00:2 Iface 7 Channel: 26 Page: 0 NID: 0x23 Long HWaddr: 23:31:53:29:36:B7:6E:5A TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4 ACK_REQ CSMA MTU:1280 HL:64 RTR RTR_ADV IPHC Source address length: 8 Link type: wireless inet6 addr: fe80::2131:5329:36b7:6e5a scope: local VAL inet6 addr: 2001:db8::2131:5329:36b7:6e5a scope: global VAL inet6 group: ff02::2 inet6 group: ff02::1 inet6 group: ff02::1:ffb7:6e5a routing: nib route 2001:db8::/64 dev #7 default* via fe80::1 dev #6 Best regards, Joakim ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Neighbor solicitations (NS) from border router (6lo ND)
Hi developers, When using the shell on the gnrc_border_router application trying to send to an unknown address with its designated prefix, the application does not send any neighbor solicitations on the wireless network. When I type ping6 2001:db8::1234 I expected that a neighbor solicitation query to go out on the interface that has been configured with the routing destination for 2001:db8::/64, but wireshark shows that nothing is sent on the wireless, but instead the ICMPv6 packet is sent immediately over the slip/ethos interface, which is configured as the default route. Is this behavior correct or is this a routing bug? Configurations: > ifconfig Iface 6 HWaddr: 02:DA:F1:03:BC:48 MTU:1500 HL:64 RTR RTR_ADV Source address length: 6 Link type: wired inet6 addr: fe80::da:f1ff:fe03:bc48 scope: local TNT[1] inet6 addr: fe80::2 scope: local VAL inet6 group: ff02::2 inet6 group: ff02::1 inet6 group: ff02::1:ff03:bc48 inet6 group: ff02::1:ff00:2 Iface 7 Channel: 26 Page: 0 NID: 0x23 Long HWaddr: 23:31:53:29:36:B7:6E:5A TX-Power: 0dBm State: IDLE max. Retrans.: 3 CSMA Retries: 4 ACK_REQ CSMA MTU:1280 HL:64 RTR RTR_ADV IPHC Source address length: 8 Link type: wireless inet6 addr: fe80::2131:5329:36b7:6e5a scope: local VAL inet6 addr: 2001:db8::2131:5329:36b7:6e5a scope: global VAL inet6 group: ff02::2 inet6 group: ff02::1 inet6 group: ff02::1:ffb7:6e5a routing: > nib route 2001:db8::/64 dev #7 default* via fe80::1 dev #6 Best regards, Joakim ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
