Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net_app: Static vs DHCPv4 behavior appears to be not as described #5696

Closed
pfalcon opened this issue Jan 16, 2018 · 0 comments
Closed

net_app: Static vs DHCPv4 behavior appears to be not as described #5696

pfalcon opened this issue Jan 16, 2018 · 0 comments
Assignees

Comments

@pfalcon
Copy link
Contributor

pfalcon commented Jan 16, 2018

net_app Kconfig states (https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/app/Kconfig#L191):

config NET_APP_MY_IPV4_GW
	string "My IPv4 gateway"
	help
	  Static gateway to use if not overridden by DHCP. Use empty value to
skip setting static value.

However, it doesn't seem to be have that way. On frdm_k64f configured with:

CONFIG_NET_APP_MY_IPV4_ADDR="192.0.2.1"
CONFIG_NET_APP_MY_IPV4_GW="192.0.2.2"
CONFIG_NET_DHCPV4=y

I get following with the lack of DHCP:

IPv4 unicast addresses (max 1):
	<none>
IPv4 multicast addresses (max 1):
	<none>
IPv4 gateway : 0.0.0.0
IPv4 netmask : 0.0.0.0
DHCPv4 lease time : 0
DHCPv4 renew time : 0
DHCPv4 server     : 0.0.0.0
DHCPv4 requested  : 0.0.0.0
DHCPv4 state      : selecting
DHCPv4 attempts   : 1

I.e. DHCP forcibly resets addresses on start (or they never configured in the first place).

@jukkar, IMHO, behavior as described in Kconfig is useful, and I would go to investigate how to (re)establish it - unless you have arguments why it shouldn't be done.

pfalcon added a commit to pfalcon/zephyr that referenced this issue Jan 22, 2018
The meaning of this address type is the same as NET_ADDR_MANUAL,
but with a provision that DHCP can override such an address.
It's intended for the usecase when there's a default static
configuration for when DHCP is not available, but DHCP should
override it.

Before going to add another address type, there was an attempt
to repurpose TENTATIVE address state, but it doesn't work as
expected, as indeed, all existing address types/states already
have clearly semantics, and it makes sense to just another
address type to avoid confusion and unexpected behavior.

Fixes: zephyrproject-rtos#5696

Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
@jukkar jukkar closed this as completed in 996c6dd Jan 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants